With over a dozen years of experience working with tag management solutions, I’ve seen all sorts of implementations. This isn’t considering details like variable assignments, but things like how rules are built out, how logic is assigned, timing of events, and the general structure of the EDDL.
Each implementation I’ve worked on in some form or another has given me valuable insights. Whether it’s how to optimize or frankly what not to do. There are too many details of tag management to fit into one summary, so I thought I’d start at the top with how to approach multi-site tag management.
Whatever the scenario, if you have multiple domains or sub-domains that require tag managers, it’s best that you understand your options. We’ll try to break it down into a few different scenarios.
Each site has its own unique event and data layer requirements.
If each of your sites is built on different on platforms, different frameworks, or simply with a different set of standards your best option will be to set up an independent tag container for each site.
This allows you to customize your logic for each site as needed, this avoids adding unnecessary Javascript logic within the container for the other sites. I’ve seen organizations with a dozen sites setting up rules for each domain with the same exact script, just swapping out the site IDs. This means the container has to load and evaluate the rules for all other the other sites, which may not be the most impactful script on your site, but it adds fuel to the fire.
The best part is in the long run, you can continue to build a global container if you decided on standardizing events and the data layer. When standardization is complete, you can simply swap out the containers or run simultaneously until you’re ready.
Global Events and Data Across Sites
This is the most ideal scenario and a target if you’re hoping to bring to efficiency to your analytics and tag management projects. Building out a standardized set of events and data objects across sites will provide exponential returns in time, performance, and quality of data.
Even with a perfectly standardized EDDL, the key still rests in how you’ve completed the implementation. The most important thing to remember is that you must keep repetitive code to a minimum. If you’re repeating the same code more than twice and simply swapping out IDs, you’re doing it wrong.
The best place to base your logic for a standardized set of sites is above the site/domain level. This means writing your rule/tag logic so that it takes into account the site and event requirements at the same time. This is counter to the above image which takes into account site and then applies the tag/rule logic.
Here’s a simple example, however in this case we’re still managing which site needs the tracking in two places. Once in the rules conditions and once in the data element or variable which maintains the tracking IDs for a given tag across sites.
A way to improve on this is to change the condition from being an explicit set of OR statements, to checking the data element or variable for whether or not a set of tracking IDs exist for the site or domain, and if so continue to executing the rule. Below is a sample of how you could possibly achieve this in Adobe Launch.
Sample Data Element or Variable
var pixelId = '';
var webLocation = window.location.host.split('.')[1];
switch(webLocation) {
case 'example1':
var pixelId = {
'domain': 'example1',
'pixelId': '12345'
};
break;
case 'example2':
var pixelId = {
'domain': 'example2',
'pixelId': '67890'
};
break;
case 'example3':
var pixelId = {
'domain': 'example3',
'pixelId': '45678'
};
break;
default:
var ttdPixelId = '';
}
return pixelId;Custom Code for the Condition
var pixelIds = {{pixelId}};
if(pixelIds && pixelIds.domain){
return true;
}Now, when we need to add the same vendor or tag to another domain or site, we simply need to update the data element and the rule will take care of itself!
