Server-side трекинг ломается не на коде, а на стыках: где чаще всего теряются конверсии
Когда команды переходят на server-side, ожидают «починить атрибуцию». На деле меняется только маршрут события: браузер, edge, сервер, трекер, MMP. Если в одном месте не совпали идентификатор, таймзона или правила дедупликации, данные начинают расходиться уже в первом отчёте.
Проверьте базовые точки:
— source и click_id должны жить в одном формате во всех системах
— event_name и статус конверсии надо нормализовать до отправки
— окно атрибуции и логика дедупа должны быть одинаковыми у трекера и у источника
— сервер обязан писать сырые логи, иначе сверка превращается в гадание
Ещё одна типовая ошибка — доверять только финальному postback. Если промежуточные события не сохраняются, вы не увидите, где именно отвалился путь: на клике, на редиректе, на обработке consent или на приёме сервером. Для разбора нужны три слоя: входящий запрос, обработка на сервере и исходящий postback.
Правило простое: сначала стройте наблюдаемость, потом оптимизацию. Без логов и единого формата идентификаторов server-side не даёт точности, он просто скрывает точку потери.
Attribution Deep
@attribution_deep
Server-side трекинг ломается не на коде, а на стыках: где чаще всего теряются конверсии
Этот пост опубликован в Telegram-канале Attribution Deep. Подписаться можно по ссылке: @attribution_deep.