Making Sense of Your Tag Containers

Since I started at PMG about a year ago, we have used a set of Best Practices that we enforce on our own and client’s sites when implementing tags. We use them because like everything else in the universe given enough time, tag containers tend towards chaos. Users pop in to add the pixel that they need, but rarely ever spend time to see what can be removed or re-used, and when you have a client that has been with several agencies and internal implementors in the past or currently, it’s easy to see how quickly a container can become a tar pit of forgotten pixels.

In this series, I’ll pass on some of the basic and advanced tips that we use at PMG and some that I’ve picked up from other client implementations to help us all tame our tag containers. It’s mostly based on Google’s Tag Manager, but the tips and tricks are general enough that they can be implemented in any tag management software. In this part, we’ll start with the fundamentals of naming our tags, triggers and variables.

Nothing is worse than getting into a container for the first time and not being able to tell if the last person in there was inhabiting the same planet as you. That’s why there is value in taking extra time to make sure that the next person understands your thinking and using verbose naming is the first step to doing just that.

At PMG, we’ve standardized our tag naming with the following convention:
Implementing Agency or Client Name - Tag Vendor - Load Rule/Page - Scope

A couple of benefits are obvious right away, the main being there is accountability attached to the tag. If a question arises concerning whether to prune this tag, we know exactly which agency to contact for the answer or if we

should contact the client for the information. In addition, if the implementing agency is no longer with the client, the next person who has to manage the container will right away know that this tag is no longer necessary and can be removed without firing an addition neuron.

Another rule I picked up from a client who was already very good at maintaining their container, is adding an expiration date to the end of the naming convention. This particular client mandated expiration dates even if the tag did not have one explicitly because like even the most delicious glass of chocolate milk, all tags eventually expire.

Naming triggers is a little different from tags as they generally do not expire, but can go bad due to site changes and updates. We like to use the following naming convention.
Event Type - Page - Filters - Scope

Let’s use the made up trigger Page DOM Ready or VPV - All Jackets - Add to Cart - North America for example. Up front in the trigger’s name we can tell when to expect a fire in the page’s timing. This trigger is supposed to fire on either the DOM Ready event or a Virtual Page View, which also makes obvious that this trigger should account for AJAX requests or other non-standard page navigation that might be in use on the site. Without this information in the naming, all you get from GTM’s trigger list is that this is a Custom Event which tells me exactly nothing useful in determining if this is the trigger that I need.

Second in the naming, I’ve got a clear outline of what pages I can expect to pass this trigger’s conditions; all of the jacket pages. Directly following that, I’ve got any further filters that I can expect to explain why this trigger would not fire on every jacket page. From the naming of this trigger, I would expect to see this fire after I added a jacket to my cart and depending on whether the page is refreshed or not, at a DOM Ready event or after a request is made to another page. All of course, as long as the page is within the scope of the trigger which we can see from the end of the naming is North America only.

Do not let your triggers turn into Rube Goldberg machines.

Naming triggers can be especially tricky when considering and creating blocking conditions, but don’t make this overly complicated. Blocking triggers should be created in a way that they can also be used as firing triggers and as such should follow the same naming techniques. For this reason, it’s good practice to name and create triggers based on a true condition rather than what they are meant to block.

For example, creating country triggers for 3 countries A, B and C then adding B and C as two blocking triggers may be more useful long term than creating one blocking trigger that has conditions to check for either country B or C and using that one as a blocking trigger. You have greater potential to reuse the individual country triggers in other tags than you do using the combined B and C trigger which may only be used once in this case.

When naming variables we like to focus on the type of data and its availability. Variables usually don’t account for a large portion of the clutter in a tag container, but its good to keep clear what data a variable contains and where exactly it is available for use. We like to follow the structure below.
Descriptive Variable Name - Data Type - Page (if availability is limited)

The benefits are once again obvious when viewed in a named example variable.
transactionsProducts - Object - Cart Page

Without the Object - Cart Page portion of this name, it would be easy for someone to attach this variable to a Confirmation page tag expecting it to contain product ids or perhaps product names. With that portion included in the name, it becomes obvious that this would not be the variable that they want to use.

My dad was always into Japanese culture. He’s a 6th Dan Black Belt in Tae Kwon Do and has been studying since Bruce Lee beat up that really tall dude in that one movie.

When I was young he took me into his office once and I was fascinated by a bonsai tree he had on his desk so he told me all about the time and dedication that it takes to grow bonsai. Decades of care from often several different people with one goal in mind. Long term thinking, regular pruning and guidance so that growth takes the caretakers’ desired shape. I like to think of maintaining tag containers the same way. Spending time thinking about the way you want the container to be used with every tag, trigger and variable you add will benefit all the users in the end and keep your tag containers from turning into bramble.