<b>QA server-side трекинга ломается не на коде, а на мелочах маршрута и дедупликации</b>

<b>QA server-side трекинга ломается не на коде, а на мелочах маршрута и дедупликации</b>

Перед релизом проверь 4 слоя:
— Network: запрос доходит до endpoint, нет 4xx/5xx, корректный content-type.
— Mapping: client_id, event_name, event_time, user_data, custom_data не теряются по пути.
— Identity: fbp/fbc, external_id, email_hash и phone_hash нормализованы до SHA-256.
— Deduplication: event_id одинаковый у Pixel и CAPI, а не сгенерирован дважды.

Отдельно смотри на source of truth. Если событие пришло из браузера и сервера, но в аналитике живёт только одно — значит, где-то расходится event_id, timestamp или окно дедупа. Для Purchase, Lead и CompleteRegistration это особенно критично: ошибка в одной переменной даёт ложную картину по ROAS и EMQ.

Технический минимум для QA:
— отправь тестовое событие и проверь его в debug-инструменте;
— сравни payload браузера и сервера байт в байт по ключам;
— убедись, что IP и User-Agent не пустые на сервере;
— проверь, что редиректы не режут fbc и click_id;
— прогоняй один и тот же сценарий через разные браузеры и с adblock включённым.

Если тестировать только «пришло/не пришло», sGTM почти всегда проходит QA и потом тихо теряет качество данных. Полезнее ловить не падение, а расхождение: в полях, в дедупе, в тайминге и в нормализации хеша.