This article will work as a guide to making the Google Analytics 4 Destination, which relies on Google’s Measurement Protocol version 2, in Segment work. Segment has created the out-of-the-box GA4 solution for its customers to the best of its ability. This is referred to as a destination. However, due to its inherent nature, Google’s Measurement Protocol lacks certain functionalities to make it work as expected. The most significant challenge is identifying sessions since the server-side payload does not send the session_id by default.
With Segment’s Analytics.js SDK we can get it to work for client-side and server-side GA4 tracking. If you are on a Segment Team Plan, this solution will work. You only need the Segment Connections module for this solution to work.
This article was inspired by Simo Ahava’s blog post Session Attribution with GA4 Measurement Protocol.
To get started, let’s set our goal: To properly track GA4 sessions using Segment’s out-of-the-box Destination from both front-end and back-end, as shown below.
I have set up an Analytics.js SDK source and a Node.js source for this guide on a dummy website. Both sources point to two separate Google Analytics 4 Destinations with the same Measurement ID. This means that data sent to these destinations will be collected using the same data stream in the same Google Analytics 4 property.
Step 1 – Setting up a client-side GA4 tag for generating the cookies
To obtain the GA4 tracking session id and client id, we need to install the Google Analytics 4 tracking script client-side. In my experience, I have found that enabling the Google Tag Manager Destination is the easiest way to achieve this. Let’s go through the steps.
Step 1.1 – Enable the Google Tag Manager Destination in Segment
Enable Google Tag Manager Destination in Segment
First, if you haven’t already done it, go to Google Tag Manager and create a new container. Copy the container id (eg. GTM-XXXXXXX). Then, in Segment, add Google Tag Manager as a Destination and enter the Container ID in the appropiate field. We will need this container for implementing a client-side Google Analytics 4 Configuration tag that will generate the necessary cookies.
Step 1.2 Add a Google Analytics 4 Configuration tag
The next step is imporatant since it will generate the _ga and the _ga_<measurement_id> cookies for us, which contain the values we need to make Measurement Protocol work properly.
Go to your Google Analytics 4 property and copy the Measurement ID you want to collect the data with. You can find the Measurement ID under:
Admin > Data Streams > (Click on the relevant Data Stream) > Copy the Measurement ID
In Google Tag Manager, add a new tag of the type Google Analytics: GA4 Configuration.
Add the Measurement ID in the Measurement ID field. Since we will be tracking Page Views using the Action mappings in the GA4 Destination in Segment, we need to disable the option ‘Send a page view event when this configuration loads’.
Finally, add the All Pages trigger (or valid consent respecting trigger) to you Google Analytics 4 Configuration tag.
Save the tag and publish the Google Tag Manager Container.
Step 2 – Adjust your source code to pass along the session id and client id to Segment
The following will be slightly different for everyone. A lot depends on the frontend framework that you are using. The goal is to collect the _ga and the _ga_<measurement_id> values from their respective cookies. Personally, I have been using the Get Cookie function on W3 for years, old habits die hard.
Thes session id can be found in the _ga_<measurement_id> where the measurement ID matches that from your Google Analytics 4 property’s data stream. In the example below, the session id is 1675243172
The client id can be found in the _ga cookie on your root domain. In the example below, the client id is 1172149353.1675243173
Although I collect the ga_client_id, it is not necessary since Segment will provide a similar value. The ajs_anonymous_id cookie contains an anonymous identification value that, due to Segment Identity Resolution feature, works similar to Google’s client id. For the purpose of this guide, I will add the Google Analytics client id.
Add the parameters to all your analytics function calls, including the identify call if you want to use Segment Functions to build out your customer GA4 connector.
Since I am simulating backend transaction events from a Node.js server it is imporant to remember that we need to push the Segment user id (not be confused with the GA4 client id) and/or anonymous id from the originating POST call to the server endpoint and then on to to Segment.
If you have been very attentive, you will have noticed that I am also using the integrations object to pass along the GA4 client id to Segment. Segment’s integration object is mainly used to filter source data from reaching a specific destination. However, Segment’s identity resolution also leverages a certain aspect of the integrations object, mainly that you can pass along the GA4 client id through it. Segment will used the forwarded GA4 client id as a default when sending data to GA4 using its destination.
Segment’s instructions on capturing GA4’s client id as an external id.
In order for this solution to work it is not immediately necessary to adopt this approach. Having worked with Segment for so long, I do this automatically in order to prevent any data loss.
Step 3 – Verify that the data is being received by Segment
The next step, before we start mapping the data to Segment’s GA4 destination, is to verify that the data is being received by Segment. Using Segment’s Debugger tab on both the Analytics.js SDK and Node.js sources show that the parameters and integrations object are properly set.
Step 4 – Update GA4 Destination mappings to include the client and session id
To make sure GA4 receives the necessary data we need to map the client id and session id to each individual Action.
For previously explained reasons, I prefer to use Segment’s anonymous id as a fallback for the Google Analytics 4 Client ID field. The main value should, however, always be the client id you have started collecting.
Finally, what we have been working towards, adding the Google Analytics 4 sesion id as an event parameter in the destination action.
Step 5 – Verifying that the Session data is properly processed in GA4
When we start looking at the data using GA4 User Explorer, it becomes evident that Google’s Measurement Protocol still lacks certain capabilities. Although we have fixed Google Analytics 4 session issue using Measurement Protocol, the user’s profile remains incomplete.
Measurement Protocol has no capabilities of passing an IP address to Google Analytics 4. It is therefore unable to determine where a user comes from. The configuration tag does have this data, and you will see users pop up on the map every so often, but this is more a gimmick than a dependable datapoint.
Segment sets the Engagement Time in Milliseconds parameter to 1 by default. I am confident that you could find a workaround for this, but the question is, is it worth the effort. Let’s wait and see what Google will offer us moving forward.
Conclusion
With thanks to Simo for shedding light on how to overcome the session attribution challenge using the Measurement Protocol, I hope that I have been able to show how to overcome this in combination with Segment. Measurement Protocol version 2 will continue to have several shortcomings, but it should not deter you from tracking sessions properly in Google Analytics 4.
This workaround will take quite some effort, mainly by developers, to get the data you need. Nevertheless, I feel that by doing so, you will seriously be able to improve the data quality in Google Analytics 4 using Segment’s Google Analytics 4 Destination option.
