How to De-Implement TDI

While we hate to see customers leave, we do want to make their transition as smooth as possible. It may be verboten in the business world to decrease the "lock-in effect," but as a core tenet of our open and accountable business model, we want customers to stay with Mezzobit for the right reasons: our tools deliver continuous value to your company and our worldview on data and how to handle it align with what you want from a trusted partner.

Here are some considerations for migrating off the Trusted Data Interchange (TDI) platform:

Migrating from TDI to another tag management platform

This is the easiest scenario. If you only have a single environment (just production, no development or QA), there are two ways you can do this:

Automated hand-off

  1. Copy the tag code from TDI and set up tags in the new TMS. Alternately, if your new system has templates for commonly used tags, you may only need specific account information to set up new tags. For tags with visual components, copy their page location to the new system.
  2. Set up a new container or whatever their equivalent is in the new TMS. Make sure that the container is not activated.
  3. Perform testing to ensure the new containers and tags are configured properly.
  4. Embed the new container in the target webpages.
  5. Set the activation date/time on the new container to when you want to perform the cutover.
  6. Set the TDI container to deactivate at the same time.
  7. The systems will automatically deactivate and activate at the zero hour.
  8. Once the cutover has occurred, remove the TDI container code from all pages/templates (or comment it out for the short-term and remove it once your new system has completed burn in).

Notes: You can specify activation/deactivation triggers down to the minute in most systems (TDI included). But this may result in tags not properly firing (either missing or doubling for a few seconds) at the exact time of cutover. Manually handling the cutover (simultaneously flipping TDI off and the new system on) will not achieve greater time-based control due to lags in how tags are propagated to content delivery networks. It is often preferable for there to be a gap in tags firing than having tags double-fire, so you may prefer to put a one-minute gap between the two systems to ensure a cleaner hand-off.


Manual hand-off

  1. Configure your new system as above, except activate your new container.
  2. Manually edit your webpage or CMS template to include the new container code and remove or comment out the TDI container.
  3. Commit the changes and the cutover is complete.

Notes: This method works well if there is a single point of integration for a TMS. If you have multiple templates, you may not be able to cut over the entire site to the system all at once using this method.


For customers with multiple environments (development, QA, staging, etc.), switching TMSes is like any other code update, albeit a bit more impactful to site operations. The preferred method is to preconfigure the new system's container as above and push the code to production across the entire site. This gets around the limitation in the manual method and doesn't require the synchronization in the automated method (as the old TDI container will simply be pulled from production instead of just being deactivated).


Migrating from TDI to a manual tag environment

Perhaps you would like to return to managing your tags manually. This is little more complex than switching systems, as you have to redeploy of your old tags into your website instead of just switching A for B. Also, many of the intricacies (and some say, nastiness) of managing tags have been handled automatically, so you'll need to do a bit of research before resuming manual control. If you're embarking on this project, feel free to open a support ticket, and our client support team can provide some advice.

As with a TMS migration, life is made substantially easier if you have multiple environments: just make the changes specified below and push them as a single release (after extensive testing, of course).

Here are the steps to take if you are a single-environment shop:

  1. Collect your tags: Within TDI, the tag list view contains all of the tags for your system, both active and inactive. You'll need two tools at this point: a plain text editor and a spreadsheet. Using the plain text editor, copy the code for each tag from TDI and paste it into the editor, making sure to properly label the tag. Using the spreadsheet, record any relevant metadata about that tag needed for configuration, such as geotargeting, activation conditions (rules), and visual placement.
  2. Determine your deployment strategy: Now that you're redeploying tags to your site, you can use this as an opportunity to fix some problems that your site had before TDI. Do you want to deploy tags as external JavaScript files or embed them directly in your page? How do you want to handle this in your CMS or blogging platform? Do you want to centralize the JS or scatter it throughout? Do you need your tags to follow the same rules they did in TDI or are you fine with them executing globally without restriction?
  3. Build out deployable code: Using the plain text code snippets you extracted some TDI, build out the actual code you want to deploy to your site. In some instances where there were TDI rules governing tabs that you wish to duplicate, you will need to write some custom JavaScript to handle this. Alternately, if you work on WordPress or a CMS with extensive plug-in libraries, do a search to see which tags can be handled via plug-ins. Select the best plug-ins for your business environment and download and install them.
  4. Test: Create a local HTML page that is a duplicate of your site's home page. Plug in your code fragments and test whether they fire correctly. You can use some of the tools listed in the Quick Start Guide to monitor your tags. Also make sure that tags that have visual elements like ad units are displaying in the correct location.
  5. Prepare for deployment: The trick to deployment is to ensure that your site is not double-firing tags and minimize the time (if any) when no tags are firing. For changes involving your CMS or normal web pages, edit your page or CMS templates to reinsert the tags. Also apply commenting code to the TDI container (insert <!-- immediately before the container and --> immediately after it) that will temporarily disable it but permit the container to be quickly re-enabled if needed. You can see what your container code looks like within TDI, but here is the general format, including the commenting codes (the alphanumeric blocks on the third line will be different for each customer):
    <script async>
    (function() {
      __mtm = [ '52922a6c400031a713000099', '', '' ];
      var s = document.createElement('script');
      s.async = 1;
      s.src = '//' + __mtm[1] + '/mtm.js';
      var e = document.getElementsByTagName('script')[0];
      (e.parentNode || document.body).insertBefore(s, e);
  6. Commit: Save your changes to go live.

WordPress users may have a slightly more complex rollback process, as some of the tags will have to be managed by special plug-ins and others will be handled through template modifications. But the basic process is still the same.

If you recently deployed TDI and followed Mezzobit's recommendations, you should have "commented out" your tags instead of removing them from your website. If this is the case, then all you need to do is step 5, except you'll simply uncomment your legacy tags instead of inserting the new code.

Have more questions? Submit a request


Please sign in to leave a comment.