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

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

Когда в один трекер сходятся push, native, Facebook, Google и direct, ошибка почти всегда не в трафике, а в архитектуре. Hub-схема держится на трёх слоях: intake, normalization, routing.

— intake принимает клики и постбэки без лишней логики;
— normalization приводит source, campaign, subid и status к единому формату;
— routing решает, куда отправить конверсию: в сеть, CRM, BI или в антифрод-слой.

Главное правило: не хранить бизнес-логику в одном place. Если правила ротации, фильтры GEO/UA и дедупликация живут внутри кампаний, любое изменение превращается в ручной рефакторинг. Лучше вынести маппинг в отдельные таблицы или скрипт и держать версионирование конфигов.

Для multi-source почти всегда нужны: единый namespace для subid, отдельные callback-эндпоинты под каждый источник, логирование сырых payload'ов и fallback на retry-очередь. Иначе при спорном postback ты не поймёшь, где потерялся атрибут — на стороне источника, в трекере или в интеграции.

Если строишь tracker как hub, думай не про кампании, а про потоки данных. Тогда добавление нового источника сведётся к маппингу, а не к переписыванию всей схемы.