The Marketing Technologist.

We talk about analytics, code, data science and everything related to marketing technology. Backed by the tech geeks of Greenhouse Group.

Every tag manager setup needs a general blocking rule

A tag manager allows you to disconnect your marketing tags from your website. It puts the control of these tags in the hands of the people who use them: marketers. It also disconnects all the tags from your developers. This is good for flexibility, but not quite as good for developers as they lose control of the scripts that run on their website and the errors they may cause.

Speed is key

If the website triggers an error that causes a part of the website to stop working, you’ll need to fix this as soon as possible. I've experienced multiple occasions where the issue seemed to be caused by 'the tag manager'. If the tag management team is not quick in replying to such issues, developers might opt for removing the tag manager altogether. Why wouldn’t they? A working website without measurement always beats a non-working one with measurement. It's a good reason to give developers a way to check if tags are causing the issue.

A blocking rule to rule them all

Besides rules that fire tags, tag managers allow you to add blocking rules. Creating a blocking rule that blocks all your tags in a given condition (e.g. URL contains block=all) allows developers to answer one simple question: does anything from the tag manager cause the issue? Optionally, you can add blocking rules for high-level categories of tags. They'd give insights in what types of tags are causing the issue:

  • Analytics tags: analytics tooling (e.g. Google Analytics) and other data loggers (e.g. Snowplow).
  • Marketing tags: conversion tracking and remarketing data (e.g. AdWords, AppNexus, Facebook).
  • Other tags: tools that don’t fall in the other two categories, such as research tools (e.g. Hotjar) or AB testing tools (e.g. Optimizely).

If you allow developers to block tags themselves, they gain just enough insights in the issues to better inform you. Instead of sending “we have an error that’s probably caused by the tag manager”, they can now verify if it’s really caused by the tag manager by blocking all tags. If you have set up the blocking rules per category, the can even check what category of tags is causing the issue.

A little effort can go a long way

That’s it, you’ve given developers some extra insights in possible issues caused by the tag manager. Just don’t forget to tell them they can use the rule(s) described in this post.