Loading...

Follow Analytics Mania | Google Analytics | Digital An.. on Feedspot

Continue with Google
Continue with Facebook
or

Valid

Yesterday, a reader of mine, Gabriel, posted a comment with a question:

I’ve implemented successfully a lot of form tracking through element visibility trigger. However, I’m struggling with one website. They don’t have a permanent element that is visible after submitting the contact form. Just a 2 second pop-up appears at the top of the page, then it disappears. Is it possible to track it somehow?

So basically, Gabriel does not get enough time to inspect the popup message (as a website element) in order to track it with the Element Visibility trigger of Google Tag Manager. What can be done here?

I’ve tried various solutions (like this one and this one) but the one that I will show you worked for me the best. I have spotted it here. I’m pretty sure that there are more elegant solutions (that I’m not aware of) but this one was fairly simple.

P.S. If you know a better solution, I’d really like to hear that! Share it in the comments, thanks!

A quick demo

To better illustrate the problem, I’ve found a demo website with a popup that disappears after 4 seconds. I know that in the future, the demo page of the popup might be shut down but let’s enjoy it while we can.

Open that page and see for yourself. Every time a page is loaded, this popup will appear and then disappear.

The problem

It does not matter what will you do with that popup (keep your mouse cursor on it, try to click the ESC button hoping that it will work the same way it does with the redirects (see the silly ESC key trick)) it will just disappear. And several seconds are definitely not enough to properly inspect the element, to check its CSS class, ID, or some other attributes.

Hence, it becomes nearly impossible to configure the Element Visibility trigger. Not unless you try this (probably also silly) trick. These exact steps apply to Google Chrome. You will have to do your own research for other browsers.

The solution

Before the popup (or some other element that you wish to track) appears on the screen, open Browser Developer tools. On Windows, you can press the F12 key. On Mac, it’s Command+Option+I.

Then go to the Settings:

Locate the setting that is called “Disable JavaScript”. Keep it disabled for now.

Now, complete the action on your website that makes that sneaky element appear on the screen. In Gabriel’s case, it’s the form submission. Once you submit the form and the popup appears, click the Disable JavaScript checkbox.

Now you can take your time and inspect the popup. Find the element you can use in your Element Visibility Trigger. The charm of this solution is that you can continue using the Elements tab of the Chrome Dev Tools while JS is disabled.

When you complete inspecting the element, turn on the JavaScript once again. That’s it!

The post How to Pause JavaScript and Inspect an Element that Quickly Disappears appeared first on Analytics Mania.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Updated: July 12th, 2019. The Data layer is one of the key concepts in the world of Google Tag Manager. It ensures maximum flexibility, portability, and ease of implementation. Remember, GTM works best when deployed alongside the data layer (in fact, broken data layer = severely crippled GTM).

At first, Google Tag Manager Data Layer might seem like one of those mysterious concepts that no one really understands (by saying “no one” I mean non-developers). But if you stay focused, it’s a concept that’s definitely possible to grasp on. Understanding and leveraging the data layer is the key to unlocking GTM’s potential so be attentive.

Of course, it takes a while to understand how everything works, but once you get the idea, you’ll start putting puzzle pieces together. It just requires some time. The purpose of this blog post (and entire analyticsmania.com) is to educate non-developers, how they can master GTM, have quite extensive control of Google Analytics, Google Ads or other implementation. And don’t limit yourself only to those two tools. You can connect GTM with A LOT of other online tools (but we’ll talk about that in other blog posts).

Before we continue: Data Layer is also explained in two of my GTM courses

If you prefer video material over lengthy blog posts, some of my Google Tag Manager courses go deeper into the Data Layer:

Table of contents #1. How does Google tag manager Data Layer work?

Technically speaking, a Google Tag Manager Data Layer is a JavaScript array that stores and sends information from your site to Google Tag Manager (later that data can be transferred to other tools, like Google Analytics). In plain English, Data Layer like a virtual layer of your website, which contains various data points (Get it? That’s why it’s call data layer.). Regular visitors don’t see that because it is not something openly displayed. But if you know how, it’s fairly simple to view what’s in it.

Imagine that Data Layer is like a bucket. That bucket can contain little ping pong balls, every ball contains some information, e.g. a user ID, the information about the clicked element, purchase ID, page category, etc. Google Tag Manager heavily relies on what is within that bucket. If click information is added to that bucket, GTM can use it as a triggering condition. Or maybe it can take the Form ID (of the form that was just submitted) and send it further to Google Analytics.

Anyone/anything can put those “data balls” in the Data Layer. It might be a 3rd party plugin, some custom code created by your developer, even Google Tag Manager itself can push the information from the Data Layer.

So if for example, you want to track purchase, one of the possible solutions could be to ask a developer to push the order information to the Data Layer once that order/purchase was successfully completed. The information that a developer could push to the Data Layer is (but not limited to):

  • Transaction ID
  • Transaction total
  • Transaction revenue
  • Transaction taxes
  • Purchased products, their quantity, product IDs, etc.

If you’re looking for a practical example, check this guide: GA Standard Ecommerce implementation via GTM.

Here’s how GTM and Data Layer work in a nutshell:

In many cases (at least from my experience), Data Layer is not commonly known among developers. This is not some standard thing that all websites have. Usually, it is tied to Tag Management tools, like Google Tag Manager. Therefore, if you just tell a developer “add product information to the Data Layer”, there’s a high chance that a developer will have no clue what you’re talking about.

That’s why my philosophy is that digital marketers/analysts should know/understand what Data Layer is and how does it work. This will make communication between you and devs much more fluent.

In further chapters of this blog post, we’ll take a closer look at what Data Layer in Google Tag Manager, how to configure it (if you need that), how to use in your tag management, etc.).

#2. How to implement Data Layer

Once in a while, I see questions online that ask how to create a data layer. If you don’t plan to use any custom data in your tag manager (e.g. user ID, product ID, etc.), you don’t need to do anything additionally on your website. Once you place GTM container’s JavaScript Snippet in your website’s source code and a visitor lands on your site, Data Layer is automatically initiated by Google Tag Manager’s snippet.

You don’t need to add anything additionally. However, if you indeed want to use some custom information, continue reading. I’ll show you how to create/implement a data layer. Just beware that usually, this is the developer’s responsibility.

Here’s an example of GTM’s container snippet.

<head>
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->
</head>

In fact, it’s just a half of the code. There’s also a noscript part that exists. But since our main topic today is Data Layer, let’s focus only on the <script> part.

The aforementioned <script> GTM code will create a dataLayer on a page. You can even see the dataLayer mentioned in the code. If the dataLayer already exists on a page, this container snippet will adapt to it and will continue using the existing layer.

#2.1. Data Layer declaration vs dataLayer.push

Now let’s talk about actually putting data into the Data Layer. Because by default, if it is created, dataLayer is just an empty bucket. The whole magic starts when someone/something starts putting there useful data/info that later can be used in Google Tag Manager.

There are two ways, how to add data to the Data Layer:

  1. By adding dataLayer snippet above the GTM container snippet. This is called “Data Layer declaration”
  2. Or by pushing data with dataLayer.push method.

What’s the difference, you ask?

#2.1.1. Data Layer declaration

The first method is very limited and can work only if you add the dataLayer code snippet ABOVE the Google Tag Manager container code. I never use it. But for the sake of science, let’s take a look.

Let’s say that you want to send the page category as a custom dimension to Google Analytics. This is the Data Layer code that must be added above the GTM container:

<script> 
dataLayer = [{ 
'pageCategory': 'google-tag-manager-tips' //this value should be replaced with some actual page category
}]; 
</script> 

<!-- Google Tag Manager --> 
... 
<!-- End Google Tag Manager -->

If you’re not comfortable with touching the website’s code, a developer should do that (and in most cases, he/she will, in fact, have to do it. Unless you have installed some GTM plugin to your website).

So when the page loads, the dataLayer code will create a Data Layer and it will contain one data point, pageCategory. After that, the Google Tag Manager container code is loaded and you can then use that pageCategory in your tag management. This can be done with the help of the Data Layer Variable.

Another example – transaction or product data. Let’s say, you want to implement Google Analytics Ecommerce Tracking. In this case, your developers should add a dataLayer snippet above GTM tracking container with the following parameters: transactionID, transactionTotal, etc. (you can read the full guide here). Once this information is added to dataLayer, Google Tag Manager can fetch it and transfer to Google Analytics.

But there are several reasons why I always advise against using this method.

  1. If dataLayer = [] code snippet is added below the Google Tag Manager container code, then your entire GTM event tracking implementation will break (stop working). And this happens way too often.
  2. Sometimes GTM beginners confuse which method to use when. I mean, should they use the dataLayer = [] or should they adopt the dataLayer.push (that I will explain next)? It’s much easier to remember and use just one method (see chapter #2.1.2).

All in all, GTM specialists don’t recommend using the Data Layer declaration method (dataLayer = [];). And it’s really weird that dataLayer declaration is still mentioned in the official Google Tag Manager documentation.

#2.1.2. dataLayer.push

The second method (dataLayer.push) is another way how you can add data to the Data Layer. Here are a few examples:

  1. You have a newsletter signup form (which cannot be easily tracked with usual form tracking methods). You should ask your website developer to push a dataLayer event once a new subscriber has entered his/her email on your website. The code of this event should look like this:
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
      'event': 'new_subscriber'
    });

    If you wish you can ask your developer for additional information (for example, form location (because you might have more than one form on the same page)).
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
     'formLocation': ‘footer’,
     'event': 'new_subscriber'
     });
  2. When a visitor adds a product to his/her cart, a dataLayer event (containing the product’s information) could be fired.
    window.dataLayer = window.dataLayer || []; 
    window.dataLayer.push({ 
     'event': 'addToCart', 
     'products': [{
            'id': '123',
            'name': 'Black T-shirt',
            'brand': 'balenciaga',
            'quantity': 1
          }]
    });

Why is this method better than the first one? It can be placed anywhere in the code (above and below Google Tag Manager container) and it will not break the event tracking within GTM. That is possible thanks to a window.dataLayer = window.dataLayer || []; line.

Also, with it, you can push events to the Data Layer that can be later used as triggering conditions. For example, if someone submits a form, a developer can activate the following code:

