Google Tag Manager Disaster Recovery Guide
Some day, even after diligently testing, you may publish a new version of your Google Tag Manager container and disaster will strike. The site, or some critical site function, will break. Or tracking will drop to zero. (Or both!) Will you be ready to fix things?
It’s as easy as “the click of a button” to revert to a previous, working version of your tag container, according to many articles about Google Tag Manager. What most of these articles do not say is which button to choose.
Yes, there’s more than one way to restore a previous version.
First, find the version you want to restore
No matter which option you choose, first you must navigate to the previous version you want to restore. Under “Versions” in the left navigation, you’ll see all of the versions ever created, in descending numerical order.
If you’ve given each version a name (highly recommended, as it helps you remember what changed in that version), they will still be sorted by version number.
For example, here we see five versions in reverse order: from version 5, Auto Cross Domain Tracking, to version 1, Initial Version No Tags.
Let’s suppose that I did something wrong when I implemented version 5 and now I want to revert to version 4, Image Link Click.
I’ll select “Image Link Click”, the version I want to restore. This will bring up the full description of version 4, including all the tags, rules, and macros, along with a row of buttons across the top of the screen.
Which button do I choose?
Option #1: The Restore Button
If I mouse over the first button, the one with two circling arrows, I’ll see pop-up text that says, “Restore version.” Sounds good, right?
Unfortunately, when I click that button, “Restore version” does not re-publish version 4 right away. Fortunately, I also get a message saying so.
Instead, this action (“Restore version”) will replace the current container draft with the content of the selected version, version 4.
Is this what I want? The answer is: maybe. Let’s see what happens.
If you choose this option, make sure you check the box to create a new container version from the current draft. If you don’t, you’ll lose any work on tags in progress since the last time you created a new version.
So if I click restore, what next? I’ll need to go to the container draft (which now contains everything from version 4), create a new version, and publish it. Not exactly the one-click process I was expecting, but it gets the job done.
The result is the new list of versions shown here.
Version 7 is my latest published version, which is the same as version 4. (And I’ve given it a name to remind me.) Version 6 is the copy of my container draft. It has any tags I was working on when I found out version 5 was not working.
We’ll come back to this list later.
Now let’s see what happens if we choose option #2. It turns out that this is the one-click option.
Option #2: The Publish Button
Suppose that, after selecting version 4 in the versions list, I decide not to click the “Restore version” button. Instead, I click “Publish” as shown here.
What happens to my container draft, and what happens to my list of versions?
My list of versions in the left navigation looks exactly the same as it did before, even though the “live” version has changed. I haven’t added any versions to the list as I did with option #1, but to see which version is actually the live version, I must look at the Overview.
The other result is that the container draft is also unchanged. I didn’t put version 4 back into the current container draft, and I didn’t save the existing draft as version 6, I just left all my tags in progress as they were.
This sounds better, right? I only have to click one button, and I don’t have to make any extra versions.
It sounds great, until I remember that the current container draft also still contains the errors from version 5.
I haven’t diagnosed what’s wrong with version 5 yet because I wanted to revert to version 4 as fast as I could, to get things working again.
Which option is best for your situation?
To some degree, this is a matter of personal preference. Additionally, your workflow (or your team’s workflow, if multiple people are responsible for editing the tag container) may dictate the use of one option over the other.
Consider the time and effort it will take for these two tasks:
- Tags in progress: How many tags have been developed since the last published version? How complex are they? Will you have to copy them into a new container?
- Troubleshooting: How many tags were new in the last published version? How complex were they? How difficult will it be to find and fix the errors that caused things to break?
If you think you can find and fix the errors easily, or there are so many tags that have been developed since the last version that it will be a pain to copy them all into a new container, then option #2 (one-click publish) is probably right for you.
Conversely, if you think it will be difficult to find and fix the errors, or there are so few tags developed since the last version that it doesn’t matter that you have to copy them into a new container, then option #1 (restore, create new version, and publish) is probably right for you.
If your situation lies somewhere in between, then you’ll want to weigh the effort of fixing errors against the effort of reproducing tags in progress to find the least painful solution.
See the official documentation for a good description of how container drafts relate to published versions.
Final reminder: Tag Manager won’t have any record of tags in progress if you choose option #1 (the restore button) and fail to check the box!
What’s your disaster recovery plan? Do you use both of these options in Google Tag Manager depending on the situation? Or do you strongly prefer one option? If so, why? Please share in the comments.
