Make your GA4 life easier: Some powertips!

Aahhh… the joy of setting up GA4. A clean, fresh implementation. No legacy.. just pure new good intentions. And also a lot of quirks to work around.

Your Universal Analytics routine won’t help you here, so.. you might wonder: What should I put in a GA4 implementation to make it truly shine, and to get the most of it?

Here’s a list of things to add in your GA4 implementation that will really make your GA4 life easier.

Data modeling in Big Query can be made easier..

Problem: Relying on the GA4 built-in event_timestamp will give you the microsecond-granular timestamp of when the event was batch-sent from the browser.

So that can be up to 5 seconds later than the actual event itseld, and all events in the batch will have the same timestamp.

Solution:

• Date.now()
  I always create a client_timestamp parameter and fill it with the client date. This way, you will have millisecond-granular data on when the event happened in the browser.

When modeling event timings, and event-order you can now use this parameter as a timestamp.

Problem: When modeling events in Big Query.. how do you know it’s an event you have already processed, or if it’s a new one?

Solution:

• {{random number}}
  Adding an event parameter random_number will allow you to use a concatenation of random_number + user_pseudo_id + event_timestamp + event_name as event ID.

This is especially convenient, because Google can update the events_YYYYMMDD tables up to days after these tables are created. So rather than waiting, or using stale information: process them again, append them to your temporaty model table, and in the end, only use the last row.

Problem: What events happened on a particular page?

That is easy enough. But can be really tricky to model, using made-up IDs and window functions. What would make it super convenient is having a page_view_id of some sort.

Solution:

• {{gtm.start}}
  When you add the gtm.start variable to a parameter called page_view_id (in the config tag for example), all the tags that are loaded in that page load, will have the same ID. Super convenient!

I use a concatenation of user_pseudo_id and page_view_id to generate a page view ID, so all events with the same ID share the same page load.

Debug parameters

Although not useful directly for the business, there are some parameters that you can add to your events that will help you find out why things go wrong:

• gtm.uniqueEventId
  adding this parameter (hat tip to Yehoshua Coren) will give you an ID that might not be unique, but in combination with the gtm.start variable, you will know if a dataLayer push made one or more tags fire.
• {{Container ID}} {{Container version}}
  Having a container id and version in tags will help you not only keep track of which versions were published at what date, but also will help you pinpoint data breakage to a certain GTM version.
• {{Container ID}} {{Container version}}
  Wait, what? Duplicate? Nope. The server container also has an ID and version. You can use that too in your server side variables!