Tracker как hub нескольких источников: без этого архитектура быстро разваливается

Tracker как hub нескольких источников: без этого архитектура быстро разваливается

Если в один трекер свести FB, TikTok, пуши, native и direct, он должен быть не просто логгером, а центром нормализации. Иначе разные источники начнут жить по своим правилам: разные click_id, разные окна атрибуции, разные postback URL, разные схемы параметров.

Базовая схема такая: один intake-слой принимает сырой клик, дальше маппит его в единый internal id, а уже потом раздаёт связки в source-specific формат. На входе сохраняй минимум: source, campaign, adset, creative, geo, ua, subid, timestamp. Всё остальное — производные поля. Если это не отделить, в отчётах начнётся путаница между источником клика и источником конверсии.

Для hub-архитектуры критичны три вещи:
— единый namespace для subid, без пересечения между сетками;
— отдельные postback endpoints или хотя бы жёсткий роутинг по source;
— слой валидации, который режет битые клики до записи в БД.

Ещё один практический момент: не смешивай логику трекинга и логику оптимизации. Tracker должен хранить истину, а не пытаться сам решать, какой источник «лучше». Оптимизация живёт в отдельном сервисе или хотя бы отдельном модуле.

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