PowerScan
RU

Антидетект-браузеры для SMM: практическая настройка

Мультиаккаунтинг · 9 мин чтения · Автор: PowerOps

Фото: Unsplash

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

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

Структура: пространство, группа, профиль

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

Именованию стоит уделить тридцать секунд политики: клиент, платформа, логин, в таком порядке. Профили пронумерованы и доступны для поиска, поэтому любой может сказать вслух в шумной комнате «открой 41», и коллега точно знает, какая строка имеется в виду.

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

Идентичность и маршрут для каждого профиля

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

  1. Купите sticky-адреса в тех странах, откуда работают аккаунты клиента, по одному на аккаунт.
  2. Добавьте их в библиотеку прокси и проверьте. Проверка показывает наблюдаемый адрес и страну, то есть то, что увидит платформа, что бы ни было написано в счёте.
  3. Назначьте по одному на каждый профиль до первого входа и в тот же заход установите часовой пояс и язык профиля по стране маршрута.
  4. Перепроверяйте библиотеку по расписанию. Endpoint'ы деградируют незаметно, и деградировавший маршрут проявляется проблемами с аккаунтом задолго до ошибки соединения.

Передача доступа без обмена паролями

Агентства постоянно передают аккаунты между людьми. Стажёр планирует публикации, менеджер утверждает, кто-то подменяет на выходных. Традиционный способ — таблица с паролями, и именно так агентства приходят к тому, что аккаунт клиента открыт на ноутбуке, который никто не может найти.

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

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

Онбординг нового клиента шаг за шагом

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

  1. Создайте пространство и группы по платформам до того, как коснётесь какого-либо аккаунта.
  2. Соберите у клиента перечень аккаунтов: логины, платформы, какую страну обслуживает каждый аккаунт и у кого сейчас учётные данные.
  3. Купите и проверьте по одному sticky-маршруту на аккаунт, в нужных странах, и дайте проверке библиотеки подтвердить, что именно пришло.
  4. Создайте профили с именами «клиент, платформа, логин» и назначьте маршруты, часовые пояса и языки за один проход.
  5. Войдите в каждый аккаунт заново внутри его профиля, пока клиент рядом для вторых факторов и писем с подтверждением.
  6. Выдайте команде роли, расскажите о ритме работы с клиентом и закройте тот канал, по которому пришли учётные данные.

Свежие входы — тот шаг, который команды пытаются сократить, импортируя cookie оттуда, где аккаунты жили раньше. Не делайте этого. Импортированная сессия несёт историю машины, с которой пришла, а смысл онбординга в том, чтобы каждая сессия аккаунтов клиента отныне создавалась внутри среды, которая продолжит ею пользоваться.

Автоматизация повторяющихся задач

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

const { profiles } = await api(`/profiles?groupId=${clientInstagramGroup}`);

for (const profile of profiles) {
  const { ws } = await api("/browser/start", { profileId: profile.id });
  try {
    const browser = await chromium.connectOverCDP(ws);
    const context = browser.contexts()[0];
    const page = context.pages()[0] ?? await context.newPage();
    // The profile's identity, storage and route are already attached.
    await collectForReport(profile.name, page);
  } finally {
    await api("/browser/stop", { profileId: profile.id });
  }
}

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

Неделя внутри этой настройки

Что даёт структура, видно в рутине. В понедельник утром команда открывает группу клиента в Instagram и проходит по почте профиль за профилем. Пятничный отчёт собирается через API, пока команда занимается чем-то лучшим во второй половине дня. Офбординг — это архивированное пространство. Ничего из этого не хитро, и в этом суть: задача настройки — сделать так, чтобы проблема среды перестала быть интересной.

О том, держится ли всё, говорят два числа. Первое — как часто кто-то вводит пароль от платформы: оно должно стремиться к нулю после завершения онбординга. Второе — как часто сессия неожиданно требует верификации: это должно быть редко и объясняться причиной, такой как смена маршрута, всплеск необычной активности или слишком быстрое развитие молодого аккаунта. Когда любое из этих чисел растёт, ответ в маршрутах и ритме, а смотреть в первую очередь стоит на то, что изменилось последним.

Правила, прямо

У каждой платформы в этом процессе есть условия об аккаунтах и об автоматизации, и эта настройка не меняет ни одного из них. Изоляция не даёт клиентам заражать друг друга. Роли убирают учётные данные из таблиц. API избавляет от рутины. Ничто из этого не даёт права на запрещённые аккаунты, запрещённую автоматизацию или поведение, которое платформа не допускает, и здесь не обещается никакой результат на платформах, которые мы не контролируем. Агентства, которые держатся долго, считают правила платформ частью работы с клиентом, а инструменты — способом делать эту работу чисто.

Чек-лист настройки

  1. Создайте пространство на клиента и группу на платформу внутри него.
  2. Купите по одному sticky-адресу на аккаунт, в стране работы аккаунта, и проверьте каждый endpoint в библиотеке прокси.
  3. Создайте по профилю на аккаунт с именем «клиент, платформа, логин» и назначьте маршрут до первого входа.
  4. Установите часовой пояс и язык каждого профиля по стране его маршрута.
  5. Выдайте каждому сотруднику роль вместо отправки кому-либо пароля.
  6. Автоматизируйте работу по обходу через локальный API, в темпе, как у человека.
  7. Закрывайте профили в конце каждого прохода.

Все статьи · Запустить проверку