The FPID cookie in server-side tagging for Google Tag Manager is an
_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
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).
Tip 126: Cross-domain tracking with the FPID cookie
So, how do you make an
By creating a version of the cookie that isn’t
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
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:
This FPLC cookie is the cross-domain linker cookie hashed from the
FPID cookie. It’s not
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.
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 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.