Google Tag Manager at The Next Web: The Most Asked Questions!?

Since I wrote this blog post on The Next Web around Google Tag Manager a lot has changed.

We added one more container, we even added more tags and our structure changes on daily basis – affecting the way we handle variables and triggers.

A few months after that post a bigger issue came up, our Google Tag Manager started to slow down a bit and we lost overview of what was triggering at what point. additionally, more questions were raised on how we solve our tag management. So I thought it was time to answer some questions I get on how we solve certain key issues.

How do you handle dozens of triggers?

It’s very hard.

We have so many sub folders or pages on TNW that need their own triggers or have tags. Most frustrating was that we use(d) it for our event tracking.

The data Layer is great for sending and creating triggers, but what if the user clicks an external link and moves away? Chances are higher that the tag can’t be triggered in time to send an event. It’s a small problem for most sites, but at our scale it will hurt our tracking by a couple of percent. Data that we’d rather have in our Google Analytics account.

How do you handle version management?

• Push as fast as we go: On average we push two to three new versions on a daily basis in GTM. There’s always something that’ll change during a workday that we wait for. As most of the work in Google Tag Manager is done by two people, me and our web analist both check if the other is making changes. If that’s the case, we’ll check with each other what the implications are for pushing something live.
• ‘Holding’ Tags: In some cases it’s beneficial for us to already have some tags in GTM but not use them yet – we created a tag for this with a trigger that wouldn’t show anything to the user. It use to have an approval/holding item in GTM for tags.
• Use atomic commits/publishing schedule: Within development it’s normal to commit smaller changes while they’re finished so you will avoid creating massive changes that can’t easily be rolled back. The upside on this is that most versions will be able to rollback very easily . When talking to the product managers of Google Tag Manager, we asked that same question:What kind of behavior do you see with other companies? Their answer: Push new versions as fast as you go so you can keep on iterating. There’s no huge downside to it.

There is a downside to pushing changes fast, as containers are pushed often it could be that the version of the user isn’t cached. This is something that we take for granted to provide an increasingly better user (plus or and here but not the symbol….) tracking environment.

It can seem risky that we push changes fast, however out of 650+ versions of our container we only had an incident twice where we rolled back an older version of the container.

What kind of naming conventions & folders do we use?

With a lot of tags it’s hard to keep overview – folders are an OK solution but don’t provide everything we’re looking for. This is something we’re hoping that the GTM team will fix in the near future.

Naming conventions that we use for Tags:

• GA - Pageview - {Property}: The tags we’ve set-up for sending pageviews to Google Analytics.
• GA - Event - {EventName}: The name of the event we’re sending along for Event Tracking in Google Analytics.
• FB - Event - {EventName}: Events that are send for the Facebook Pixel.
• HTML - {ScriptName}: Code snippets that we load for a better user experience.
• Intercom - {Site}: Interactions with Intercom.io.
• JS - {ScriptName}: JavaScript snippets that we’re using for more advanced tracking.
• Pixel - {Network}: Pixels that we’re loading for other networks then the bigger ones that we’re using.

Folders that we’re using for Tags:

• Data Layer: Collects all the variables we’ve created using the data Layer.
• Facebook: Collects all Facebook Event pixels.
• Google Analytics: Collects both pageview and event tags.
• Intercom.io: Collects all events/interactions with Intercom.io.
• Pixels: Collects all the pixels that we load.

Are you using Workspaces?

Not yet. For now we don’t see the value of using them as explained in the questions around version management. We can handle changes quite fast and without much overhead.

Got more questions?

So what are the issues that you struggled with and how did you solve them? Do you have more questions related to handling 'big scale' GTM implementations? Let me know in the comments.

Want to know more about how we do Marketing at The Next Web. Read more of my posts on The Next Web. Want to know more about how our container looks like, read this post: Google Tag Manager and The Next Web; here’s our container.