Direct Anti‑Fraud
Синхронизация доступного контекста, attribution и anti‑fraud‑оценки.
Подробнее →AntiPF использует yclid/UTM и доступный контекст Директа/Метрики, чтобы сопоставить рекламный переход с visitor identity, сетевыми и browser‑сигналами, Risk Engine и последующим поведением. Решение остаётся объяснимым, а внешнее действие — контролируемым.
Чтобы делать выводы, полезно связать рекламный идентификатор, посадочную страницу и визит с тем, что реально происходило на сайте.
Сам факт рекламного идентификатора ничего не говорит о качестве посетителя.
IP‑исключение может задеть нормальных пользователей, если адрес разделяется.
Аномалия может быть локальна для конкретного источника, а не для всей рекламы.
Метрика Logs и внешние API имеют собственные jobs/retry/freshness — статус должен быть честным.
Рекламная аналитика не живёт отдельно: она получает visitor evidence из общей системы.
Фиксация yclid/UTM и landing URL.
Метрика и доступный campaign/ad context.
Session/identity, Risk, browser/network evidence.
Fraud Confidence + Exclusion Suitability.
Preview, лимиты и только затем разрешённая запись.
В AntiPF рекламный слой опирается на те же источники доверия, что и защита сайта.
Синхронизация доступного контекста, attribution и anti‑fraud‑оценки.
Подробнее →Visitor/request risk с объяснимыми contributions.
Подробнее →Automation/consistency evidence для браузерной сессии.
Подробнее →ASN и network‑context с NO_DATA/PARTIAL semantics.
Подробнее →Посадочная страница в одном реестре с поисковыми и HTTP‑данными.
Подробнее →История причин, predicted/actual action и override.
Подробнее →Яндекс Директ сам фильтрует недействительный трафик и недействительные клики до/после перехода и отражает отфильтрованную активность в своей статистике. AntiPF не заменяет этот слой: он помогает расследовать то, что дошло до сайта, сопоставляя yclid/UTM, Метрику, session/visitor identity, User-Agent и другие evidence.
Сначала нужно отделить технические аномалии от обычной низкой конверсии: связать yclid/визит/посадочную страницу, посмотреть повторяемость, visitor risk, сеть и поведение. Затем выбирать мягкое или внешнее действие.
В архитектуре предусмотрены интеграция Метрики и Logs API, а также jobs/retry‑модель. Фактическая глубина данных зависит от выданных прав и состояния API.
Такое действие нельзя считать безопасным по умолчанию. Exclusion Suitability нужна именно затем, чтобы отделять вероятность фрода от пригодности адреса для исключения.
Тогда важнее session/visitor identity, browser fingerprint stability, поведение и корреляция сигналов, а не один адрес.
Нет. Платформа помогает обнаруживать и обрабатывать технически подозрительные паттерны, но не может гарантировать отсутствие внешнего фрода или возврат рекламных расходов.
Начнём с домена, периода и симптомов. Доступы к Метрике/Директу понадобятся только после согласования объёма диагностики.