window.dataLayer = window.dataLayer || []; 
window.dataLayer.push({ 
 'event': 'formSubmission' 
});

Since the code above contains the event key, this dataLayer.push can be used as a triggering condition in Google Tag Manager. Read more about the Custom Event Trigger.

If you want to learn more about dataLayer.push, read this guide.

#3. How GTM uses Data Layer’s information/content?

Google Tag Manager uses the information (stored in the data layer) in two ways:

  1. To use certain pieces of data (in the shape of variables). I will explain it in chapter #3.1.
  2. To decide when to fire a tag (in the shape of triggers because you can use dataLayer events as triggers). This part will be explained in chapter #5.

We can achieve the first part with the help of the Data Layer Variable and the 2nd one with triggers.

#3.1. Using the Data Layer Variable

Imagine, there are several authors in this blog:

  • Me (Julius Fedorovicius)
  • John Doe
  • Jack Torrance
  • etc.

I want to find out which authors write the most engaging content and then segment sessions in Google Analytics. I am using a DurecellTomi WordPress plugin which stores post author name in the Data Layer. If you don’t have WP, ask a developer to add additional data points to the Data Layer.  The snippet could look like this:

<head>
   <script>
     window.dataLayer = window.dataLayer || [];
     window.dataLayer.push [{
       pagePostAuthor: 'Julius Fedorovicius'
     }];
   </script>
   <!-- Google Tag Manager -->
   ...
   <!-- End Google Tag Manager -->
</head>

By default, Google Tag Manager does not recognize custom data in the Data Layer thus you cannot use it as variables. Unless you employ the Data Layer Variable. In order to create a variable, you’ll need to specify the Data Layer key of which value you want to retrieve. When the Variable is resolved, it will return whatever was most recently pushed into the key. Easy as that!

If I wanted to fetch pagePostAuthor value, I’d just need to set the pagePostAuthor key in variable’s settings.

Say, you want to send a Google Analytics event when someone leaves a comment. With every event, you also want to push the full name of the article’s author. This way you’ll see which authors drive the highest reader engagement.

In this example, I will not go into details how to create a tag, I will only demonstrate how to pull the author data from the Data Layer and turn it into a variable (within Google Tag Manager).

In GTM account, you should go to Variables and create a new one with the following settings (dlv stands for data layer variable):

It’s important to remember that the “Data Layer Variable Name” field is case sensitive, meaning that only pagePostAuthor will work (not pagepostauthor or Pagepostauthor, etc.).

That’s it! Save this variable, refresh Preview and Debug (P&D) mode, and refresh the website you’re working on. You should then see your newly created variable in the Variables tab of Preview & Debug console.

It’s completely possible (and quite common) to have a bit more difficult data structures stored in the Data Layer, for example:

{ 
  attributes: {
    pagePostAuthor: {
      authorName: 'Julius Fedorovicius',
      authorTag: 'Google Tag Manager' 
    } 
  } 
}

So if you wanted to reach the “authorName” key, that would require some additional knowledge of a thing called dot notation. In my other blog post, I have shared how to access various data structures in the Data Layer. You should definitely check it out.

#4. Example No.1: using data from the Data Layer in GTM and GA

Let’s imagine that I have a website and all registered users are split into two groups:

  • Paying customers.
  • Users with a Free plan.

I want to segment these users and all their events/pageviews in Google analytics by their pricing plan. I have already asked my developers to add static information to dataLayer when the page loads. The dataLayer snippet looks like this:

<head>
   <script>
     window.dataLayer = window.dataLayer || [];
     window.dataLayer.push [{
       pricingPlan: 'Premium'
     }];
   </script>
   <!-- Google Tag Manager -->
   ...
   <!-- End Google Tag Manager -->
</head>

The code (between <script> and </script> tags) is our static Data Layer information. We’ll use it later.

It’s very important that dataLayer snippet is placed above Google Tag Manager’s container code in your website’s code. First, you need to send data to dataLayer, then this data is fetched by Google Tag Manager. If the snippet is placed after GTM container code, dataLayer’s data won’t be fetched by GTM.

#4.1. Create a Data Layer Variable in Google Tag Manager

First, you need to create a dataLayer variable in GTM’s account. This way Tag Manager will recognize the parameter. Open Variables > Scroll down to User-defined variables and click New.

  • All my Google Tag Manager Data Layer variables titles start with “dlv” (it’s easier to keep everything in order. Read this useful blog post by Lunametrics how you should name all your tags, triggers, and variables)
  • Choose a type – Data Layer Variable
  • Set pricingPlan as Data Layer variable name, because this variable was added to dataLayer’s snippet by your developer.
  • Click Save.
#4.2. Enable Preview and Debug mode in Google Tag Manager

Let’s check if Google Tag Manager catches pricingPlan variable.

In your GTM panel, enter Preview and Debug mode (by clicking Preview button)

When Debug mode is enabled, you should see an orange notification bar:

Go to your website (or refresh a page if you’re already on it). A GTM debug console should appear at the bottom of the screen.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Updated: June 23th, 2019. I have to be honest with you. I’ve tried hard to come up with some interesting and intriguing introduction for this blog post and I guess I failed. But this does not mean that Custom Event Trigger is a boring and rarely used concept. Actually, this can’t be farther from the truth. Without it, you wouldn’t be able to track form abandonment, AJAX form submissions, etc. In fact, more than 90% of Google Tag Manager Recipes are based on custom events.

So what is it exactly and why should you bother at all? In this blog post, I’ll explain everything you need to know about Google Tag Manager Custom Event.

What is a Google Tag Manager custom event?

According to Google, Google Tag Manager Custom Event is used for tracking interactions that might take place on your website or mobile app that isn’t handled by standard methods. Standard tracking methods include:

Standard tracking methods include:

Every other event that occurs in the Data Layer is called a Custom Event. Here are a few examples:

  • Your website contains a form that a standard Form Submission trigger cannot track. What do you do? You ask a developer to activate a Data Layer event whenever that form is successfully submitted. That event is a Custom Form Submission Event (simply put, Custom Event).
  • A user logs in to his/her account. Unfortunately, the page URL does not change, therefore, you cannot just simply track pageviews. You can ask a developer to push the “login” event to the data layer. After you, you will need to catch the event in the data layer by using the “Custom Event” trigger.
  • And the list could go on and on. Remember, every Data Layer event that does not support a default GTM trigger is called Custom Event.
Where do custom events come from?

Usually (but not necessarily), custom events are dispatched by custom auto-event listeners, JavaScript functions which listen to particular interactions on a web page. In case something important happens, those listeners initiate a dataLayer.push event.

That’s how Custom Events see the daylight. I have already collected a whole bunch of ready-made custom auto-event listeners which are at your disposal. If you want to track something more specific (but unfortunately don’t know how to code), go ask a developer to write a custom auto-event listener for you. Believe me, they are really good at this (if they know JavaScript, of course!).

I’m no developer and I once spent more than a day trying to figure out how to track a particular interaction on a webpage. Believe it or not, but an experienced colleague of mine (JavaScript developer) spent 15 minutes to write a custom listener for that very same interaction (it was like 10-15 lines of code!).

Working side-by-side with a developer

I guess, most of my readers started using Google Tag Manager after they heard promises that developers are no more needed in web tracking. From now on, web analysts will be able to track all interactions and deploy marketing tags by themselves. Does that sound familiar?

Well, I cannot say that the aforementioned statement is a lie. But I can’t also say that it’s entirely true. There is no black and white.

I bet you can track a lot of web interactions without anyone’s input, and that’s awesome! But the web is full of unique, non-standard, and really strange solutions. If you don’t know how to write your own JavaScript, you have to prepare to work with a developer as a team.

Cooperation

Let’s imagine there is a certain interaction you wish to track. You’ve already tried various methods described on other blogs. No luck. What are your next steps? You decide to ask the developer’s help.

That’s no shame! In fact, working side-by-side with a developer is one of the Google Tag Manager Best Practices.

What’s next?

Step 1. Prepare a Data Layer Event Code.

Now, you need to prepare a Data Layer event code snippet and give it to a developer. I’ve put an example below:

<script>
 window.dataLayer = window.dataLayer || [];
 window.dataLayer.push({
 'event': 'registrationComplete'
 });
</script>

You might notice that this code is a bit different from the one which is recommended by Google:

<script>
 dataLayer.push({
  'event': 'registrationComplete'
 });
</script>

I’ve had a quick discussion with Simo Ahava in one of my blog post’s comments and according to him, it’s better to use window.dataLayer.push rather than dataLayer.push. Since Simo is a well-known GTM specialist with a solid background of JavaScript development, I fully trust him and follow his recommendations.

Ok, let’s get back to my dataLayer.push code example. You don’t have to be a developer in order to understand how to prepare a dataLayer event code snippet. Just copy my example and edit it. Take this code:

<script>
 window.dataLayer = window.dataLayer || [];
 window.dataLayer.push({
 'event': 'registrationComplete'
 });
</script>

If you want to add additional data, do this:

<script>
 window.dataLayer = window.dataLayer || [];
 window.dataLayer.push({
 'event': 'registrationComplete',
 'registrationCountry': 'United States',
 'plan': 'Premium'
 });
</script>

I’ve just added two additional lines with registrationCountry and plan. Just keep in mind that the last line must not end with a comma. In my case this was:

'plan': 'Premium'

If you wish, you can add 10 more lines.

Also, tell the developer that those two attributes need to be dynamically replaced. If a visitor chooses Norway as a registration country, then this value should be changed in the Data Layer event snippet as well.

'registrationCountry': 'Norway',
STEP 2. Tell the developer when to fire this code

Another important step is to explain to the developer WHEN you want the dataLayer.push event to fire. If you’re interested in the tracking of a specific form, Data Layer event must be fired after the successful submission occurs.

STEP 3. Test the event

After a developer says that his/her task is complete, enable GTM Preview and Debug mode to test it. Complete that specific interaction (e.g. submit the form) and keep looking for the Data Layer event in Preview and Debug mode’s event stream. It should look like this:

So far so good. Now, let’s check whether the developer passed two additional attributes you asked for, registrationCountry and plan. In Preview and Debug mode, click the registrationCompleted event and go to Data Layer tab. As you can see from the screenshot below, developer did a good job as I can see both registrationCountry and plan in the Data Layer.

