Server Side Gtm And First Party Mode More Control Less Restrictions
Management Summary
FPM and ssGTM: Improved control and fewer cookie restrictions – find out if this setup is right for your business in this blog article.
Notes
According to the official Google documentation, First Party Mode (FPM) is still in beta:
- Note: First-party mode is in beta. Setting up First-party mode may help your tag setup perform better, resulting in better quality measurement signals. If you have a question or issue with your setup, reach out to us at1p-mode-beta-feedback@googlegroups.com.
source
In addition, it should be pointed out that the First Party Mode can also be implemented without Server Side GTM, but since Server Side GTM is often already in use in our environment, this blog article refers specifically to this combination and not purely to First Party Mode.
Advantages
More control
Since a reverse proxy is switched in front of the ssGTM, you have the opportunity to change or remove data before it arrives, for example, in the GCP or on the ssGTM.
An example would be removing the user IP address on the reverse proxy before sending it to the ssGTM. This may be necessary in a company that has very strict data protection rules.
The question that arises in this context is which reverse proxy is used for this? A load balancer in GCP? Features in Cloudflare (a US company)? Or another provider?
Advantage: More control – Source: e-dialog
Reduce ITP restrictions
The problem in this context is that the IP of the website (e.g.: analytics-test-1.com 162.159.134.42) and the IP of the ssGTM tracking subdomain (e.g.: sst.analytics-test-1.com 35.190.14.188) are (too) different. In this case, ITP classifies the ssGTM and its cookies set via the Set-Cookie HTTP Response Header (e.g.: FPID) as suspicious and therefore limits the cookie lifespan to 7 days.
However, if you use first party mode, the ssGTM operates under the same IP address as the website and the lifetime of the cookies set is not limited.
This only has advantages for tools that only set first-party cookies (e.g.: GA4 using FPID cookies). The third party cookies of many other tools (e.g.: Google Ads, Floodlight Tags, LinkedIn etc.) are still limited by ITP. Even if these tags are moved to ssGTM, they set their cookies in a third party context and are therefore limited.
No change
Bypass ad/tracking blockers
Most blockers use lists of domains and/or paths.
Blockers that only use domain lists (e.g.: googletagmanager.com) have already been bypassed with the usual setup of ssGTM with tracking subdomain and loading the client side GTM and the Google libraries.
Blockers that also block based on paths in their lists (e.g.: /gtm.js) also identify, for example, the client side GTM when it is loaded via FPM (e.g.: analytics-test-1.com/metrics/gtm.js).
Unfortunately, in both cases the FPM does not bring any improvement.
CSP can be simplified
Another advantage cited by FPM is that the CSP of the website can be simplified. If you assume in this case that the Client Side GTM is already loaded via its own subdomain, and that this is a subdomain of the website domain anyway, the advantage here is probably limited.
This advantage only applies if the Client Side GTM is still integrated directly via https://www.googletagmanager.com and not via the tracking subdomains of the ssGTM.
Disadvantages
Additional costs
Depending on the setup, there may be no or additional costs for the upstream reverse proxy.
Implementation effort
Expenses arise for the following points:
- The code of the client side GTM must be adapted on the website
- The reverse proxy must be set up
- The Client Side GTM only needs a small adjustment
- Testing and evaluation of tracking
Cookies to Google
One disadvantage that is mentioned again and again is that all website cookies are sent to Google Host at FPM.
When FPM is combined with ssGTM, this is not the case because the cookies are sent to the self-hosted ssGTM and not directly to Google Host.
Definitions
Proxy vs. Reverse Proxy
The term “reverse proxy” is often used in connection with FPM.
Many people know the classic “proxy”. It is used by the client/user and is mostly used for the purpose of data protection and bypassing geolocation blocks (e.g. streaming abroad).
In contrast, the “reverse proxy” is used by the web server and is placed in front of it. A reverse proxy can have many areas of application, some of which are: security, load balancing, caching etc. In other words: reverse proxy is the generic term and, for example, a load balancer is a special type of reverse proxy.
To implement FPM, it is necessary to redirect the requests from the Google libraries (client side GTM, GTag) and the tracking requests themselves (/collect etc.) to ssGTM.
Whether this is done by a load balancer or another type of reverse proxy is irrelevant, there are many options here.
Reverse Proxy vs FPM
With a finished FPM setup in combination with ssGTM, all tracking resources and requests are sent via a previously defined path, e.g.: /metrics
The Client Side GTM is then loaded via the following URL: analytics-test-1.com/metrics/gtm.js
The reverse proxy takes care of this routing of the /metrics/* requests to the ssGTM.
First Party Mode is essentially the feature of Google or the ssGTM that actually returns the client side GTM library when a request comes from the URL analytics-test-1.com/metrics/gtm.js. The first party mode enables the ssGTM to respond correctly to tracking requests via the new /metrics path.
CNAME cloaking
CNAME cloaking in the tracking area attempts to hide the actual source of resources. A CNAME, i.e. a redirect from one domain name to another domain name, is used for this.
In the example below there is a CNAME redirect from cdn.analytics-test-1.com to third-party.com
In this case, the Network tab of the Developer Tools would actually show the domain cdn.analytics-test-1.com, but the actual IP 33.33.33.33 where the resource is hosted would be shown.
In this way, tracking blockers that are looking for the domain third-party.com cannot recognize it and therefore cannot block anything.
The setup using Cloud Run and the Custom Domain Feature is similar to CNAME cloaking, but does not entirely apply to it. Because you link your own ssGTM using CNAME and not a third-party domain.
As you can see, the domain is not a reliable source for detecting tracking, for this reason ITP checks the IPs. If the IP deviates too far from a certain resource (compared to the IP of the website), then the associated cookies are also limited.
This also means, regardless of whether you use your ssGTM using Cloud Run and Custom Domain Feature (CNAME Record), or Cloud Run and a Load Balancer (A Record), the IP of the ssGTM differs too much from the IP of the website and is therefore recognized by ITP.
Conclusion
FPM in combination with ssGTM offers some advantages, but is probably not necessary for every scenario.
