Server-side tag management is a recommended step when focusing on privacy and ownership of your data. Server-side tagging can be a bit complex. However, it is customizable to fit your industry standards and compliance requirements. With this flexibility, comes nuance and choices, which the analyst must research and test. As a privacy and compliance leader, InfoTrust aims to share the knowledge that we’ve obtained to aid in this configuration.
In this article, we will focus on one portion of the server container configuration: the client. The client in the sGTM container is the adapter between the events happening on a user’s device and the server container. The client receives measurement data from a request (frequently a browser), transforms the data to be processed in the server container, and packages any relevant results to send back to the requester.
The main client configuration Google Analytics users will need is the Google Analytics 4 (GA4) client. The server container needs a client configured to receive the event once it reaches the server. The GA4 client is pre-installed in the server container, which makes configuration simple. The GA4 client and GA4 server tags are meant to work together. You can use a single GA4 tag to communicate all GA4 events with the GA4 client and send hits to the server measurement stream.
How Do I Configure the GA4 (Web) Client?
The primary settings for the client are priority and activation criteria. When working with a single client, use priority “0”. The priority sets the order in which clients will run, with the highest numbers running first. The first client that matches the incoming request will become the active client for that request. This is important to remember when using two separate data streams (app and web) or measurement protocols.
Activation criteria refer to conditions that must be met on the server container for the client to pass the hit to your GA4 property. InfoTrust recommends using the default GA4 paths when setting up the GA4 web client. The other option, Default gtag.js paths for specific IDs, is used when applying the gtag.js directly on the page source, not when you set up the Google Tag through GTM.
Javascript Managed or Server-Managed Cookies?
From here, we will move on to more settings. Cookies and client identification is the first section we will tackle. Here, you will decide between JavaScript-managed or server-managed cookies. InfoTrust recommends server managed for a few reasons. The server-managed cookie uses a new Client ID stored in a secure HttpOnly cookie (FPID cookie). This FPID cookie will be used for setting the Client ID in the request sent to Google’s servers.
Alternatively, the JavaScript-managed cookie uses the GA4 Client ID stored in a browser-accessible cookie (_ga cookie). This is the same cookie used by existing implementations of Google Analytics. The FPID cookie is only accessible through the server, not the browser, and is therefore more secure. The server-managed cookie extends the lifetime of the cookie to two years. As a server cookie, it is not limited by the same browser cookie restrictions and, due to this, we can identify users and attribution longer. Therefore, using the server-managed cookie can benefit attribution between its long life span and secured accessibility.
If you’re using Google’s consent mode, the FPID access is automatically prevented when consent is not granted for analytics_storage. This may be your default depending on your opt-in or opt-out market. Otherwise, it is always sent with the requests.
To recap, the benefits of switching to a server-managed cookie and why Google recommends this are the following:
- Increased long-term data accuracy: Server-side IDs are typically more accurate than client-side IDs, as they are not subject to the same browser limitations.
- Improved user privacy: Server-side IDs can provide better user privacy protection, as they are not stored in the browser.
- Source: Google Support
Data Verification
During the initial implementation of sGTM setup, when verifying data parity utilizing a server-managed cookie for the server-side GA4 property and JavaScript-managed cookie for the client side, it may introduce differences in user reporting comparison. Each site differs based on normal user behavior and data collection implementation, but a 10-20 percent discrepancy between server and client side is common.
However, you can migrate from JavaScript to the server-side ID (FPID). There are a few caveats when switching from the JavaScript cookie to the server-managed cookie. In the next section, we will discuss this migration.
Migrate from JavaScript-Managed Client ID
Within the GA4 client settings, there is a checkbox for Migrate from JavaScript-Managed Client ID. When enabled, this function has many of the benefits described above due to cookie longevity and attribution. Below we will discuss what this function does and its down-stream impact caused by enablement.
What’s the Impact of the “Migrate from JavaScript-Managed Client ID Setting?
If you activate the option to migrate from JavaScript-managed cookies (CID) you will still use the pre-existing Javascript cookie for all recurring users as to not duplicate user counts in GA4. Once the JavaScript cookie expires or is deleted, the migration function will set a server-side cookie (FPID). For all new users who haven’t been to your website, it is directly reliant on the server-side cookie without any transition period. For this reason, you will see both server-side and client-side IDs in BigQuery.
Keep in mind that when switching fully to server-side IDs (without enabling the migration option), it is expected to see a spike in new users within the GA4 UI for some time. This is because every website visitor will get a new FPID cookie and will ignore the previously set _ga cookie which stores the client ID. Over time, as the new server-side cookie (FPID) populates, the number of new users should decrease.
To recap, the impact of switching to a server-managed cookie is:
- Potential impact on reporting: Switching to server-side ID may result in changes to reporting data, as the data source will be different (especially for the transition period).
- Source: Google Support
Wrapping Up
The sGTM client setup is one of the integral pieces to your sGTM setup. While there are many customization options, Google and InfoTrust recommend that the Google tag be set up with:
- Priority: 0 (when using a single client)
- Activation criteria set to Default GA4 paths
- Cookies and Client Identification: Server-Managed
- Migrate from JS cookie: Enabled
