Эта публикация навеяна выступлением Fred Pike на MeasureSummit. Она о том, что и для каких целей стоит включать в набор параметров события перед отправкой в GA4.
В большинстве своем это параметры для дебаггинга, удобства работы в BigQuery или исследовательских задач. Учтите, что в бесплатной версии GA4 существует ограничение на отправку параметров с каждым событием: до 25. И некоторые из параметров (например временную метку события) просто не имеет смысла создавать в качестве кастомного параметра – тогда как в BigQuery она пригодится. Длинна специального параметра не должна превышать 100 символов.
Итак, мой топ параметров веб-событий в GTM:
hit_timestamp - временная метка события. Получаю с помощью JS-функции на клиенте. Необходима для расчета последовательности хитов – поскольку события в GA4 отправляются батчами;
container_id - мастхэв в случае использования нескольких контейнеров на одном ресурсе;
user_id - отправляю с каждым событием несмотря на наличие аналогичного параметра в Google Tag Settings. Практика показывает, что последняя опция не очень надежна;
debug_mode - то же самое. Но это опционально;
container_version - сразу становится понятно после какого обновления появились те или иные события и их параметры;
environment_name - обязательно, если вы используете среды в GTM;
referrer_hostname, page_hostname, page_path - делаю это дабы не парсить каждый раз page_location или page_referrer;
fbp, fbc, gclid - эти и другие значения cookie-файлов полезны для точной идентификации рекламного трафика;
custom_event - с помощью этого параметра вы прямо в интерфейсе BigQuery увидите, что тригерило это событие - скажем gtm.js или gtm.load;
user_agent - строка целиком для исследования аномалий.
Все это подразумевает гигиену – достаточно детальную документацию изменений в GTM, использование человекопонятных наименований тегов, триггеров, переменных.
Больше о работе с данными в продукте и маркетинге есть в Телеграм-канале "Модель атрибуции”
