Масслукинг - Массовый просмотр рассказов Instagram Stories

Функция просмотра рассказов активно использовалась нашими клиентами достаточно давно. Как правило, в совокупности с задачами на массфоловинг (МФ) и масслайкинг (МЛ), что позволяло несколько увеличить лояльность целевой аудитории. Дополнительным плюсом было то, что данная функция не имела никаких лимитов. Лимит ограничивался лишь техническими особенностями реализации этой функции в Instagram, в связи с чем программа могла обходить до 25 тыс. уникальных пользователей в сутки и смотреть сотни тысяч рассказов.

Однако, с недавнего времени появилась возможность просматривать миллионы рассказов в сутки у сотен тысяч уникальных пользователей Instagram. На наш взгляд эта возможность не является уязвимостью, а, скорее, является техническим упущением разработчиков Instagram.

Суть масслукинга состоит в следующем. Аккаунт, на который нужно привлечь аудиторию симулирует просмотр рассказов других пользователей от своего имени - целевой аудитории. Владельцы аккаунтов, видя, что их рассказы кто-то просмотрел, из любопытства открывают список просмотревших и видят аккаунт, с которого был просмотр. Если в этом списке просмотревших продвигаемый аккаунт находится на первых позициях, то велика вероятность, что человек перейдёт на новый профиль из любопытства. Из-за возможности обрабатывать за сутки огромный объём целевой аудитории такие действия могут давать ощутимый приток новых пользователей, потенциальных клиентов и улучшать статистику аккаунта в целом, т.к. Instagram учитывает высокий интерес других пользователей при ранжировании медиа продвигаемого профиля в поисковой выдаче.

ОСНОВНЫЕ МОМЕНТЫ ТЕЗИСНО

I. В SocialKit три способа просмотра рассказов: 1 - последовательный (низкая эффективность, наиболее безопасный), 2 - массовый со сбором базы активности "на лету" (средняя эффективность, средняя безопасность), 3 - массовый по базе активности из внешнего файла (высокая эффективность, потенциально небезопасен).

II. Максимальная эффективность на данный момент составляет 8-10 млн. просмотренных рассказов в сутки с каждого работающего Instagram-аккаунта. Это примерно 3 млн. профилей.

III. С блокировками профилей, которые бы явно были выданы за массовый просмотр рассказов мы не встречались.

ВАЖНО! Вся информация о лимитах приведена в конце статьи в разделе "Актуальная информация о лимитах".

КЕЙС 1: ПОСЛЕДОВАТЕЛЬНЫЙ ПРОСМОТР РАССКАЗОВ (БЕЗОПАСНЫЙ АЛГОРИТМ)

Безопасный алгоритм просмотра рассказов состоит в том, что программа максимально подстраивается под действия живого человека, обрабатывая при этом профили линейно, а не массово. При анализе такой активности нельзя уверенно сказать, автоматизированно просматривались рассказы или вручную, но очень усердно. Обычно такой способ просмотра рассказов применяется в составных задачах, например, вместе с подписками и/или вместе с расстановкой лайков, но тогда число обработанных рассказов будет лимитироваться заданным количеством основных действий.

Можно настроить задачу только лишь на просмотр рассказов, сильно увеличив объём действий, но делать это безопасным образом. Верхняя предельная граница для количества анализируемых профилей при этом будет составлять ~25 тыс. профилей. Это примерно по одному профилю в 3-4 секунды.

Для запуска такой задачи вам достаточно выбрать один или несколько нужных аккаунтов в главном окне и нажать кнопку "Указать задачу", а после открытия основного рабочего окна перейти на закладку "Лайки (+Просмотры)".

Выбор списка и настройка основных параметров задачи.

Далее нужно выбрать файл со списком профилей (подойдут списки в формате ID или ID:LOGIN), указать минимальные тайм-ауты, обнулить количество лайков и выставить желаемое количество просмотров.

По аналогии с другими задачами вы можете активировать автооудаление из списка тех профилей, что были обработаны программой. Для этого установите отметку в поле "Удалять из списка тех, чьи рассказы просмотрены" и в поле "Автосохранение списка". При массовой работе данные опции будут неактивны.

Отключение перерывов для максимально быстрой работы.

