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. We will cover how server-side 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.

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, and it’s also the reason many teams look into how to run GA4 without cookies, since session continuity and cross-domain tracking depend on these server-managed identifiers.

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

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 or Stape Store to preserve cookies on one site and extract them on another. Since you will use one Firestore collection for both sites, if you configure with Firestore, ensure both have access to the same Firestore database.

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.

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. Configure the Cookie reStore tag.

Choose the database for this setup - Stape Store or Firebase. For this article, we will consider the setup using Firebase in detail, as this configuration is more complex than with Stape Store.

Check the box “Only restore cookies” if you want to prevent saving cookies to Firebase or Stape Store. The option is useful if you want to sync cookies between sites only in one direction.

To complete the setup with the Stape Store, add identifiers and cookies that need to be restored.

Requirements:

• The same server GTM container has to be used by both websites.
• Stape Store has to be enabled.

To set up a tag using Firebase, add Firebase path and Firebase Project ID. Make sure that you've connected Google Service account to your Stape.io containers.

• 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 the Cookie reStore tag triggers. 
• Firebase Project ID - add Firebase project ID. Tag uses a default project ID connected to your service account when empty. 

Add cookies that should be stored in Firebase. We will use first party _ga cookie as a unique user identifier. To have the same user identifier on the destination domain, we've set up cross-domain GA4 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 _gl linker parameter will be added to the destination URL. This parameter contains the encoded values of _ga cookie (Client ID), _ga_<Measurement ID> cookie (Session information), among other information.

When the user lands on the destination website, the cookie _ga will be recreated with the same value as the previous website. We can read it by creating a cookie variable.

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 user_id parameter that uses _ga value extracted from the cookie.

5. Once you’ve finished the setup, open sGTM previews, Firebase, and console to make a test. In my case, I checked that the 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. 

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.