Причины банов: как вести базу знаний по заблокированным аккаунтам

Редакция GetAntik · 26 октября 2026 г. · 8 минут чтения

Как фиксировать причины блокировки аккаунтов, искать закономерности и превращать баны в рабочий чек-лист команды, а не разовую головную боль.

Аккаунт заблокировали — обычная реакция команды: расстроиться, списать на «платформа лютует», взять резервный профиль и пойти дальше. Через месяц банят следующий, через два — ещё три за неделю. Если каждый случай живёт только в голове того, кто его заметил, команда наступает на одни и те же грабли годами. Между тем баны — это данные. Если их собирать системно, через 20-30 случаев видны закономерности: какой тип прокси ломает конкретную платформу, с какой скоростью прогрева начинаются блокировки, какие связки ОС/браузер чаще попадают под подозрение. Это превращает мультиаккаунтинг из игры в рулетку в управляемый процесс.

Почему разовый разбор бана ничего не даёт

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

Закономерность видна только на выборке. Нужно минимум 15-20 зафиксированных банов на одной платформе, чтобы отличить случайность от системной проблемы. Поэтому первая задача — не делать правильные выводы сразу, а наладить сбор данных, по которым выводы вообще можно будет делать.

Что фиксировать по каждому бану

Минимальный набор полей, без которого анализ не сложится:

• Платформа и тип аккаунта — не просто «рекламный кабинет», а конкретно Meta Ads / Google Ads / маркетплейс с указанием категории.
• Возраст аккаунта на момент бана — часы, дни, месяцы. Разница между баном на 2-й день и на 90-й говорит о разных причинах.
• Тип и гео прокси — датацентр, резидентный, мобильный; страна и совпадает ли она с заявленной геолокацией аккаунта.
• Связка профиля — ОС, браузер и версия, которые показывал антидетект-браузер на момент бана.
• Скорость и сценарий прогрева — сколько дней грели, какие действия выполняли, не ускоряли ли темп в последние сутки.
• Действие перед баном — что именно делал оператор: смена платёжного метода, массовая рассылка, запуск кампании, смена email.
• Формулировка платформы — точный текст уведомления о блокировке, если он есть. Платформы часто дают намёк на причину даже в шаблонном письме.
• Кто вёл профиль — не для поиска виноватого, а чтобы увидеть, не повторяется ли ошибка у конкретного сотрудника из-за непонятой инструкции.

Семи полей достаточно для старта. Пытаться зафиксировать всё — от User-Agent до порядка кликов — не нужно: такую таблицу никто не будет заполнять после третьего раза.

Где хранить и кто заполняет

Таблицу можно вести где угодно — от Google Sheets до Notion, важно не место, а дисциплина заполнения. Практика, которая реально работает: запись в базу — обязательный шаг в процессе закрытия профиля, а не отдельная задача «когда будет время». Пока сотрудник помнит детали, он тратит на заполнение полторы минуты. Через неделю он уже не вспомнит, был ли там мобильный прокси или резидентный.

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

Отдельный вопрос — кто анализирует накопленные данные. Если это делает каждый сам за себя, закономерности на уровне команды не всплывают: один байер заметил, что мобильные прокси реже ловят баны на одной вертикали, но не поделился с остальными. Разбор раз в две-четыре недели должен делать тимлид или человек с ролью admin — у него есть доступ ко всем профилям команды и мотивация искать системные проблемы, а не точечные.

Паттерны, которые реально стоит искать

Прокси и география. Самая частая находка — несовпадение типа прокси с профилем риска платформы. Банковские и платёжные сервисы жёстче реагируют на датацентровые IP, чем соцсети. Если в базе видно, что 70% банов на одной платформе пришлись на один тип прокси — это не совпадение, это сигнал менять стратегию закупки. Подробнее про выбор момента для смены IP разобрано в материале про ротацию IP для профилей — многие баны случаются не из-за самого прокси, а из-за неудачно выбранного момента его смены.

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

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

Повторяющийся человеческий фактор. Если баны концентрируются у одного сотрудника, вопрос не в его компетентности, а в том, понятна ли ему инструкция. Часто выясняется, что новый человек не в курсе правила «не менять платёжный метод в первые две недели» просто потому, что оно нигде не зафиксировано, кроме памяти тимлида.

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

Частые ошибки при ведении базы

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

Фиксировать только свои баны, не делясь с командой. База ценна только как общий ресурс. Если каждый ведёт личную табличку, корреляции на уровне 5-10 инцидентов одного человека просто не набираются — нужна выборка по всей команде.

Искать одну причину вместо комбинации факторов. Баны редко случаются от одного триггера. Чаще это совпадение двух-трёх условий: новый прокси плюс резкая активность плюс смена платёжных данных. Если в базе фиксировать только «финальную» причину по письму от платформы, реальная картина теряется.

Делать выводы на 2-3 случаях. Соблазн велик — «опять этот прокси, меняем всех на резидентные». Подождите, пока наберётся статистика хотя бы на десяток случаев, иначе решения принимаются на шуме, а не на сигнале.

Хранить причину бана отдельно от резервного плана. Разбор без действия бесполезен. Если база показала, что аккаунты одной категории банятся на 5-7 день из-за слишком быстрого прогрева — это повод обновить план прогрева и держать под рукой готовые резервные аккаунты, подготовленные с учётом новых выводов, а не по старому шаблону.

Как это выглядит в работе с GetAntik

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

Для команд с ролями полезно, что доступ к разбору причин банов не обязан быть у всех — роль admin или finance может смотреть сводную картину по всем профилям, а member работает только со своим пулом. Подробнее о распределении ролей и лимитов — в разделе команда и доступы.

Если команда только выстраивает процесс анализа блокировок, разумно начать с малого: заведите таблицу на 7-8 полей, обязуйте закрывать профиль только после заполнения записи, назначьте человека, который раз в месяц смотрит на накопленные данные. Через квартал у вас будет не ощущение «баны случаются», а конкретный список из 3-4 факторов, которые реально стоит исправить — и это куда дешевле, чем терять аккаунты вслепую. Если антидетект-браузер для команды ещё не настроен, можно начать с бесплатного плана на 3 профиля и попробовать выстроить процесс на небольшом масштабе, прежде чем расширять парк.

FAQ

Сколько времени нужно вести базу, чтобы увидеть первые закономерности? Обычно 4-8 недель активной работы при 5-10 забаненных профилях в неделю. На меньшем масштабе выборка слишком мала для выводов — ждите, не спешите с решениями.

Нужно ли фиксировать баны, причина которых и так очевидна? Да. Даже «очевидные» баны со временем складываются в статистику. То, что кажется случайностью сегодня, через месяц может оказаться системной проблемой — например, одна и та же формулировка от платформы повторяется в 40% случаев.

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

Можно ли автоматизировать сбор части данных? Частично да — если в работе используется журнал действий в профилях, хронологию последних действий и время сессии можно брать оттуда, а не восстанавливать по памяти. Причину и формулировку от платформы всё равно приходится вносить вручную.

Что делать, если платформа не присылает причину бана вообще? Фиксируйте факт и контекст — дату, возраст аккаунта, последние действия, прокси. Даже без формулировки от площадки такие записи позже складываются в статистику по косвенным признакам.

банымультиаккаунтингантидетект-браузеркомандабезопасность