Убедитесь также, что в настройках задачи отключены дополнительные перерывы - это будет актуально и для массового просмотра рассказов по списку профилей или по базе активности в кейсах ниже.

Отключение различных дополнительных алгоритмов, т.к. просмотры рассказов никак не лимитируются.

В технических настройках тоже желательно отключить всё, что может сказываться на производительности задачи. Данные опции направлены в своём большинстве на рандомизацию активности и на различные усложнения логики работы задачи, что важно при выполнении лимитируемых Instagram'ом действий, таких как, например, подписки и расстановка лайков. Просмотр рассказов пока не лимитируется Instagram'ом никак.

Настройка аппаратной нагрузки при работе с большими списками.

На подзакладке "Служебные" рекомендуем установить отметку в поле "Приоритет HDD", чтобы снизить потребление ОЗУ при работе с большими списками, если рабочее место, где запущена программа не имеет ограничений на число дисковых операций (такие ограничения иногда выдают VDS-провайдеры).

Блок с различными фильтрами, которые могут быть применены в реальном времени во время работы задачи.

На подзакладке "Фильтр" вы можете настроить фильтрацию списка "на лету", непосредственно во время выполнения задачи. Собранную аудиторию лучше всего предварительно фильтровать с помощью комплексного многопоточного фильтра, но многие пользователи для экономии времени используют фильтр "на лету".

Использование игнор-листов, формирование базы активности и базы профилей с рассказами на момент работы.

На подзакладке "Статистика" можно активировать целый ряд дополнительных опций. Первый блок связан с игнор-листами - их три вида. Можно задавать использование базового игнор-листа аккаунта, группового игнор-листа из произвольного внешнего файла, а также задавать игнор-лист для фильтруемых профилей и тоже из произвольного внешнего файла. При массовой установке задачи на группу аккаунтов первый игнор-лист является индивидуальным, а два других - общими. Т.е. при их использовании каждый из работающих Instagram-аккаунтов будет использовать информацию из общего файла, а также добавлять в него новую по мере работы задачи.

Помимо этого в ходе работы задачи вы можете выгружать на диск специальную базу активности, которую можно использовать при работе с другими аккаунтами. Следует лишь помнить, что база активности актуальна не более 24 часов, т.к. после этого времени все незакреплённые рассказы на просматриваемых профилях пропадают.

Также можно выгружать на диск список тех профилей, что имели рассказы в момент работы задачи. Это может быть полезно, если вы предварительно не фильтровали собранную аудиторию на наличие рассказов. В дальнейшем можно будет работать по этой выгруженной базе, не затрачивая время на анализ ненужных профилей.

КЕЙС 2: МАССОВЫЙ ПРОСМОТР РАССКАЗОВ ПО СПИСКУ ПРОФИЛЕЙ

Это самый простой в настройке и использовании режим массового просмотра Stories. Отличие этого режима от описанного выше состоит в том, что профили из списка анализируются массово. Этот алгоритм не рекомендуется нами по умолчанию лишь потому, что в теории сотрудники Instagram будут иметь возможность с лёгкостью выявить профили, использовавшие этот алгоритм, если, конечно, они захотят это сделать. При использовании официальной версии Instagram-клиента живой человек физически не может просматривать рассказы миллионов пользователей в день, т.к. это предполагает заход в сотни профилей и просмотр тысяч рассказов в течение 1-2 секунд.

Тем не менее, этот способ привлечения внимания очень популярен сейчас, т.к. позволяет получать живой интерес тысяч пользователей к вашему профилю ежедневно, а также органический прирост активной аудитории. За всё время существования данной возможности с момента её первого появления не было случаев, указывающих на блокировку аккаунтов именно за массовый просмотр рассказов. Однако, этот момент следует учитывать и не подвергать ценные профили излишней опасности. На наш взгляд, лучше создать аккаунты-сателлиты и от их имени выполнять подобные действия, перенаправляя трафик на свой основной аккаунт.

Настройка задачи на массовый просмотр рассказов с формированием базы активности "на лету".

Как и в первом кейсе нужно выбрать список с целями, а после установить отметку в поле "Массовый просмотр Stories со сбором базы активности "на лету"". После установки флага в этом поле программа сообщит, что все настройки будут приведены в соответствие с этим необычным режимом работы. Если они для вас важны, например, используются во время запуска задачи на расстановку лайков, то вы можете сохранить их в шаблоны.

