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

Если коротко

Самая частая причина бана - белая страница не похожа на ту, которую модератор ожидал увидеть после клика по объявлению. Второе место - неаккуратная работа с реферером и user-agent: антифрод фейсбука ловит несовпадения буквально за секунды. Дальше идут технические косяки: TTL, edge-кэш и неправильная сегментация по гео.

Ошибка 1. Белая страница не соответствует объявлению

Самое больное. Вы запускаете объявление "Похудение за 30 дней - попробуйте", а модератор видит абстрактную страницу про "финансовую грамотность". Фейсбук смотрит на это и думает: "О, классика", и через 48 часов аккаунт улетает в reject.

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

Что мы наблюдаем

Команды, которые делают белую страницу длиной 800-1500 слов с парой картинок, проходят модерацию в 3-4 раза чаще, чем те, у кого там "Hello world". Модераторы фейсбука листают страницу и смотрят, что там по факту.

Ошибка 2. Реферер и user-agent выдают клоак

Когда модератор фейсбука кликает по вашему объявлению, он приходит с реферером facebook.com и user-agent, который содержит подпись их внутреннего краулера (FB_IAB, FB4A и подобные). Если ваш клоак не умеет это ловить - всё, привет белая.

Обратная история тоже бывает: люди настраивают клоак "показывать оффер только если реферер пустой", и у половины пользователей с iOS 17+ реферер именно пустой по умолчанию (Apple Tracking Prevention). В итоге половина живого трафика видит белую вместо оффера.

Правильно: фильтровать не только по рефереру и UA, но и по совокупности сигналов. У нас, например, fingerprint, поведение и сеть дают score, и решение принимается по score, а не по одному критерию.

Ошибка 3. CDN кэширует и отдаёт всем одно и то же

Классика. Ставите Cloudflare с proxied = true, не настраиваете cache rules - и через 5 минут любой посетитель получает ту страницу, которую Cloudflare закэшировал первой. Если первым пришёл бот фейсбука - все увидят белую. Если живой пользователь - все увидят оффер, включая модератора, который зашёл проверить. Сюрприз.

Что делать: либо отключать proxied на доменах с клоаком, либо явно ставить cache rule "не кэшировать этот path", либо использовать Vary: User-Agent и Cache-Control: private. Любой из вариантов работает, главное проверить курлом: 

curl -I -A "facebookexternalhit/1.1" https://your-domain.com/lp
curl -I -A "Mozilla/5.0 (iPhone; ..." https://your-domain.com/lp

Если в обоих случаях Cloudflare отвечает cf-cache-status: HIT с одинаковым ETag - вы прокачались под кэшированную страницу, и клоак не работает.

Ошибка 4. Слишком грубая гео-фильтрация

"Показываем оффер только из США" - звучит логично. Проблема в том, что модераторы фейсбука сидят в разных гео: Дублин, Манила, Хайдарабад, иногда сам Менло-Парк. Если ваш клоак отрезает всё, кроме US, модератор из Ирландии увидит белую и оценит её как "ну, странновато, но не реклама". Через неделю на ваши кампании прилетит метка policy violation - алгоритм пересмотрел рекламу и нашёл несоответствие.

Правильно: фильтровать в две стадии. Первая - "явные DC/VPN/Tor" режем сразу. Вторая - "регион, не подходящий под оффер" показываем мягкую белую (не пустую страницу, а нормальный контент), без чёрной. Так модератор из Дублина видит нормальную тематическую страницу и не считает её клоаком.

Ошибка 5. Слишком длинный TTL на DNS

Этот пункт спецэффект, но видим его постоянно. Купили домен, поставили A-запись с TTL 86400, начали лить - всё работает. Через две недели хотите подменить infrastructure (переехать с одного клоака на другой, поменять edge, добавить балансировщик) - и понимаете, что TTL у вашего домена сутки. То есть DNS-провайдеры по всему миру могут ещё 24 часа отдавать старую запись.

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

Правильно: с самого начала ставить TTL = 60-300 секунд на доменах для арбитража. Cloudflare и Namecheap позволяют это в один клик. На фронте сайта компании, конечно, ставьте нормальный TTL - там 60 секунд не нужны, но для рабочих доменов это правило.

Бонусом: что не ошибки, но многие думают, что да

  • "Менять IP домена каждый день - помогает". Нет, фейсбук это не отслеживает. Помогает менять контент белой страницы, а не сетевую инфраструктуру.
  • "Если креатив одобрили - значит, всё ок". Тоже нет. Алгоритм пересматривает рекламу спустя 3-7 дней после запуска, и баны прилетают именно тогда.
  • "Использование CDN с большим количеством IP защитит от бана". Не защитит. Бан привязан к домену и аккаунту, не к IP.

Что мы делаем в TDS

В нашем клоаке (его внутри называем Bouncer) учтены все пять пунктов. По умолчанию: фильтр по совокупности сигналов, отдельные правила для модераторов фейсбука/гугла, динамический контент белой страницы, мягкая гео-фильтрация с фоллбэком на нейтральный контент.

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