Клоакинг ломается не на фильтрах, а на кривой техничке: где обычно течёт

Клоакинг ломается не на фильтрах, а на кривой техничке: где обычно течёт

Разбираем воронку на атомы: клоакинг держится не на «магии», а на стабильной маршрутизации. Если у тебя расходятся UTM, subid и postback — модерация или антифрод видят одну картину, а трекер другую. Итог предсказуем: белая страница попадает в whitelist, серый трафик — в бан, а источник начинает резать сам себя.

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

Что проверять перед запуском:
• совпадают ли clickid в трекере, пикселе и postback;
• не теряются ли параметры на 301/302 и междоменном редиректе;
• отрабатывает ли fallback-страница без задержек и цепочек;
• не палится ли связка по IP, ASN, user-agent и времени ответа.

Отдельно тестируй промежуточный слой: API-интеграции, куки, кеш, таймауты, подмену контента и правила по гео. Сплит-тест — единственный аргумент: если один и тот же поток в трекере даёт разные логи на разных ветках, проблема не в крео, а в маршрутизации.

Если клоакинг нужен, он должен быть предсказуемым, а не «на удачу»: меньше точек отказа, больше контроля на сервере и всегда сверка логов трекера с ответами лендинга. Логи трекера врать не будут.