На этом настройка задачи завершена и можно нажимать кнопку "Добавить задание в очередь".

Если вы хотите, чтобы работа по списку велась с зацикливанием, то установите в поле "Число циклов" нужное их количество - задача на массовый просмотр рассказов может работать неделями без какого-либо вмешательства. Изредка Instagram сбрасывает сессию и требуется повторно инициализировать аккаунт. Тогда задачу можно остановить, повторно инициализировать аккаунт, а затем возобновить её из главного окна, как показано ниже

Возобновление остановленной задачи на массовый просмотр рассказов Instagram Stories.

ВАЖНО! Задача на последовательный и массовый просмотр рассказов может выполняться с любых быстрых приватных прокси. Идеально для этого подходят наши IPv6 и IPv4 прокси SocProxy. Аккаунты с прокси нужно связывать исключительно в соотношении 1к1. В противном случае IP-адреса будут получать временные блокировки за превышение допустимого числа запросов в единицу времени. Если у вас всего один Instagram-аккаунт, то можно обойтись без прокси, но учтите при этом, что никакие другие программы с вашего IP-адреса не должны активно работать с Instagram. Иначе аккаунт в ходе работы будет сталкиваться всё с теми же блокировками за превышение допустимого числа запросов в единицу времени. Мобильные прокси лучше не использовать для данного типа задачи в принципе, т.к. все они уступают по производительности быстрым IPv6 / IPv4 и при этом для них, как правило, настраиваются реконнекты для смены оконцовочного IP, что будет очень сильно затормаживать массовый просмотр.

Производительность данного способа работы составляет примерно 60-150 тыс. обрабатываемых профилей в час. Столь сильный разброс зависит от целого ряда критериев, среди которых: число доступных для просмотра рассказов у каждого анализируемого профиля, скорость ответа серверов Instagram, производительность прокси и в целом Интернет-соединения по умолчанию, производительность ПК. Соответственно, число по факту просмотренных рассказов будет зависеть от того, сколько среди проанализированных доноров было найдено профилей со свежими рассказами. Если база доноров в целом достаточно активная, то соотношение профилей со свежими рассказами к профилям без них составляет примерно 1к2. Рассказы чаще всего публикуются в количестве нескольких штук. Среднее арифметическое тут будет 3-5 рассказов на каждый активный профиль. Таким образом, примерная производительность в сутки - 1-1.5 млн. доноров, среди которых 500-800 тыс. профилей со свежими рассказами с общим числом рассказов 2-4 млн.

UPDATE 21.06.19: На данный момент Instagram искусственно занижает скорость ответа своих серверов при выполнении запросов, непосредственно связанных с масслукингом. Потому производительность функции масслукинга при таком подходе может быть раза в 2-3 ниже заявленной. Instagram регулирует эту нагрузку в реальном времени на своей стороне, не выдавая никаких предупреждений. Если запросы от клиента поступают в слишком большом количестве, то выдаётся временное ограничение, более известное как "rate limit" - о нём есть информация в следующем кейсе. Таким образом, для получения максимальной производительности мы рекомендуем использовать "Кейс 3".

Преимущество такого подхода в том, что для работы нужно минимум ресурсов. Даже наличие прокси не является необходимостью, если вы собираетесь продвигать таким образом лишь 1 Instagram-аккаунт.

Однако, это далеко не предел. В SocialKit есть уникальный алгоритм просмотра рассказов по базе активности, который позволяет смотреть от имени каждого продвигаемого аккаунта миллионы рассказов в сутки. Всё, что нужно для работы - это заранее подготовить базу активности.

КЕЙС 3: МАССОВЫЙ ПРОСМОТР РАССКАЗОВ ПО БАЗЕ АКТИВНОСТИ

База активности - это специальный файл в текстовом формате с готовыми к просмотру рассказами. Т.е. во время работы продвигаемый аккаунт не будет тратить время на анализ аудитории и рассказов, а будет только смотреть их. Важно при этом помнить, что база активности теряет свою актуальность в течение суток, т.к. содержит информацию о свежих рассказах, а они, как известно, пропадают после суток с момента публикации.

