How to Publish a Single Tag (and not others) in Google Tag Manager


Let me know if you’ve heard this one before. You have a developer building out some tags in Google Tag Manager, but they’re not ready to be published yet. They have several tags with major changes, new tags, different triggers and variables. Lots of changes.

Then you get a notification that you need to quickly add a different remarketing pixel to a single page. This is tough at the moment in Google Tag Manager. You don’t want to publish what’s in the container, it’s not ready, but you need to just add a quick tag and get it up on the site.

No problem.

Stop the Presses

First, tell the developer to stop working in GTM while you do your stuff. You don’t want two people interfering with each other during this process.

Find Your Center

Second, go into Google Tag Manager, and on the main Container page look at the green area on the right with the Last Published Version. Click on the ‘view published version’ link there.


Create Anew

Third, on the version page for the published version, there is a blue button on the top right with ‘actions’ on it. Click that and choose ‘edit as a new version’.


You’ll get a popup that asks you to replace the current container draft with the content of this live version. There is a checkbox there to ‘save the current container draft before editing’. Make sure that stays checked, and then click edit as a new version.


The system may spit out a couple of quick messages up top, but you probably won’t get redirected anywhere. Click back to the main container page though and you should notice that the ‘now editing’ version, i.e. your container draft, is now empty.


Be The Change

You’re good to make your single change. Add your new tag, make your single tweak, and then publish your new version.

The Cleanup

Once you’re done with your little change, go back to the ‘view all versions’ page and view the specific previous version that your developer had been working on. (If the live version was 66, and he was working on version 67, you just published version 68. So you’d go back to version 67 in this case, etc.)

Then repeat the process from above from that version, and go to ‘actions’ and click ‘edit as a new version’, except this time UNCHECK the ‘save the current container draft before editing’ button, as you don’t need to make a blank version with no changes in it from the current empty container draft.

Then once you click through there, and return back to your main Container Draft. Your new working version will have the developers work still in there, ready for him to return to it, while your little tweak is now published and live.

You have to add the single tag to this version as well.

It’s a little complicated, but you don’t have to feel like you’re hijacked from making any little changes if you use the above process. Get Tagging!

If you’re looking for additional ideas, we’ve also written about how to accomplish this by using triggers and trigger exceptions. Check out this post on trigger exceptions and pay particular attention to the Blocking – Regular Site Visitors trigger.

Sayf is a former LunaMetrician and contributor to our blog.

  • Matthew

    In my opinion this is complicated and time-consuming. Why not just add a blocking trigger to the tags you have done but are not ready to publish?

    • Sayf Sharif

      That’s a great question, and why we linked to Jon Meck’s post on blocking triggers. For a new tag that isn’t ready to publish a blocking trigger would be perfect.

      However, if you are editing an existing tag… Say you have a pageview tag, and you have added a bunch of changes to the tag like additional custom dimensions, or you are modifying and testing a script in a custom html tag that already exists, if you put a blocking trigger on it, then you lose the current tag. You can’t block a tag your’e modifying from firing, or you won’t get the original one to fire.

      Now you could get around that similarly by copying the tag, making a new tag, etc… but at a certain point, particularly when there are multiple chef’s in the kitchen, that’s simply not practical. When you’re looking at a container draft with multiple changes being affected by an outside vendor, or even multiple outside vendors simultaneously to currently existing tags, simply adding blocking triggers isn’t effective.

      • Elías Nuevo

        Absolutely agree. Blocking rules might not work in all scenarios (trigger vs page load) and having different versions, which you can also rename, is more practical.

        I’d recommend checking previous versions before publishing a new one live, in order to avoid losing tags that other vendor/people might have added.

        • Sayf Sharif

          Yeah there’s lost of room for human error, I agree. Ultimately what I’d love is some sort of branching system. It’s on my christmas wish list.

Contact Us.


24 S. 18th Street, Suite 100,
Pittsburgh, PA 15203

Follow Us



We'll get back to you
in ONE business day.