<b>Клоакинг ломается не на «бане», а на кривой технической схеме</b>

<b>Клоакинг ломается не на «бане», а на кривой технической схеме</b>

Разбираем воронку на атомы: у Facebook и Google должен быть один сценарий, у модерации — другой. Если URL-цепочка, редиректы и параметризация собраны хаотично, фильтр начинает путать бота, модератора и живой трафик. Техничка решает всё.

Базовая схема: входной домен → серверный фильтр → split на white/black → логирование в трекер. Проверять нужно не только IP и user-agent, но и отпечаток устройства, язык, таймзону, заголовки Accept-Language, referer, скорость перехода. На слабом фильтре хватает одной лишней дырки — и весь сплит едет в мусор.

Для Facebook критично, чтобы prelander и белая ветка открывались без задержек и подозрительных цепочек. Для Google — аккуратнее с редиректами и совпадением контента между crawl и пользовательским визитом. Если используете API-интеграции, прокидывайте clickid и event_id в трекер, иначе постбеки будут выглядеть как шум, а не как сигнал.

Проверка перед запуском: 1) один и тот же клик должен стабильно попадать в нужную ветку; 2) боты не должны видеть арбитражный контент; 3) логи сервера и трекера должны сходиться по времени и параметрам; 4) ручная проверка из разных сетей нужна до любого масштаба.

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