Основная задача состоит в том, чтобы подготовить базу активности максимально быстро, проанализировав максимальное количество аудитории. Для этой цели подойдет замечательная функция распределения одной задачи между Instagram-аккаунтами - именно они будут выполнять массовый поиск рассказов по большому списку доноров и сохранять информацию в единый файл на диске. Не трудно догадаться, что работу, которую выполняет 1 аккаунт, 20 аккаунтов выполнят в 20 раз быстрее, если её грамотным образом распределить. 

Для примера рассмотрим использованный ранее список доноров на 650+ тыс. профилей и настроим задачу поиска рассказов Instagram Stories с распределением задачи на 20 технических аккаунтов.

Настройка задачи на формирование базы активности для массового просмотра рассказов оптимальным образом.

Для этого нужно выбрать в главном окне 20 ТА и нажать кнопку "Указать задачу". Далее аналогичным образом выбрать список доноров, установить отметку в поле "Массовый просмотр Stories со сбором базы активности "на лету"", снять отметку в поле "Просматривать рассказы" и снять отметку в поле "Не распределять список профилей между выбранными аккаунтами", чтобы каждый из аккаунтов получил свою порцию на обработку, а не весь список целиком.

Указание файла с базой активности, куда будут сохранять информацию все работающие технические аккаунты.

На подзакладке "Статистика" необходимо указать файл с базой активности, куда будет сохранена информация о рассказах всех профилей. При желании можно выгрузить также список всех профилей, которые на момент анализа содержали эти рассказы.

На этом первый этап завершёна, можно нажимать "Добавить задание в очередь". Если в поле "Кол-во просмотров" стоит слишком большая цифра, то программа сама предложит нужную для равномерного распределения задачи.

Скорость анализа, опять же, как и в предыдущем кейсе будет зависеть от тех же критериев, но в любом случае 20 аккаунтов будут анализировать базу доноров в 20 раз быстрее, 100 аккаунтов - в 100 раз быстрее, если хватит производительности ПК и Интернет-канала.

Результат анализа базы Instagram-аккаунтов с высоким процентом "активных" профилей.

В нашем примере 20 ТА справились с задачей поиска рассказов Instagram Stories в среднем за 22-25 минут. Как отмечалось выше, чем чаще в анализируемых подгруппах попадаются Instagram-аккаунты с рассказами, тем больше объём ответа сервера и тем дольше процесс его получения и последующий анализ.

Для сравнения приводим результат анализа другой базы Instagram-профилей, среди которых было очень мало аккаунтов со свежими рассказами. Как видно из скриншота ниже, время, затраченное на анализ каждой части списка от имени каждого ТА, сопоставимо с временем анализа из примера выше, однако, суммарное количество проанализированных профилей почти в 2 раза больше во втором случае.

Пример анализа альтернативной базы Instagram-аккаунтов с низким числом "полезных" профилей.

Это происходит именно потому, что в каждой анализируемой подгруппе мало аккаунтов со свежими рассказами. Соответственно, ответ от сервера Instagram имеет небольшой объём и его анализ происходит быстрее.

Тем не менее, не так важна скорость, сколь важно число найденных профилей с рассказами. Как раз по этому показателю база из нашего примера оказалась лучше, т.к. за сопоставимое время в первом случае программа зафиксировала гораздо больше рассказов, которые потом можно просмотреть, чем во втором. Это указывает на то, что в идеале базы Instagram-профилей хорошо бы очищать от бесполезных аккаунтов и ботов при помощи комплексного многопоточного фильтра.

На следующем этапе нужно выбрать любое число продвигаемых аккаунтов и указать им эту базу активности.

Выбор базы активности для просмотра рассказов по ней и исходного списка с перечнем доноров.

ВАЖНО! Список доноров, который использовался для создания базы активности выбирать не нужно - так вы сэкономите массу ресурсов для других задач. На скриншоте выше это сделано в качестве наглядной иллюстрации.

Проверьте, перед запуском, соответствует ли значение в поле "Кол-во просмотров" с перечнем доноров из базы (программа сама тоже это проверит). Если да, то больше ничего настраивать не нужно. Задача готова к запуску.

Скорость просмотра рассказов по базе активности без анализа доноров в десятки раз выше, чем в предыдущем кейсе. Именно потому суточная производительность может измеряться для каждого продвигаемого аккаунта десятками миллионов просмотренных рассказов и миллионами профилей.

