While it is possible to use one container for absolutely everything in Opentag, it’s worth thinking about how you’re going to structure the container to handle multiple domains, as well as staging/uat environments.
Opting for this structure allows a very simple process of deploying tags onto your different domains.
For example, if you had four different domains:
Each website would have a different container in the Opentag UI, and a different container code hardcoded onto the website.
If you wanted to add a Google Re-marketing tag to all pages on the .co.uk site, you could add it to the corresponding .co.uk container within Opentag, and easily deploy it without having to add additional custom work.
Staging and UAT environments
We recommend usually having a separate Opentag container in the dashboard for each of the two environments. This allows tags to be deployed and tested on your staging environment, and they can then be easily copied over to the live container and deployed to live when you’re ready.
Duplicate filter logic
If you want to fire many tags under the same criteria, it can be laborious to add the same filter to every single tag, especially if it’s a complex filter.
To handle this, you can use “rule-based dependencies”. To find out how to implement these, visit the dependencies page.
document.write is complex, and is generally considered bad practice by the developer community. To find out more information on how
document.write can interfere with tags, visit the document.write page.
To ensure legacy tags don’t cause issues with your site, you should do the following:
- Ensure any tag using
document.write has the “Script uses document.write” checked in the “Advanced features” tab.
- Enable “delay document.write” in your container options:
- Use newer asynchronous versions of scripts that do not use
Was this helpful? Yes | No