Self-hosted трекер под нагрузкой: где умирает сервер и как это чинить

Первый узкий слой — база. Если трекер пишет все клики, постбэки и редиректы в одну БД без индексов по campaign_id, sub_id и created_at, ты получаешь очередь, а не аналитику. Разносите hot-path: отдельные таблицы под сырые события, отдельные — под агрегаты, кэш для частых выборок.

Дальше I/O. Под высокой нагрузкой чаще всего упираются не в CPU, а в диск и сетевые round-trip. Логируй асинхронно, режь синхронные записи, выноси тяжелые отчеты в фоновые джобы. Если в пике растет latency редиректа, сначала смотри в очередь записи и время ответа БД, а не в график загрузки ядер.

На уровне приложения держи API-гейты и S2S-постбэки короткими: минимум вычислений, максимум предсказуемости. Любая валидация, антифрод и нормализация параметров — после приема события, а не в критическом пути. Для сплит-тестов и ретаргета используй кэшированные правила, иначе каждое обращение будет бить по throughput. ⚙️

Финальный слой — наблюдаемость: метрики p95/p99 по редиректу, длина очереди, lag репликации, ошибки постбэков, процент дубликатов. Без этого ты не увидишь, где именно трекер начинает деградировать. Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.

Фильтрация бот-трафика в трекере: настройки, которые режут мусор до клика

Бот-срез на стороне трекера нужен не для красоты, а чтобы не ломать оптимизацию. Если в поток попадают headless, датacenter, прокси-цепочки и скриптовые клики, то сплиты, правила авто-оптимизации и postback-атрибуция начинают врать. Фильтровать лучше до отправки в источники, а не после — иначе мусор уже испортил статистику.

Базовый набор фильтров: • user-agent и сигнатуры браузеров без нормальной навигации • IP-респонсы из датацентров и прокси-сетей • слишком короткий time-on-page • аномальная частота кликов с одного ASN/подсети • отсутствие JS/cookie/session-chain • несостыковка GEO, языка и таймзоны. В трекере это удобно сводить в правила на уровне потоков, чтобы разные офферы и GEO не жили по одной логике.

Не делай грубую резку по одному признаку. Один только UA-фильтр режет и живой трафик с нестандартных устройств. Рабочая схема — скоринг: несколько слабых сигналов дают бан, один слабый — только метка. Так ты сохраняешь объем и не убиваешь конвертящий трафик вместе с мусором.

После включения фильтра обязательно проверяй дубли, долю rejected-луков и качество postback-цепочки: если клик есть, а конверт не доезжает, проблема может быть не в ботах, а в кривом токене или редиректе. Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

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

В арбитраже денег нет 💵

Безопасность трекинга ломается не на креативах, а на домене и реферере

Если трекер принимает любой Host, а редирект не валидирует связку домен→проект, уязвимость уже в проде. Что проверять:
— whitelist доменов и привязка к конкретному офферу/потоку;
— отдельные поддомены под клики, постбэки и статик;
— DNS и SSL без общих «запасных» записей;
— запрет open redirect и лишних query-параметров.

Реферер — не источник истины, а сигнал, который легко подменить. Для защиты не полагайся на него как на единственный фильтр: сверяй click_id, ip, user-agent, timestamp и цепочку редиректов. Если трафик идёт через промежуточные шлюзы, часть реферера теряется, поэтому логируй входной URL до всех 302 и сохраняй исходные заголовки отдельно.

Ещё один слой — контроль postback endpoint. Закрывай его секретом, IP allowlist и проверкой формата события. Любой колл без валидного токена должен уходить в reject, а не в «pending». Так ты режешь фрод, склейки и попытки подмены конверсий на уровне API-гейта.

Чистим логи, проверяем постбэки. Технический стек определяет потолок вашего ROI: чем жёстче валидация доменов и сигналов, тем меньше мусора в статистике и больше доверия к атрибуции.

Multivariate сплит-тесты без слива бюджета: как резать гипотезы до нужного объёма

Когда бюджет ограничен, multivariate-тест быстро превращается в шум, если лить на все комбинации. Рабочая схема — тестировать не “всё сразу”, а только переменные с максимальным вкладом в CR: заголовок, оффер, преленд, CTA. Остальное фиксируй и не трогай до подтверждения базовой связки.

Собирай матрицу по принципу 2x2 или 2x3, а не 5x5. Чем больше факторов, тем выше расход на статистику и тем дольше ты ждёшь валидный сигнал. Если трафика мало, режь количество вариантов через приоритизацию: сначала меняй элемент, который сильнее всего влияет на клик и постклик. На ленде это обычно первый экран, на крео — визуал и первый тезис.

Чтобы не утонуть в погрешности, заранее задавай минимальный объём на вариант и единые условия трекинга: одна и та же аудитория, одинаковые окна атрибуции, без параллельных источников с разной quality distribution. Иначе ты сравниваешь не связки, а мусор из разного трафика. Чистим логи, проверяем постбэки.

Если данных мало, используй sequential-подход: убрал слабый вариант — оставил сильный, затем тестируешь следующий слой. Так бюджет идёт не на “статистическую красоту”, а на ускорение обучения. Data-driven подход или работа вслепую — выбор за тобой.