Результат работы задачи на просмотр рассказов Instagram Stories по базе активности за 5 минут.

Выше пример работы по базе активности. В течение 5 минут аккаунт успел просмотреть рассказы 15 тыс. пользователей, имеющих эти рассказы. Начиная с версии 2.2.14 эффективность работы в этом режиме стала ещё выше.

Спешим заметить, что не следует путать эту цифру с цифрой общих проанализированных профилей, как в первом или втором кейсе, т.к. в базе активности находятся уже готовые к просмотру рассказы доноров.

Из лога видно, сколько, соответственно, за это время проанализировано рассказов.

Лог по целевому аккаунту, выполняющему массовый просмотр рассказов по базе активности.

Простой расчёт показывает, что эффективность такого подхода максимальна, т.к. данный способ позволяет обойти в разы больший объём аудитории за сопоставимое время и требует совсем небольших дополнительных затрат в виде дополнительных технических аккаунтов и быстрых прокси, например, наших IPv6.

ВАЖНО! Учтите, что КПД задачи на массовый просмотр рассказов по базе активности тем выше, чем быстрее с момента начала её сбора вы перейдёте непосредственно к просмотру собранных рассказов от имени ЦА.

ВАЖНО! Выбирая любой из способов для массового просмотра рассказов мы рекомендуем вставлять в список доноров, так называемые, контрольные профили - любые профили с рассказами к которым у вас есть доступ. Это полезно, чтобы иметь чёткую уверенность в том, что рассказы доноров по факту были просмотрены вместе с вашими контрольными профилями. Вставляйте контрольные профили в разные произвольные позиции списка с донорами.

КЕЙС 4: ЕЩЁ ОДИН НАГЛЯДНЫЙ ПРИМЕР РАБОТЫ С БАЗОЙ АКТИВНОСТИ

Рассмотрим ещё один пример эффективной работы по очень большому списку с донорами, размером в ~6 млн. Этот пример полностью аналогичен тому, что рассмотрен выше. Только на этот раз мы возьмём большой список с донорами, который не проходил предварительную фильтрацию в SocialKit.

Запуск задачи на распределённый поиск и сохранение базы активности в файл.

Задачу на сбор базы активности распределим между 50 ТА с настройками, как описывалось выше в предыдущем кейсе. Для контроля можно вставить в произвольные части списка доноров свои профили с рассказами. Это делать не обязательно, но если у Вас есть какие-то сомнения относительно работоспособности массового просмотра рассказов, то такой способ проверки поможет наверняка знать, что программа обрабатывает все профили.

Задача на поиск и сохранения рассказов в базу активности распределена между 50 ТА.

Не забывайте, что от скорости работы прокси и от числа доноров с рассказами в исходной базе будет напрямую зависеть и скорость обработки списка. Список в нашем примере специально взят "сырой", т.е. мы заранее знаем, что в нём будет большое количество бесполезных профилей. В этом случае сбор базы активности особенно актуален, т.к. функция работает и как фильтр по наличию рассказов. Актуальность и полезность этой задачи увеличивается в разы, если вы предполагаете смотреть рассказы не от имени одного целевого аккаунта, а от имени нескольких.

Аппаратная нагрузка, создающаяся при обработке 6 млн. базы доноров от имени 50 ТА.

Стоит сказать несколько слов о нагрузкке. Задачи из данных кейсов запускались на среднестатистическом ПК под управлением Windows 10. Как видно из скриншота, 50 ТА, обрабатывающие базу доноров на 6 млн. создают не слишком высокую нагрузку для ЦП и потребляют достаточно скромный объём оперативной памяти. Напоминаем, что задачи по столь объёмным базам лучше запускать в приоритете аппаратной нагрузки на HDD.

Пример автоматической обработки ограничения, более известного как "rate limit".

Во время работы задачи программа ведёт четкий контроль ошибок, оставляя соответствующие уведомления не только в логе, но и в виде визуальных пометок в главном окне. На скриншоте выше показан пример, когда на определённом рубеже большая часть из 50 ТА столкнулись с временным ограничением на запросы.

Данное ограничение более известно как "rate limit" и происходит оно каждые ~25 тыс. профилей. Длится пару-тройку минут, после чего обработка продолжается до следующего "рубежа", как правило, без вынужденных пауз.