STEP 4. Configure GTM

By default, Data Layer events do not appear in the Google Tag Manager as triggers. You need to do that manually. Since we are interested in tracking successful form submissions, we need to tell GTM that registrationComplete events are important to us and we wish to use them as triggers.

In Google Tag Manager, go to Triggers and hit New button. Choose Custom Event as trigger type and enter the following settings:

Done. You have just created a Google Tag Manager Custom Event Trigger. If you also wish to use registrationCountry and plan as variables in your Google Tag Manager tags, read the guide on how to access data in the Data Layer and turn them into GTM variables.

Example: Sending an event to GA when a user registers

Let’s continue with our example of registration tracking. What we’ve got so far is:

  • We asked a developer to implement the dataLayer.push code when a user successfully signs up. The value of the event  key is registrationComplete
  • A developer has implemented our request and we checked that in the Preview and Debug mode (Data Layer tab)
  • We created a Custom Event trigger registrationComplete

So what’s next? Let’s send an event to Google Analytics every time a registrationComplete event is pushed to the Data Layer. Additionally, we’ll pass the value of the plan (pricing plan to which a user signed up).

#6.1. Data Layer Variable

In Google Tag Manager, go to Variables > User Defined Variables > New > Data Layer Variable. Enter the following settings:

We entered “plan” because that’s the name of the key in the Data Layer (when the registrationComplete event is pushed to the DL). You can learn more about the Data Layer Variable here.

#6.2. Universal Analytics Event Tag

Now, let’s create a GA event tag that will send the event data to Google Analytics every time a registrationComplete is pushed to the Data Layer). In GTM, go to Tags > New > Universal Analytics. Enter the following settings:

If you’re not familiar with what is Google Analytics Settings Variable, read this guide. The key things here:

  • Track type: Event. This means that we will send events about successful registrations to GA
  • Event Action: {{dlv – plan}}. Whenever a registration is completed, Google Tag Manager will take the value of the plan key in the Data Layer and will send it to GA (together with a GA event). That way, you will be able to slice the registrationComplete numbers by the pricing plan.
  • Assign the trigger, the previously created Custom Event Trigger registrationComplete.
#6.3. Let’s test

Save the GA tag, refresh the preview and debug mode, go to your website (+ refresh it), and complete the registration once again. Once you do that, the registrationComplete Data Layer event will appear in the preview mode. Click it and check whether your GA Event tag is fired.

If the tag has not fired, check whether you have entered the proper event name in the trigger settings. It is super important that you enter the event name precisely as it is displayed in the Data Layer (case sensitive).

If the tag has indeed fired, head over to your GA Real-time reports > Events. Check whether you also see the event there.

If you are still struggling with testing your tags in GTM, read this blog post with 30+ debugging tips.

#6.4. Configure a goal in Google Analytics

The final step. Let’s turn the “registration complete” GA event into a GA goal. In your Google Analytics property, go to Admin and in the “View” column of your GA property go to Goals.

Create a new goal and enter the following settings:

  • Goal setup: Custom
  • Goal name: Registration complete (but basically, anything you want)
  • Goal type: Event
  • Goal details: Category equals to registration complete. Leave all other fields empty.

With this kind of setup, whenever an event (with event category “registration complete”) is tracked by Google Analytics, it a goal completion will also be counted. Just remember that a goal completion applies to the entire session. This means that 5 registrations of the same user during the same session will be counted just as a single goal.

You can also test goals in GA real-time reports. So whenever you save this goal, complete another registration on your website, go to real-time reports > Conversions and check whether it was displayed there.

Conclusion

Google Tag Manager Custom Event is used for tracking interactions that might take place on your website or mobile app that isn’t handled by standard methods (i.e. form submissions, page views, clicks, etc.). In other words, every other event that occurs in the Data Layer can be called Custom Event.

Without custom events, there would be no Scroll Tracking, Form Abandonment tracking, AJAX form tracking, etc.

If you spot a non-standard interaction which cannot be tracked with ready-made tracking solutions (like GTM Recipes), work side-by-side with a developer:

  • Explain to him/her which interaction do you wish to track and what additional data are you expecting.
  • Give him/her a little piece of Data Layer event code.
  • Test everything after the developer finishes his/her task.
  • Configure Google Tag Manager to recognize that Custom Event.

Is there anything I missed about Google Tag Manager Custom Event? If yes, let me know in the comments.

SUBSCRIBE & GET THE ULTIMATE LIST OF 120+ GOOGLE TAG MANAGER RESOURCES. A TO Z.
Please wait...
You have successfully subscribed. Go check your inbox.
Please enter your email address
Please enter a valid email address
Unexpected error occurred!

The post Google Tag Manager Custom Event Trigger Explained appeared first on Analytics Mania.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Google Tag Manager offers a whole bunch of variables that are at your disposal, built-in and user-defined ones. While I have posted many blog posts about user-defined variables (and I mean many, many, many, many…), this time, I’d like to put a spotlight on the unsung hero of built-in variables, Click Element.

To keep you intrigued, I can say that this variable has a twin-variable in GTM with the same abilities, also Click Element lets us use one of the most powerful (but also quite risky) features in GTM.  So stay tuned and continue reading.

Table of Contents
  • What is Click Element Variable in Google Tag Manager?
  • Where does the Click Element data come from?
  • Click Element variable is not the only one of this kind
    • You can also create custom variables that access the same values
  • Why would you need to use the Click Element variable at all?
  • Example: Click Element + Matches CSS Selector
  • Another case where Click Element variable is useful
  • Exploring the gtm.element object
    • Expand the gtm.element object
  • Final words
What is Click Element Variable in Google Tag Manager?

It is a variable that returns the element, that was clicked. By default, it is disabled in all new GTM containers and needs to be enabled by going to Variables > Configure (in the Built-in variables section). Then click the checkbox next to a Click Element.

But just enabling the variable won’t do anything in the Preview and Debug mode. You also need to have enabled at least one “Just links” or “All element clicks” trigger. If you’re not familiar with this process, I urge you to read the guide about Click Tracking with Google Tag Manager.

In GTM Preview and Debug mode, this variable looks really misleading and sometimes even similar to the Click URL but this is far from the truth.

Click Element returns a clicked object. If you click a link, this variable returns the actual element that was clicked. Not only its address (if it has one) but also attributes and other data that it contains (and is not necessarily visible for a non-technical eye).

But Google Tag Manager preview and debug console does not display those additional attributes. Therefore, sometimes, the only proof that these two variables are different is their type:

Where does the Click Element data come from?

It comes from some of Google Tag Manager’s default auto-event listeners. If you have at least one Just links, All Elements Clicks, Form Submission or Element Visibility trigger, it also enables (somewhere in the background) its respective auto-event listener that starts listening to certain interactions happening on a page.

Just links listener listens to link clicks. All Element Clicks listener is listening to clicks of any element on a page (that is not in the iFrame). Form submission listens to form submissions. And, as you probably guessed it, Element Visibility is listening to when a particular element appears on the screen.

When those listeners spot an interaction, they push certain data to the Data Layer. That data is related to the element, with which a user has just interacted. That dataLayer.push includes the following keys:

  • gtm.element
  • gtm.elementClasses
  • gtm.elementTarget
  • gtm.elementUrl
  • gtm.elementId

If you go to GTM Preview and Debug mode > Data Layer, you might see something like this (of course, the values will be different).

Each one of those keys in the Data Layer variables can be accessed by the built-in variables in GTM (Click Element, Click Classes, Click Target, Click URL, Click ID). gtm.elementClasses, gtm.elementTarget, gtm.elementUrl and gtm.elementId are strings (read “text content”) but the gtm.element is an object that contains more information. Unfortunately, that is hiding deep and we’ll need to take a deeper dive. But that will happen a bit later.

By now, you should know/remember the following things:

  • When an auto-event listener (this applies to clicks, form submissions, or element visibility) pushes data to the Data Layer, one of the pushed keys is gtm.element
  • This value in the Data Layer can be accessed by the Click Element variable in GTM (but not limited to. More on that — a bit later)
  • In preview and debug mode, Click Element might look similar to the Click URL variable but they are totally different. Click URL just simply returns a string that is a web address (URL). Click Element is actually a clicked element, an object and contains much more information about the element with which a user interacted.

In the upcoming chapters, we’ll take a look at Click Element alternatives, why is Click Element a very useful variable and also what other data is hiding in that gtm.element object.

Click Element variable is not the only one of its kind

So as you have already learned, Click Element returns the value that is stored in the Data Layer as a gtm.element key. If no such key exists, the variable will return undefined.

What some of my readers will definitely not know is that there is another built-in variable in GTM, which accesses the very same key in the Data Layer. And that is… drumroll, please … Form Element.

Yes, both of these variables access the same gtm.element key in the Data Layer (or, more precisely, Data Model). In fact, all Form and Click variable pairs are identical. They access the same keys:

  • gtm.elementTarget is accessed by Click Target and Form Target variables
  • gtm.elementUrl is accessed by Click URL and Form URL variables
  • gtm.elementClasses is accessed by Click Classes and Form Classes variables
  • gtm.elementId is accessed by Click ID and Form ID variables
  • and finally, gtm.element is accessed by Click Element and Form Element variables.

Why is it like that? I cannot talk on behalf of GTM developers but I can guess. I think that this makes things a bit easier to understand for GTM beginners. In order to track clicks, a GTM user has to enable a click trigger and then activate click variables. The same process is with form tracking. If you want to use the built-in GTM form submission trigger, you need to enable it and then enable the form variables.

Such workflow sounds easier to understand for those who are just starting with Google Tag Manager. (but maybe my guess is wrong).

You can also create custom variables that access the same values

Alternatively, you can also create user-defined variables that will work the same as the aforementioned click and form variables. If you wanted to create, say, your own alternative to the Click Element variable, go to Variables > New > Data Layer Variable and enter gtm.element. It’s the name of the key that is stored in the Data Layer.

Both Click Element and Form Element variables access that very same key as well. So there you have it, 3 different variables return the same thing. Why would you want to create your own user-defined variable to access gtm.element? No particular reason. I just wanted to show you how things are connected here.

