Cross Domain Tracking of the FPID cookie in server-side tagging for Google Tag Manager is an HttpOnly
, server-managed ID cookie that’s designed to replace the JavaScript-managed _ga
cookie used by Google Analytics 4 and Universal Analytics.
In that article, I mentioned one caveat for adopting FPID is the fact that cross-domain tracking will not work.
I mean, how could it? FPID is an HttpOnly
cookie, which means it’s not available to JavaScript in the browser. Cross-domain tracking, on the other hand, decorates links dynamically as users click them, which means it needs the cookie to be available via JavaScript so that it could be decorated into the target page URL.
Well, Google has now released a solution for cross-domain tracking with FPID, and it’s probably something you already expected (if you know your way around cookies).
![Cross domain tracking](https://analytics-smart.com/wp-content/uploads/2023/04/cross-domain-tracking.jpg)
Cross Domain Tracking with the FPID Cookie
How to create HttpOnly cookie available to JavaScript? By creating a version of the cookie that isn’t HttpOnly
If you have the Server Managed option selected in your GA4 or UA Client in the Server container, it means that the Client will write the FPID
cookie and use it instead of the JavaScript-accessible _ga
cookie.
![](https://analytics-smart.com/wp-content/uploads/2023/04/Javascript-managed.png)
Now, you’ll be able to see how in addition to the FPID cookie, the HTTP response from the Client back to the browser also includes the FPLC cookie in some requests.
This FPLC cookie is the cross-domain linker cookie hashed from the FPID
cookie. It’s not HttpOnly
, which means it can be read with JavaScript. It has a relatively short lifetime, just 20 hours.
It means that if the page is loaded and use stays on the page for 20 hours and 1 minute, then cross-domain tracking will not work event if they click a link with flagged URL. They will need to reload the page to get FPLC cookie again.
If you have configured cross-domain tracking in either Google Analytics 4 admin or in the Universal Analytics web tag, the corresponding JavaScript library is configured to read this new cookie.
So, when the user then clicks a link that has been flagged for cross-domain tracking, the URL will include a hash of the FPLC cookie (which is, in turn, a hash of the FPID cookie) in addition to the regular Google Analytics linker parameters.
For cross-domain linking to work in the target URL, the page must of course be running a Server container, as that’s the only place where FPID is relevant. The server container picks up the FPLC
a cookie in the request headers checks that it’s valid, and then creates the FPID
cookie with it, if all goes well.
There’s an important catch here.
The Server containers running on the source and target sites MUST belong to the same Google Tag Manager account!
In other words, it’s OK to have different containers, but they must belong to the same GTM account. I’m guessing it has something to do with how the hash is calculated.
And that’s how cross-domain tracking with the server-side FPID cookie works!
It’s of course a bit disappointing that a new cookie is required when the whole point of FPID was to move the ID away from the client. Well, FPLC isn’t the ID itself – it’s a hash of the ID and will never be used as the identifier in the requests.
Also, cross-domain tracking just happens to always require a client-side component! Due to how browsers work, the only alternative would be to add fingerprinting into the mix of ID resolution, and that’s a nasty can of worms I’m sure the Google Analytics team doesn’t want to touch with a long pole. Although, technically they already do some fingerprinting in the linker parameter (to make sure that the browser is the same between the source and target URLs).
Anyway, this feature is certainly something that many have been waiting for since FPID was released, myself included.
![Google Analytics GA4](http://analytics-smart.com/wp-content/uploads/2022/06/Google-Analytics-GA4-on-your-path.gif)