Поведенческая клоака и screen size: где ломают UA и как это ловить

Поведенческая клоака и screen size: где ломают UA и как это ловить

Поведенческая клоака редко палится по одному признаку. Чаще это связка: UA выглядит как десктоп, а screen size и touch events — как у телефона. Или наоборот: мобильный UA, но окно, DPR и набор событий не сходятся. Такие расхождения особенно заметны в WebView и hybrid-app, где часть логики живёт в JS.

Что обычно выдают:
— несостыковка между UA, viewport и devicePixelRatio;
— отсутствие touchstart/touchmove при “мобильном” профиле;
— слишком ровные интервалы скролла, кликов и фокуса;
— одинаковое поведение на разных экранах, будто сценарий рисуется скриптом.

На практике проверяют не только размер окна, а весь паттерн: orientation, availableWidth/Height, pointer/hover, maxTouchPoints, тайминги взаимодействий. Если клоака режет трафик по screen size, она часто делает это грубо — через фиксированные пороги. Тогда один и тот же креатив может пройти на 390 px, но отвалиться на 393 px, хотя для модерации это уже выглядит подозрительно.

Что важно: не пытаться маскировать один параметр отдельно. Если меняете UA, подтягивайте поведение, DPR, viewport и события под один профиль. Иначе антифрод видит не “устройство”, а набор конфликтующих сигналов. Для арбитража это главная ошибка: верят строке UA, а проверяют всю среду.

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