Server-side cross-domain tracking using Cookie reStore tag

The process of cross-domain tracking is complicated, even for browser tracking. A list with requirements should match in order for cross-domain tracking to work properly and accurately - besides that there are different technologies used when setting up your own implementation.

Cross-domain server-side tracking can be even more frustrating. I will cover how ss cross-domain tracking works in this article and some related topics such as Google Analytics server-side tracking, use of FPLC cookies and Stape's Cookie ReStore tag that can help reuse cookies across domains.

Server-side Google Analytics cross-domain trackingCopy link to this section

Cross-domain tracking allows seeing users who visited two different domains as a single session instead of two separate sessions. It helps to measure user journeys more accurately. 

Google Analytics keeps track of user sessions by generating a unique client ID (_ga) for each one. This way, it can tell if someone is returning or new to the site. 

When Google Analytics links users between different domains, it will use the same client ID for both websites. The client ID is stored in the browser's cookies. When cross-domain tracking is enabled, web GA will add a linker parameter to URLs that point to the destination domain. 

This URL parameter contains the client ID, timestamp, and browser metadata. On a destination domain, GA will check for the parameters in the URL, and if it finds linker parameters, then GA extracts the client ID from the parameter and stores it in cookies.

When you switch over to the server-side Google Analytics and server-managed cookies, a new FPID cookie is created. This one replaces _ga and has an HttpOnly flag, meaning it is not accessible by JavaScript. This is when complications start.

We already discussed that web GA cross-domain tracking uses client ID (_ga cookie) and adds linker parameters to the destination domain. Since the FPID cookie is HttpOnly, it’s impossible to read and add it to the URL since JavaScripts can’t access HttpOnly cookie.

To eliminate this issue, Google created a new FPLC cookie. 

FPLC cookie for cross-domain trackingCopy link to this section

FPLC is a hash of FPID cookies, and it’s not HttpOnly, which means that JavaScript can access FPLC and use it for cross-domain tracking. 

There are a few critical nuances that you should be aware of before setting up cross-domain tracking for ss GA:

•  FPLC cookie lifetime is 20 hours. It means that cross-domain tracking will only work if a user clicks on a destination URL in less than 20 hours after they landed on a site. Assume, there will be close to 0 cases when a user stays on a page longer than 20 hours and clicks the destination URL.

• Both websites should use server-side tracking. Since FPID and FPLC are available only for ss GA, both sites that you set up ss cross-domain tracking for must use ss GA. 

Similar to web GA cross-domain tracking, after you’ve set up ss GA cross-domain tracking, GA will add the FPLC parameter to the URLs of the destination site. The server container of the destination site will catch the FPLC parameter from the URL and set FPID. 

How Cookie reStore tag worksCopy link to this section

Server-side cross-domain Google Analytics tracking helps only with GA tracking on different domains. But what if you want to pass other cookies from domainA.com to domainB.com. To help address these issues, stape created Cookie reStore tag for server Google Tag Manager. 

The cookie reStore tag is designed to store user identifiers and their cookies in Firebase and restore them when you need. To make this tag work, you must pass any user identifiers on the first site and use the same user identifier on another site to extract cookies.

There are no restrictions on the type of user identifier and it's number. It could either be an email address or some other kind of unique identifies, like user ID in the CRM, cookie, etc.

Cookie reStore tag use cases:

• Cross-domain tracking
• Cross-browser tracking
• Setting correct UTM tags
• Basically, any situations when you need to store and extract cookies of the same user

The cookie reStore tag uses Firestore to preserve cookies on one site and extracts them on another. Since you will use one Firestore collection for both sites, ensure both have access to the same Firestore database.

Firebase Path - path to Firebase collection that should be used to write/read data. The tag will create a new Firestore document in a specified collection every time cookie reStore tag triggers. 

Firebase Project ID - add Firebase project ID. Tag uses a default project ID connected to your service account when empty. 

List of identifiers - add user identifiers that should be used to identify the same user.

List cookies that need to be restored - list of cookies and their lifetime in seconds that should be stored and restored. 

How to use Cookie reStore tagCopy link to this section

In this example, I will store fbc, fbp and channel_flow cookies on the site https://wp-demo.stape.io/ and restore them on https://stape.dev/. 

To set up this tag, I need: 

• Both sites using server-side tracking via sGTM.
• Cross-domain Google Analytics set up, since I will use _ga as a unique user identifier.
• Google Service account created and connected to both containers in stape.io power-ups. Firestore permission set up for service account. 

Let’s get started with setting up the cookie reStore tag. 

1. Download Cookie reStore tag from GitHub -> Open tag templates sections in the server Google Tag Manager container -> Click New -> Import reStore tag template you’ve recently downloaded ->  Click Save.

Download and import the Cookie reStore tag for all sites that you need to set up cross-domain tracking for. In my case, I’ve added Cookie reStore tag template to https://wp-demo.stape.io/ and https://stape.dev/ sGTM containers.

2. Create a cookie reStore tag. Add Firebase path and Firebase Project ID. Make sure that you've connected Google Service account to your stape.io containers.

Add cookies that should be stored in Firebase. I will use first party _ga cookie as a unique user indetifier. To have the same user identifier on the destination domain, I've set up cross-domain UA tracking. 

3. When a user visits wp-demo.stape.io, they can click a button and land on another domain, stape.dev. Every time a user clicks on the outbound link, the _ga linker parameter will be added to the destination URL. 

To extract the _ga parameter from the URL on the destination site, I’m using the split string variable available in the sGTM template gallery. 

4. In the sGTM container of the destination site (stape.dev), I’ve set up a cookie reStore tag that extracts and sets fbc, fbp, and channel flow cookies from Firestore based on the client_id parameter that uses _ga parameter extracted from the URL. 

5. Once you’ve finished the setup, open sGTM previews, Firebase, and console to make a test. In my case, I checked that cookies wp-demo.stape.io  match stape.dev cookies, and corresponding records were created in Firestore. 

6. Do not forget to publish updates for both containers once you’ve done with the setup. 

Conclusion:Copy link to this section

Hope this blog post sheds more light on cross-domain server-side tracking. We've discussed that Google Analytics has a native solution for cross-domain tracking that uses a new FPLC cookie that can be accessed by JavaScript and pass these cookies between different domains.

If you need to store and restore cookies cross-domains, cookie reStore tag might be the best solution. It stores unique user identifiers and cookies in Firestore and then uses the same unique identifier to restore cookies on a destination site.

I hope this guide will help you set up cross-domain tracking for the server-side tracking. If you need help setting up ss track feel free to reach out.