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

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

Давайте поднимем логи и посмотрим правде в глаза. Если у вас фильтрация живёт в «табличке с UTM», бюджет уже течёт через дырявый кран. Нормальная схема строится так: сырой клик/лид летит в ClickHouse, Python забирает подозрительные срезы, считает аномалии и возвращает verdict в трекер или CRM.

Базовый слой правил:
— частота кликов с одного IP / /24;
— несостыковка UA, языка, timezone и географии;
— слишком короткий dwell time и мгновенные возвраты;
— повторяемые цепочки cookie, click_id, fingerprint;
— одинаковые паттерны заголовков, пустые referer и кривые редиректы.

В ClickHouse удобно держать не «истину», а следы: сырые события, агрегации по окнам, z-score по источнику, плотность конверсий, всплески по user_agent. Python здесь не для красоты — он оркестрирует запросы, сравнивает окна, помечает риск и пишет ответ в отдельную таблицу. Ботнеты эволюционируют, но паттерны их поведения остаются прежними: пачки однотипных сессий, ровные интервалы, мёртвые цепочки без микродвижений.

Хорошая практика — разнести фильтры по слоям: hard block на сетевые аномалии, soft flag на поведенческие, delayed decision на спорные кейсы. Тогда вы не рубите живой трафик одним тупым правилом и не кормите фрод-машину бесплатными обходами.

Если у вас есть сырые логи и дисциплина на уровне схемы данных, ClickHouse и Python закрывают 80% задачи без магии. Остальное — ручной разбор самых дорогих аномалий, где уже видно, кто именно делает вид, что это «обычные пользователи».