This post is the part of discussion which parameters to include in the set of event parameters before sending them to GA4 and why. Mostly, these parameters are for debugging, convenience in BigQuery, or research purposes. Keep in mind that the free version of GA4 has a limit on sending parameters with each event: up to 25. Some parameters, such as event timestamp, may not make sense as a custom parameter but can be useful in BigQuery.
The length of a special parameter should not exceed 100 characters. So, here are my top web event parameters in GTM:
hit_timestamp - the event timestamp obtained using a client-side JS function. Necessary for calculating hit sequences since GA4 events are sent in batches;
container_id - crucial when using multiple containers on one resource;
user_id - sent with each event despite the existence of a similar parameter in Google Tag Settings, as practical experience shows that the latter option is not very reliable;
debug_mode - the same as above, but optional;
container_version - immediately clarifies events and their parameters after a particular update;
environment_name - mandatory if you use environments in GTM;
referrer_hostname, page_hostname, page_path - done to avoid parsing page_location or page_referrer every time;
fbp, fbc, gclid - these and other cookie file values are useful for precise identification of ad traffic;
custom_event - with this parameter, you can see in the BigQuery interface what triggered this event, for example, gtm.js or gtm.load;
user_agent - the entire string for investigating anomalies.
All of this assumes hygiene - detailed documentation of changes in GTM, the use of human-readable names for tags, triggers, and variables. You probably have your tricks for sending event parameters - share them in the comments. If you have questions about organizing work with raw data for marketing analytics, reach me out in dm. If you feel like sharing this post with friends and colleagues - don't deny yourself that pleasure.
