Cross Domain Tracking
As the digital world becomes increasingly interconnected, businesses face the challenge of understanding and interpreting user behavior across multiple websites or platforms. Cross-domain tracking is a potent tool that helps businesses overcome this hurdle, providing insights that improve marketing decisions and strategies. In this article, we will delve into how to approach cross domain tracking with JENTIS Data Capturing platform and tag management system. With a keen look into the purpose, advantages and technical caveats of cross-domain tracking.
If you want to track your data between your main domain (top-level domain) and subdomains, we recommend reviewing the following guide instead: Main Domain Cookie.
Purpose and Advantages of Cross-Domain Tracking
Cross-domain tracking allows organizations to monitor user activities and behaviors across different websites under their purview. This could include various websites that belong to the same company, or a set of websites that share an affiliation, such as partner websites, third-party tools, or checkout portals. By tagging users with a unique identifier, businesses can trace user journeys across these different websites, gaining a more holistic view of user behaviors.
Questions in such analytical approaches to answer are among "what is the user journey between sites" and "which channel touchpoints my users have on a global level". So there is a high demand and value in this data.
The primary purpose of cross-domain tracking is to provide a comprehensive understanding of user behavior across multiple digital touchpoints. Without cross-domain tracking, analytics tools would view each site visit as a unique session by a different user, distorting analytics data and undermining its value for strategizing. Cross-domain tracking thus allows for the consolidation of user interactions, paving the way for precise performance measurement and efficient strategizing.
Advantages of Cross-Domain Tracking
Accurate Analytics: Cross-domain tracking provides a more accurate representation of user behavior, consolidating interactions across multiple domains into a single user journey. This results in more reliable data for analysis and decision-making.
Enhanced User Profiling: With a better understanding of user behavior, businesses can create detailed user profiles that facilitate personalized marketing, leading to improved conversion rates.
Improved Conversion Attribution: Cross-domain tracking lets businesses understand which platforms and touchpoints contribute most to conversions. This understanding helps in refining marketing strategies and allocating resources more efficiently.
Superior User Experience: With insights gained from cross-domain tracking, businesses can enhance user experience by making improvements and optimizations across their platforms based on real user data.
In conclusion, cross-domain tracking is an invaluable tool in the modern digital landscape. It gives businesses a comprehensive, realistic view of user behavior across different domains, driving informed decision-making and facilitating superior user experiences. As businesses expand their digital presence across multiple platforms, adopting cross-domain tracking becomes not just beneficial, but essential for sustainable success.
Technical implementation and challenges
The implementation of such an approach is not easy. As there are limitations for very good reasons: privacy is important. And thus data can not be shared in a third party context (based on the domain the user visits) easily.
The option to share the data between domains has one window of opportunity. That is when the user actively clicks on a link on one domain (website-a.com) and there navigates to the second website of the same provider (website-b.com). Here a method can be leveraged to activate the consistent data: link decoration.
Link decoration refers to the method where a common identifier will be appended to the target URL on the click. When accessing the next website it will contain this identifier in the URL and the receiving system can stitch this session together into one journey of this single virtual user.
Implementing this requires two functions: decorating the link on click and receiving the data on the next website. Lets run through both operations in a JENTIS tool configuration example.
Implement the link decoration
Let's get the first part running. Add the following script to your JENTIS container (Server Side Tag Manager: Codes) that should decorate links from the current domain to any other domain.
The trigger for this code should be "Page Load" or a similar trigger that activates the code on all relevant pages.
If you wish to adjust this logic of "all other domains than the current" to only a specific target-domain adjust this section in the code accordingly:
- `url.hostname !== currentDomain` to `url.hostname == "www.website-b.com"` (to only decorate links that actually link to the "website-b.com")
var queryParamKey = '_jtsuid';
var link_decor_done = false;
// append cookie values to links on click, only if the link's domain is different from the current domain
function decorateLinks(){
var allLinks = document.getElementsByTagName("a");
for (var i=0, max=allLinks.length; i < max; i++) {
allLinks[i].addEventListener("click", function(e){
var jtsuid_value = encodeURIComponent(window.jentis.tracker.readDocumentID("user")); //current user id value
var originalHref = this.href;
var url = new URL(originalHref);
var currentDomain = window.location.hostname;
if (url.hostname && url.hostname !== currentDomain && url.searchParams.get(queryParamKey) === null) {
url.searchParams.append(queryParamKey, jtsuid_value);
this.href = url.href;
}
});
}
link_decor_done = true;
}
//if user id is not yet defined, ie. because no consent was given yet at this moment,
//switch between awaiting the consent signal first or simply apply it as it is available immediately
if(window.jentis.tracker.readDocumentID("user") !== null){
decorateLinks();
} else {
if(typeof window.jentis !== "undefined" && typeof window.jentis.consent !== "undefined" &&typeof window.jentis.consent.engine !== "undefined"){
//If the engine is allready loaded, we maybe missed the events, so we want to register at the engine instead of the document.
var oEventBaseObject = window.jentis.consent.engine;
} else {
//No engine allready exists, so it is safe to register at the document.
var oEventBaseObject = document;
}
//Now listen to the Init Event of the Consent Engine.
(function(oMe,oEventBaseObject){
oEventBaseObject.addEventListener('jentis.consent.engine.send-consent-data',function(e){
if(!link_decor_done)
decorateLinks();
});
})(this,oEventBaseObject);
}What this code does is to create a "click"-listener on all anchor (<a...>) elements on your website. Then a query parameter `_jtsuid` is append to the target URL with the current user-id.
Now the receiving website must catch this value and apply it.
Implement the receiving end
Add the following code snippet to your JENTIS Server Tag Manager. Again this element must trigger on all pages to make sure the user-id can be received on any page.
Hint: you must select the trigger "Before JENTIS Bundle Load". This will make sure this code is executed before the native JENTIS code will generate a user-id.
var queryParamKey = '_jtsuid';
var location = new URL(document.location.href);
var queryParamVal = location.searchParams.get(queryParamKey);
var temp_cookie_name = "jts-rw";
if(queryParamVal && document.cookie.indexOf(temp_cookie_name) == -1){
queryParamVal = decodeURIComponent(queryParamVal);
let cookieValue = '{"u":"'+queryParamVal+'"}';
document.cookie = temp_cookie_name+"="+cookieValue;
}This code will receive the same query parameter that was used in the decoration. If no "jts-rw" cookie exists yet and such query parameter is found in the URL a temporary cookie will be written. This is to set a surrogate user-id that JENTIS native code will then pick up and from that create all internal derivates based on this user-id. The temporary cookie will be replaced by the proper "jts-rw" cookie and will not interfere.
Meaning that the existing user-id is only applied on this new domain (ie. "website-b.com") if the user has not previously visited the page (and hence already had a user-id defined).
In result that the user-id is now the same on both websites (website-a.com and website-b.com) any data that is processed by JENTIS DCP server side it can be connected and access the same server-side storages. For tools that for example have a "client-id" defined on server-side (for instance GA4 Server-side tool in JENTIS) this client-id will have the same value for the JENTIS container on website-a and website-b.
Compatibility Notice
Please be aware of the usage of the "URL" class in the code that is not supported by all browser versions. Visit this site for a full compatibility overview: MDN URL Class
Caveats of Cross-Domain Tracking
Now that we have all set up to decorate links and receive the user ID to have fully consistent data, let's also put some light on possible limitations of this solution.
There are two very important topics that you must be aware of:
Link Limitation
Only when a user actively clicks on a link from website-a.com to website-b.com the user-id is shared. If the user visits website-a and later manually navigates to website-b.com (or by any other referrer or external campaign), the data will not be shared.JENTIS Tool Storage Sharing Limits → Resolved
In JENTIS, you can now connect two or more different tool configuration instances to use the same server-side storage. Everything is linked to the User-ID, ensuring seamless integration and consistent data management across tools.Currently the data between different tool configuration instances (ie. a "GA4 - website-a.com" tool in your account and a "GA4 - website-b.com" tool will have different client-ids as the data between tools is not shared; the same client-id can only be used when you have one tool instance and define it to apply to both websites by selecting both containers on that tool).JS Browser Compatibility
Please see the note of compatibility notice above, not all browsers support the URL interface. But in general we expect more than 90% of the users run a browser that is compatible as a general indication.User-ID Overrride
If the user visited website-b.com before (and has a user-id already assigned) then comes to website-a.com and there clicks again on a link (that is now decorated) to website-b.com the receiving end will not override the previously existing user-id.
With all that acknowledged, you should be all set and ready to go to enhance your analytics.