Tracker как hub нескольких источников: схема, которая не ломается при росте

Tracker как hub нескольких источников: схема, которая не ломается при росте

Если трекер собирает трафик из разных источников, его лучше проектировать как hub, а не как «один лендинг на всё». У каждого источника должны быть свои правила маршрутизации: source token, отдельные campaign IDs, своя UTM/parameter map и отдельный postback endpoint.

Дальше важен слой нормализации. Не тащите сырой вход в аналитику без приведения к единому виду: geo, device, OS, placement, creative ID, click ID. Иначе в отчётах начнётся каша, а любой split-test будет сравнивать не кампании, а мусорные поля. Логика должна жить в одном месте: в трекере или в отдельном middleware, но не в пяти таблицах вручную.

Для нескольких источников критичны три вещи: 1) единый формат click_id, 2) стабильная схема postback, 3) резервный маршрут на случай падения upstream. Если source отдаёт только часть параметров, сохраняйте raw payload отдельно: потом можно добрать атрибуцию, а не пересобирать всё по логам.

Маршрутизацию делайте по правилам, а не по памяти команды: whitelist источников, fallback-офферы, отдельные кампании под webview и desktop, отдельные окна атрибуции для каждого канала. Когда hub собран правильно, новый источник подключается как ещё один адаптер, а не как ручной костыль.

Главное правило: чем больше источников, тем меньше допускается «магии» в настройках. Одна схема ID, один формат postback, один слой нормализации — это дешевле, чем чинить атрибуцию после очередного сплита.