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 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.
To eliminate this issue, Google created a new FPLC cookie.
There are a few critical nuances that you should be aware of before setting up cross-domain tracking for 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:
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.
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:
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.
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.
By the end of 2024, Chrome and Chrome-based browsers will be done with third-party cookies. Safari and Firefox already implemented Intelligent Tracking Algorithms that can block trackers. That leads to the next point: digital advertising methods that rely on third-party cookies to target consumers might become ineffective or even stop working altogether. This change in how advertisers track users will hurt many publishers and ad networks that rely on these third-party companies to display ads and collect data from site visitors to understand their audience. In this blog post, I will explain what a third-party cookie is, why it matters, and how server-side tracking can help businesses transit to the world without third-party cookies.Apr 9, 2022
Learn how to create a Google Service Account and connect it to your stape container in this step-by-step tutorial. Doing so will allow you to integrate server Google Tag Manager with BigQuery and Firestore.Apr 26, 2022
This blog post will show how to write data to Firestore from the server Google Tag Manager container. I’ll also show how to use the Firestore Writer tag and Firestore Lookup variable to enrich server-side data.