Клоакинг ломается не на фильтре, а на плохой логике разделения трафика
Что бросилось в глаза за годы разборов: большинство сбоев в cloaking stack начинается не с антибота, а с кривой цепочки решений. Если сначала проверять user-agent, потом IP, а потом реферер — это уже не защита, а лотерея.
Рабочая схема обычно строится вокруг трёх слоёв:
• транспорт: IP, ASN, дата-центры, прокси-сети;
• поведение: частота кликов, глубина сессии, скорость навигации;
• отпечаток: язык, таймзона, экран, WebGL, cookie-consent.
Если один слой «шумит», следующий должен добирать решение, а не ломать всю воронку.
Есть наблюдение которое стоит проверить: чем раньше вы отдаёте трафик в жёсткий deny, тем больше ложных срабатываний на мобильных и корпоративных сетях. Лучше сначала уводить сомнительные сессии в серую зону — преленд, пустой ротационный маршрут, дополнительную валидацию — и только потом резать.
Ещё одна типовая ошибка — смешивать правила антифрода и правила показа оффера в одном месте. Когда логика доступа и логика конверсии живут отдельно, проще тестировать связки, искать утечки и быстро менять гео-фильтры без каскадного падения трафика.
Если коротко: сначала стройте прозрачную схему принятия решения, потом усложняйте фильтры. В cloaking выигрывает не самый агрессивный фильтр, а тот, который можно объяснить по шагам и воспроизвести на чистом логе.
Cloaking Stack — Keitaro, Adspect, Imklo
@cloaking_stack
Клоакинг ломается не на фильтре, а на плохой логике разделения трафика
Этот пост опубликован в Telegram-канале Cloaking Stack — Keitaro, Adspect, Imklo. Подписаться можно по ссылке: @cloaking_stack.