Why & How to Implement Google Tag Manager Like an Expert
This article will look at how to implement Google Tag Manager. We’ll focus on the following three areas:
- Why & How to Implement Google Tag Manager Like an Expert
- Regaining control over data collection
- Before the dataLayer pushes
This is a write-up of Alexander Kirtzel’s talk that he gave at GTM4ward. Here you can find his slides. If you want the recording of Alexander’s great talk and others from GTM4ward, you can purchase them for a small fee.
What all web pages have in common
What do all web pages have in common? It doesn’t matter if you’re viewing from a monitor, a tablet, or a mobile device, all pages are made of HTML rendered with CSS. You must keep this factor in mind as we move ahead.
Basic principles of a Google Tag Manager implementation
Go step-by-step
When using GTM, it’s very important to stay calm and go step-by-step. Usually, if you have a website, achieving key goals can take a long time.
First, you need to think about what you want to measure, and the purpose of measuring it (for legislation like GDPR, this is a legal requirement). Always aim for clean and structured data. Following step-by-step approaches will best help you achieve your goals in the long run.
Try to use first-party data
We often find ourselves in positions where we must build on top of third-party apps. This means searching for documentation, hacks, and workarounds to work with third parties effectively.
There is an alternative, though. Our website and infrastructure could be used to set up everything. This approach gives us much more control.
Use one platform to handle your data
Set up one source of truth for handling content, only after this should you distribute the data. This approach will lower implementation costs and bring you far more peace of mind in relation to compliance. Because you have less to manage.
Focus on what you can control
Focusing on what we can control brings us lots of power. Instead of waiting for GTM to support templates enabling snowflake support, for example, tell GTM what you want to work with. Taking control like this helps provide many more opportunities.
Create a simple setup using tools for their main purpose
Let’s imagine that you only use Google Analytics for analytical purposes. GA was mainly built for marketing purposes. It’s great for tasks such as segmentation but isn’t great for analysis or debugging your implementation.
If you’re focusing on one tool, you won’t have any problems. There are plenty of other tools, however, that solve different issues. It’s hard to integrate these tools one by one, but after focusing on what you can control, why not simplify the setup?
Choose a monitoring tool for monitoring, an analytics tool for analytics, etc.
Learn from past experiences
Sometimes it’s useful to go back and learn from our past experiences. After all, resilience comes from learning. Think about some of the challenges that you encountered and the ways that you overcame them. Think about how your product has evolved as a result of user engagement.
Keep tag management at the core of your website design
Instead of designing a website, deploying it, and going through your tag management system – design something, tag, and deploy it. Once deployed, it will be there immediately.
Internalization of tracking will keep you up-to-date. Detached setups are meant to break– When changes occur, this system will need to be reconfigured.
Expectations vs. reality
Imagine a real-life scenario. Ideally, you want to have an event that is sent to a destination. In reality, though, you have ended up with lots of events with lots of destinations. You start asking yourself lots of questions:
- How to set up enhanced e-commerce tracking?
- What are repetitive tasks and patterns?
- Who’s involved and interested in data?
You conclude that you need ‘one implementation to rule them all.
If you go on a website, you should think about the different people using the website. Let’s consider some examples:
- Online marketers – Want to utilise GTM tools and measure campaign performance.
- Data governance – Make sure that consent is respected. They want to follow all the same naming conventions.
- Data scientist – Concerned about the placement of cookies for setting up user IDs. They’re interested in the latest configuration of the website.
- Product owners – Design the pages and the products that you’re building. This includes considering what should be placed where, and product designs. They want to know about the adoption rates on your website.
- Data analyst – Go a little deeper – what’s the event? Are users clicking on products at a higher price? Do they interact with filters? Analysts are interested in usage.
- Growth manager – Manipulate the website through A/B testing to boost conversions. They’re keen to monitor user behavior.
- Dev ops and developer – Above all, want peace of mind. They need to bring requirements together to produce a site that runs effectively.
Generic event structure
Let’s take a look at a generic website (seen below). We can see a promotion as well as a list of products. These are the different entities that make up the webpage.
Alongside entities, we have actions. We can click on products or promotions and be redirected to new pages. If we were to select a promotion, for example, we’d trigger a ‘promotion_view’ event.
We might want to go a level deeper and find out which promotion was viewed. We call this stage ‘data’. In the example below, we know there was a promotion view of the ‘how to tag’ promotion.
From this, we can see that there is more to look at. The positioning of the hero is interesting–there are language settings at the side and a cart value.
These two factors could influence everything that happens on the website. These elements are known as ‘globals’. Changing the language settings or cart values can have a huge influence on the user’s behavior.
From this, we identified five HTML attributes (shown below).
Together, these five attributes make everything measurable. They’re also factors that computers can understand well. They can bring structure into your code and data collection and provide peace of mind.
Understanding HTML elements
Take a look at the image below. On the left side, we have the data-elb attributes; these can be anything that you’d like. This includes entities, triggers, and data attributes.
On the right side of the image, we have the global state objects. These contain data that is used across different web pages (themes, cart data, etc).
If we tag a page that contains a promotion, we might include a visual action that triggers the promotion view. Once a user scrolls up to our promotion, they will trigger the event. This is a piece of cake for our developers to set up. This can be accomplished thanks to the following HTML attributes:
- Data-elbaction=”visible:view” – Let’s us know that an event has been triggered when a user views a promotion.
- Data-elb-promotion=”name…” – allows us to tag the name.
- data-elbcontext=”position:left” – Tells us about the posistioning of the promotion.
- data-elbglobals=”language:en” – Informs of the language used to view the promotion.
The event model
Together, this is what these attributes look like in our event model.
Of course, there are many different attributes that we can choose from. We can gain additional information that data scientists might be interested in. For example, the timestamp of a user. Or. the length of time between a page loading and an action being triggered.
There is also the option of adding user information for cross-domain tracking on the ID level. Alternatively, we can carry out session stitching to create simple user journeys.
Other attributes, like session start, might interest marketers. They can find the name and source of the campaign and much more.
Understanding these attributes can bring many benefits, including:
- A first-party implementation that occurs in your code.
- Gaining a single source of truth.
- You have ‘structured visibility’ – you know the context of when events took place.
- You can use many different sources.
- We haven’t yet had any vendor that provides more resilience.
- The event model is industry-independent – not just e-commerce tracking.
Data infrastructure
We have a problem – nothing has been tracked yet! Where was our data created? In the image below, you’ll see our clients on one side and destinations on the other. We’ve grouped these into marketing and analytics. Each requires a different content state. We’re using stacks like GTM to set up everything.
Over time we find that new marketing or analytics destinations are coming as well as new clients. With AI, we’ve learned about the importance of raw data and want to set up our own database and send data to Snowflake.
All these growing setups trigger an issue. We’re rapidly acquiring new setups and losing control.
This issue is that we’re focusing on what we can’t control. We have no influence, for example, over the look of the GA4 interface. We’re told how GTAG implementation should be carried out.
So, what’s the solution? It’s time to take back control. We’ll set up server-side GTM. Using the tool, we can create our own templates to help with the GTAG call, which will push elements to the dataLayer.
Setting up server-side GTM
To do this properly, though, we need to go step by step.
- We need to tag all the elements on our website.
- Go on the walker.js web client. This can implement and read everything and set up observers.
- Send the data somewhere. This will provide us with HTML attributes and fully rendered events on the console. You could send data to GTM and initialize the dataLayer on your site by pushing in data. Or, you could try sending data to Piwik PRO.
- On the server-side why not create a function for receiving information? You can then push this directly to BigQuery. Gluing this together could be a piece of cake; we can add another API destination.
- The tagged website with the processed and fully enriched events will be sent to different destinations. This can now be processed on the server-side. Adding new sources, like the GA4 destination should be much easier with one implementation.
Event names must be translated to each destination. For instance, if you want to send the promotion_view GTM event data to Snowplow it should be called ‘trackPromotionView’. More examples can be seen below.
With the structured flexibility, we have the chance to set up data contracts. Let’s look at one issue. Data analysts can’t differentiate between promotions. To solve this issue, we can create a contract that asks that promotions always have a name.
Wrapping up
So, there we have it, some top tips for implementing GTM successfully. Why not try putting some of these steps into practice yourself?
Remember, to utilize GTM effectively, you need a coherent, well-structured account. This means no bloated containers with lots of unused tags, triggers, and variables. If you’re account needs sprucing up, you can use the GTM cleaner tool, a completely free SaaS tool. It’ll provide you with a clean and lightweight version of GTM.
About Alexander Kirtzel
Alex grew up with GA and fell in love with the idea of data-driven decisions until he learned about the importance of “data quality” and then he questioned EVERYTHING! After 100s of tracking implementations, he started working on a NEW approach to bypass common pitfalls & RESTORE trust in Analytics data and most importantly, AUTOMATE recurring QA testing tasks.
During regular “nerdy” sessions with friends… the Entity + Action event concept of WalkerOS was born! In 2019, he co-founded ElbWalker to simplify tracking implementations with Open-Source software – so that more teams can make BETTER decisions based on RELIABLE data.
- What is a Customer Data Platform (CDP) & How to Use One - 25/04/2024
- What is Google Consent Mode V2 & How to Implement It - 24/04/2024
- How to Implement Consent Mode with Cookiebot CMP - 09/04/2024