#GTMTips: Cross-Domain Tracking Using Server-Side FPID Cookie – News Couple

#GTMTips: Cross-Domain Tracking Using Server-Side FPID Cookie

The FPID cookie In server-side tagging of Google Tag Manager is HttpOnlyAnd managed by the server A cookie identifier designed to replace a file Managed by JavaScript _ga Cookie used by Google Analytics 4 and Universal Analytics.

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

In this article, I mentioned one caveat to FPID adoption and that is the fact that cross-domain tracking will not work.

I mean how is that possible? FPID is a file HttpOnly A cookie, which means that it is not available to JavaScript in your browser. On the other hand, cross-domain tracking decorates links dynamically when users click on them, which means it needs a cookie to be available via JavaScript so that it can be decorated in the URL of the target page.

Well, Google has now released a solution for cross-domain tracking with an FPID, and it’s probably something you’ve already expected (if you know your way around cookies).


Simmer . Newsletter

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

So, how do you make a file HttpOnly Is the cookie available for javascript?

By creating a copy of that cookie No HttpOnly!

This is what Google did.

If you have administers the server The option is selected in GA4 or UA Client in the server container, it means that the client will write a file FPID A cookie and use it instead of accessing JavaScript _ga Cookie (with some nuances if JavaScript migration option is enabled, but I could digress).

Server Managed Identifier

Now, you’ll see how in addition to FPID The cookie, the HTTP response from the client to the browser also includes a file FPLC Cookie in some requests:

FPLC cookie in reply

This is amazing FPLC A cookie is a cross-domain link cookie that has been hashed from FPID biscuit. it’s not HttpOnly, which means it can be read using JavaScript. It has a relatively short life span, only 20 hours.

This means that if the page loads and the user stays on the page for 20 hours and 1 minute, cross-domain tracking won’t work even if they click on a link with a tagged URL. They will need to reload the page to get the FPLC cookie again. But this may be very rare.

If you configure files Cross Domain Tracking In the 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 on a link flagged for cross-domain tracking, the URL will include an FPLC cookie hash (which is in turn a hash of the FPID cookie) in addition to the normal Google Analytics link parameters.

Google Analytics parameters in green, FPLC in red

Google Analytics parameters in green, FPLC in red

In order for the cross-domain link to work in the target URL, the page must of course be run with the . extension server container, because that’s the only place an FPID is appropriate. Server container captures a file FPLC cookie in request headers, checks that it is valid, then creates a file FPID A cookie with her, if all goes well.

There is an important problem here.

Server containers running on source and target sites must belong to the same Google Tag Manager account!

In other words, it’s okay to have different containers, but they must belong to Same as GTME account. I think it has something to do with how the hash is calculated.

And this is how cross-domain tracking with a server-side FPID cookie works!

Of course it is a bit disappointing that a new cookie is required, when the FPID was intended to move the identifier away from the client. Well, FPLC is not the identifier itself – it’s a hash of the identifier and will never be used as an identifier in requests.

Also, cross-domain tracking happens to always require a client-side component! Due to how browsers work, the only alternative would be an extension fingerprint In the mix of identifier resolution, and that’s a nasty can of worms, I’m sure the Google Analytics team doesn’t want to deal with a long column. Technically though, they actually do some fingerprinting in the link parameter (to make sure the browser is the same between the source and target URLs).

Anyway, this feature is definitely something that many have been waiting for since the release of FPID, myself included.

Source link

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button