Собственная фильтрация трафика на ClickHouse и Python: где именно режется фрод

Собственная фильтрация трафика на ClickHouse и Python: где именно режется фрод

Давайте поднимем логи и посмотрим правде в глаза. Если фильтр живёт только в кабинете, бюджет уже течёт в сторону. Нормальная схема — сначала писать сырой поток событий в ClickHouse, а Python использовать как слой решения: быстрый скоринг, правила, обогащение, блок-листы, возврат причины в разрезе click_id.

База строится на трёх таблицах: raw_events, decisions, whitelist_blacklist. В raw_events кладите всё без «улучшений»: timestamp, ip, ua, referer, click_id, landing_ms, geo, device_hash. В decisions фиксируйте outcome и rule_id, иначе через неделю вы не восстановите, почему пользователь улетел в reject. ClickHouse здесь хорош тем, что дешево переваривает объём и даёт мгновенную агрегацию по аномалиям.

В Python не городите монолит. Держите набор детекторов: • дубли по click_id/ip/ua; • невозможная скорость между click и conversion; • низкая энтропия UA и referer; • всплески по ASN или /24; • повторяющиеся паттерны mouse/scroll, если события есть. На вход — батч из ClickHouse, на выход — score и причина. Логика должна быть детерминированной: один и тот же набор признаков всегда даёт один и тот же verdict.

Критичный момент — обратная связь. Каждый false positive возвращайте в whitelist, каждый confirmed bot — в blacklist, но с TTL. Ботнеты эволюционируют, но паттерны их поведения остаются прежними: скрипт меняется, а сетевой след, временная связность и мусорные UA часто нет. Вот технический разбор того, как именно уплывает ваш рекламный бюджет: не в «плохой креатив», а в отсутствие собственной точки принятия решения.

Если у вас нет внутреннего скоринга, у вас есть только надежда. А надежда в AdTech обычно заканчивается в сырых логах.