Make INSTANT tag changes using sGTM

Summary

When you publish changes to your Google Tag Manager (GTM) container, it is possible the changes are not instantly live.

This post demonstrates two techniques that enable instant changes to GTM containers - 1 desirable, one to watch out for!

GTM versions get cached

Browsers can cache assets like images, and JavaScript libraries. That's good because it makes the internet feel faster. It also means changes to your GTM container may not get refreshed immediately.

Our handy chart of GTM container versions below shows how our versions sometimes overlap.

Consider a potentially even worse use case where a user has left their browser open with one of your pages...and they return to click, do something, even purchase. The last loaded container version will be the one that's used.

You can avoid caching and stale versions by using server-side Google Tag Manager - sGTM - with some caveats and watch outs!

sGTM is live now

When you publish a change to your sGTM container, it's live. Not cached by a browser and even if the "Johnny-come-lately" with the old page in their browser comes along, the tag request sent to the server side container will hit the latest version.

Neat, right? But how do you see this in GA4, for example?

Avoiding stale GTM versions requires a reliable version data point. I've long been a fan of setting the container ID and version in the GA4 event settings:

Client side only, that works fine and dandy thank you. More or less...but there can be issues. Read on:

GA4 Configuration changes can affect GTM/gtag

When you enable Enhanced Measurement in GA4, the resultant measurements will use your event settings variable. You cannot distinguish between your tags sending data to GA4 and that sent by enhanced measurement.

See here where my GTM container didn't fire a tag on History Change:

But the gtag did send data:

And you can see it used the event settings:

So how can you see the source of the GA4 event?

The solution is simple enough. You could use a naming convention but that lacks version information. For the solution to be robust and complete, add an event parameter to your tag like so:

Then you see events with the initiator payload - they're your tags, enhanced measurement doesn't get its hands on your tag settings:

On the server side, we add a server side initiator value:

The case for custom events configured in GA4 requires another approach. The custom event is still very much based on the original event so it will include our new initiator parameter. When setting up the custom event, you can further modify the event parameters but it is limited. Ideally, we'd add a prefix to the initiator value to flag the event source using a 'ga4 - ' prefix for added clarity. This ins't possible, you get a value of 'ga4 - [[initiator]]'

So, you can, at least, delete the initiator event parameter from the event that wasn't strictly from GTM:

And then, if required, add a new event parameter with a modified name:

This is now visible on the event payload, and so is also visible in preview mode:

And in the DebugView:

side note

I'd love to see modified event parameter values, and I think filtering event based on parameter values will be a superb additional feature to the BQ export.

Now you can see what system is responsible for generating the data, and which version of GTM was used - great for filtering old data from new.

One more thing - don't have nightmares

When you change settings in GA4 around enhanced measurement, and modified/created events, they're applied really quickly.

I found this out when I unexpectedly saw these TWO events being collected in testing:

2 page_view events going to two different measurement ids. Huh? Where did G-WH0RF7M2XE come from?

I had been experimenting adding another destination to my gtag:

Turns out G-WH0RF7M2XE has enhanced measurement turned on! Now to get rid of the extra destination - good luck with that:

One does not simply remove a destination, it must either be reassigned, or the stream where it was configured needs to be deleted:

And having done so, my client side data stream is clean, and G-WH0RF7M2XE is immediately removed from my data collection:

Takeaways

Given what the article has covered, consider these takeaways

• You need to know where and how events are triggers with accuracy

• Think really carefully about using enhanced measurement

• Be careful which events are created/modified in GA4

• Add an event parameter to your Config tag - see when it's being used by enhanced measurement