Go to Qubit

Opentag documentation

Best practices

Make sure your implementation goes swimmingly.


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.

Multiple domains

Typically what we recommend here is to have one container for every domain within the Opentag UI. Each container corresponds to a different JavaScript file on our CDN, so a slightly different code snippet should be added to each of your domains.

Opting for this structure allows a very simple process of deploying tags onto your different domains.

For example, if you had four different domains:

  • .com
  • .co.uk
  • .fr
  • .de

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

Was this helpful?