Не стоит путать это ограничение со спам-блокировками. В данном случае Instagram просто ограничивает свои сервера от отправки им от имени каждого аккаунта слишком большого числа запросов. Это ограничение может длится от несколько секунд до нескольких минут. Программа автоматически выждет нужное время и продолжит работу.

Обращайте также внимание на то, нет остановились ли какие-либо аккаунты преждевременно - они будет помечены в списке аналогичным образом а в колонке "Состояние" будет запись "Завершено".

Задача отменена, т.к. сессия устарела. После обновления аккаунта задачу можно возобновить с того же места.

Вынужденная остановка может быть обусловлена лишь тремя причинами: 1 - запросом на верификацию, 2 - сбросом сессии, 3 - огромным числом пустых профилей. Рассмотрим их подробнее.

В первых двух случаях для "проблемного" Instagram-аккаунта нужно выполнить повторную инициализацию, а затем возобновить задачу через пункт "Возобновить" в главном окне программы (см. скриншот из "Кейса 2").

Если этого не сделать, то рассказы соответствующей группы профилей не попадут в базу активности и, соответственно, не будут просмотрены на следующем этапе. Если вы используете свои контрольные профили с рассказами, то не забывайте учитывать этот момент, т.к. представители контрольной группы могут также оказаться среди перечня доноров, анализ которых приостановился по описанной выше причине.

В третьем случае следует увеличить порог срабатывания контроллера пустых ответов, но возобновить задачу по одному или нескольким аккаунтам, что столкнулись с такой проблемой уже не получится. Потому об этом нужно думать заранее, объективно оценивая состояние базы.

Настройка порога срабатывания контроллера пустых ответов.

Если база доноров содержит десятки тысяч профилей без рассказов подряд, то нужно увеличить данный порог. Значение "50" соответствует 5-6 тысячам профилей без рассказов подряд. Исходя из этого, вы можете поставить любое другое значение или перемешать базу доноров.

В базе доноров из нашего примера в ходе работы обнаружился один участок, где была группа из нескольких тысяч ботов (разумеется, без рассказов) подряд. Эта группа оказалась в составе 25го аккаунта и потому он остановился чуть раньше, т.к. порог срабатывания контроллера соответствовал значению по умолчанию - 50. Все остальные аккаунты обработали полный переданный объём.

50 ТА обработали базу "сырых" доноров примерно за час.

Как видно из скриншота, время, затраченное на обработку 6 млн. доноров составляет приблизительно час. Какие-то аккаунты справились с задачей чуть быстрее, какие-то чуть медленнее. В общей сложности получилось собрать более 500 тыс. активных профилей с ~2 миллионами рассказов - это станет понятно в ходе работы.

Как и предполагалось, список доноров содержал большое количество мусорных профилей, не отфильтровав которые программа бы выполняла масслукинг, имея фактический КПД не выше 10%. Работая по базе активности КПД будет стремиться к 100%. Всё будет зависеть лишь от того, как много времени прошло с момента первого найденного рассказа. Старайтесь организовать работу так, чтобы проходило не более часа.

На данном этапе уже можно проверить, зафиксировала ли программа в базе рассказы ваших контрольных профилей, если вы их использовали согласно тем рекомендациям, что мы давали выше. Если соответствующие рассказы по какой-то причине не попали в базу активности, то и просмотрены они не будут.

Запуск задачи на массовый просмотр рассказов по базе активности.

На следующем этапе запускаем просмотр, по собранной базе активности. Устанавливаем приоритет аппаратной нагрузки на HDD, если это не так, и минимальные тайм-ауты. Исходную базу доноров загружать не нужно.

Если вы не знаете, какой объём профилей в базе активности - не страшно. Ставьте любое большое число или маленькое - программа предложит скорректировать его автоматически.

Основная статистика по задаче на массовый просмотр рассказов по базе активности.

Как видно из скриншота, эффективность работы по базе активности огромна, особенно учитывая высокий процент КПД, т.к. в базе изначально нет "пустых" профилей - профилей без рассказов.

Лог по целевому аккаунту, выполняющему масслукинг, с промежуточными результатами работы.

За час целевой аккаунт просмотрел ~900 тыс. рассказы ~260 тыс. человек - промежуточные данные всегда есть в логе.

