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.

For more details about the cookie itself, check out my previous article on FPID.

In that article, I mentioned one caveat for adopting FPID being 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 have 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).

X

The Simmer Newsletter

Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!

Cross-domain tracking with server-side FPID cookie

So, how do you make an HttpOnly cookie available to JavaScript?

By creating a version of the cookie that isn’t HttpOnly!

And that’s what Google have done.

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 (with some nuance in case you have the JavaScript migration option enabled, but I digress).

Server Managed ID

Now, you’ll 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:

FPLC cookie in the response

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.

This means that if the page is loaded and the user stays on the page for 20 hours and 1 minute, then cross-domain tracking will not work even if they click a link with a flagged URL. They’ll need to reload the page to get the FPLC cookie again. But this is probably quite rare.

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.

Google Analytics parameters in green, FPLC in red Google Analytics parameters in green, FPLC in red

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 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.