of FPID cookie with server-side tagging Google Tag Manager is HttpOnly, Server management ID cookies designed to replace JavaScript management _ga Cookies used by Google Analytics 4 and Universal Analytics.
For more information on the cookie itself, see our previous article on FPID.
In that article, one caveat in adopting FPID was: Cross-domain tracking it won’t work.
I mean, why? FPIDs are HttpOnly In other words, it cannot be used in browser JavaScript. Cross-domain tracking, on the other hand, dynamically decorates the link when the user clicks it. This means that the cookie should be available via JavaScript so that it can be decorated into the target page URL.
Well, Google has released a solution for cross-domain tracking using FPID. This is probably what you expected already (if you know how to avoid cookies).
X
shimmer newsletter
Subscribe to our Simmer newsletter to receive the latest news and content from Simo Ahava right in your email inbox!
Tip 126: Cross-domain tracking with FPID cookies
So how HttpOnly What cookies can be used in JavaScript?
By creating a version of the cookie, is not HttpOnly!
And that’s what Google has done.
if you have Server management The option selected in the GA4 or UA client in the server container means that the client FPID Using cookies and accessible in JavaScript _ga cookies (there are nuances if you have the JavaScript migration option enabled, but that’s an aside).
next, FPID Cookies are also included in the HTTP response returned from the client to the browser. FPLC Cookies on some requests:
this FPLCs cookie is the cross-domain linker cookie hashed from FPID cookie.it’s not HttpOnlyThat is, it can be read by JavaScript. relatively short lifespan 20 hours.
This means that once a page loads and the user stays on that page for 20 hours and 1 minute, clicking a link with a flagged URL will not work for cross-domain tracking. To get the FPLC cookie again, you have to reload the page. But this is probably very rare.
If configured Cross-domain tracking Either Google Analytics 4 Admin or Universal Analytics web tagsthe corresponding JavaScript library is configured to read this new cookie.
So when a user clicks on a link flagged for cross-domain tracking, the URL will contain the hash of the FPLC cookie (that is, the hash of the FPID cookie) in addition to regular Google Analytics. linker parameters.
Green for Google Analytics parameters, red for FPLC
The page must of course be running for the cross-domain link to work on the target URL. server container, which is the only place where FPID is relevant.the server container is FPLC Insert a cookie in the request header, make sure it’s valid, then FPID Cookies along with it, if all goes well.
There is an important pitfall here.
The server containers running on the source and target sites must belong to the same Google Tag Manager account.
In other words, it is OK to have different containersbut they must belong to Same GTM accountI think it has something to do with how the hash is calculated.
This is how cross-domain tracking works using server-side FPID cookies.
Of course, the purpose of FPID was to keep the identity away from the client, so it’s a bit disappointing to need a new cookie. FPLC is not the ID itself. This is a hash of the ID and is never used as an identifier in requests.
Also, cross-domain tracking always requires a client-side component.Due to how browsers work, the only alternative is to add fingerprinting I’m sure the Google Analytics team doesn’t want to touch long sticks. But technically, we’re already doing some fingerprinting in the linker parameters (to make sure the browser is the same for the source and target URLs).
Anyway, this feature is certainly what many people, myself included, have been waiting for since FPID was released.