Не трудно рассчитать, что вся собранная база активности будет обработана примерно за 2 часа, а общее число просмотренных рассказов будет составлять около 2 млн.

Исходя из этой пропорции, при наличии более обширной базы активности число просмотренных профилей составляло бы ~6 млн., а просмотренных рассказов - 25 млн., но недавно Instagram начал ограничивать суточную активность на использование данной функции.

UPDATE 21.06.19: Во-первых, Instagram может занижать скорость ответа своих серверов при работе  с данной функцией. В некоторых случаях Instagram применяет, так называемое, прогрессивное занижение производительности. Т.е. чем чаще профиль использует функцию массового просмотра в течение суток, тем медленнее может отвечать сервер Instagram и тем ниже будет эффективность. При этом в логе не будет никаких ошибок. Во-вторых, возможно исчерпание лимита (ошибка "rate limit") - об этом в отдельном разделе в конце статьи.

Максимально преимущество работы с предварительно собранной базой активности ощущается, когда масслукингом занимается не один целевой аккаунт, а группа. КПД при этом в сравнении с "Кейсом 2" возрастает на порядки, т.к. каждый из целевых аккаунтов не занимается анализом доноров, а только массово просматривает рассказы.

Пример эффективной работы группы аккаунтов по одной базе активности.

Выше показан пример работы группы из 15 Instagram-аккаунтов по базе активности, собранной в данном кейсе.

Не забывайте о том, что в случае вынужденных остановок работы по внешним причинам, например, в результате аварийного завершения работы ПК, вы всегда можете возобновить задачу с места последней остановки через кнопку "Возобновить" на панели инструментов в главном окне программы (см. скриншот в "Кейсе 2").

Также не забывайте, что вы можете контролировать работу при помощи своих личных профилей с рассказами, если вы ранее вставляли их в список с донорами. Это позволит вам знать наверняка, что все просмотры были засчитаны.

АКТУАЛЬНАЯ ИНФОРМАЦИЯ О ЛИМИТАХ

При использовании "Кейса 2" можно работать на минимальных тайм-аутах. Если в базе доноров слишком много "пустых" профилей, то, возможно, задача будет сталкиваться с коротким видом "rate limit'а", который накладывается на функцию сбора информации о рассказах. Программа будет автоматически принимать все необходимые меры и возьмёт минимально необходимую паузу согласно экспертным настройкам, а после продолжит работу.

При использовании "Кейса 3" и "Кейса 4" в 24 часовом режиме работы может встать вопрос о суточных лимитах непосредственно на функцию просмотра. Проявляется это в виде ошибки "rate limit" в логе. Выглядит это так:

Пример срабатывания ограничения ("rate limit") на функцию просмотра рассказов по базе активности.

Программа "понимает" этот вид ограничения и использует паузы из экспертных настроек (об этом чуть ниже).

При работе на минимальных тайм-аутах в задаче на просмотр по базе активности (1-2 сек. между действиями)  ограничение "rate limit" наступает примерно на 2.7-3 млн. просмотренных рассказов (800-900 тыс. пользователей) спустя 5 часов работы задачи при условии, что от имени искомых аккаунтов не выполнялись просмотры минимум сутки.

При этом суточный предел составляет ~5 млн. просмотренных рассказов и, соответственно, ~1.5 млн. пользователей.

Если вы не собираетесь использовать данную функцию 24 часа в сутки, то можно дойти до лимита на минимальных тайм-аутах, а после переключиться на другие задачи или отработать меньший объём по базе активности.

ВАЖНО! В режиме работы 24/7 рекомендуется использовать тайм-ауты между действиями, исходя из описанных ограничений - до 3400 просмотренных рассказов в минуту. В профилях это число соответствует ~1000 профилей в минуту. Исходя из того, что за один запрос при работе по базе активности программа просматривает ~1150 рассказов, можно сформулировать рекомендованные тайм-ауты между действиями при работе по базе активности из внешнего файла с растяжкой на сутки - они будут составлять 12-24 секунды.

Рекомендованные экспертные настройки для обработки ошибок вида "rate limit" выглядят так:

Экспертные настройки для обработки ошибок вида "rate limit".

Если суточная эффективность при указанных тайм-аутах между действиями будет высокой, то можно попробовать их немного снизить, а приведенные экспертные настройки будут универсальными при работе со всеми кейсами.