Что умеет Measurement Protocol в GA4?

Я использую протокол, когда бэкенд подтверждает действие и располагает нужными для GA4 данными. Это помогает связать онлайн- и офлайн-действия и собрать серверные и браузерные события в одном ресурсе.

Протокол не восстановит просмотры, которые не записывались. По документации Google, он дополняет автоматический сбор через тег Google, Tag Manager или Firebase. Полученное событие без связи с исходным посетителем не подтверждает восстановление атрибуции исходной сессии.

События можно датировать задним числом: до 72 часов назад. Это не способ задним числом добавить пропавшие покупки прошлого месяца, а сам этот лимит не гарантирует привязку к сессии.

Для веб-потока client_id идентифицирует экземпляр пользователя и должен совпадать с ID, который генерирует тег GA4 сайта. Когда это разрешено, я переношу это значение в бэкенд, а не заменяю его номером заказа или новым случайным значением для каждой покупки. В запросе также нужны measurement_id потока и api_secret, который остаётся на сервере.

transaction_id идентифицирует заказ в событии покупки. По документации Google, в веб-потоках дедуплицируются покупки одного и того же пользователя с одним и тем же transaction ID. В любой серверной копии я сохраняю идентификатор клиента из браузера и тот же идентификатор заказа. Один transaction ID сам по себе не обещает дедупликацию между разными пользователями или потоками приложений.

Я проверяю поток назначения, сохранение client_id, пустой или повторно использованный transaction_id, параметры ecommerce и время события. Важен и контекст сессии. Для точных метрик сессий и вовлечённости, включая Realtime, Google рекомендует session_id и engagement_time_msec. Я передаю реальные данные сессии, без выдуманных значений вовлечённости.