Why would you need to use the Click Element variable at all?

Since you already know that Click Element variable returns an object, with which a user interacted (e.g. clicked element, displayed element or submitted form), it’s time to take the next step. So where is this variable useful? When you need to work with an actual element.

The most popular use case is “together with CSS Selectors”. If you want to track, say, clicks of particular website elements but none of them have unique IDs, CSS Selectors might be a solution.

“CSS ….what?”, you might ask. CSS Selectors are patterns that allow you to select any elements on a page. For example, if you wanted to track clicks only of those elements that have the class “white-button” but also belong to the red sidebar widget of your website, the regular Click Classes variable would not work.

However, if you combine Click Element variable together with a Matches CSS Selector operator, that would be possible.

If you are just starting with Google Tag Manager and you have never heard of CSS Selectors before, I think that this topic might be a bit too difficult for you right now. There are many other things for you to learn first like:

Example: Click Element + Matches CSS Selector

Anyway, back to the main topic. I hope I won’t intimidate you too much with the following example. In my other (broader) guide on Click Tracking in GTM, I showed a case where CSS Selectors are really useful. Here it goes.

Imagine that you’re working on an e-commerce website and you want to track clicks of the Add To Cart button. The button does not have any link (hence our Just Links trigger will not work). All we are left with is the All Element Clicks trigger.

Unfortunately, not everything is that easy. Turns out that one button actually consists of two elements: button text and button background/rectangle.

If those two elements have similar IDs or Classes, using Click ID or Click Classes variables might still work. Take a look at the screenshot below.

Text of the button has a class AddToCartText while the background (box) of the button has an ID AddToCart.

This situation is still very convenient and you would be able to create a trigger with a single condition (Click ID starts with “AddToCart”). However, sometimes, things might get more complicated when no IDs or useful Click Classes (read: CSS Classes) are available. What if an element actually consisted of 5 or more elements?

You could create multiple triggers for every element, assign it to a single tag but that’s not the way you should do. Your container must be as optimal as possible that’s why we should cope with that by creating a single click trigger and using CSS Selectors (if possible).

Let’s see how this works in action. We’ll apply CSS selectors to track Add To Cart button clicks. Take a look at the code of that button (in the screenshot below).

The button is created with an HTML element called button (with the ID AddToCart) and its direct child is a <span> element that contains the button text. With a single CSS Selector, we could instruct Google Tag Manager that we want to track clicks of an element of which ID is AddToCart and also all we want to track clicks of all its children (descendants).

In GTM, go to Triggers > New > Clicks > All Elements and enter the following settings:

Take note that we’re using Click Element as a variable because we are checking the entire clicked HTML element against our CSS Selector. Matches CSS Selector works only with the Click Element variable.

#AddToCart CSS selector means that we are interested in clicks of ALL elements that have AddToCart ID (exact match).

A comma means “OR”.

#AddToCart * CSS selector means that we are interested in clicks of ALL the descendants of elements that have AddToCart ID (exact match). In our case, the button text is a direct descendant of the button that has an ID AddToCart. Simo Ahava has published a guide explaining the technique of Wildcard CSS Selectors.

It will not be very easy to grasp on the concept of CSS Selectors if you have no previous knowledge or even idea what they are. However, knowing at least the basics will really help you in GTM. Here are additional guides for you to dig into:

But, on the other hand, keep in mind that CSS Selectors should be used with caution otherwise, your tracking implementation will be very unstable and easy to break.

Another case where Click Element variable is useful

All in all, Click Element as a variable should be used when you want to work with an actual element (not its attribute). An example of this could be Simo Ahava’s blog post where he shares a technique on how to capture a correct element in Google Tag Manager.

In that solution, he uses {{Click Element}} variable in this custom JavaScript.

By using the actually clicked element, Simo’s Custom JS code finds the closest element that matches a certain CSS Selector. This is an advanced technique but one day you will most likely need to use it.

Exploring the gtm.element object

Let’s enter the final chapter of this blog post. So what is that other data that is stored in the gtm.element object? How can we see it if the GTM Preview and Debug mode does not allow us?

Well, you have you use the console in your browser’s developer tools.

Prerequisites for this to work:

  • Have enabled at least one All Element Clicks trigger on a page (any settings will work). Just Links, Form Submission, or Element Visibility will work too.
  • (optional) Enable the Preview and Debug mode. This is not necessary but will make things a bit easier.

If you have enabled a click trigger, click any element on a page so that Click event appeared in the GTM debug console. Did it appear? No? Then refresh the preview mode and make sure that you have actually enabled at least one click trigger.

If the Click event actually appeared, that’s great. Now go to the Browser’s Developer tools and open the Console. On Chrome (Windows), press F12 and then go to Console. Here are also some tips for other browsers.

Enter dataLayer. Case-sensitive. And hit Enter.

Click the black triangle to expand. This is the list of all the dataLayer.push that occurred on a page. Choose the one that says gtm.click (if you are working now with the All Element Clicks trigger). If you’re working with the Just Links trigger, the event’s name is gtm.linkClick. Form Submission event name is gtm.formSubmit. Element Visibility event’s name is gtm.elementVisibility.

Seeing many gtm.click events? That’s because you clicked many elements on a page. If you want to check a particular event that you also see in the GTM debug mode, take a closer look at the number. In the GTM preview and debug mode that number will be larger by 1. At least that’s how usually things work if developers are not doing some nasty modifications to the dataLayer.

Anyway, when you spot the correct event, expand it by clicking the black triangle next to it.

Expand the gtm.element object

This is what was pushed by the listener to the Data Layer when you clicked the element.

See anything familiar? gtm.elementClasses, gtm.elementId, etc. Only the gtm.element has a black triangle next to it because it contains some additional data. And that’s where we’re going.

Click the black triangle (next to gtm.element) and you’ll see A LOT of keys that you can access. While the majority of them will look unusable to you, there are several things worth mentioning.

If you go deeper within that gtm.element key and expand parentElement and then className, you will be able to access the parent element’s class (if, for example, that element was clicked).

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Google Tag Manager can help you do a lot of useful things and extracting query parameters is one of them. If a URL of the page contains a query parameter (it comes after the question mark in the address), you can turn that into a variable in Google Tag Manager and reuse in tags, triggers or even other variables. In today’s guide, I’ll show you several examples of how to extract query parameters in GTM.

What is a query parameter?

Before we continue, first let’s have a quick reminder of (or maybe learn?) what query parameters are in general. Query parameter (also known as a query string) is a part of the URL that assigns values to specified parameters.

Typical URL example with the query parameter can look like this:

https:///www.analyticsmania.com/search?keyword=google+tag+manager

In the case above, the query parameter is “keyword” and its value is “google+tag+manager“. Speaking of web tracking, one of the most popular (if not the most popular) query parameters are UTM parameters. If you want to track the impact of your digital marketing campaigns, you can add UTMs to your links (e.g. utm_medium or utm_source) and Google Analytics will automatically catch them, attributing the session to that particular traffic source.

However, it’s very common for websites to use other query parameters that are necessary for websites/apps to work and coincidentally, you might want to use those query strings in your GTM setup as well. For example, maybe a URL contains a parameter called product_id that you would like to use as a custom dimension and pass to Google Analytics?

With Google Tag Manager, that is not a problem. Continue reading and I’ll show you how to do that.

How to extract a query parameter of the current page URL

