Over the past year, I’ve worked with almost a dozen different clients that migrated their Google Analytics implementation from UA to GA4 using Segment. While I’m generally fond of Segment and find implementing simple tags with it rather stable, its GA4 Destination is a mess. In this post, I’ll try to explain why it’s so bad and how you can go about implementing it properly.
Segment’s GA4 Destination
Segment has plenty of Destinations prebuilt and ready for immediate & easy deployment, one of which is of course Google Analytics 4 (GA4). While the previous version, Universal Analytics, had the option for using Client and Server side tracking (either or both in parallel), the GA4 destination offers only Server-side integration.
GA4 Measurement Protocol
GA4 comes with a brand new API, aka Measurement Protocol, for measuring server-side events. This API, widely adopted for UA, allows marketers to send sensitive data to GA without exposing it on the client side. It also offered significantly more stable tracking for critical data such as e-commerce purchases.
It wasn’t built to replace a full-blown client-side implementation of GA but rather only to enhance it.
As a Google employee put it:
The Measurement Protocol for GA4 is only intended to supplement events already collected via other libraries such as the SDKs and gtag.jsSource: Google’s Issue Tracker
Google Analytics Cookies
Another often overlooked issue with this setup is which anonymous identifier do we send as the Client ID (aka CID). Segment defaults to using it own anonymous ID, which is a great solution for keeping your analytics platforms consistent. In a full server-side scenario, where no GA cookie is available it even makes sense.
However, if you would later want to create audiences for ad targeting, these audiences won’t be able to match any user as the cookie wasn’t set by Google and can’t be traced back to a user.
Getting it done right
So now we understand why using the standard GA4 destination is bad. I really hope they fix it soon enough so that we won’t have to jump through hoops to get it done right.
Using Google Tag Manager
I’m a big fan of adding GTM on top of Segment. It might sound strange, but they work well together when each of the two is implemented to do exactly what it should.
The first step is to add GTM as a destination in Segment. By doing this we achieve two things:
- The GTM code is loaded via Segment, no need for additional site edits
- All the Segment event data is sent as DataLayer event data
Once we’ve set this up, every event logged by Segment can be used to create a Custom Event trigger for a GA4 event tag.
In a simple scenario, multiple triggers can be combined under a single tag with the event’s name set dynamically from the Custom Event.
A more complex scenario, with event parameters, will require mapping these specifically. This will require using multiple tags or some conditional logic.
Caveats to the Segment Datalayer push
Segment’s events and parameters are specific to the event triggered, i.e. if a certain parameter is sent with a certain event, it won’t apply to subsequent events.
In the data layer, a parameter set in a certain key will persist throughout the same page (or until the data layer is reset). This means that using a variable in GTM can represent data from a previous Segment push to the data layer, and not necessarily from the most recent event pushed.
Leave a Reply