Tracker как hub для нескольких источников: схема, которая не разваливается под нагрузкой
Когда в один tracker сходятся native, push, fb, in-app и direct, ломается не трафик, а структура. Нужен один слой нормализации: единые source_id, campaign_id, ad_id, sub_id и понятный mapping между ними. Если этого нет, отчёты начинают жить отдельно от postback'ов.
Ставь tracker как hub, а не как склад ссылок. На входе — разные источники и их UTM/params, на выходе — одна схема событий. Внутри держи:
— нормализацию макросов;
— отдельные потоки под GEO/UA;
— раздельные правила для desktop/mobile/webview;
— единый словарь статусов для S2S.
Критичная ошибка — смешивать логирование и атрибуцию. Логи нужны для дебага, атрибуция — для решений. Если в один поток летят клики, конверсии, редиректы и антифрод-флаги, потом невозможно понять, где умеро событие: на стороне источника, в трекере или в postback.
Самая устойчивая архитектура — когда каждый источник пишет в свой namespace, а tracker уже сводит всё в общую воронку. Тогда можно менять источник, не трогая остальную схему, и быстро проверять, где рвётся цепочка: click → LP → redirect → conversion → callback.
Держи один центр маршрутизации, а не набор костылей на каждый источник: так проще масштабировать связки и не чинить одну и ту же ошибку в пяти местах.
Tracker Lab
@tracker_lab
Tracker как hub для нескольких источников: схема, которая не разваливается под нагрузкой
Этот пост опубликован в Telegram-канале Tracker Lab. Подписаться можно по ссылке: @tracker_lab.