Google Tag Manager has a neat feature called URL Variable. It can return a value of a particular query parameter that is currently in the URL. So if a URL indeed contains, say, a product ID (https://www.analyticsmania.com/products?product_id=12345), with that variable, you could actually fetch and get the value of “12345”.

If you want to extract a query parameter with Google Tag Manager, go to your GTMr container > Variables > New (in the User-defined variables section). Enter the following settings:

  • Variable type: URL
  • Component type: Query
  • Query key: product_id (you should enter here the name of the actual query string you want to get)

Save the variable, enable the Preview and Debug mode, refresh the web page of your site that you’re currently working on (with the query string in the URL) and check the Variables tab. In it, you should find your recently created URL variable that returns the value of the query parameter.

If you want to learn more about other Component Types of the URL variable, read this guide.

Where else would you need to extract a query parameter?

If you’re interested in other use cases of this variable, here is some food for thought. I’ve used this variable in various situations, e.g.:

How to extract a query parameter of the clicked URL (or any other URL)

Another cool feature of the URL variable in GTM is that you can work not only with the URL of the current page (because that’s how the variable works by default). In fact, you can use any variable as an input.

For example, if you want to extract a query parameter of a clicked link, you can do that by completing the following actions:

  • In the URL variable, expand More Settings section
  • And choose the {{Click URL}} as a URL source.

In this example, you should use the Click URL variable.

That’s it! Now this variable will return the product_id query string of the clicked URL (if that link actually contains the parameter). If the query parameter is not present, the URL variable will return undefined.

If you want to extract ALL the query parameters that are in the URL

If for some reason, you need to extract all the query parameters of the URL and have them as a single variable, you can use the JavaScript variable type of Google Tag Manager (because URL variable can return the value only of a single parameter).

Go to Variables > New (in the User-defined variables section) and choose JavaScript variable. Enter document.location.search.

This will return all the query parameters that are present in the URL (including the leading question mark). Like this:

?product_id=1234&category_id=2222

If you don’t want to have that question mark in the variable, you can use this Custom JavaScript variable instead.

function() {
  return document.location.search.split('?')[1];
}

This will return the same value except for the first question mark, product_id=1234&category_id=2222.

How to extract a query parameter with Google Tag Manager: Final Words

In this quick guide, you have learned how to use URL variable (or other alternatives) in order to extract a query string with the help of Google Tag Manager. Just keep in mind that if you have a choice between using a URL Variable or some custom code, always go with the built-in GTM functionality (in this case, URL Variable). Google Tag Manager developers do a really good job creating optimized built-in features.

By the way, URL Variable is very versatile and can retrieve not only query parameters. You can also get the value of URL fragment, hostname, etc. Just choose a different Component Type in the variable’s settings.

The post How to Extract a Query Parameter with Google Tag Manager appeared first on Analytics Mania.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Even though this topic (How to install Google Tag Manager) might sound way too basic for some of you, remember that there are nuances you should keep in mind. In this blog post, I’ll describe several ways how to install Google Tag Manager on a website, highlighting pros and cons of each option.

Where can I find Google Tag Manager code?

Google Tag Manager provides you with the exact code and instructions where to add it to your website. There are two places where you can find it:

  1. By clicking container ID link (located next to Publish and Preview buttons)
  2. Or by going to Admin > Account > Container > Install Google Tag Manager

Any of these options will open instructions how to install Google Tag Manager code on your website.

Add Google Tag Manager container code to the website

Follow the instruction and place the first code (which is surrounded by <script> tags) somewhere between <head> tags of your website. This code is the key part. It tells your page to load your GTM container asynchronously, which means that the rest of the page can continue loading while Google is doing its magic.

Here’s an example of website’s <head> where you could add the GTM <script> code.

The second Google Tag Manager code (noscript) should be placed immediately after the opening <body> tag. This works as a backup, allowing you to track users without Javascript. The <noscript> tag tells the browser if the user does not have JavaScript enabled, then render an iframe version of the GTM Container to the page.

Important: While you can place both these codes in <body> only, you must not add them both in <head>. As it was mentioned before, <noscript> part renders an iframe, which is not allowed in <head>, otherwise you’re website’s HTML will be invalid.

So the possible options are:

  • <script> code is added to the <head> and <noscript> to the <body>
  • both <script> and <noscript> codes are added to the <body>

Another thing to mention is that the <noscript> part of the GTM code is not required. You’ll need it only if you want to track visitors without enabled JavaScript (which is a very small fraction of the web traffic with many limitations) or if you want to verify the ownership of Search Console Property.

Check if GTM plugins are available

If you are using a popular Content Management System (CMS) that allows using plugins, chances are that there is already a plugin that installs Google Tag Manager for you. All you need to do is just to add your Google Tag Manager container ID.

Here are several examples of such plugins:

  • For WordPress – I always recommend GTM4WP (handsdown)
  • I saw that Magento also offers a bunch of GTM plugins
  • on Shopify, you’ll also find several good ones, for example, this.

That should save you some time. Also, some platforms offer built-in GTM integration (for example, WIX).

However, if you decided to move with the manual installation (with or without a developer’s input), here’s what you need to know (continue reading)

Why should I place Google Tag Manager code in <head>?

While this is not 100% required, it is highly recommended that you place <script> part of GTM code into <head> of your website.

Why? It’s better for tracking. The higher up in the page the snippet is, the faster it is loaded. In the older version of Google Tag Manager, it was recommended to place the snippet in the body tag, but this would potentially miss users who left your page before the body tag loaded (due to slow page speed).

If your website is pretty heavy, it might take more than few seconds for GTM to start loading in <body>, but in <head> it would be initiated much faster, thus you could catch more visitors and see how they behave.

This could empower you to identify the percentage of traffic which bounces before even the page completely loads.

Remember, the lower your tracking codes are placed in website’s code, the later they will be launched.

Publish the Container

When the code is placed on your website, head over to Google Tag Manager account and publish the container. Especially if it’s empty.

Why? Because unpublished GTM container will cause an error (visible in browser’s console).

404 not found for GET: GET http://www.googletagmanager.com/gtm.js?id=GTM-XXXXX

Your browser is requesting data from Google’s servers, although that container is still not published, thus no data will be returned.

This isn’t a big problem, but if your developers are tracking Javascript errors with particular tools (e.g. TrackJS), they’ll see those 404 errors in reports. This will create an unwanted noise for them (yes, I know they can use filters, but simply publishing an empty container won’t hurt anybody).

Need some custom data on every page? Use the Data Layer

When Google Tag Manager code is placed on your website, it automatically creates a Data Layer.

It’s like a virtual layer of your website which contains various data points (Get it? That’s why it’s call data layer.). With its help GTM is able to read, push and transfer data between your website and other tracking tools.

If you want to push some data to dataLayer when the page loads, you need to place that data above Google Tag Manager code. Like this:

<head>
 <script>
 window.dataLayer = window.dataLayer || [];
 window.dataLayer.push({
 'customerType': 'vip',
 'registrationCountry': 'United States'
 });
 </script>

 <script>
 <!-- Google Tag Manager -->
 ...
 <!-- End Google Tag Manager -->
 </script>
</head>

If you don’t possess coding skills, this work should be done by a developer (because just blind copy-pasting will not work). There must be some logic written that adds actually dynamic information to the dataLayer (e.g. if a user logs in, his/her actual customerType should be added to the Data Layer.

Data Layer is not an easy concept to grasp on for beginners. So if you are confused in this chapter, don’t worry. Everyone was. Here are some additional resources for you to read to get more familiar with it:

SUBSCRIBE & GET THE ULTIMATE LIST OF 120+ GOOGLE TAG MANAGER RESOURCES. A TO Z.
Please wait...
You have successfully subscribed. Go check your inbox.
Please enter your email address
Please enter a valid email address
Unexpected error occurred!
Frequently Asked Questions

So I’ve described what the perfect and recommended scenario looks like:

  1. <script> part of Google Tag Manager code goes to <head> (usually before the closing </head> tag).
  2. <noscript> part goes after the opening <body> tag.

But real-life situations are far from perfect and sometimes we have to deal with very limited circumstances. In this chapter, we’ll discuss other not-so-perfect options and what the possible outcome might be.

#1. Can I place <noscript> part somewhere else rather than right after <body> tag?

Yes, you can.

This usually happens while working with limited content management systems (CMS), which prohibit you from accessing the website’s source directly and only allows to paste tracking codes into a dedicated field. All content of that field is then placed at the very end of website’s HTML.

While it is not recommended, it is possible to put the Google Tag Manager <script> and <noscript> tags in the body section, as shown below. If you are planning on, or already using GTM to run A/B testing, then you definitely should place the top snippet in the head to make sure your experiments run smoothly.

But if you’re planning just to utilize some basic Google Analytics tracking (or something like it), then you should be fine.

But keep in mind, the lower your tracking codes are in website’s code, the later your tracking tags will fire.

#2. Can I remove <noscript> part and use only <script>

Yes. 

If you don’t care about people who disable JavaScript completely, you can forgo the <noscript> part completely. Remember: putting it in the HEAD will create non-compliant HTML since an iframe shouldn’t be there.

You should either put noscript part in the <body> or don’t use it at all.

#3. I Installed GTM few years ago; Both <script> and <noscript> parts are in body. Is it bad?

It’s fine.

As it was mentioned before, prior to late 2016, Google’s recommendation was to place the entire Google Tag Manager code to <body>. This is still working till this day.

But remember that you might be losing some tracking data, because GTM (placed in <body>) starts loading a bit later compared to GTM code placed in <head>.

So if you have time and resources, I definitely recommend moving <script> part to <head>.

How To Install Google Tag Manager: Conclusion

The advice here is simple: just follow Google’s instructions.

The most recommended way how to install Google Tag Manager code is to place <script> part to <head> of your website, and <noscript> part should be place somewhere in <body> (preferably right after <body> tag).

This ensures that your marketing tags in GTM will be fired as soon as possible without much of data loss.

The lower Google Tag Manager code placement is, the later your tags will fire. As a result, you might lose a portion of your data.

If you are using a popular content management system to run your website (e.g. WordPress), look for ready-made plugins that will help install Google Tag Manager with a couple of clicks.

SUBSCRIBE & GET THE ULTIMATE LIST OF 120+ GOOGLE TAG MANAGER RESOURCES. A TO Z.
Please wait...
You have successfully subscribed. Go check your inbox.
Please enter your email address
Please enter a valid email address
Unexpected error occurred!

The post How to Install Google Tag Manager on your Website Properly appeared first on Analytics Mania.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

There are already plenty of resources online that explain how to implement Google Analytics Cross-domain tracking. However, it feels that the questions of this topic are still one of the most popular ones in the community (source of this statement: my gut). And that’s no surprise. Sometimes people just blindly follow guides without properly understanding WHY this or that was made. In other cases, they do understand the basic principles but are not aware that their case/project has some nuances.

That’s why I decided to also chime in, join this bandwagon and give my take on how to explain Google Analytics Cross-domain tracking with Google Tag Manager.

Brace yourself, this guide will be a long one (but definitely rewarding).

P.S. If you’re not sure whether you should use Google Tag Manager (because in this guide, I’ll solely focus on GA+GTM setup), the short answer is yes, you should. The longer answer is yes, you most definitely should start using GTM. And the longest answer can be found here.

Before we continue

If you find this blog post too long, too confusing or you just simply prefer when someone explains it to you visually, I have taken a very deep dive into cross-domain tracking in my Intermediate Google Tag Manager course. In addition to other awesome and comprehensive topics (like in-depth Enhanced Ecommerce setup), cross-domain tracking also gets a lot of attention there. After all, it’s one of those pains in the butt that I see GA users coping with pretty often.

If you are looking for a fast track in order to learn next-level tracking techniques with GTM (and GA), that course is exactly what you need.

Table of contents
Interested in Digital Analytics? Me too! Subscribe and receive relevant tips & resources.
Please wait...
You have successfully subscribed. Go check your inbox.
Please enter your email address
Please enter a valid email address
Unexpected error occurred!
How to read this guide?

This guide will be a large one (so is the cross-domain tracking). That’s why I’d like to give you several hints on how to read this guide and how to benefit from it the most.

  • This blog post is split into four main parts:
    • #1. Introduction to Google Analytics cross-domain tracking
    • #2. How to configure Google Analytics cross-domain tracking with Google Tag Manager?
    • #3. Testing the entire flow
    • #4. Other things to keep in mind
  • One of the first mistakes about the cross-domain tracking that I notice in the community is that some people don’t understand why it exists in the first place. Hence they don’t always understand whether they need it in their project at all. So if you’re not sure whether you need Google Analytics cross-domain tracking configured, definitely read the Part 1 of this guide.
  • On the other hand, if you are 100% sure that you need cross-domain configured in your GA (via GTM), then Part 2 is where the actual setup is explained. Since there are different ways of how cross-domain tracking should be implemented (based on how your website works), this part is the main reason why the guide is a lengthy one.
  • In the third part, we’ll take a look at the main debugging tips, where and what to check.
  • The fourth part of the guide is optional and contains some additional tips.
PART 1: Introduction to Google Analytics Cross-domain tracking #1.1. A quick step back. How does GA track visitors?

This will be very simplified.

By default, Google Analytics tracks users with first-party cookies. You land on a website and GA (on behalf of your website) stores a _ga cookie in visitor’s browser (with some random identifier). When you, as a visitor, navigate from page A to page B (of your website), Google Analytics checks the value of that cookie.

Since the cookie is still present (and the same), GA understands that you are the same person who just was on page A, therefore, the 2nd page view is also attributed to the same session and user.

And that’s great! With web analytics tools (not just GA), you can track how visitors are using your website, what are they doing, etc. Of course, cookies, as a technology, are far from being perfect and have a lot of drawbacks but let’s keep this topic for another blog post.

#1.2. So where is the problem?

Where am I heading with all of this? First-party cookies (created on behalf of your website) cannot be shared between two separate domains (due to cross-domain policy). So if you have a website where the journey of a visitor starts on domainA.com and eventually, ends on the domainB.com, Google Analytics on the domainB.com will not able to understand that this is the same visitor as on the domainA.com (even if the GA property on both domains is the same).

When the visitor navigates from domain A to domain B, Google Analytics on domain B cannot reach the _ga cookie of domain A, therefore, it creates a new one.

The result? Google Analytics (and other cookie-based web analytics tracking tools) will see you as two separate visitors, one on the domainA.com and one on the domainB.com.

And that’s a big problem.

  • First of all, you will see too many users in your GA reports. Every person who visits both domainA.com and domainB.com will turn into two users.
  • You’ll lose the original traffic source. If a visitor lands on the domainA.com from a Google Ads, then navigates to domainB.com and converts, that sale will not be attributed to Google Ads. Because whenever a visitor jumps from one domain to another, GA will start a new session and its traffic source will be domainA.com. This means that such conversion will be attributed to your own website and you won’t be able to properly measure the effectiveness of your marketing efforts. This situation is called “self-referral”.

#1.3. Examples of GA cross-domain tracking

If you’re very new to Google Analytics cross-domain tracking and don’t understand its main purpose, don’t worry! Here’s are several examples where you must implement it:

  • A visitor lands on your ecommerce store > initiates a purchase > is redirected to payment processor’s website (which is hosted on another domain) > makes a purchase and returns. Cross-domain tracking must be implemented in the jump between your store and the payment processor’s website. Otherwise, all your purchases will be attributed to that payment processor, not the original traffic source (like Google organic, paid ads or something else).
  • You run a travel blog and have an embedded form where visitors can check hotel prices and even book rooms. That form belongs to another domain (embedded via iFrame). So if you want to track how your blog visitors interact with that booking form (and you want Google Analytics to properly track it), you need to enable the cross-domain tracking (within that iFrame). Otherwise, all the bookings within that form will be attributed to the parent website (your travel blog) and GA will see users of the booking form as totally different users.
#1.4. Google Analytics Cross-domain tracking to the rescue!

Not everything is hopeless here. Otherwise, this guide would not exist, right?

Even though you cannot access domainA.com’s first-party cookies on domainB.com, there is a workaround that can help you make sure that _ga cookie’s value on both domains is the same. Because that is your main goal. Google Analytics can track the same visitor on different domains without any problems (but some additional configurations will be needed) as long as _ga cookie’s value persists across those domains.

Here’s how Google Analytics cross-domain tracking works in a nutshell.

When a visitor navigates from domainA.com to domainB.com, we’ll pass a special linker parameter to domainB.com’s URL. Thanks to that linker parameter, the GA on domainB.com will be able to update the _ga cookie and will understand that it’s actually just one person navigating between two websites.

#1.5. Your main goal: the same value of _ga cookie across different domains

I cannot stress this enough. Cross-domain tracking will work only if you make sure that the _ga cookie (that Google Analytics uses to identify visitors) has the same value on different domains.

Of course, there are some other additional configurations needed (I’ll explain them a bit later) but this is the key ingredient to success (and in many cases, the most difficult part to do and the most tricky part where GA users struggle).

#1.6. You DON’T need Google Analytics cross-domain tracking on subdomains of the same domain

This is a common misconception of how cross-domain tracking works. Its purpose is to help track visitors that navigate between totally different domains, like domainA.com and domainB.com.

If you just have a website www.website.com and your visitors can also navigate between blog.website.com, support.website.com, you DON’t need to configure cross-domain tracking.

Just go to your Google Tag Manager container, open Google Analytics Settings Variable that is used by your GA tags and set Cookie Domain to auto. By default, all GA Settings Variables have it enabled.

That’s it. There is no need to implement GA cross-domain tracking for subdomains. Better spend your time somewhere else.

But if, on the other hand, you indeed need to track visitors/users across different domains, then you will find the rest of this guide very useful (hopefully).

So that was the end of the first part of this guide. So far, so good. Nothing super difficult. But that might change in the 2nd part (I’ll do my best to keep it simple).

PART 2: How to configure Google Analytics cross-domain tracking with Google Tag Manager? #2.1. Four requirements/steps for cross-domain tracking to work

In order to make cross-domain tracking work, your setup must meet for requirements. ALL of them. If at least one of them is not possible (due to some circumstances), then I have some bad news.

  1. All websites must use the same Google Analytics property.
  2. The URL of the destination page must be decorated with the linker parameter (_ga=)
  3. You must have enabled the allowLinker field on the destination page. Set it to true. If you don’t have access to the destination website’s GTM or if nobody can help you edit the hardcoded GA code there, proper cross-domain tracking will not work. That’s it. No workarounds. End of story.
  4. Update the referral exclusion list. Include all the outbound domains, from which a visitor navigates to the destination domain.

Did I mention that ALL of these requirements must be met?

#2.2. Let’s agree on terms

In this guide, I’ll use the following definitions. So in order not to be confusing, I thought it would be useful to agree on them.

Outbound website – if the visitor moves from domainA.com to domainB.com, then domainA.com is the outbound website. If the visitor can freely jump back and forth between both of these domains, then they both are considered as outbound websites. In GA official docs, you will find that outbound website is called Primary website. But I like to call it outbound.

Destination website – if the visitor moves from domainA.com to domainB.com, then domainB.com is the destination website. If the visitor can freely jump back and forth between both of these domains, then they both are considered as destination websites.

If a visitor can freely navigate between websites, then each one of them is considered to be both outbound and destination website. It just depends from where (and to where) the visitor is navigating.

#2.3. The flow

From this point, we’ll take a look at every requirement for GA cross-domain tracking to work. Some of them are fairly simple and straightforward, some of them — not so much. But first, let’s remember the workflow of how cross-domain tracking works in a nutshell.

When a visitor navigates from domainA.com to domainB.com, then domainB’s URL must be somehow decorated with the _ga linker parameter. That linker parameter contains some information, including the value of the _ga cookie of the domainA.com.

Once the allowLinker field is enabled on the destination domain, Google Analytics reads the linker parameter from the URL (_ga) and updates the _ga cookie accordingly. From this moment, both domainA.com and domainB.com have the same value of the _ga cookie and this allows Google Analytics to see that visitor as one person.

Keep in mind that both websites are using the same GA property (e.g. UA-1234567-1). Also, the referral exclusion list is configured, it’s just not displayed in one of the schemes above.

Alright, let’s go to the actual configuration of all the necessary steps/requirements.

#2.4. Step/requirement No.1: All domains must be tracked with the same GA property

There isn’t much to add here. Cross-domain tracking works only if both outbound and destination domains/websites are tracked under the same GA property. This means that the tracking ID (UA-xxxxxxxx-xx) must be the same during the entire visitor journey.

#2.5. Step/requirement No.2: The URL of the destination page must be decorated with a linker parameter (_ga)

From my experience (and looking at the questions in forums), this part is the most tricky/confusing. People either just blindly follow tutorials without realizing what is going on, or they are not sure how to test this. Or they just implement URL decoration without realizing that their project/website requires a different decoration method.

Because… surprise surprise… there are different methods of how to add that _ga parameter to the URL. And they are not universal. You need to choose wisely depending on the context.

But before we dive into those decoration methods, first, let’s take a quick look at the linker parameter itself. In the future, it may eventually change/look differently (for example, in early 2019 Google was already doing live tests with a differently looking parameter). But as of the moment of writing this blog post, the parameter is still _ga

So if the URL is decorated with the link parameter, it might look like this:

See this part?

That’s the value of the _ga cookie on the domainA.com. So if we pass this value from the domainA.com to domainB.com and then instruct Google Analytics to fetch that value on the domainB.com, the _ga cookies on both domains will be the same. And this is exactly what we are aiming for!

We need to somehow decorate the URL of the domainB.com when the visitor navigates from the domainA.com

#2.5.1. In order for link decoration to work, there must be an interaction

Before you properly implement Google Analytics cross-domain tracking with Google Tag Manager, ask yourself: how is the visitor navigating from domainA.com to domainB.com?

This question is crucial. By answering it, you will know how to decorate the URL of the destination page. There are several options/possible answers:

  • A user navigates from domainA.com to domainB.com by clicking the link on the domainA.com
  • A user navigates from domainA.com to domainB.com by submitting a form on the domainA.com (which then redirects to the domainB.com)
  • A user loads a page (on domainA.com) that has an embedded iFrame (of the domainB.com)
  • A user completes some other interaction on the domainA.com that redirects to the domainB.com (for example, submits a form that is coded in a way Google Tag Manager cannot track with the built-in form submission trigger).

Each of these answers leads to a different way how can a URL (page address) of the domainB.com be decorated.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

WIX is one of the most popular website builders that positions itself as “easy to use” and “allows to build gorgeous websites”). Even though such builders take away a lot of flexibility from you (especially when it comes to SEO-or-GTM-related modifications), their popularity is still solid.

When the owners of such websites start realizing that they also need to track what their website visitors are doing, Google Tag Manager + Google Analytics come as one of the first tools to consider.

Just a bit more than a year ago (early 2018) WIX added support for Google Tag Manager (meaning that you can actually implement its code and use the tool for what it does the best, controlling marketing tags and firing them when you actually need). Nevertheless, there are still some nuances people face and I decided to address them in this blog post.

So if you want to track WIX website with Google Tag Manager, continue reading.

Quick Context

Some time ago (in 2017 and before that) WIX’es Custom HTML widgets did not function properly with GTM container code in them. And this approach still doesn’t work. The only way you could enable Google Analytics Tracking was by going to a dedicated Analytics section and adding GA tracking code there.

Yay, pageviews.

But what if I wanted to track particular clicks or other interactions happening on a website? Usually, GTM was the tool that could do that. Well, that’s too bad because WIX did not care much about it and GTM fans (WIX users) were crying in the corner (or maybe even switching to another website builder).

Thankfully, that time is over and GTM can be installed in no time.

Install Google Tag Manager on a WIX website

First of all, this feature is only available for paid plans of WIX. If you’re still using the free plan, sorry, there’s no workaround. You’ll either need to upgrade or stay just with regular pageviews. If you’re on any premium plan, continue reading. Also, you MUST have a domain connected to the website. Otherwise, GTM integration option will not be available.

Login to your WIX account and choose the website where you wish to install GTM, click Edit Site.

Then you will be redirected to WIX’s Editor (a.k.a. ADI). In the top right corner, click Site and then choose Settings.

Then, in the left sidebar, go to Tracking & Analytics.

Finally, in the top right corner, click New Tool > Google Tag Manager.

Enter the ID of your GTM container (e.g. GTM-XXXXXXX) and click Apply. Google Tag Manager container code snippet will be added to all pages of a WIX website. You can find the GTM container ID in the top bar of Google Tag Manager account:

Test Google Tag Manager on WIX

Now, let’s test whether Google Tag Manager container was added correctly. Enable Preview and Debug mode (by hitting the Preview button in GTM), go to the website you’re working on (the public part) and refresh the page. A debug console window will appear at the bottom of your browser, showing detailed information about your tags, including their firing status and what data is being processed.

Not seeing it? Continue reading.

Important! If you don’t see the Preview and Debug mode on WIX

WIX is far from being perfect. Pretty far. I had some struggles with it even while writing this blog post. At some point of this article, WIX’s built-in Google Tag Manager integration just stopped working.

Even though I was able to add the GTM container ID (just as I have described it above), the Google Tag Manager container was not loaded on a page anymore. Direct Google Analytics integration was working fine, but not GTM.

So if this situation also applies to you, do the following.

#1. Diagnose if the GTM container is loaded at all. Once you have added the container ID to the WIX’s settings, publish the website. Then go to your website’s public section (I mean open your website as a visitor) and then open browser’s developer tools (on Windows you can do that by pressing F12). Go to the Network tab and enter gtm.js in the search field. Refresh the page. Did the search return anything that contains “gtm.js”? If yes, this means that you have some other problem. Read this guide to find a solution.

If, however, the search did not return gtm.js at all, this means that Google Tag Manager container was not even added to your website. This exact case applied to me. What’s the solution?

#2. Replace the built-in GTM integration with the custom one. Go to WIX’s analytics settings and disable the GTM integration.

Then in the top right corner, click New Tool > Custom and enter the following settings (in the first field you should paste the first (out of two) Google Tag Manager container code snippets (that is surrounded by the script tags):

This is an alternative solution that worked for me. Maybe it will work for you as well.

But wait, there’s more. Regular pageview tracking does not work on WIX

So here’s the situation. You want to start tracking pageviews with Google Analytics via GTM. You create a Pageview tag, set it to fire on all pages, refresh the preview mode, then refresh the WIX website. The Pageview tag has successfully fired and you also see it in GA’s real-time reports.

Great!

But once you continue browsing your website, you’ll start noticing that none of the subsequent pageviews are displayed in GA real-time reports (and, of course, the UA tag never fires again as well, unless you completely refresh the page). And it always happens like this: the first page view is tracked, all the subsequent: not.

Why? Because WIX websites are coded as single page applications. Even though it looks like pages are being reloaded while you’re navigating, that’s just an illusion. In fact, when you initially load the page, the entire website (or at least the large chunk of it) is loaded immediately. When you’re browsing the site, WIX is dynamically changing the view and imitates that pages are loading.

This means that Google Tag Manager container snippet is also just loaded once, hence only the first load (pageview) is tracked. How can this be solved? Luckily, WIX is sending virtual page view events every time a visitor navigates from section A to section B. That data is pushed to the Data Layer. All you need to do is to catch your Data Layer pageview events and use them to fire Universal Analytics pageview tags (or Facebook Pixel, or whatever). Here’s an example

As you can see in the screenshot above, there are two Pageviews in the event stream. The more pages you navigate through, the more of these events you’ll see. The first Page View is generated by the GTM container itself. The second Pageview event (without a space in its title) is sent by the WIX itself.

So how are we going to track page views in WIX?

Since WIX is automatically sending custom page view events to the Data Layer every time a visitor navigates to a new page, we need to catch them, turn into triggers and use them to dispatch our Google Analytics Pageview Tag.

If you want to turn a particular Data Layer event into a trigger, you’ll need to create a Custom Event Trigger. In your GTM container, go to Triggers > New > Custom Event. Enter Pageview (because it is the exact name of the event you saw in the Preview & Debug Console’s screenshot above). Note: this field is case sensitive, therefore, make sure that you enter the uppercase P.

Add the custom event trigger to the GA Pageview tag

Next step, you need to update your GA pageview tag in Google Tag Manager. Prior to reading this guide, it was most likely that your GA Pageview Tag already had All Pages trigger. This time, add the additional trigger that we created in this guide, Custom Event Trigger.

What does it mean? When the page initially loads, the All Pages trigger will fire your GA Pageview tag. When a visitor continues to browse the website, WIX will push custom Pageview events to the Data Layer, thus your Custom Event trigger will activate. That trigger will fire a GA Page View tag and you should see that data in the GA Real-time reports.

Test pageviews

After you implement all the changes I’ve described above, refresh the Preview and Debug (P&D) mode in GTM, reload the WIX website you’re currently working on. Start browsing it. You should see that GA Page View tag fires with every custom Pageview event in the P&D console. That’s the result you should expect. If the tag does not fire, make sure that you enter Pageview event name in the Custom Event trigger properly (with the uppercase P).

Next step, go to GA Real-time reports and check whether your page views are properly tracked in the Overview section.

Prevent rogue referral issue

As I’ve mentioned at the beginning of this guide, WIX websites behave as single-page websites (meaning that they do not reload the entire page as a visitor navigates from one page to another). This causes problems with the referral data in your GA reports as the data becomes inaccurate. This is especially harmful if you are receiving paid traffic (e.g. from Google Ads). Therefore, you need to implement an additional solution provided by Simo Ahava.

Next stop: click tracking

If you want to track which elements are being clicked the most, which links are driving your visitors away, etc., read this guide. Here I have explained the essentials you need to know about in order to track clicks with Google Tag Manager on your WIX website.

Here is some food for thought:

Going further: WIX form tracking with Google Tag Manager

Form is another important website element that webmasters and marketers are willing to track. They usually mean micro or macro conversions to businesses. Newsletter subscriptions, lead form submissions, etc. All of them should be tracked in order to get a better understanding of where converters are coming from.

I haven’t tried all of WIX’s form plugins but I’ve noticed that default ones are actually pushing form submissions to the Data Layer (which is good!). When you submit the form on your WIX website, check the Preview and Debug mode. Did some event appear? If you have enabled the built-in GTM integration, you might see an event called lead.

 So if that’s also the case of yours, all you have to do now is to create a Custom Event Trigger in GTM that will catch that lead event and you’ll be able to use that as a tag firing condition (trigger).

Then assign this trigger to the tag you want to fire (it might be GA Event tag, Google Ads conversion tag or anything else).

If you haven’t enabled GTM built-in feature of WIX (maybe it’s not working for you), there are other options as well. Form tracking isn’t easy if you’re just starting with GTM. There are multiple types of forms online, hence many form tracking methods. In fact, as of the moment of writing this post, I’ve published 7. This is another extensive guide that might take require a lot of your effort. So if you’re looking for other ways how to track form submissions, check my form tracking guide and you’ll eventually find something useful. E.g. Element Visibility trigger might be a solution.

Can’t get enough?

If you’re looking for more ideas/inspiration what to track on WIX website with Google Tag Manager, here’s a list of 99 things you can do with GTM. While not all of them will be possible on WIX, make sure you check them out. For example, you might want to implement scroll tracking.

Track WIX website with Google Tag Manager: Final words

If you want to track WIX website with Google Tag Manager, you need to keep in mind several nuances. First of all, you cannot just simply paste GTM container’s code snippet to the Custom HTML block in WIX’es editor.  That will not work. Instead, you should use a feature dedicated for that (available in website’s settings).

Furthermore, WIX websites are coded as single page applications. This means that by default only the first pageview is tracked. All the subsequent ones — not so much. That’s why you need to do some additional modifications in the GTM container to catch those “virtual” page views as well.

But other than that, the rest of the tracking should work properly. Unless you are expecting a developer to push some custom data to the Data Layer. I really doubt that this is possible but, on the other hand, when I had to work with WIX websites they were fairly small and there was no need for developer’s input.

If you see that I missed some important nuance (because maybe I just never had faced it), let me know in the comments.

By the way, if you are feeling stuck with Google Tag Manager in general, check my Google Tag Manager course where a lot of the techniques from this blog post are explained in greater detail and logical flow.

The post How to track WIX website with Google Tag Manager appeared first on Analytics Mania.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

This time, I’ll give you a quick tip. Most likely, the significant group of my readers already know this but maybe it will help the rest of you. When I explain GTM, I often find myself showcasing and editing live GTM containers. When the demonstration is over, the container is littered with unwanted garbage, temporary tags, triggers, variables.

I don’t want to leave my trace, therefore, I have to keep things clean. How do I get rid of those temporary changes? One way is to go to the Overview of the container and then manually abandon change after change. Not very convenient.

I could have created a new temporary workspace just for that demonstration and delete it afterward. However, I forgot to do that. In fact, I often find myself forgetting to create temporary workspaces for some demo stuff. Restoring to previous versions can also be an option but it is still more time-consuming than I want.

So what can I (or you) do? What is the faster way to abandon all the changes in the default GTM workspace (knowing that it’s the only workspace I currently have)?

The answer is simple (and I guess that many of you already know that). Delete the default workspace. Even if that’s the only workspace you have, feel free to delete it. Default workspaces can also be deleted.

Once you do that, all the changes in the workspace will vanish and the new (clean) default workspace will be automatically created in a moment. To do that, click on the “Current workspace” button.

A list of all workspaces will slide from the right. Click on “i” icon next to the workspace you wish to delete.

When another panel will slide it from the right, click 3 dots in the top right corner then choose Delete.

If you had only one (default) workspace, you will be immediately redirected to the Overview of your GTM container where you will find yourself in a newly created workspace.

What happens if you delete a default workspace while some custom workspaces are already available? Immediately after you delete it, you will see the very same list of all the workspaces in the container (including the fresh new default workspace).

Choose the workspace you want to continue working with, e.g. Default Workspace.

That’s it. You have just got rid of all the temporary changes just in several clicks. This tip was so quick that I don’t even need to write the conclusion.

If you have any questions related to this, the comments section below is at your service.

The post How to quickly get rid of all the changes in the default GTM workspace? appeared first on Analytics Mania.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Updated: May 28th, 2019. Why doesn’t my tag fire? What data can I send to Google Analytics? Why didn’t this trigger work?

When it comes to Google Tag Manager, we sometimes run into trouble that requires further investigation of what’s going on. One of the most important, yet commonly overlooked steps in the GTM process is debugging. It allows us to ensure that every possible user experience scenario is tested and data consistency is validated. In this guide, I’ll show you how to utilize Google Tag Manager Debug mode and share some best practices.

Table of Contents Before we continue

If you feel like you’re a bit more experienced, here is a bunch of additional Google Tag Manager debugging tips. Not only does that guide include GTM Preview and Debug mode tips, but it also mentions 3rd party debugging tools as well.

But on the other hand, if you’re just getting started with GTM, I also give an overview of the Preview and Debug mode in my free GTM Fundamentals course.

What Is Google Tag Manager Debug Mode?

Google Tag Manager Preview and Debug (P&D) mode allows you to browse a site on which your GTM container code is implemented. Sites with preview mode enabled will display a debugger pane (a.k.a. console) at the bottom of your browser screen so that you can inspect which tags fired and in what order.

Enable Preview And Debug Mode

To enable Google Tag Manager Debug mode, click Preview button in the top right corner of your GTM interface (near Submit button).

After you enable P&D mode, a large orange notification banner will appear.

Now, navigate to the site where the Google Tag Manager container code is implemented, refresh the page and a debug console window will appear at the bottom of your browser, showing detailed information about your tags, including their firing status and what data is being processed.

This console window will appear only on your computer as you preview the site, and is not visible to your other website visitors.

Important: If you’re having difficulties with Preview and Debug mode, read the guide on how to fix it.

The layout of Preview and Debug console

Google Tag Manager Debug mode (a.k.a. Google Tag Manager Console or just GTM console) consists of five main parts:

  1. Event Timeline. Displays all events that occur in the Data Layer (e.g. page views, form submissions, clicks, etc.). Do not mistake them for Google Analytics events. These are totally two different concepts, which I have discussed in another blog post.
  2. Tags. Displays which tags fired on the selected event and which ones didn’t.
  3. Variables. Displays detailed information about variables in the selected event, including the type of variable, the type of data returned, and the resolved value.
  4. Data Layer. Displays the exact message object as it was pushed to the data layer for the selected event, and what the data layer looks like after the message transaction is complete. All data points available here can be turned into variables (which then will appear in Variables tab). Continue reading to learn more.
  5. Errors. This feature is pretty new in GTM and isn’t used too often (at least from my experience). But if you notice any number in the tab (rather than 0), click it and see what is the cause.
Event Timeline

All events that occur in the data layer are displayed on the left side of the Preview and Debug console, Event Timeline. Every time a page loads, there must be three events displayed in the list – Page view, DOM ready and Window loaded.

If you see more events (for example, Message), that’s fine. But it’s important that all three aforementioned events appear in the list. If you’re missing Page view event, there’s probably a case of the broken data layer. I have published a blog post, which explains both the problem and the solution when page view event does not appear in GTM P&D mode.

Why are there always three events?

What do they mean?

Pageview event (a.k.a. gtm.js) is the earliest moment when GTM starts loading and when our tracking scripts can be fired. For example, that’s when you should fire the Google Analytics page view tracking tag. Even if the page hasn’t finished loading, your tracking script will be already launched.

DOM Ready event (a.k.a. gtm.dom) occurs when the website’s HTML is downloaded, the page’s document is rendered and a visitor starts to see elements of your website.

Window Loaded event (a.k.a. gtm.load) fires only when everything else (including Javascript) finishes loading.

If you have tags that are not so important but still must fire on every page, I recommend linking them with DOM Ready or Window Loaded events/triggers. Browsers limit the number of HTTP requests that can happen at a time. Firing all tags with Page view might cause some issues.

This situation can also be resolved by implementing tag priorities or tag sequencing.

What Are Other Possible Google Tag Manager Events?

Actually, the list of events is endless. Let me explain.

Google Tag Manager offers a list of built-in triggers, such as page view (incl. previously described Page view, DOM ready and Window Loaded), click (link click and click of any element), form submission, timer, history change, Javascript error.

After a trigger is enabled, it starts looking for particular interactions on your website. For example, Form submission trigger is looking for form submissions, Link Click trigger is waiting for interactions when visitor clicks any link.

When the desired interaction occurs, that event appears in the GTM Event Timeline.

So why did I say that the list of GTM events is endless? It’s because of the last type of trigger, called Custom.

A custom event is an event defined by you, your developer or a 3rd party solution which is implemented on your website.

As an example I’d like to mention is Twitter Tweet tracking recipe which is available in my library of GTM recipes. After that recipe is imported to your Tag Manager container, it starts monitoring all clicks of embedded Twitter Tweet buttons. After one occurs, a data layer event (called social interaction) fires.

Custom events are also important when you’re tracking VimeoForm abandonment, etc.

When you click any event in the timeline, you can see which tags fired and which ones didn’t. That’s where Tags tab becomes super important.

Tags

This tab displays all available tags separated between those that fired on the selected event and those that did not. What makes this section really awesome, is the ability to find out the exact reason why a particular tag did or didn’t fire.

Choose any event in the Event Timeline (1) and then click the tag you’re interested in (2).

What you’ll see is a much more detailed view of what happens with that tag:

  • Properties of the tag.
  • Triggers of the tag.
  • Blocking triggers.

If you’re using more complex triggers with several conditions, you can see the status of each condition (take a look at the screenshot below). The green checkbox indicates that the condition was met, otherwise, a red X appears.

Variables

OK, let’s head over to Variables tab. It displays detailed information about variables in the selected event, including the type of variable, the type of data returned, and the resolved value.

These variables are at your service. You can include them in any tag you want, whether it’s Google Analytics event tag, Mixpanel event tag, or anything else. Variables can be included by surrounding them with curly brackets {{ }}. Take a look at the example below.

Switch between GTM events (in Events Timeline) and you’ll see how values of variables were changing depending on context.

Data Layer

Data Layer tab is the most undervalued and totally untapped part of GTM debug console, which is forgotten by beginners and (especially) intermediate users.

This tab shows the exact message object as it was pushed to the data layer for the selected event, and what the data layer looks like after the message transaction is complete.

In other words, you can see all data that is currently available in the data layer and what values were available after every Google Tag Manager event. And the best part: every data point (pushed to data layer) can be turned into a variable in Google Tag Manager.

Variables tab (of Google Tag Manager Debug pane) displays only those variables, which are configured in Google Tag Manager interface, e.g. Page Path, Page URL, etc. So if you have something interesting in data layer that you’d like pass to Google Analytics, you’ll need to create a data layer variable in GTM interface.

Here’s an example. For my WordPress blog I’m using DuracellTomi’s GTM plugin, which is pushing some data with each page load: pagePostType, pagePostType2, pageCategory, pagePostAuthor.

These four data points do not appear in my Variables tab, because I haven’t created them in my GTM user interface as Data Layer variables.

Say, you want to send a Google Analytics event when someone leaves a comment. With every event you also want to push article author’s full name. This way you’ll see which authors drive the highest reader engagement.

In Google Tag Manager account, you should go to Variables and create new one with the following settings (dlv stands for data layer variable):

After you refresh P&D mode AND your website in browser window you should see a new variable in Variables tab with every new page load. Later on, you can include that {{dlv – Post Author}} variable in Google Analytics event.

In my other blog post, how to track AJAX forms with Google Tag Manager, I have explained how you can dive deeper into the data layer, pull nested values and turn them into GTM variables. That simple technique has already been useful so many times, I can hardly imagine how I used to work without it.

Errors tab

As it was mentioned before, this tab isn’t visited very often (because not many tags actually throw errors that are displayed there. But if you notice any number in the tab (rather than 0), click it and see what is the cause. This tab displays if a GTM Tag Template failed to fire due to an error. Here’s a quick guide about it.

Share or Exit

Remember, when you enable preview mode, the previewed container configuration and debugger pane are only visible from the same browser from where you activated preview mode.

However, you may share your preview with others using the share preview feature. Click Share Preview in the preview notification banner.

This brings up a dialog box where you can copy a URL to send to someone else. Enter the website domain (you are currently working on) and copy the generated preview URL in the box below.

You can then send the preview URL to another person. The preview URL will take the user to a landing page where they will be informed that their browser has been enabled for preview mode. There will also be a link on the landing page to disable preview mode for that browser.

Make sure that person has also enabled 3rd party cookies in his/her browser. If Preview and Debug pane does not appear, read this blog post.

After you finished debugging your Google Tag Manager implementation, click Leave Preview Mode link in the orange notification bar.

Few More Tips

Here are a few more quick tips that did not fit in any previous chapter of this blog post:

  • If Google Tag Manager Debug console is taking too much space of the screen, you can easily resize it by dragging its top border up or down, or you just can simply hide the entire pane by clicking down-arrow icon located in its top right corner.
  • If you see “Message” event prior to Page view event in Preview and Debug console’s Event Timeline, do not worry. This means that your developer, plugin or particular 3rd party solution..

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview