MTProto-просмотры и бот-сети: разные следы, разные триггеры, разные риски фильтров

MTProto-просмотры и бот-сети: разные следы, разные триггеры, разные риски фильтров

Давайте снимем розовые очки и посмотрим на сырые логи. Для фильтров MTProto-просмотры и классические бот-сети — не одно и то же: у первых есть транспортный слой Telegram-клиента, у вторых часто торчит примитивный паттерн автоматики. Алгоритмы пишут люди, а значит, у любой защиты есть свой порог чувствительности.

MTProto-источник обычно выглядит мягче: сессии живут дольше, запросы идут через нормальный стек, меньше мусора по user-agent и fingerpints. Но это не индульгенция. Если пул аккаунтов однотипный, гео не бьётся, а тайминги идут ровной линейкой, TGStat и внутренние фильтры быстро начинают видеть не живую аудиторию, а управляемую массу.

Классическая бот-сеть палится грубее:
— одинаковые интервалы действий;
— повторяющиеся IP/ASN и слабая ротация;
— нулевой ретеншн и мгновенный отвал;
— синтетические реакции без естественного распределения.
Такая нагрузка даёт всплеск метрик, но почти всегда режется по поведенческому профилю, а не по самому факту просмотра.

У MTProto-схемы другая проблема: она дольше живёт, но дороже в обслуживании. Нужны нормальные сессии, прокси-матчинг, контроль прогрева и разнесение активности по окнам. Иначе фильтр не банит сразу, а просто обесценивает сигнал: просмотры есть, а доверия к ним — ноль. Вот и вся магия.

Вывод простой: бот-сети дают шум, MTProto — более чистый след, но только при дисциплине по фингерпринтам и таймингу. Если хотите обойти фильтр, сначала проверьте не объём, а правдоподобие распределения.