Analytics Maniahttps://www.analyticsmania.com
Google Tag Manager & Google AnalyticsSun, 07 Jun 2020 08:58:17 +0000en-UShourly1https://wordpress.org/?v=4.9.8https://www.analyticsmania.com/wp-content/uploads/2018/09/cropped-Analytics-Mania-Premium-Icon-32x32.pngAnalytics Maniahttps://www.analyticsmania.com
323210 Most Common Enhanced Ecommerce Mistakes (Implemented via GTM)https://www.analyticsmania.com/post/common-enhanced-ecommerce-mistakes/
https://www.analyticsmania.com/post/common-enhanced-ecommerce-mistakes/#commentsSun, 07 Jun 2020 03:40:28 +0000https://www.analyticsmania.com/?p=8086Updated: June 7th, 2020. Enhanced Ecommerce (EE) is probably the most powerful web tracking feature in the Google Analytics toolset (I intentionally added the word “probably” so that I would more or less right #thanksCarlsberg). It allows you to track not only the final goal (purchase or something similar) but also the entire funnel (starting from […]

Enhanced Ecommerce (EE) is probably the most powerful web tracking feature in the Google Analytics toolset (I intentionally added the word “probably” so that I would more or less right #thanksCarlsberg). It allows you to track not only the final goal (purchase or something similar) but also the entire funnel (starting from the product impression).

However, with great power comes great responsibility (read: in order to properly implement EE you will face many challenges, issues, nuances, quite lengthy documentation (for an inexperienced eye), and some not-so-intuitive requirements). It isn’t always like that. The more EE implementations you do, the better you will become at it. However, the initial steps are full of traps and you will probably learn lessons the hard way.

Even though there are some very useful EE-related resources online (e.g. a bunch of Simo Ahava’s blog posts), people still tend to do same mistakes over and over again (at least that’s what if feels like when I’m seeing yet another post in the GTM community about the Enhanced Ecommerce problem that was discussed a week or two ago).

But I fully understand that. The topic is complex, there are many things you need to understand and keep in mind, some guides might look too complicated, and, in the end, the best teachers happen to be our own mistakes. However, those mistakes might cost a lot of time and money. That’s why I decided to also add my two cents to the ecosystem of blog posts/guides about EE. In this article, I will share Enhanced Ecommerce mistakes that I notice most often in others’ Google Tag Manager implementations (or questions in Google Tag Manager communities).

In May 2019, I have released an Intermediate Google Tag Manager course that takes a deep dive into various web tracking topics where GTM is one of the most important ingredients. I will uncover and explain many underutilized Tag Manager features but, most importantly, I tackle some biggest pains that digital marketers and analysts face in web tracking:

iFrames and Cross-domain tracking

Cooperation with developers

Proper testing and debugging

Enhanced Ecommerce, etc.

Enhanced E-commerce takes a special place in the course by getting a 2-hour-long module where I explain the entire implementation process, starting from planning and ending with the actual configuration and testing.

Many of my early-adopter students have named Enhanced Ecommerce implementation as one of their top pains at work and, after taking that intermediate course, they learned A LOT about it and now can own the process with confidence.

Most common Enhanced Ecommerce mistakes

Alright, enough of the introduction, let’s get down the business. Not all of these list items are considered critical mistakes. Some belong to the “it would be better if you did this” zone.

If you see that some very common mistakes are missing from this list (which is totally possible), let me know in the comments and I’ll add them here.

Mistake #0. Not studying EE-related resources well enough and trying to bet on your intuition

The majority of the mistakes mentioned below are caused (I think) because people don’t read the available resources online (the official docs, Simo’s blog posts, other resources).

My guess is that they just quickly skim some parts and try to figure out the rest along the way. The result? Well, this blog post is considered to be one of them.

Mistake #1. Using the Universal Analytics Transaction tag

If you’re familiar with the implementation of GA Standard Ecommerce, you already know that the purchase must be tracked with a Transaction Tag.

However, this type of Universal Analytics tag works only with the Standard Ecommerce. In the case of Enhanced Ecommerce, information about all funnel steps (including purchase) must be sent either with a page view or with an event tag (with Enhanced Ecommerce features enabled). The transaction tag will not work.

Mistake #2. Not following the structure (and naming convention) of dataLayer.push snippets

So here is the main principle of how the Enhanced Ecommerce implementation via GTM works. A developer pushes ecommerce data to the Data Layer (e.g. product impression, product click, add to cart, purchase, etc.), then you fire the Universal Analytics tag (with enabled Enhanced Ecommerce features) that sends the EE data (from the Data Layer) to Google Analytics.

But here’s the catch: a developer cannot just push some random ecommerce data to the Data Layer. The data must be formatted (and use the same naming convention) as it is strictly described in the official GTM documentation (for Enhanced Ecommerce).

In the dataLayer.push there always must be an ecommerce object that contains certain data related to a particular funnel step. Then there must be the name of the action (e.g. add, remove, purchase, checkout, etc.) and then some data related to that particular action.

dataLayer.push does not have to include all the purchase-related fields that are displayed in the documentation (because some are optional), however, if you decide to include a particular parameter, then make sure that a developer uses the key of the attribute as it is displayed in the official docs.

Also, data types of those attributes must be as Google requires. If products is displayed in the documentation be an array then it must be an array.

Mistake #3. Not being consistent

As Simo Ahava mentions this multiple times in his blog posts (e.g. this one), there is almost no attribution in Enhanced Ecommerce. This means: if you are tracking products and, for example, send the product name to GA (in the “add to cart” funnel step), that data will not be automatically available in the GA reports of subsequent funnel steps (e.g. checkout or purchase). Forget session or user scopes here. The only way to make sure that data (e.g. product name) persists in all the funnel steps is to ask a developer to push such product information (dimensions and metrics) to the Data Layer in every step of the EE funnel. Read this guide for more info.

Consistency is key here and you have to ask a developer to push the dimensions not just once (in a single funnel step) but to do that in every funnel step. That way you will be able to see, say, the stats of that particular product throughout the entire funnel.

P.S. Checkout steps are an exclusion to the rule here (it’s sufficient to pass the product data only with the first checkout step).

Tip:read this guide on attribution in Enhanced Ecommerce. There is almost none of it, however, you need to be aware of some exceptions.

Once you do that, optionally, you can label the checkout funnel steps. But here is a part that, apparently, is tricky for those who just quickly skim Enhanced Ecommerce guides. Checkout funnel includes only those steps that happen after the product(s) is added to a cart (e.g. the customer clicks Start Checkout button) and before the actual purchase.

Checkout funnel is NOT the full Ecommerce funnel. You do not have to enter all the funnel steps here (starting from product impressions and ending with the purchase). That’s not how it works.

In this section, you only need to enter steps like “Enter billing information”, “Enter shipping information”, “Order review”, or something similar. A customer completes these steps only when he/she is ready to pay for what is added to a cart. However, the purchase (as a step) should not be entered here as well, because there is a separate ecommerce action called purchase that tracks it.

If we open the Enhanced Ecommerce reports of the official Google Analytics demo account, you will see that there are two funnel visualization reports:

Shopping behavior

Checkout behavior

Shopping Behavior includes all the Ecommerce funnel steps (starting from product views (if you track such data) and ending with a purchase). One of the columns in that funnel is Sessions with Check-out.

However, if you go to another report called Checkout Behavior, you will see that it consists of multiple steps (like Billing and Shipping, Payment (a.k.a. “enter payment information”), Review, and Sessions with Transactions). This funnel is a more detailed view at the Sessions with Check-out column of the previous screenshot.

These columns (except the last one) are the ones that are configured in the Ecommerce settings of the GA View.

But this applies only to the user, session or hit-scoped dimensions (not product-scoped). Imagine a situation: you’re tracking products that have a custom dimension called size (possible values: S, M, L, XL, XXL, etc.). Now you want to pass such dimension with every product to Google Analytics.

There are many cases where a single Enhanced Ecommerce hit might include multiple products (for example, a purchase). Each product in that payload might have different sizes. If you set the custom dimension size on the level of a Universal Analytics tag, how is GTM supposed to know which products should get what size? Well, GTM will simply not know that.

Therefore, product-scoped custom dimension (and the same applies to custom metrics) must be included in the ecommerce object that is pushed to the data layer and that dimension/metric must be placed right next to other product dimensions/metrics.

Based on the index (e.g. dimension2, metric1) GTM will know which custom definition is being used here.

Mistake #6. Not passing the Product ID or Product Name

If you take a look at the official Enhanced Ecommerce docs for GTM, you will see that only one of these two parameters are required when the product information is passed to GA.

However, I strongly advise on using both.

If you don’t include the Product name, you will see (not set) in the Product column of your GA reports.

If you don’t include the Product ID, then product list attribution will not work (of course, if you are tracking the performance of the product list in the first place). Simo Ahava has explained this part in his blog post (so if you’re interested, go ahead and check it out).

Mistake #7. Trying to send multiple actions with a single dataLayer.push

While Enhanced Ecommerce in Google Tag Manager allows you to send more than one data type in a single Enhanced Ecommerce hit, there are some limitations. But first of all, here’s an example of a totally acceptable dataLayer.push() that includes multiple Ecommerce data types (product impressions and promotion impressions).

For example, a single dataLayer.push (containing the ecommerce object) cannot contain both Product Click and Product Detail (when the detailed information about the product is viewed) at the same time.

A solution for this? Ask a developer to do two separate dataLayer.push (one for the Product Click and another one for Product Detail) and then send this information as two separate hits to Google Analytics. Like this:

If you already know what payment method was chosen (because maybe that is not the first purchase of a customer), you can also send the option key that contains some additional information about that checkout step, for example, payment method.

Alternatively, a developer can first push just the checkout object with the step number (to the Data Layer) and after that, a developer can activate an additional .push that contains the checkout_option (with the chosen payment method).

If you choose to implement both checkout and checkout_step, remember this: a Checkout option hit is always sent after the corresponding Checkout Step has already been sent. So you can’t send a Checkout option hit for step 2 if you haven’t first sent a regular Checkout hit for step 2. This is where some people get stuck.

Once again:

Checkout step one must be pushed first

Then Checkout option for step 1 can be pushed

(the same applies to the rest steps of the checkout funnel)

On the other hand, you’re not required to send Checkout option hit at all (because some checkout steps might have no options at all).

This mistake will not affect your Enhanced Ecommerce data, however, some other parts of GA reports will suffer. Bounce rate, in particular. It will make it real low (which is not a good thing (learn why)).

First, let’s get a quick refresher on what is a bounce in GA. In short, a bounce rate is the percentage of single-interaction sessions on your web page. In other words, a visitor landed on your site, did nothing (i.e. did not interact with the content), and then left. To sum up:

1 interaction (e.g. page view) = bounce.

2+ interactions = no bounce.

Now, let’s go back to Enhanced Ecommerce. It’s perfectly fine to send the EE data not via Pageview tag (but with a GA Event tag). In fact, this is the way I always implement. However, there is one issue. What happens if:

I first send the product impression EE data with an event tag (meaning that a product is displayed)

And then separately track a regular pageview (with a Page view tag and without anything related to EE)?

The result: two hits are sent to Google Analytics. Two hits = two interactions = no bounce.

What if a visitor just landed on a product list, did nothing, and left? In this case, we would have sent two hits (a pageview and an event that transports the product impression data), therefore, such a session would not be counted as a bounce (even though this is a clear bounce). Not good.

What’s the solution?

Pick Google Analytics events that are sending EE data and that are being fired together, before or right after the GA pageview tag. Set those events to “non-interaction hit: true”. Such events will not affect the bounce rate (because they are sent as non-interactions). You still be able to see their data in the GA reports.

For example, if Add to cart EE data is sent right after the cart page loads, you should set the event to non-interaction hit: true.

Mistake #10. Exceeding the limit of 8kb per request to GA

Universal analytics has a certain limitation that might become very annoying for those who have implemented the Enhanced Ecommerce and are sending a lot of data with every request to Google Analytics.

That limitation is 8kb. A single request sent to Google Analytics cannot exceed the limit of 8 kilobytes. If it does, the request will not be sent to GA.

How is it possible to reach that limit?

If you’re tracking things like the product detail, add to cart, checkout, purchase AND usually, visitors are not buying many products at the same time, you’re (most likely) safe. However, if you are actively tracking product list impressions, if people usually buy, say, 50 products (or maybe you’re sending a lot of parameters with each product, chances are that you are already reaching that limit.

What can you do about it? First of all, you should check whether you have this problem in the first place. This guide explains the idea of how you can log requests that exceeded the request size limit. It might get quite challenging but it’s definitely worth a try.

Another option could be to follow this guide. It will send the request size to GA as a custom dimension. Unfortunately, if the request is too large, then the dimension will be sent at all. However, you will be able to see those requests that were quite close to reaching the limit. So, if you’re already quite close, that’s a warning that you should do something about it.

What is that something? What can you do about the requests that are too large? You can:

Most common Enhanced Ecommerce mistakes (via GTM): Final words

I’ll repeat myself once again. Enhanced Ecommerce in Google Analytics is an amazing feature that gives you a lot of great insight into how visitors/customers are behaving on your website/online store and where are they getting stuck in the journey to the final conversion.

However, not everything is so easy. In order to gain such rich reports, you need to work your ass off while implementing it together with a developer. Just by looking at this list of Enhanced Ecommerce mistakes you can realize that there are many nuances where digital marketers and analysts struggle.

That’s why I, by seeing repetitive posts in Google Tag Manager communities, decided to put a lot of focus on Enhanced Ecommerce in my latest Intermediate Google Tag Manager course. It includes over 2 hours of video material on how to properly own the process of EE implementation (from planning to the final testing).

So if this is one of your major work-related pain points, I have a solution for that.

]]>https://www.analyticsmania.com/post/common-enhanced-ecommerce-mistakes/feed/1132 Google Tag Manager Debugging and Testing Tipshttps://www.analyticsmania.com/post/google-tag-manager-debugging-tips/
https://www.analyticsmania.com/post/google-tag-manager-debugging-tips/#commentsFri, 05 Jun 2020 23:52:05 +0000https://www.analyticsmania.com/?p=6681Updated: June 5th, 2020 Google Tag Manager debugging is an art of its own. Checking the Preview and Debug mode to see if the tag was fired is just the tip of the iceberg. In fact, there are many more things/techniques you need to follow in order to be sure that everything is working properly […]

Google Tag Manager debugging is an art of its own. Checking the Preview and Debug mode to see if the tag was fired is just the tip of the iceberg. In fact, there are many more things/techniques you need to follow in order to be sure that everything is working properly (or just to find the reason that is causing some nasty bugs).

In this guide, I’ve collected a list of Google Tag Manager debugging and testing tips (and some tools) to help you better understand what and where you should check. Some of them are overlapping, therefore, in the end, it’s up to you which ones to use. Let’s start, shall we?

Before we continue

This list is definitely far from being complete, therefore, I ask for your input. If you see some very useful debugging technique missing, please let me know in the comments or contact me via other channels(e.g. social media, email, or contact form). Also, there’s still a high chance that I still don’t know or just forgot to include something, so any input from my audience is appreciated.

Let’s move to Google Tag Manager Debugging Tips

I’ve written down a bunch of tips/suggestions/ideas and then split them into categories:

Part I: GTM debugging with the Preview and Debug mode

In this part, I’ll dive a bit deeper into the standard GTM Functionality.

#1. If the orange box does not appear, the GTM Preview console also won’t

If you hit the Preview button in the top right corner of your GTM interface and the orange box (see below) did not appear, that’s a good indicator that the 3rd party cookie (from www.googletagmanager.com) was not stored in your browser.

This means that the Preview and Debug console will not appear either. There might be several reasons for that. For example, your browser’s privacy settings block 3rd party cookies or you’re using a more aggressive privacy-related browser extension that also blocks GTM’s 3rd party cookies.

A solution for that? Change 3rd party cookie settings to accept them, whitelist www.googletagmanager.com cookies, whitelist www.googletagmanager.com in your browser privacy extension, etc. Since there are many browsers and extensions, I leave this task (to find out) for you.

#2. If you share a link to the Preview and Debug mode, always try to enter the destination link too

There are two main reasons why you want to share your Preview and Debug mode:

show someone how you implemented changes in the container (say, for the QA purposes)

get help from someone to debug a particular issue for you.

The latter point is the reason why I included this “tip” in this list at all. If you want to get GTM help faster from someone (for example, in the GTM community on Facebook), do your best to provide as much information as you can. This also includes the URL of the page where the issue should be debugged.

I’ve had too many times when a person sends me a link to the P&D mode without actually entering the destination URL where I should check. I’m not a psychic to read your mind

So even though this tip is not directly related to YOUR debugging, it will make the job easier for the person who wants to help you and debug.

#3. To exit the shared Preview and Debug mode, you need to revisit the shared URL and click EXIT or delete the 3rd party cookie

If you clicked someone’s shared link of the Preview and Debug mode and keep seeing the debug console at the bottom of your browser screen even after the debugging job/task is already done, you have two options:

Revisit the link of the shared P&D mode and click the Exit preview and debug mode.

Or delete the 3rd party cookie that belongs to www.googletagmanager.com

#4. Preview and debug mode may not always work and there are many causes for that

There are many reasons why the GTM Preview and Debug mode does not work on your (client’s) website. In fact, I’ve listed at least 15 reasons and solutions to them. The list contains (but is not limited to):

Wrong container

Heavy caching

Content Security Policy (CSP)

AdBlockers

etc.

#5. Preview mode can be minimized. It can also remain like that after a page reloaded.

If GTM is taking too much space on your screen, you can resize it by dragging its top border. If you want, feel free to minimize it by clicking a little icon in its top-right corner.

If you refresh a page, the debug console will appear in your screen again (regardless of its previous state). Fortunately, this can be fixed with a Chrome Extension Da Vinci Tools. This handy plugin implements various enhancements in GA, GTM, Data Studio. One of them is the “Remember minimized” feature that keeps the Preview and Debug console minimized even after the page was reloaded.

#6. Preview and Debug mode resets after the page refreshes

This happens because the P&D console displays what is happening in the dataLayer, which is wiped out after the page refreshes. So if you have some click or other interaction tracked in the debug console and want to see what kind of variables were available at that moment, you won’t be able to do that after the page refreshes… unless you apply one of the following techniques/tools:

Want to track a link? CTRL + Click (on Windows) or CMD + Click (on Mac) will help. These commands will open the link in a new tab while the data in the previous tab is still preserved.

After you do a click or submit a form, quickly hit the ESC button on your keyboard. Success is not guaranteed but still worth trying.

Even though the page refreshes, you can still preserve Data Layer’s information in your browser. This can be done by enabling “Preserve log” setting in the browser’s JavaScript console and then combining it with extensions like dataLayer Inspector+.
Here’s how you can preserve log in Google Chrome:
Once you do that, enable dataLayer Inspector+ by clicking its icon and then ticking the checkbox:
After that, you’ll start seeing some magic in your browser’s JS console.
Alternatively, you can use GTM Debugger or Data Layer Checker extensions that preserve data in the Data Layer without Preserve Log feature.

Enter a Custom Script in browser’s JavaScript Console and it will block the page from reloading (read the tip #2 here)

Automatically pausing the page upon the beforeunload event. By going to your browser’s developer tools, you can set the page to pause when it intends to reload. During the pause, you can inspect the Data Layer in the browser’s JavaScript console. This advanced technique is also explained in Simo Ahava’s guide (read the tip #3)

#7. The left side of the Preview and Debug mode displays changes in the Data Layer

Click any interaction to inspect what happened in the Data Layer in that exact moment: what data was (un)available. Every dataLayer.push is visible in this stream. If the push has an event key, then that very exact key name will be visible in the stream. If there is no event key, then the dataLayer.push will be displayed as a message.

#8. If you want to use a particular data (from the Data Layer) in a GTM tag, make sure that this data is available as a variable on that particular Data Layer event

Take a look at the screenshot below.

There are several interactions in the Data Layer:

userInfo (custom dataLayer.push)

Page view

DOM Ready

Window Loaded

formSubmission (another custom dataLayer.push)

With the userInfo event, there was some user-related data pushed to the Data Layer, including pricingPlan. Now, if you want to pass the value of pricingPlan with the formSubmission event to a 3rd party tool, like Google Analytics or Facebook Pixel, you need to make sure that the value of the pricing plan is actually available in the Data Layer.

You can easily check that by:

choosing the formSubmission event in the Preview and Debug mode (because you want to fire a tag upon this event)

and going to the Variables tab.

If the variable contains some actual value (not an undefined, NaN, etc.) on that Data Layer event, you can definitely use the variable in a tag to send its value to a 3rd party tool. Keep in mind that custom data in the Data Layer is not by default available in the Variables tab of the Preview console.

Now, if the userInfo dataLayer.push occurs after the formSubmission dataLayer.push, the pricingPlan value will not be available and will not be sent to GA or anywhere else. And that is one of the most common mistakes among GTM beginners: not checking if the variable is actually available at the moment when a tag is fired).

If a variable is not available in the Variables tab at all, then go to the Data Layer tab and see if the needed data is there. If yes, either enable a proper built-in GTM variable or create a Data Layer Variable.

To sum up: if you want to use a particular data from the Data Layer in your tag, make sure that it is available there. If a particular key is pushed to the Data Layer only after a click, then it will definitely not be available with the Page View event (because the Page View happens sooner than the click).

#9. Keep an eye on the Errors tab

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. This tab displays if a GTM Tag Template failed to fire due to an error. Here’s a quick guide about it.

#10. Check what values were sent to a 3rd party tool by clicking on a tag

Choose an event in the Preview and Debug mode’s event stream and click the tag that fired on that event.

If needed, expand the table to see what configuration was of that particular tag and what data was sent to a 3rd party tool (like Google Analytics).

#11. The Summary shows how many times each tag was fired

This is useful if you planned a particular tag to fire only once but, in fact, it was triggered several times by multiple triggers.

P.S. You can prevent a tag from firing multiple times in its Advanced Settings. Choose Once per page.

#12. View trigger conditions by clicking on a tag

If you want to find out why a particular tag did or did not fire, choose an event in the Preview and Debug console’s event stream and click the tag that has fired (or not).

Scroll down to see all the linked firing and blocking triggers. Take a closer look at the icons. If a trigger has a green check icon, that means that this trigger activated the tag. You can also see green and red icons next to every condition of tags. If the condition was met, the icon will be green.

This helps you identify possible reasons why one or another tag has fired (or not).

#13. Preview and Debug mode does not show everything related to firing conditions

There is a chance that such a situation has already happened to you once (or will happen in the future). A tag has fired even though conditions in your triggers were not met. Or the opposite, all conditions were met but the tag did not fire. Why do such things happen?

As for November 2018 (and many years before), not everything (related to tag firing conditions) is displayed in the Preview and Debug mode. I’m talking about Tag Sequencing and Tag Firing Options.

If you set a tag to fire before or after another tag (via Tag Sequencing), this will not be visible in the Preview console, under Firing Triggers section. You can only see it in the GTM UI by opening a particular tag and scrolling down to Triggering section.

Anyway, as a result, you might start thinking that your tags are firing even when they shouldn’t but that’s not true. It’s just that the Preview console does not display the Tag Sequencing (that’s a feature request right here).

Speaking of tags not firing even though they should, another setting that may prevent that is Tag Firing Options. You may have set a tag to fire only once per page load. This means that a tag (which has already fired) will not fire anymore even if all the conditions are met. That setting can be found under tag’s Advanced Options.

#14. Missing Pageview Event? The Data Layer is set incorrectly.

Every time a page loads, at least 3 Data Layer events are visible in the Preview and Debug mode:

Page view (gtm.js)

DOM Ready (gtm.dom)

Window Loaded (gtm.load)

And it always should be like that. At least 3. However, sometimes the Data Layer is implemented incorrectly on a website that causes the Page view (gtm.js) event to break. This happens because a developer places the following Data Layer snippet below the Google Tag Manager container:

<script>
dataLayer = [];
</script>

So whenever you are debugging Google Tag Manager implementation, keep an eye on whether all three Pageload-related events appear in the Preview and Debug mode.

A solution for this? At least ask a developer to place the Data Layer code above the GTM container. But even a better option is to use dataLayer.push instead of dataLayer=[]. Then the position of the snippet is not that important anymore.

Part II: Google Tag Manager debugging with built-in browser tools

Making use of the standard browser functionality for developers.

#15. Check the browser’s JavaScript console for errors

Since I’m mainly using Google Chrome to work with Google Tag Manager, here’s how you can enable JS console there. In the top right corner of the browser, click three dots, then navigate to More tools > Developer tools.

A pane will appear at the bottom of the screen (or in the sidebar, this depends on your preferences). Switch to console, click Clear Console and refresh the page. If you notice any red errors, consult with your developer whether they are critical. The variety of errors is huge so don’t think I can give you some tips on how to act is the most standard cases.

If you notice that an error that is originating from gtm.js, then take a deeper look at it (because that something cause by Google Tag Manager).

One of the most common is this one:

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

#16. View the Data Layer by entering “dataLayer” in the console

Even if you don’t have the access to website’s Google Tag Manager container and cannot enable the Preview and Debug mode, you can still check what is happening in the Data Layer. This is very useful if you’re asked to quickly debug a particular issue but, for some reason, cannot get access to the GTM container right away.

To do that, open your browser’s JavaScript console and enter the dataLayer. What you’ll see is the list of all the information which was pushed into the Data Layer.

Click the triangle to expand the Data Layer and then click any other triangle to expand that particular dataLayer.push to see what’s happening.

However, it’s really important to understand that this dataLayer is not the same as the data that gets captured by Google Tag Manager’s data model. I know, this sounds confusing, but if you want to go advanced, you’ll need to do that. Simo Ahava has posted a blog post about the GTM Data Model here. If you want to know access to the exact values that Google Tag Manager sees in the Data Layer, use methods described in tip #19.

#17. “Tag Fired” ≠ data was properly sent to a 3rd party tool

Even though a tag is displayed among “Fired” in the GTM Preview and Debug mode, this does not mean that the data was sent to another tool (e.g. Google Analytics or Facebook Pixel) as you expected.

It is pretty common among beginners to assume that if a tag has fired, the job is done here. Even if that happened, the request might end with an error (404, 502, etc.). Or maybe the request was indeed sent properly but the values of your variables were undefined.

So how can you make sure that the data reached its destination as you intended? There are several options:

Check real-time reports if they exist in your tool of choice.

For example, in GA real-time reports you can debug page views, events, conversions. When your tag is fired in the Preview and Debug mode, go check the real-time reports and see if the data is actually displayed here. Keep in mind that custom dimensions, custom metrics, e-commerce data are not available there.

As for the Facebook Pixel, you can also check their real-time data in Facebook Analytics. Go to analytics.facebook.com, open your Pixel’s reports and in the left sidebar choose Event Debugging. This is where you can check what data was recently picked up by Facebook.

Check the Network tab in your browser’s Developer Tools. In developer tools, go to the Network Tab to see the list of requests that your browser has made on that page. You can locate a specific type of request by using the filter feature. For example, if you’re debugging Facebook Pixel requests, enter facebook.com/tr/ to see the requests sent by Facebook Pixel. If status codes are 200, this means that everything is great. Sometimes internal redirects are possible so 307 status code is also fine, as long as you see other requests getting the 200 OK.Read Simo Ahava’s guide where he explains this topic more in-depth.

Use helpers (browser extensions) tailored to debugging of particular tools/platforms. I will not dig deeper into this topic a bit later (in one of the upcoming chapters in this blog post). But when I say “helpers”, I’m talking about Facebook Pixel Helper, Twitter Pixel helper, GA Debugger, etc.

#18. Check if there are more website elements matching the same CSS Selector

If you’re actively tracking clicks and other interactions by using element IDs, CSS Classes, or Matches CSS Selector operators in GTM, you’ll find this one useful. By employing HTML element attributes and/or operator in their GTM triggers, people are often assuming that those attributes/CSS Selectors are pretty unique and apply only to those elements that they wish to track.

Well, usually that’s not how things work.

The problem with this approach is that people cannot be 100% positive that those classes, IDs, etc. are unique enough to rely on. What if you want to track clicks of one element with a CSS class btn-bt? How can you be sure that you’re not setting a trigger that will cause many false positives?

In fact, there is a decent chance that there are more elements on that page/website with a similar CSS class. So if you’re checking your analytics reports and wondering why there was a click tracked on a certain page (even though the page does not contain THAT SPECIAL ELEMENT), this tip is for you.

Let’s continue with the aforementioned example, CSS class btn-bt. In order to know the number of elements that utilize this class, open the JavaScript console in your browser’s developer tools, and enter the following command:

document.querySelectorAll("your_css_selector")

Replace the your_css_selector with the actual CSS selector you wish to test against. In our case, the selector is “.red-block”.

document.querySelectorAll(".btn-bt")

Hit enter. What you’ll see is the list of all the elements on a page that use this class. In the example below, I got 2 elements. You can tell that from the number next to the NodeList and if you click the triangle next to it, you’ll see the list of all HTML elements that use that btn-bt CSS class).

To make use of this method you need to possess at least some basic knowledge of CSS selectors. Simo Ahava’s guide is very useful here.

How many elements do you see after you launch this command? Is that the result you expected? If not, then try narrowing down the CSS Selector to pick the item you are actually interested in.

As for debugging, the most useful here is google_tag_manager[‘GTM-XXXX’].dataLayer.get(‘key’) because you can quickly find out what should be the correct value of your Data Layer variable (without having the need to constantly update the actual variable in the GTM UI and refresh the preview mode).

I bet that this still looks confusing to some of my readers. No worries! A bit more visual explanation of this can be found in MeasureSchool’s video (starts @1:07) and @5:07 you’ll learn about one of the ways where you can apply this in practice.

Too many Google Tag Manager debugging tips at once? No worries. Just bookmark this guide and come back at your earliest convenience.

Part III: Google Tag Manager debugging with browser extensions

When you create a new Google Tag Manager container, a developer must add its code to the website’s source code to make it work. But what if he/she is currently busy and can do that only after a couple of days? With injector extensions, you can emulate your GTM container on any website and then continue working/configuring GTM without any disruptions.

What this extension does is it injects your Google Tag Manager container on all tabs of the browser (if you want to narrow down in which tabs should the container be injected, use the Include Domains feature and enter only those hostnames to which you actually want to inject the container.

So after you enable the Preview and Debug mode, you’ll start seeing the debugging panel at the bottom of the screen. Even though the container code is not actually added by a developer to the website’s source code, you can successfully debug and configure your tags, triggers, and variables.

Once the developer actually implements the container code, your GTM configuration will be already ready.

Another situation where I use it is when someone asks for help to debug a particular issue. I just inject my own GTM container and do configurations that are needed to replicate the issue and resolve it.

Keep in mind:

Using Tag Manager Injector, dataLayer Inspector+ or any other injecting extension will work only within the boundaries of your browser. Calm down, you are not hacking the actual website. You’re just playing in your sandbox.

If there is already some GTM container added directly in a website and you have injected your own container, you WILL NOT see the content of the original container. I’m talking about tags, triggers, variables, their configuration. On the other hand, you will be able to see what’s in the Data Layer. But that’s it.

#21. dataLayer inspector+

AnalyticsPros have created an amazing browser extension that can be used as a Swiss army knife in Google Tag Manager debugging and testing. Not only can it inject your GTM container but there are also other goodies at your disposal.

This tip is related to the aforementioned dataLayer Inspector+. I did not want it to blend with just a mention of the extension so I created it as a separate tip.

Here’s the situation. Someone asks for your help to debug an interaction with the GTM on a particular website, which already has its own Google Tag Manager container. For some reason, you cannot quickly get access to the original container so you decided to inject your own (for testing purposes).

Even though you cannot see in your Preview and Debug mode original container’s content, you’re still able the monitor what’s happening in the Data Layer and play around with the website itself.

The original container is actively using the Data Layer and keeps pushing some data that is messing around with your container. This just makes the debugging inconvenient as you’re seeing events that should not be seen in your container.

What’s the solution? You could temporarily block the original container’s script so that it would not interfere with your debugging efforts. Luckily, dataLayer Inspector+ offers a neat feature called Block & Swap Script.

Ability to copy the data from the Data Layer tab in the GTM Preview and Debug mode. Have you noticed that, by default, it’s impossible to copy anything from the Preview mode’s Data Layer tab? Well, not anymore. Da Vinci got you covered. After you install the plugin, the Copy option will be back!

Tidy GTM Preview (e.g. tag blocks are enriched with icons)

Remembers if the Preview and Debug pane is minimized (and keeps it that way after the page is refreshed)

Exit the Preview and Debug mode directly from the debug pane

Also, I’ve seen Stéphane mentioning somewhere that in the long run, he plans to add debugging features similar to the WASP extension, which (surprise!) was also developed by him.

#24. GA Debugger

This extension is useful if you want to dig deeper into what data was passed onto Google Analytics. Once installed and enabled, it enables GA’s debug mode that starts displaying the data in the browser’s JavaScript console (among other Developer Tools).

To enable it, simply click the extension’s icon and you’ll see the ON badge. This indicates that the GA Debug mode is enabled and you can start checking the data.

After the extension is enabled, open the browser’s JavaScript console and refresh the page. You’ll start seeing all the requests that were sent to GA.

Even though the info might look a bit too technical, this is definitely worth checking out as it (more or less) clearly displays all the parameters that were passed to Google Analytics. Every GA hit (e.g. pageview, event, etc) is visible as a separate table with all the parameters and their values.

By default, browser’s console is cleared every time the page reloads. So if you want to preserve what was captured, enable Preserve Log setting:

#25. GA debug mode setting in GTM

Even though this tip should have probably been mentioned in one of the other chapters of this post, I thought that it would be more appropriate to mention this right after presenting the GA Debugger extension.

Alternatively to GA Debugger, you can also see the GA payload data in the console just by enabling the following setting in the GA Settings Variable that is being used by your Google Analytics tag.

Once enabled, it will display the very same data as it was with the GA Debugger extension.

To make this data visible only when you have enabled GTM Preview and Debug mode, enable the built-in variable called Debug Mode. It returns true if you’re currently in the Preview and Debug mode.

That variable then should be inserted into the Debug Mode field of your Google Analytics Settings Variable or GA tags.

So while you’re in the GTM preview mode, the GA debug mode will be enabled too. And when you exit the preview mode, the Debug Mode variable will return false, therefore the GA data will stop being logged in browser’s console. Nice and clean.

First things first, Google Tag Assistant is a Chrome Extension that helps you validate the tracking code on your website and troubleshoot common problems and makes the entire process much easier and faster. It enables you to record a typical user flow, it keeps track of all the hits you send, checks them for any problems, and gives you a full report of interactions. In case of any issues or potential improvements, it will let you know about them.

By default, Tag Assistant is in the “sleep mode”, meaning that it does not check anything that’s happening on a page. In order to activate it, click the blue tag icon and then Enable.

Now refresh the page. If any of Google’s products are implemented on that page, you’ll start seeing a particular number within that blue tag icon which represents the count of tags found.

A great, yet often underused feature is session recordings. Recording a flow produces a report of all hits that were sent via marketing tags. This lets you validate that a particular tracking tag on your site works as expected.

For example, if you own an e-commerce site, you could run through the pages and steps required to select an item, place the order, and submit payment. After the recording is complete, you can review all events/pageviews/etc. that were passed through and see what particular data was sent, what errors occurred, where they happened, etc.

To start recording a flow, click the Tag Assistant icon and then RECORD button.

The actual recording will start after you refresh the page. During the entire session, a red dot will be attached to the blue tag icon. To stop recording, click the icon, the red STOP RECORDING button, and the summary of the session will be displayed. Click Show Full Report.

This report will give you more insights into what happened during that recording session. Two types of reports are at your service:

Tag Assistant Report.

And Google Analytics Report.

The Tag Assistant report shows all the tags that fired on all the pages you visited during the recording session. The controls in the left-hand panel let you do the following:

Filter tags

Switch between detailed and basic views

Show/hide ignored requests.

The main body of the page contains Recording summary (of what happened during the session) and recorded pages. Click every page to expand its details and tags that were fired. Keep in mind that these tags are listed alphabetically (and not in their sequence).

The 2nd report (Google Analytics Report) will show an emulation of how Google Analytics will process the hits. The tab will recognize the account ID for this site and will allow you to see the full report (if you have access to that account).

In it, you’ll see multiple data points collected by Google Analytics including acquisition data, behavior data, and conversions data. If you notice some issue in the report that needs to be fixed in the GA account (say, you had to configure a Cross-domain tracking’s Referral Exclusion List in your Google Analytics account), feel free to do that.

After you’re done, just go back to the Google Tag Manager’s report and hit the Update report button in the top left corner. The plugin will check the entire recording session against your new GA Property settings and will let you know if the issue was fixed. That’s a real time saver!

#27. Non-standard Google Analytics implementation is not a problem

So you implement Google Analytics tags via Google Tag Manager, open the Tag Assistant and see that GA tag’s color is blue, not green. Click it and you’ll get a message “Non-standard implementation” under the “Where to optimize?” section.

#28. Google Tag Manager debugger

Yet another amazing GTM-related Chrome extension, this time developed by David Vallejo. It adds an additional tab to your Chrome browser’s Developer Tools that ease your Google Tag Manager debugging process.

First of all, the extension clearly displays (in a pretty readable manner) the data that was pushed to the Data Layer and the current data that is stored there. If you want to copy the Data Layer (e.g. to send the snippet to a developer (to report a bug)), you can do with a couple of clicks.

If Enhanced E-commerce data were sent to Google Analytics, an additional tab will activate within the interface of the plugin. It displays all the E-commerce steps completed in the exact order they occurred. Each step can be expanded and checked in greater detail. If the number of products is too overwhelming, feel free to use the search field.

And if the website (that you’re working on) tracks A LOT of interactions, it might be a good idea to filter them out and track only particular types of GA hits.

At this moment, David is actively updating/improving the extension thus I’m sure that you’ll find some new features there pretty soon. I still catch myself discovering something new (and pleasant/convenient) there.

#29. Use helpers/debugging plugins tailored to specific tools

I’m talking here about Facebook Pixel Helper, Twitter Helper, and other similar plugins tailored to specific tools. These browser extensions let you easily debug what kind of data was passed to 3rd party tools and whether that data was formatted properly.

For example, once you install the Facebook Pixel helper and load a page where the pixel is present, you’ll notice that extension’s icon has become active.

Click it to see the detailed view of what was captured and what was transferred to Facebook’s servers.

If tracking issues occur, the extension will display that in a readable manner. Once you fix the problem, refresh the preview and debug mode. then the page and revisit the plugin’s report once again to check if that helped.

Part IV: Other GTM/GA debugging tips

Everything else that I could not find a place to.

#30. Don’t see the data in GA Real-time reports? There are several possible reasons

#31. Not every GA interaction is visible in the real-time reports

Real-time reports show you the most common interactions, page views, and events. Unfortunately, if you wish to see e-commerce data, social interactions, timing hits in GA, you’ll need to wait for them to appear in our actual reports.

So if you wish to debug them beforehand, you’ll need to use browser extensions or GA debug mode to see what data was passed to GA and whether it was formatted properly. But in order to check if the data has actually reached the destination, you have no other choice rather than wait.

#32. It is possible to test GTM implementation (web) on a mobile device

If you want to check what’s happening in the Preview and Debug mode while being on a mobile device, just enable the P&D mode on your desktop/laptop, click Share Preview, and copy the generated link (don’t forget to enter the Destination URL for easier access).

Send that shared preview’s link to a chat/email/whatever so that you could open it via a mobile device.

That’s it! Now you’ll see the Preview and Debug mode.

Of course, it won’t be the most pleasant experience but it still possible to work. Pro tip: consider enabling Desktop view in your mobile browser to see more of the debug console.

In order to exit the debug mode, revisit the shared preview link and click Exit.

Update: Jean (in the comments of this blog post) also suggested an alternative solution: It is possible to test GTM implementation (web) on a mobile device You can simply activate the Toggle Device Mode in Chrome Dev console or Ctrl + Shift + M (while the Console is open). I use it to check that my tags fire only on a mobile.

Google Tag Manager Debugging: Final words

Whew! That was a long one! As you can see there a lot of things to know and/or try when it comes to Google Tag Manager debugging. Although some of these tips are related purely to Google Analytics, GA is the most common 3rd party tool that’s being configured within GTM. So I guess it’s fair enough.

Anyway, the key takeaway here (especially for beginners) should be that that GTM debugging consists not only of checking if a tag has fired. That’s just a beginning. You also need to make sure that:

The data/request was sent successfully (e.g. via Network tab or some browser extension)

And it is properly displayed in the 3rd party tool (e.g. Facebook Pixel, Google Analytics, etc.)

And also there are a lot of different testing/debugging tools you can choose from. So pick the ones you find the most suitable/convenient go hunt those bugs!

The list of these tips is definitely far from complete. So whenever I remember something else (that is useful) or if you have some GTM debugging tricks up your sleeve, feel free to share it in the comments and I’ll probably add it to the guide.

If you have done anything with Google Tag Manager, you probably already know three key concepts: tags, triggers, and variables. But, actually, you should know there is one more key ingredient, the Data Layer. Google Tag Manager walks hand in hand with the Data Layer which ensures maximum flexibility, portability, and ease of implementation. Without it, there would be no variables and no triggers in GTM, therefore no tags would be fired. It is what keeps your tag management running properly.

Unfortunately, I’m not going to dive into what the Data Layer is because that’s a totally another story. In today’s blog post, I’ll take a look at what the Data Layer Variable is.

If you have no clue what Data Layer is, read this guide first and then come back to this article.

The context

Before we dive in, let’s quickly remember how the Data Layer (DL) works. DL is a virtual layer of a website where useful information is stored, e.g. userID, Text of a Clicked Button, Order Total, etc. This data can be later transferred to other tools like Google Analytics, Mixpanel, Google Ads, etc.

In fact, Google Tag Manager already supports a bunch of default built-in variables. You can find a full list of them by going to Variables > Configure.

After you enable these variables, they’ll appear in GTM Preview and Debug mode’s Variables Tab.

These data points can later be used in trigger conditions, tags, even other variables (e.g. Lookup or Regex Tables). And that’s awesome! But what if we want to have some custom variables? For example, blog post author’s name, user’s registration country, etc.?

That’s where the Data Layer Variables come in handy.

What is a Data Layer Variable?

Data Layer Variable enables you to fetch a value from the Data Layer and turn it into a variable (which can be used in Tags, Trigger, and other variables). But first, let’s take a look at how the data is stored in the Data Layer.

Looks like I have some interesting data there: pagePostType, pagePostType2, pageCategory, pagePostAuthor. My blog is running on WordPress and I’m using DuracellTomi’s GTM Plugin which pushes this data to the Data Layer every time page loads.

Anyway, let’s go back to the example. As you can see in the screenshot above, there’s some interesting data I could employ in my tags and triggers. Unfortunately, if I navigate to the Variables tab of the Preview and Debug Console, those variables aren’t there. Why?

By default, Google Tag Manager does not recognize custom data in the Data Layer thus you cannot use it as variables unless you use the Data Layer Variable. In order to create this variable, you’ll need to specify the Data Layer key whose 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 pageCategory value, I’d just need to set the pageCategory key in variable’s settings. Let me show you how it works in action.

Let’s create a Data Layer Variable

In my previous example, there were 4 custom keys and values in the Data Layer:

Key: pagePostType, value: post

Key: pagePostType2, value: single-post

Key: pageCategory, value: google-tag-manager-tips

Key: pagePostAuthor, value: Julius Fedorovicius

With help of Data Layer Variable, I can easily retrieve those values and re-use them in other tags, triggers, or variables.

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

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

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

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 the P&D console.

Data Layer version

Another setting available in the Data Layer Variable is Version. When you select the Version, you’re instructing GTM to treat the values in the data model in two different ways.

Version 1

It’s pretty limited and does not allow you to access nested values. If you create a DL variable and tried to access pagePostAuthor (in the example below), you’d fail because it’s not in the root of the object (instead, it’s a direct child of attributes key).

See? There’s no attributes key and pagePostAuthor is at the root level.

That’s not the only limitation of Version 1. There’s also no merging available. Every time you push the data to the Data Layer, it will overwrite the entire key (that you’re pushing data to). Let me illustrate. Imagine that we have two Data Layer Pushes with different data. The first push contains a post object with only one parameter, pagePostAuthor, the other one includes the other two keys, pageCategory and pagePostType.

As a final result, you’d have only two values in the Data Layer: pageCategory and pagePostType because the 2nd push has completely overwritten the data of the 1st push.

So what’s the point of the 1st Version? It sounds like a useless thing, you might say. Definitely not. For example, in Enhanced E-commerce, it’s really important not to have any artifacts (scraps) from previous pushes, meaning that every time a window.dataLayer.push occurs, it rewrites keys.

VERSION 2

The 2nd version is much more flexible. It allows you to access nested values, arrays, merge data.

Let’s go back to the previous example with two subsequent Data Layer Pushes. The first push contains only pagePostAuthor, the other one includes two more keys, pageCategory and pagePostType.

This happened because pagePostAuthor from the 2nd push overwrote the pagePostAuthor from the 1st one. Simo Ahava has posted a detailed guide about Data Layer Versions. If you still have some questions, go check it out.

Default value

The last setting in the Data Layer Variable is Default Value. If you’re trying to access the value of a particular key in the Data Layer AND that key does not exist, “undefined” will be returned. Sometimes you might need to get a different default value, e.g. (not set), empty, or anything else. In that case, click the checkbox and set the default value.

Different data structures

Keep in mind that data can be stored in the data layer using different structures. Here’s an example (the key pagePostAuthor is in the root level)

Data Layer Variable: final words

Data Layer variable is one of the most (if not THE MOST) used the type of variables in my Google Tag Manager accounts.

With its help, you can access data stored in the Data Layer and utilize it in your tags, triggers, or even other variables. In this blog post, I’ve explained how to set up a variable, how to access data (which is stored using different data structures), what’s the difference between Version 1 and Version 2, etc.

If you have any questions, feel free to leave a comment below or drop me a tweet/LinkedIn message.

]]>https://www.analyticsmania.com/post/data-layer-variable/feed/15A Guide To Google Tag Manager Debug Modehttps://www.analyticsmania.com/post/google-tag-manager-debug-mode/
https://www.analyticsmania.com/post/google-tag-manager-debug-mode/#commentsFri, 05 Jun 2020 06:14:18 +0000https://www.analyticsmania.com/?p=1744Updated: June 5th, 2020. 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 […]

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.

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

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

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.

Tags. Displays which tags fired on the selected event and which ones didn’t.

Variables. Displays detailed information about variables in the selected event, including the type of variable, the type of data returned, and the resolved value.

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.

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 – Container Loaded (previously known as Pageview), 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 the Container Loaded 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 Container Loaded event does not appear in GTM P&D mode.

Why are there always three events?

What do they mean?

Container Loaded (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. Previously, this event was called Pageview.

DOM Readyevent (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.

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.

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 that 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.

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 Preview Mode

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. If you struggle with exiting the Preview and Debug mode, read this guide.

Google Tag Manager Preview mode new working?

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 the down-arrow icon located in its top-right corner.

If you see the “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 pushed some data into Data Layer but that dataLayer.push did not contain an “event” key. Use GTM debug mode to explore what exact data was pushed at that moment, maybe you’ll find something useful!

Although Google Tag Manager debug mode is a very important part of tag deployment, it’s not the only tool you should be using. Here is a list of Google Tag Manager Chrome extensions which will make your work much easier.

If you’re debugging Google Analytics events, ALWAYS check them in GA Real-time reports. It’s the best way to verify and react to errors without any delay.

Conclusion

Google Tag Manager debug mode is an essential part of tag deployment which helps us ensure that every possible user experience scenario is tested and data consistency is validated.

It brings us the full transparency of what’s happening under the hood, what data is being fetched or pushed, why a certain tag isn’t firing, etc.

And the best part, it is fairly simple to use even for non-developers, which makes it even more attractive for regular marketers. But it is really important to understand that this is not the only place where you should check/test your tag management implementation. There are many more things you need to keep in mind.

]]>https://www.analyticsmania.com/post/google-tag-manager-debug-mode/feed/15Google Analytics Cross Domain Tracking with Google Tag Manager. The Guide.https://www.analyticsmania.com/post/google-analytics-cross-domain-tracking-with-google-tag-manager/
https://www.analyticsmania.com/post/google-analytics-cross-domain-tracking-with-google-tag-manager/#commentsFri, 05 Jun 2020 02:23:07 +0000https://www.analyticsmania.com/?p=8339Updated: June 5th, 2020. 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 […]

]]>Updated: June 5th, 2020. 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 Google Tag Manager. And a longer 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 Google Tag Manager (and GA), that course is exactly what you need.

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 Google Tag Manager), 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 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. What is cross-domain tracking?

It is a workaround that allows webmasters/marketers/analysts to send user’s/visitor’s identifier (a.k.a. client ID) from domain A to domain B and preserve the session information. That way, the visitor is being tracked as the same person across multiple websites/domains.

In order to make this work, you will need to have access to both websites/domains and make some configurations. This entire guide explains different approaches you need to keep in mind (because every situation needs a different treatment).

I will mention this multiple times throughout this article but cross-domain tracking is needed only if domains are totally different. If you are tracking the visitor across the subdomain of the same domain, you don’t need cross-domain tracking. I will explain what to do about this in a moment.

#1.4. 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 the 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.5. 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.

#1.6. How does Google Analytics cross domain tracking work?

Here is it 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.7. 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.8. 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).

#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.

All websites must use the same Google Analytics property.

The URL of the destination page must be decorated with the linker parameter (_ga=)

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 Google Tag Manager 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.

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 the 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.

If the visitor navigates between domains by clicking links, then we’ll need to configure auto-link domains feature.

If the visitor navigates by submitting a form, then Decorate formtag might be an option.

If the visitor lands on the domainB.com, which is embedded within the domainA.com, then we’ll need to decorate the iFrame’s URL.

#2.5.2. URL decoration option #1: Auto Link domains

Once again, this option will work ONLY if the visitor navigates between domains by clicking links. So if I am on the domainA.com and click the link that redirects me to the domainB.com, auto-link domains feature is the best option.

How does it work?

If you go to domainA’s Google Tag Manager container (if both websites are using different containers) (but both websites can also use the same container (read more)), then open the GA Settings Variable > More Settings > Cross domain tracking, locate the “Auto Link Domains” field.

In that field, you should enter the destination domain’s URL.

If it’s only possible for the visitor to navigate one-way (e.g. from domainA.com to domainB.com), then domainB.com should be entered in that field). If it is possible for a visitor to move both ways, back and forth), then enter both domains in that field. Separate domains with a comma, e.g. domainA.com, domainB.com.

Once you enter the domains, save the GA Settings Variable, refresh the preview and debug mode and refresh the page that you’re currently working on. That page should be on the outbound domain and include at least one link to the destination page.

Now, it’s time to test whether the link to the destination page is actually decorated. Do the right-click on the URL (to domainB.com) and select Inspect Element. You’ll see the Elements explorer with the highlighted link you’ve just selected.

Take a look at the link’s href attribute. Is it just a regular link to the domainB or does it also contain a _ga parameter with some random numbers at the end? Like in the screenshot below:

If the parameter is indeed there, that’s a good sign! Now, let’s test whether that parameter actually remains in the URL after you click it.

Close the Elements explorer (of your browser’s developer tools) and click the link that will redirect to the domainB.com. Once you land on the destination page, do you see the _ga parameter in the URL? (some browsers hide parameters, therefore, you might need to click on the address bar of your browser and check. If the _ga parameter is still present, that’s good. The URL decoration part of your work is complete and you can proceed to chapter #2.6 of this blog post.

If you don’t see the _ga parameter in the URL, skip to chapter #3.1.2. where you should find further instructions.

#2.5.3. URL decoration option #2: “Decorate Forms” GA tag

If the visitor navigates from website A to website B by submitting a form (which then redirects to the website B), then this next option might be a solution for you.

Important: This solution will work only if you can properly track that form with the built-in Google Tag Manager Form Submission trigger. If your form is coded in a bit different way and the default trigger is not working, then this method is not for you. You will need to skip to the URL decoration option #4, a.k.a. cooperation with a developer.

How can you find out whether your form can be decorated with the “Decorate Forms” tag?

Now, the trigger. This tag must fire on a Form Submission trigger that activates after the successful submission. If you are already tracking the submissions of that form, just use the same form trigger for this “Decorate Form” trigger. If you don’t have any triggers for that form yet, read this chapter of my form tracking guide to properly configure it.

Now, test. Try to submit the form and check whether the destination URL is decorated with the _ga parameter. If it isn’t, move over to chapter #3.1.2.. Chances are that the parameter is lost due to multiple redirects. If redirects are not the case, then most likely, you will need to move to the URL decoration option No. 4.

#2.5.4. URL decoration option #3: Cross domain iFrame tracking

Update: since more and more browsers are starting to block 3rd party cookies, cross-domain iframe tracking becomes more and more unreliable.

You see, when a cookie (from your GA) is set from within the iframe, that cookie is treated as a 3rd party cookie (to be more precise – that cookie is being set in a 3rd party context).

What are the consequences? Your GA tracking will not work because the _ga cookie will not be created in the first place.

What’s a solution for that? A cookieless iFrame tracking.

In a nutshell, you can configure GTM (within the iframe) to send the interaction data to the parent page.

#2.5.5. URL decoration option #4: Developer’s help

Most likely, you’re reading this chapter because the previous 3 URL decoration methods failed. Even if you’re working with the form (that redirects to another page), it might not have worked. And that is more than realistic.

In this case, your last hope is to contact a developer who has access to the domainA.com website and can make sure (somehow) that the URL of the destination page (on domainB.com) is decorated with the _ga parameter.

How can a developer get that _ga linker parameter and decorate the URL of the form’s “Thank you” page? Hand him/her this code:

function decorateUrl(urlString) {
var ga = window[window['GoogleAnalyticsObject']];
var tracker;
if (ga && typeof ga.getAll === 'function') {
tracker = ga.getAll()[0]; // Uses the first tracker created on the page, but you could make it more robust by looking for the correct tracking ID or something
urlString = (new window.gaplugins.Linker(tracker)).decorate(urlString);
}
return urlString;
}

This function is taken from Simo Ahava’s upgraded cross domain iframe tracking solution. When a URL of the “thank you” page is passed to the function (variable’s name is urlString), it will return a readymade decorated URL (if Google Analytics has already loaded on a page) or will just return a regular “Thank you” page URL that was passed to the function.

Here’s a rough process of how things should be implemented.

The developer adds the aforementioned function (called decorateUrl) to the form’s code. When the form fields are validated and the form is successfullysubmitted (right before the redirect) a developer should call the decorateUrl function and pass the URL of the “Thank you” page (or basically, some page where the user will be redirected after the submission), for example:

This means that at first, the developer sets the initial value of the thankYouUrl (which is just a regular URL) and then a developer calls the decorateUrl function and inserts the https://www.example.com/success. The result is one of two:

https://www.example.com/success?_ga=2.174383108.3496197…… (with some different numbers)

Or just https://www.example.com/success (if GA hasn’t loaded on a page). This means that your form’s redirect will not break if GA fails somewhere along the way.

Important: It’s crucial that the developer activates this code right before the redirect (after a successful form submission). That’s because the part of that _ga=…. parameter is valid only for two minutes, therefore, activating the decorateUrl function on all pageviews will have a high chance of the linker parameter’s expiration.

So what exactly should you ask from a developer? If you’re trying to implement the cross domain tracking after your custom form was successfully submitted (and the user was redirected), here’s a sample text you could use in your email (while asking for developer’s input). Replace all gray parts with information applicable to your project.

Hey [developer’s name],

I’m trying to implement the Google Analytics Cross domain tracking on [domainA] when the visitor submits the form [or you can enter some other action] and is redirected to [domainB]. To make this work, the URL of the form’s Thank You page must be decorated with a special parameter. I need you to use the following function and run it right before the redirect [it is better to paste this code to pastebin or gist.github.com or just attach as a txt file. Keep the code as plain text.]:

function decorateUrl(urlString) { var ga = window[window[‘GoogleAnalyticsObject’]]; var tracker; if (ga && typeof ga.getAll === ‘function’) { tracker = ga.getAll()[0]; // Uses the first tracker created on the page, but you could make it more robust by looking for the correct tracking ID or something urlString = (new window.gaplugins.Linker(tracker)).decorate(urlString); } return urlString;}

Pass the URL of the “Thank you” page to this function (as a “urlString” variable) and it will return the decorated URL, to which you have to redirect after a SUCCESSFUL form submission (when all form validations were passed).

Expected result: when the visitor submits the form, right before the redirect to the [domainB.com], run the “decorateUrl” function and insert the Thank You page’s URL (that belongs to the [domainB]). The function will return the decorated URL. Use it as a destination to which a visitor/user should be redirected. Important: activate the “decorateUrl” function before the redirect because that parameter expires in 2 minutes.

Thanks![Your name]

When the developer tells you the job is done, you need to submit the form on domainA.com and then, after you land on the domainB.com, check the URL of the Thank you page. If the _ga=…. is present, then everything is fine. If not, then contact the developer once again and try to find the reason for this issue.

#2.6. Step/requirement No.3: allowLinker field must be enabled on domainB.com

Once you manage to decorate the URL of the domainB.com (and _ga parameter is visible in the URL), then you need to instruct Google Analytics (on domainB) to read that parameter and update the _ga cookie on the domainB accordingly.

By default, Google Analytics does not care about the _ga query parameter in the URL, therefore, if you just decorate the URL, cross domain tracking will still not work. You need to explicitly instruct GA to fetch the _ga parameter in the URL and update the cookie accordingly.

If you’re using Google Tag Manager on the domainB.com, then this is how you should enable the allowLinker field. In GTM, go to Variables and open the GA Settings Variable. Then go to More Settings > Fields to Set and enter:

allowLinker (case-sensitive)

true

Hit save.

It is not necessary for the domainB.com to have Google Tag Manager implemented. It’s just important to configure the GA on domainB.com to read the _ga URL parameter and update the cookie accordingly.

If, for example, domainB.com uses the hardcoded gtag.js, then you will need to contact a developer and ask to include the following command: ‘linker’: {‘accept_incoming’: true}});

#2.7. Step/requirement No.4: Update the Referral Exclusion list in GA

Even if all the previous 3 steps are implemented flawlessly, the step No.4 is as important as they are. Google Analytics acquisition reports work based on several things (e.g. UTM parameters or Referral). The referral is the address (or just the domain) of the previous page.

If the value of a referral is empty, such traffic is treated as (direct). But if the referrer indeed returns some value and its domain is different than the one I’m currently on, GA will start a new session. This means that you, as a visitor, have landed on this website from a different website.

And that is a problem in cross domain tracking. When I navigate from domainA.com to domainB.com, the referrer is domainA.com. And I’m currently on the page of which domain is domainB.com. Since the referrer and the current page domain are different, GA starts a new session.

Without any additional configurations, the GA will always attribute conversions (that happen on domainB.com) to domainA.com (if the visitor landed from that domain). That way, you will lose valuable traffic source data and it will be polluted with self-referrals.

A solution? Update the referral exclusion list in GA to ignore self-referrals.

Add the domain of the outbound website. If you have multiple websites “participating” in the cross domain tracking, add all the domains to that list.

Important if cross domain tracking was not set up on day 1 of your tracking implementation: due to how Google Analytics attribution works (last non-direct click), you will still continue seeing self-referrals in GA reports even after updating the Referral Exclusion List. However, the numbers of self-referrals will be falling down and will 100% disappear after 6 months.

On the other hand, if you have implemented cross domain tracking on day 1 (when you started tracking that website), self-referrals will not be a 6-month-problem.

PART 3: How to test cross domain tracking

Once you have configured the Google Analytics cross domain tracking with Google Tag Manager, it’s time to test this. Here are several things to check.

#3.1. The destination URL must contain the _ga parameter

When the visitor makes an interaction on the domainA.com and is redirected to the domainB.com, the URL of the destination page MUST contain the _ga parameter with some value, e.g. domainB.com/_ga=2.127758917.935544379.1560750528-1792149684.1557994615

If that did not happen, there are several possible reasons (continue reading).

#3.1.1. Poorly implemented link decoration on the domainA.com

If you’re working with links or iFrames, inspect them on domain A and see whether their links contain the _ga parameter. If they actually do contain the parameter, but the destination URL doesn’t, read the following possible reason.

#3.1.2. Redirect between the domainA and B is losing the parameter

One of the possible ways to check redirects is to use the Chrome Extension Redirect Path. It displays all the redirects that happen between pages. Sometimes it’s possible even see 6, 7 or more redirects between two websites. This is a very common reason why _ga parameter is lost.

In order to validate this hypothesis, go back to the domainA.com. Complete the action that redirects to the domainB.com. Once you land on the destination page, click on the Redirect Path icon to see what kind of redirects happened.

With it, you will be able to see whether the initial redirect actually included the _ga parameter and then whether on each step of the redirect the parameter persisted.

If the _ga parameter is missing from the very beginning of the redirect, this means that the problem still lies within the URL decoration and it properly does not work.

However, if the parameter is indeed visible in the first step of the redirect and is then lost, you need to reach out to a developer and tell him/her to preserve the _ga query parameter throughout the entire redirect.

Only a developer can do that. There is NO way around it with Google Tag Manager.

#3.2. The _ga cookies on both domains must contain the same value

When you are 100% sure that the URL decoration works properly, the next step is to check whether the _ga cookies on both domains have the same value. Once they are indeed the same, GA will start treating a visitor as the same person on both websites (as long as those cookies match).

How can you check whether the _ga cookies on both websites match?

In Chrome, go to Developer tools (while being on the domainA.com) and go to Application > Cookies. If you’re using a different browser, you’ll need to find a way how to do that. Expand the Cookies section and choose the domainA. Keep looking for a _ga cookie that is stored on behalf of domainA.com. Memorize last 4 digits.

Now go to domainB.com and repeat the same process. Find the _ga cookie there. Is its value the same as on the domainA?. If yes, then everything is working properly.

If not, this means that you haven’t enabled allowLinker in the Google Tag Manager container, GA Settings Variable. This must be done at least for the domainB.com.

#1. GA Real-time traffic source reports. If you navigate from domainA.com to domainB.com, your traffic source must be displayed as (direct)

#2. GA > Acquisition > All Traffic > Referrals reports. See if you notice domainA.com as a referral. If you implemented Google Analytics cross domain tracking after a while (and self-referral were swarming in your GA reports), you will still continue seeing them. However, the number of those sessions will gradually decrease (over a period of 6 months). More information

#3.4. You can also use Tag Assitant recordings for debugging

Watch this video to learn more.

PART 4: Other things to know

I have several more things to say but did not find a proper place in this guide, hence, part 4 was born.

#4.1. Even the perfect cross domain setup does not guarantee that it will work in 100% cases

As I have already mentioned multiple times in this guide, in order to pass the linker parameter from domainA to domainB, there must be some sort of interaction, like a click, form submission, or page load within the page (iFrame). So if you have perfectly configured your Google Analytics cross domain tracking and visitors complete that interaction every time they jump between websites, then you’re good.

However, if a visitor can freely land on the domainB and then directly land on the domainA (without clicking links, submitting forms or completing another action that will help decorate the URL), the cookies will remain different on both domains, hence GA will continue treating the person as two unique people.

The only way to make cookies the same is for the visitor to navigate from domainA to domainB and the destination URL must be decorated with the linker parameter (and allowLinker must be enabled on domainB as well).

#4.2. If you cannot enable allowLinker on domain B, there is a partial solution

This is definitely not a robust solution but if you have no other choice, it can still be implemented. I have a solution, which lets you transfer UTM parameters from domainA to domainB. Unfortunately, the transition between domains will start a new session in GA but, as a plan B, this technique can be definitely considered.

Google Analytics cross domain tracking is definitely not an easy topic and is full of tricky parts. However, it is necessary if you want to track visitors’ journey between separate domains. GA (and other cookie-based web tracking tools) heavily rely on cookies. They are used to identify a person as he/she navigates from page to page, returns to your website, etc.

However, cookies cannot be shared between separate domains (like domainA.com and domainB.com), hence when a visitor jumps between websites, Google Analytics sees that person as actually two people. Additionally, such jumps start new sessions in GA, which distort your acquisition reports.

Luckily, Google Analytics offers a workaround, which is called cross domain tracking. When a visitor navigates from one domain to another, you can pass the value of the _ga cookie (of domainA) and GA on the domainB will accept its value and update the _ga cookie (of website B) accordingly. When the _ga cookies on both domains are the same, GA will start treating that visitor as the same person across both domains.

Here are the necessary steps/requirements that need to be taken to make this work:

Both websites must be tracked under the same Google Analytics property (if a visitor can navigate between 3 or more websites, all of them bust me tracked with the same GA property as well)

The page address of the destination page (domainB.com) must be decorated with the _ga linker parameter. There are several techniques on how that can be done. The choice depends on how a visitor is jumping between websites:

A link on domainA.com is clicked. That link redirects to the domainB.com

A form is submitted on domainA.com. The form redirects to a “Thank you page” on domainB.com

An iFrame on domainA.com is loaded. The URL of that iFrame is domainB.com

Some other interaction is made that cannot be properly tracked/covered by the aforementioned 3 options

allowLinker field on the domainB.com must be set to true. If the domainB.com is not using Google Tag Manager (but maybe hardcoded gtag.js, instead), then some other identical parameter must be enabled. E.g. in case of gtag.js, that parameter is called “accept_incoming”.

The referral exclusion list (in GA Property settings) must be updated. You should include all the outbound domains that play a role in the cross domain tracking flow. In other words, enter all the domainA.com from which a visitor lands on the destination domain (domainB.com).

ALL of these requirements must be met in order for the cross domain tracking to properly work.

Got some questions regarding Google Analytics cross domain tracking with Google Tag Manager? Did I miss something? I’m more than open to hearing your thoughts, questions, ideas. The comments section below is at your service.

]]>https://www.analyticsmania.com/post/google-analytics-cross-domain-tracking-with-google-tag-manager/feed/27Track PDF Downloads with Google Tag Manager + Templatehttps://www.analyticsmania.com/post/track-pdf-downloads-with-google-tag-manager-ga/
https://www.analyticsmania.com/post/track-pdf-downloads-with-google-tag-manager-ga/#respondThu, 04 Jun 2020 12:56:23 +0000https://www.analyticsmania.com/?p=12026Updated: June 4th, 2020 If you’re running a website where people can click and open/download files (like PDF or Excel Spreadsheets), you would probably want to know which links are clicked the most and whether your visitors/users care about those resources at all. Maybe that document that you spent countless hours on last year was […]

If you’re running a website where people can click and open/download files (like PDF or Excel Spreadsheets), you would probably want to know which links are clicked the most and whether your visitors/users care about those resources at all.

Maybe that document that you spent countless hours on last year was clicked just 10 times in total? By measuring file downloads you will be able to understand which content is more engaging and where you should focus your effort more.

In today’s blog post, I’ll show you how to track PDF downloads with Google Tag Manager and send that info as events to Google Analytics. In fact, in the second half of the blog post, we’ll focus on other file types too.

I’ll start the blog post with a basic (most standard setup) and then we’ll move on to some edge cases (that require more advanced solutions). Also, we’ll take a look at how that data is displayed in Google Analytics reports. Finally, if some downloads are super important to your business, you can create a Google Analytics goal for that.

New to Google Tag Manager?

If you’re new to Google Tag Manager, I highly recommend checking out my free e-book “Google Tag Manager for Beginners”. But in a nutshell, there are 3 main things you should know as a total beginner (there are actually more things to know when you advance):

Tags

Triggers

Variables

And for this setup, this is exactly what we will do – create the aforementioned items in the container so that they would track PDF downloads and send that data to Google Analytics.

How to Track PDF Downloads with GTM

Here are the steps that you will need to do in order to track PDF downloads with Google Tag Manager and Google Analytics:

Create a link click trigger (for .pdf files)

Enable Click-related variables

Create a Google Analytics event tag

Insert Click URL variable in that tag

Set this tag to fire only when the pdf link is clicked

Check Google Analytics reports

And now, let’s take a closer look at every step. In the second half of this blog post, I’ll show some advanced techniques as well.

Trigger

A trigger is a condition. When it is met, we will send the click data to GA (via tag).

In GTM, go to Triggers > New

Click Trigger Configuration

Choose Just Link Clicks.

Select Some Link Clicks

And enter the following condition:Click URLcontains.pdf

If you don’t see the Click URL in the dropdown, click Choose Built-in Variable and then select Click URL

Save the trigger.

Variables

For this specific example, we need just one click-related variable – Click URL. But I can guarantee that you will also need other Click variables very soon. That’s why I highly recommend that you go to Variables > Configure (in the Built-in Variables Section) and then tick checkboxes next to all click variables. That way, you will make them available in your Google Tag Manager Container

In the Tracking ID field, enter the ID of your Google Analytics property.

You can do that by going to the Google Analytics admin:

Then Tracking Info > Tracking Code. Copy the ID that looks like this UA-XXXXXX-XX and paste it to the Tracking ID field in GTM.

Google Analytics Tag

Now, it’s time to create the final ingredient of this recipe, the tag. Think of a tag as a transportation method for your information. When the PDF link click occurs, GTM will fire a tag (that will transport PDF click data from your website to Google Analytics).

Before you implement this tag, I hope that you already know/have the general GA Pageview tag. If not, get my free GTM for Beginners e-book and learn how to set it in no time.

Go to Tags and click New

Track Type – Event

Category – file download (actually, you can name this whatever you want but that’s just the usual naming convention I follow)

Action – {{Click URL}}

Label – leave it empty or {{Page URL}}

In the Google Analytics Settings field select the GA Settings Variable you were already using or you have created several minutes ago.

In the Triggering section, choose the Just Link Clicks trigger we’ve created in one of the previous chapters.

Save the tag

Test the setup

I cannot stress this enough – testing your configuration is super crucial. No matter how cool is your setup; if it sends incorrect data (or maybe never works), all your efforts are for nothing.

Let’s make sure that your GA event tag fires only when a PDF link was clicked.

Enable the preview and debug mode by clicking the Preview button in the top right corner. If you don’t see the button, this means that you don’t have enough permissions in that container. You MUST have at least Edit permissions. This blog post explains a very similar issue.

An orange banner in your GTM interface must appear.

If it does not, read this guide. It is 100% necessary for you to see that orange banner.

Then go to your website where you want to track PDF downloads with Google Tag Manager and Google Analytics. Refresh the page and the Preview console must appear at the bottom of your page. If it does not, read this guide.

Now, click the PDF link. If the file opens in the same tab and your GTM preview mode disappears, here’s what you will need to do:

That regular expression means that if the clicked link contains .pdf, .xls, .xlsx, or other file extensions, then the trigger will be activated and we will be able to activate a Google Analytics tag thus send the file data to GA.

If you want to add more supported file extensions, add a pipe (vertical line) | before the closing parentheses and then enter one more extension. Just make sure that you DO NOT leave the pipe before the parentheses.

Good example: \.(pdf|xlsx?|docx?|pptx?|odt|zip|rar|txt|rtf|odp|ods|xlsm|.exe)

Container Template

If you want to save some time in the future, you can check this GTM Container template for tracking file downloads. Download the template, import it and it will automatically create all the tags and variables you need. You’ll just need to configure the GA property ID/GA Settings Variable).

Check the GA Reports

After you’ve tested and published the container, the data will start pouring in in no time (or quite soon — this depends on your traffic volume). However, keep in mind that non-real-time (a.k.a. standard) reports in Google Analytics will not show the data immediately.

There is some delay that depends on the traffic volume your GA property is getting. The delay might take minutes, but it also might take hours. GA keeps the right to display the data within 24 hours.

So, be patient.

Once you have waited at least for a while, go to Behavior > Events > Top events. You should see your file download events there.

If you want to see which exact file was viewed/downloaded, click the Event Category you’re interested in (like file download) and you will all the possible Event Action values that belong to that Event Category.

Create a Google Analytics Goal

If you think that the clicks of certain files are super important to you and you consider this as some sort of success (usually, I don’t ), you can also configure a goal in Google Analytics.

What is a goal? It is an important interaction for your business, a.k.a. a conversion. That interaction can be a view of a certain pageview, a number of page views, event, etc.

In this case, we can instruct Google Analytics to treat certain file link click events as super important.

In GA, go to Admin > Goals (in the View column) > New Goal

Template – Custom

Goal name – enter whatever is meaningful to you

Type – Event

Goal details:

Now it’s up to you to decide which events you want to turn into goals. If you want to treat all file downloads as goals (with you shouldn’t), then just enter “file download” (without quotation marks) in the Category field and that’s it.

If you want to consider only a download only of a certain file as a goal, then you can enter something like this:

Remember, these settings in the Goal depend on what naming convention are you using for events.

If your event action is XXX, and you want to treat all XXX actions as goals, then you enter that XXX in the goal settings’ Action field.

Don’t bother to click the Verify this goal link because you’ve just recently created the event for document click tracking and this verification feature still hasn’t gotten the latest data.

Save the goal and go to GA Realtime > Conversions. That’s where your goals will be visible. Click the document link (on your site) that you treat as a conversion/goal. Then check the GA Real-time reports. If you don’t see the goal in that report, read this guide.

Bonus: Advanced Tracking of File Downloads with Google Tag Manager

If you implemented the link click tracking as I’ve instructed above, you will see the value of the Click URL in your reports. But what if your business (or Content Management System) is naming files in a very bizarre way and all you can see in reports is this?

Then you could cooperate with a developer and ask him/her to add some additional information to that link element (that you could later fetch with Google Tag Manager).

Here’s an example of a link on some website. I do the right-click on it > Inspect and then see something like this. This is a bit more technical. The href attribute shows the destination URL of that link (a.k.a. where that link will redirect, a.k.a. the Click URL).

This is one of those incomprehensible links that will be very hard to read in your GA reports.

What you could do to make things better is to ask a developer to add an attribute “data-filename” to that link.

“data-filename” is a made-up parameter, you can ask for whatever you want, e.g. “data-filedescription”, etc. You should explain to a developer, that this new custom attribute should include some meaningful, more understandable information about the file. Maybe in your CMS, that file is already using a proper name?

Here’s an example of how that parameter could look after a developer implements it.

This step (to get a developer buy-in) is the most difficult. Now, the easier part – GTM configuration.

That’s it. Apply the same testing principles I’ve explained in one of the previous chapters of this blog post.

FAQ

Sometimes, I end blog posts with the most popular questions I see online related to the current topic. This time, I have only one. Hopefully, the list will be updated in the future if I notice new trends in the comments section below.

Can you track the download button in the PDF file? Usually, people refer to this button that is available when you open a PDF file in the browser (like Google Chrome):

Unfortunately, the answer to this question is no. You cannot track that because you are now viewing the PDF file directly in a browser and you cannot place tracking codes in these files.

Final Words

Usually, tracking PDF downloads with Google Tag Manager is fairly easy (or any other types of files). Once you get a grasp on the main concepts, like triggers, tags, variables, you should be up-and-running fairly quickly.

Here’s the summary of things you should do:

Create a trigger that will check link clicks on your site. If Click URL contains .pdf, .xlsx, or other file extensions, this should be considered as a file download.

If you haven’t already, enable click-related variables in the GTM container. For this case, we’ll need the Click URL but you can enable all of the Click Variables. You’ll need them in other cases quite soon

]]>Updated: June 4th, 2020. 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:

Intermediate Google Tag Manager course goes even deeper into the Data Layer (explaining even some technical aspects that are behind the DL). Also, the course teaches some nuances that are not covered in the blog post.

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

Before we continue, a quick note: in this article, I will interchangeably use dataLayer and Data Layer. FYI – they are the same thing.

Technically speaking, a Google Tag Manager Data Layer is a JavaScript array that temporarily stores the information you need and then Google Tag Manager uses that data in tag/triggers/variables (later that data can be transferred to other tools, like Google Analytics).

In plain English, a Data Layer like a virtual layer of your website, which contains various data points and GTM uses them (Get it? That’s why it’s called 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 GA.

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):

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 additional on your website. Once you place the 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.

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 Data Layer on a page. You can even see the dataLayer mentioned in the code. If the Data Layer 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, Data Layer 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:

By adding a dataLayer snippet above the GTM container snippet. This is called “Data Layer declaration”

Or by pushing data with dataLayer.push method.

What’s the difference, you ask?

#2.1.1. Data Layer declaration

Thefirst method is very limited and can work only if you add the Data Layer 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:

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 Data Layer 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 the Google Tag Manager container with the following parameters: transactionID, transactionTotal, etc. (you can read the full guide here). Once this information is added to the Data Layer, Google Tag Manager can fetch it and transfer it to Google Analytics.

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

Sometimes Google Tag Manager 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 Data Layer 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:

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 Data Layer event once a new subscriber has entered his/her email on your website. The code of this event should look like this:

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:

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

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

To use certain pieces of data (in the shape of variables). I will explain it in chapter #3.1.

To decide when to fire a tag (in the shape of triggers because you can use Data Layer 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:

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 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 detail on 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:

#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 the Data Layer when the page loads. The Data Layer snippet looks like this:

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

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

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

#4.2. Enable Preview and Debug mode in Google Tag Manager

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 Google Tag Manager debug console should appear at the bottom of the screen.

Click Variables and look for pricingPlan. Check its value. If pricingPlan is undefined, you should double-check whether you have entered a correct Data Layer Variable name in GTM’s admin panel (by the way, it’s case-sensitive). In my case, pricingPlan variable is defined correctly, because I get the value Free.

#4.3. Create a custom dimension in Google Analytics

pricingPlan is a custom parameter that was defined by you (or your developer) so Google Analytics will not catch it by default. You need to create a custom dimension pricingPlan in order to inform Google Analytics about this new parameter.

Login to your Google Analytics account.

Open your website’s account and then click Admin. You should see something like this.

If you already had a GA Pageview tag in your GTM container, there’s no need to create a new one. Just use the existing one because the most important part (where you need to enter the Custom Dimension) is hiding within the GA Settings Variable.

Since we want to pass this dimension with every Google Analytics hit, go to Variables (in your GTM container), find the Google Analytics Settings Variable, and open it. Go to More Settings > Custom Dimensions and enter the Custom Dimension number you saw in the GA interface (see chapter #4.3) and then enter the Data Layer Variable you created in chapter #4.1.

Save the variable. After you complete these steps, you will start sending user’s pricing plan name with every Google Analytics hit (pageview, event, etc.)

That’s how you can transfer additional data from Google Tag Manager Data Layer to Google Analytics.

#5. Using Data Layer in triggering

The entire concept of the event tracking in Google Tag Manager is based on the Data Layer. If you want to capture interaction and fire a particular tag (e.g. Google Ads conversion tag), the interaction first must be pushed to the Data Layer. Only then Google Tag Manager can catch it and use it as a triggering condition. This applies to both standard (e.g. links, forms) and custom event (e.g. purchase, login) tracking.

In this chapter, I will focus on custom event tracking (if you want to learn more about standard event tracking in Google Tag Manager, check these articles for inspiration: click tracking, using history change trigger).

Back to custom event tracking. If for example, you want to track events when users successfully register on your website and then send such events to Google Analytics, here is one of the possible solutions. You can ask a developer to activate the following code every time a user signs up.

The key part here is the “event” key. It is necessary if you want to fire tags every time a certain interaction occurs on a page. Also, let’s say that we want to also track pricing plans of the signup (because users can sign up to free or to a premium plan). That’s why we could update the code and add an additional piece of information, plan.

Once a developer confirms that the above code is implemented, it’s time for you to check whether that’s true.

Enable the Preview and Debug mode in your Google Tag Manager container, register on your website (just like a regular user would do that) and take a look at the debug console. First of all, the “registrationComplete” event must appear in the event stream (left side of the console).

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

Please ignore the registrationCountry key in the screenshot above. That’s from another example.

If unfortunately, registrationComplete is missing, contact the developer and tell him/her to properly follow your instructions. Also, this guide is quite useful for developers to better understand how to work with the Data Layer.

#5.1. Custom Event Trigger

So once you reach the point where a developer pushes the interaction data (together with the event key) to the Data Layer, the next step is to catch that .push and turn it into a triggering condition. By default, Google Tag Manager does not care about the pushed events that are happening in the Data Layer (I mean that no tags will be fired unless you specifically instruct GTM to do so).

Since we are interested in tracking successful registrations, 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 the New button. Choose Custom Event as trigger type and enter the following settings (event name is case-sensitive):

Done. You have just created a Google Tag Manager Custom Event Trigger.

How can you use that in the event tracking? Let’s take a look at the example.

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

We entered “plan” because that’s the name of the key in the Data Layer (when the registrationComplete event is pushed to the DL).

#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 GA

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.

With this kind of setup, whenever an event (with event category “registration complete”) is tracked by GA, 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

If you read the entire article, well done (and thank you)! If you skipped to the summary without reading the entire thing, then I suggest you bookmarking this page so you can come back later. This is not a topic that can be covered by a quick 500-words blog post.

Google Tag Manager Data Layer is a fundamental part of GTM. Without it, event tracking would simply not work. It enables us to capture interactions (+ use them as triggers) and get some additional data about the interaction or the context (+ use it with the help of Data Layer Variables). If you feel that this concept is difficult to master, you’re not alone. It’s perfectly fine to be confused at the beginning. I suggest starting with a few events and then scale up. You’ll become better with time.

]]>https://www.analyticsmania.com/post/what-is-data-layer-in-google-tag-manager/feed/17Google Tag Manager Video Tracking Guide: Beyond Youtubehttps://www.analyticsmania.com/post/google-tag-manager-video-tracking/
https://www.analyticsmania.com/post/google-tag-manager-video-tracking/#commentsThu, 04 Jun 2020 02:22:52 +0000https://www.analyticsmania.com/?p=2725Updated: June 4th, 2020. To understand what website visitors are doing on your site, tracking pageviews is far from enough. You should also consider other interactions, such as clicks, views of particular elements, video interactions, etc. When it comes to videos, the most popular embedded video players are Youtube (I have no stats to support […]

To understand what website visitors are doing on your site, tracking pageviews is far from enough. You should also consider other interactions, such as clicks, views of particular elements, video interactions, etc.

When it comes to videos, the most popular embedded video players are Youtube (I have no stats to support this; just saying this based on what I’ve seen on other websites). But what if your website is using a different player (like Vimeo or maybe a generic HTML5 player)?

That’s not a problem, because you can track them with GTM.

In today’s blog post, I’ll show you how to track videos with Google Tag Manager. I’ll cover Youtube video tracking, Vimeo video tracking, and will also mention several other players.

So, what’s the plan?

First, we’ll take a look at the most common video tracking example in Google Tag Manager: Youtube video trigger. Then, I’ll show you an example with a video player that is not supported by GTM by default. That’s Vimeo.

And finally, I’ll also give you some ready-made solutions (recipes) designed for various embedded video players.

Ready? Let’s go.

Chapter 1. How to track Youtube videos with Google Tag Manager

If you are in a hurry, I have created a ready-made Youtube video tracking recipe. Download it, import, configure (according to instructions) and it will automatically start tracking Youtube videos on your website in no time.

But if you want to understand the ins and outs of the Youtube video tracking, then continue reading.

Here are the steps you need to complete in order to track Youtube videos with Google Tag Manager.

Step 1. Create a Youtube Video Trigger

It all starts with a trigger. In Google Tag Manager, go to Triggers > New > Trigger Configuration and choose Youtube Video. Then enter the following settings:

You can change the Percentage threshold to anything you like, just separate them with a comma. Also, you can enable Pause, Seeking, and Buffering tracking. Personally, I prefer tracking Start, Complete, and Progress (e.g. 25% of the video was watched).

Also, even though the Add JavaScript API support to all Youtube videos is an Advanced setting, I enable it by default because it increases the change that Youtube video tracking will work.

If the video player status is “progress”, this means that a certain percentage of a video was seen by a visitor and this event became available in the preview and debug mode.

In this case, we want this lookup variable to return the video player status (progress) and also the video percentage that was watched together with a % sign.

But if the Video status is not “progress”, then this lookup variable will just return the name of the status (for example, start,complete, etc.). That’s why I have configured the “Set Default Value” checkbox.

Step 4. Create a Google Analytics tag

Now, it’s time to send the Youtube video data to Google Analytics. In GTM, go to Tags > New > Universal Analytics and enter the following settings.

If you are new to Google Tag Manager and have no idea what a Google Analytics Settings Variable is, click here.

You can choose some other names/values in the Event Category/Action/Label fields if you want (but I highly recommend following this naming convention).

Also, keep an eye on the Event Action field. We have entered the Lookup Table variable here.

Also, assign the Custom Event trigger (for video event) to that tag.

Step 5. Test the setup

Once you have completed all previous steps, it’s time to test. Enable/Refresh the Preview and Debug mode, refresh the page on your website with the embedded Youtube video player and try to interact with it.

What if your website does not contain embedded Youtube videos? What if you are using something else? In that case, the built-in Youtube video tracking in Google Tag Manager will not work. You need to find some custom solution.

It all starts with identifying the video player

Before you start with the actual tracking of video player interactions, first you need to identify what kind of video player is that. Video players clearly show their logo in the player box (e.g. Vimeo), others will probably be not that obvious.

If your case is the latter, do this. In your browser, open developer tools (in Chrome, that’s F12 (on Windows)) and then go to Elements tab. Then click this button…

… and then click on the player itself. Now try to browse a bit and locate some clues mentioning the player provider name. For example, in this case, the player that I’m inspecting is JW player.

Once you identify the name of the video player, just google [ video player name ] tracking with Google Tag Manager and you should find some guide or tutorial.

Let’s imagine, that in our case, we see the “Vimeo” logo at the corner of the embedded video player.

Step 1. Create a variable “Is Vimeo player present on a page”

In order to track Vimeo players with GTM on a page, we will need to add a lengthy code to the container. Loading that code on every page is not optimal and will affect the page loading speed, that’s why we need to activate that code ONLY when the Vimeo player is actually embedded on that site.

To do that, first, we need to create a Custom JavaScript variable and paste the following code:

If the Vimeo player is embedded in the page, this variable will return true.

Then create a pageview trigger and use that Custom JavaScript variable in it. If the Vimeo player is present, this trigger will be activated. If there is no Vimeo player, that trigger will remain silent.

Step 2. Vimeo Auto-Event Listener

Now, it’s Vimeo Listener’s turn. A listener is a function (or a bunch of functions) that are built to keep looking for certain interactions on a page. In this case, the listener will be looking for Vimeo player interactions. If it spots one, it will make that data visible in the Preview and Debug mode.

Create a Custom HTML tag and paste the following code. The original authors of this code are Bill Tripple and Bogdan Bistriceanu from Cardinal Path).

This listener was recently slightly updated to support some changes in Vimeo.

A Pageview Trigger which checks whether Vimeo video player is embedded in the web page (thanks to a Custom JavaScript variable).

A Vimeo Auto-Event Listener (as a Custom HTML tag) fires only when the aforementioned Pageview Trigger activates. Every time a Vimeo player interaction occurs, the listener will dispatch a Data Layer event with the following data:

eventLabel: [Video title] (this value is dynamically changed and depends on a video).

If you want to test this now, enable the Preview and Debug mode, refresh the page with the Vimeo player and try interacting with it. You should start seeing videoevents in the Preview mode’s left side.

Step 3. Create Data Layer Variables and a Custom Event Trigger

Google Tag Manager does not recognize Data Layer events or other data. So if you wish to transfer some information to other tools (e.g. Google Analytics), you need to “teach” GTM to fetch certain information (with the help of Data Layer Variables).

After variables are configured, it’s time to create a Custom Event Trigger. Vimeo Auto-Event Listener sends all interactions as Data Layer events under the name of “video”.

So the next thing you should do is to create a Custom Event Trigger which listens to ALL video events. Later, it will be assigned to Google Analytics Tag.

In GTM, go to Triggers > New > Custom Event and enter the following settings:

Step 4. Create a Google Analytics Tag

Last but not least, Google Analytics. Now you need to send an event and pass the corresponding data with it. Create a new tag, select Universal Analytics as Tag Type, choose Event as Track Type, and enter all three Data Layer variables.

This means that every time a video event is created, a Google Analytics Event will be pushed to Google’s servers and all three variables will be dynamically replaced with the actual data.

If eventLabel equals to Video Title Lorem Ipsum, this exact value will be passed to Google Analytics.

Just make sure that you enter the GA settings Variable in its special dropdown (see the screenshot below).

Step 5. Test test test

Don’t forget to test this entire configuration. Enable GTM Preview and Debug mode, go to a page with an embedded Vimeo player, and click Play. The next thing you should see is a video event in Preview and Debug mode’s event stream. Click it and see whether the Universal Analytics tag has fired.

The entire process in a nutshell

We created a Custom JS variable that returns true if the Vimeo player is embedded on a page.

Then we created a Pageview Trigger that checks whether Vimeo video player is embedded in the web page (thanks to a Custom JavaScript variable)

Then we created a Custom HTML tag (a Vimeo Auto-Event Listener). And it will fire on all pages where the Vimeo player is embedded. Important: even if you haven’t interacted with the player yet, that tag will still be fired.

Every time a Vimeo player interaction occurs, the listener will dispatch a Data Layer event with the following data:

Since most of the GTM Recipes are created by distinct authors, their naming convention is also diverse. That’s why I’ve spent some time and unified them (and included the 6th recipe – Youtube tracking with the built-in GTM functionality).

What does it mean? Well, if you use several types of video players on your website, video auto-event listeners will fire events following the same naming pattern. In other words, data in your Google Analytics event reports will be consistent. For example, Vimeo auto-event listener would fire this Data Layer event:

One thing that I’ve noticed is that the HTML5 recipe doesn’t play well with others (well, at least some of them). Sometimes, it overtakes all interactions and other video listeners stop working. So make sure that HTML5 auto-event listener does not fire on the same page as JW player, etc. Everything else should be fine. If you notice any bugs, please let me know.

Video tracking with Google Tag Manager: Final words

When it comes to video tracking with Google Tag Manager, the first thing that probably comes to your mind is the tracking of embedded Youtube videos. Well, I don’t blame you, since this is the most popular video hosting platform in the world.

But if you are dealing with a non-youtube video player, that is still possible with some custom solutions.

In this blog post, I’ve explained how you can track both Youtube and non-youtube videos embedded on your site.

And to save you some time, I’ve also included a bunch of recipes that you can download, import, configure, and start tracking videos in minutes.

Just download any of them, import to your GTM account, and start tracking videos in a blink of an eye.

All these Google Tag Manager video tracking solutions follow the same principle, so once you master one, you’ll conquer all of them.

]]>https://www.analyticsmania.com/post/google-tag-manager-video-tracking/feed/46Transfer UTM Parameters From One Page To Another with GTMhttps://www.analyticsmania.com/post/transfer-utm-parameters-google-tag-manager/
https://www.analyticsmania.com/post/transfer-utm-parameters-google-tag-manager/#commentsThu, 04 Jun 2020 00:34:09 +0000https://www.analyticsmania.com/?p=3386Updated: June 4th, 2020. Imagine this. You’re running a promo campaign that brings traffic to a certain landing page (e.g. landingpage.com). After the visitor clicks the main Call-to-action button (e.g. GET YOUR DISCOUNT), he/she is redirected to another page (2ndpage.com) which asks a visitor to do the final action, install the app, fill in the form, sign up, […]

Imagine this. You’re running a promo campaign that brings traffic to a certain landing page (e.g. landingpage.com). After the visitor clicks the main Call-to-action button (e.g. GET YOUR DISCOUNT), he/she is redirected to another page (2ndpage.com) which asks a visitor to do the final action, install the app, fill in the form, sign up, etc.

When the conversion is completed, a Google Analytics event is fired. Unfortunately, when you look at your GA reports, what you’ll see is that all conversions are attributed to the landingpage.com. Technically, this is correct because all visitors landed on the 2ndpage.com from landingpage.com, but you’d like to see the original source which brought the visitor, wouldn’t you?

In this blog post, I’ll show you how to transfer UTM parameters from the initial page landingpage.com to the subsequent one (2ndpage.com) if the cross-domain tracking cannot be implemented.

Update: The original script supported only one domain. At the end of this blog post, I also added another script that checks against a list of domains. If you want to transfer UTM parameters to somedomain1.com, somedomain2.com, and somedomain3.com, use the script placed at the end of this blog post.

All other chapters of this guide apply to both scripts.

The problem explained

Say, that you’re promoting an application that is available in the App Store. We’ll call it Lorem Appsum. Its App Store page isn’t sufficient to list all the benefits, cool features, etc. So you decided to create a separate landing page that you’ll drive traffic to. You have also marked all inbound links (stored on other websites/forums/etc.) that lead visitors to that landing page with UTM parameters.

Before we continue, here’s a quick update.Yehoshua Coren chimed in by saying that everything can be easily solved by implementing a regular cross-domain tracking. Yes, that’s totally true.

When I was writing this blog post, I actually, totally forgot to mention one more reason why cross-domain tracking isn’t always a solution. In the case of app stores, usually, creators/developers are not allowed to edit Google Analytics tracking code, therefore cross-domain tracking cannot be configured properly.

This is what we faced with Omnisend (when I was working there) at Shopify Appstore. We were allowed to set Google Analytics Tracking ID, that’s it. Unfortunately, in order to make cross-domain tracking work, we also needed to enable allowLinker option on the receiving domain (app store) but that was not possible.

So we had to improvise and this blog post is the solution to the problem.

Note: I did not write the code mentioned in this blogpost. My co-worker developer did that based on my request.

OK, let’s go back to the topic. You have a page in the app store, so you decide to create an additional intermediate landing page on a different domain. Cross-domain tracking cannot be implemented due to the limited app store’s functionality.

That new landing page contains key selling points, descriptions of features, video, and a big GET APP NOW button (Call-to-action, a.k.a. CTA). Perfect. The visitor lands on the initial page, he clicks that CTA button, lands on the App Store page and installs the app. Heres’ the scheme of the entire visitor journey:

Notice that UTM parameters are lost after the visitor clicks an appstore.com link on loremappsum.com page.

The problem is that Google Analytics will attribute this conversion to loremappsum.com, although it would be more beneficial to see the values of the initial UTMs.

The Solution – Overview

One of the solutions is to transfer UTM parameters from loremappsum.com and automatically add them to all links which redirect users to appstore.com/loremappsum. We’ll do this with Google Tag Manager and a custom script.

Once the visitor lands on loremappsum.com AND the Page URL contains utm_medium, utm_source, and utm_campaign, this script will be launched. It will scan the entire page and look for links which contain the domain of the final landing page, in this case, appstore.com.

If the script finds the link, it will:

Fetch all 3 UTM parameters from the browser’s address bar.

And will add those UTM parameters to that spotted link (which contains “appstore.com”).

So instead of appstore.com/loremappsum, all links on loremappsum.com will be automatically modified to appstore.com/loremapsum?utm_medium=referral&utm_source=promo&utm_campain=blackfriday2017. Here’s the updated visitor flow:

The Solution – Implementation in GTM

First of all, we need to create 3 URL variables that parse the value of 3 UTM parameters, utm_medium, utm_source, utm_campaign. They are important because we’ll use them in the custom script.

Important: In Google Tag Manager, you should name variables exactly the same as they are named in the script (case sensitive!), URL – utm_medium, URL – utm_source, URL – utm_campaign.

Next step, the trigger. We need to fire that custom script only when all 3 UTM variables contain something rather than undefined. In addition to that, we’ll need the DOM to be loaded in order to do some manipulations.

That’s why we’re creating a Pageview-type trigger with the following settings:

Let’s Test

Save all changes, enable Preview and Debug mode. Now head over to the page you’re working on. There are two situations we need to test:

Make sure that there are all 3 UTM parameters in the Page URL. In my case, the page URL is www.loremappsum.com?utm_medium=referral&utm_source=promo&utm_campaign=blackfriday2017

Click the link which contains the domain name you have defined in that custom script I’ve shared in this blog post. In my case, it’s www.appstore.com/loremappsum

After I’m redirected, the Page URL (appstore.com/loremappsum) should also contain those 3 UTM parameters. The final result in the browser’s address bar should be www.appstore.com/loremappsum?utm_medium=referral&utm_source=promo&utm_campaign=blackfriday2017

Also, do not forget to test the opposite situation when there are no UTMs in the address bar. In that case, no UTMs should be appended to appstore.com links.

Oh, there’s also a third case to test, check at least a couple of other external links (unrelated to appstore.com), they should never contain UTM parameters.

What if you want to affect several domains at the same time?

The solution (explained above) works only if you want to decorate all links of a single domain. But what should you do if there is more than one? For example, externaldomain1.com and externaldomain2.com.

In this case, you should use a bit modified version of the code which checks against an array of domains.

Replace two fake domains in the 4th and 5th lines of the script. In fact, if you want, you can add even more of them. Just make sure, that the last item in the array does not end with a comma.

var utmInheritingDomains = [
"externaldomain1.com",
"externaldomain2.com",
"externaldomain3.com" // The last item must not end with a comma
],

If you want to target only a specific set of subdomains of external domains, enter just those specific subdomains. Otherwise, if you enter just externaldomain1.com, this script will affect links that belong to all subdomains of externaldomain1.com, e.g. www.externaldomain1.com, app.externaldomain1.com, etc.

What if your UTM parameters contain a ‘+’ sign?

Sometimes, UTMs might contain a plus sign, for example:

utm_campaign=Prospecting+-+Facebook+Image+2

Unfortunately, what I’ve noticed is that some browsers (at least Chrome) automatically replace a ‘+’ sign with %20 (which is an encoded empty space). In order words, Chrome turns this:

utm_campaign=Prospecting+-+Facebook+Image+2

into this

utm_campaign=Prospecting%20-%20Facebook%20Image%202

Naturally, the solution described in this blog post will pull the values with %20 and will accordingly decorate certain links. Sadly, I haven’t found a way how to avoid this. So my best tip right now would be to not use ‘+’ in your UTM tags.

Transfer UTM Parameters: Final words

In this quick blog post, I’ve explained how to transfer UTM parameters from one page to another. This is really useful when you have an intermediate landing page that you’re attracting visitors to, and then they have to proceed to the final page which is stored in another domain.

By default, you’ll lose all attribution data and Google Analytics will display your intermediate landing page as the main referral.

With the script I’ve shared, you’ll be able to reuse UTM parameters of the initial landing page and decorate certain links with them.

The situation I’ve described is not a very common issue, but it occurs from time to time. Actually, one of my readers has recently asked a question related to this very same topic.

]]>https://www.analyticsmania.com/post/transfer-utm-parameters-google-tag-manager/feed/117Google Tag Manager vs Google Analytics: What’s the difference?https://www.analyticsmania.com/post/google-tag-manager-vs-google-analytics/
https://www.analyticsmania.com/post/google-tag-manager-vs-google-analytics/#commentsWed, 03 Jun 2020 05:03:46 +0000https://www.analyticsmania.com/?p=451Updated: June 3rd, 2020. When I first heard about Google Tag Manager (GTM) in early 2013, I felt a bit confused. At that time I had no idea that tag management was a thing at all, so naturally, I found myself questioning what is Google Tag Manager? What’s the difference between Google Analytics events and GTM events? And nowadays I actually […]

]]>Updated: June 3rd, 2020. When I first heard about Google Tag Manager (GTM) in early 2013, I felt a bit confused. At that time I had no idea that tag management was a thing at all, so naturally, I found myself questioning what is Google Tag Manager? What’s the difference between Google Analytics events and GTM events?

And nowadays I actually still notice this trend of confusion among many beginners. In this blog post, I’ll compare Google Tag Manager vs Google Analytics and show you the main differences.

Spoiler alert: they do not replace each other. They are meant to be used together.

Google Analytics In a Nutshell

Google Analytics’ main purpose is tracking data, storing it and generating reports about your website, for example:

how many people visited your website yesterday?

what country are they from?

how many pages did they visit per session?

how many visitors bounced off your website (without performing any action)?

which pages were the most popular, etc.?

The only way Google Analytics can track these user interactions is with the help of tracking code (also known as GA Javascript code snippet) that must be placed on every page of your website.

Once an interaction occurs on a site (e.g. pageview), a Javascript snippet sends the corresponding data to Google Analytics.

There’s no problem if you just want to put the GA tag on all websites and track general information like page views, bounce rate, session duration, referrals, etc. However, you’re limiting yourself big time.

You may want to track how many people use a specific feature on your website/app. Or maybe you are interested in tracking sales, huh? In this case, you’ll need to add custom tags – Google Analytics events that send the data only when a visitor completes a particular action on your website. A good example here could be a form submission.

So what do you do here? Ask the developer to add that form submission tracking tag to a website (directly in the code), right? But what happens when there are tens or hundreds of interactions you are willing to track with Google Analytics?

Unfortunately, it will require a lot of developer’s time (and they are always very busy!). It might take weeks or even months until you can get your marketing tags up and running, which is a real bummer.

Google Tag Manager to the Rescue!

Google Tag Manager makes it easier to manage this mess of tags by letting you define the rules of when certain tags should fire, but first, let’s take a quick overview of GTM.

Google Tag Manager is free software from Google that allows you to deploy various types of code (tags) to your website. Some good examples of a tag would be Google Analytics tracking code, Google Analytics event codes, Google Ads conversion script and remarketing tags. There are many more types of code that can be added to your website using GTM, including custom codes.

Prior to GTM, GA tracking codes had to be hard-coded, usually by a web developer on each individual page. Having hundreds of events is very difficult when it comes to maintaining/updating them. But Google Tag Manager solves this problem because all your tags are stored in one place – your GTM account.

Imagine that Google Tag Manager is a Toolbox, where you keep all your tools: a ruler (Google Analytics), a hammer (Google Ads), etc.

Google Tag Manager also lets you test your tags to make sure they are triggered when you load the right page or click a particular button. Another great benefit: you can change your tags and the way they work without actually changing the source code of your website (which you may not be able to do because of slow-release cycles or busy schedule of developers) – instead you just edit tags in GTM user interface and publish changes with a click of a button.

Google Analytics is not the only tag compatible with Google Tag Manager. Other examples include:

What is the difference between Google Analytics and Google Tag Manager?

They are totally two different things that serve two very different purposes.

Google Tag Manager lets you manage various Javascript tracking codes (also known as Tags)on your website. Google Analytics tracking code is one of those tags.

Google Analytics is an analytics tool that provides reports. Google Tag Manager has no reporting features. It is used to send data from your website to other marketing/analytics tools (including GA).

If you don’t want to use Google Tag Manager, that’s fine. You can still continue adding Google Analytics tracking codes directly to your website’s source code (but keep in mind that you, as a marketer/analyst, will lose a lot of flexibility).

Example

As I have previously pointed out, Google Analytics is a Tag itself. According to GA instructions, you need to place GA tracking code on every page of your website. A sample tracking code should look like this:

Congratulations! You just created a Google Analytics Pageview tag in Google Tag Manager. It will track pageviews on all pages which have GTM container snippet installed. All pageviews will be sent to Google Analytics property UA-XXXXXXX).

Google Tag Manager vs Google Analytics: Events

In Google Analytics all events are displayed in the event report (Behavior → Events). They often represent interactions that happened on your webpage. The data for this report is populated from Event hits that are sent from your website to Google Analytics’ servers. Prior to the birth of Tag Management systems (like GTM) Event hits had to be initiated by small Javascript codes placed on your website. Here’s an example:

As you can see, this snippet of code contains eventCategory, eventAction, eventLabel and eventValue (optional). After a particular action occurs on your website (e.g. user submits “Contact us” form), the Google Analytics Event will be fired and the corresponding data will be passed onto Google Analytics, for example:

Now let’s talk about Google Tag Manager events. In order to see them enable GTM’s Preview and Debug mode by clicking the Preview button in the top right corner of Google Tag Manager interface.

After you enable Preview and Debug mode, a large orange notification banner will appear in GTM user interface.

Once the preview mode is enabled, navigate to the site where Google Tag Manager Container code is placed and you will see a debug console window at the bottom of the browser showing detailed information about your tags, including their firing status and what data is being processed. If it didn’t appear, read the guide explaining how to fix GTM preview mode.

On the left side of the Preview and Debug console, you should see a list of some definitions. These, my friend, are Google Tag Manager Events.

They actually play a very important role within GTM – you can fire your Tags (scripts of various marketing tools) based on these Google Tag Manager events. Here are a few examples to make it easier to comprehend:

A Pageview Google Tag Manager Event can be used as a trigger to fire Google Analytics Pageview Tag.

A Link Click obviously occurs when a certain element with a link is clicked. For example, when someone clicks a PDF link on your website, you can send this click as Google Analytics event (and see it in your reports). P.S. Out of the box, you won’t be seeing any events except Pageview, DOM Ready and Window Loaded. In order to start seeing events, you need to have at least one trigger of that type enabled in the container. Here’s an example of how to track link clicks and button clicks.

A Form Submission GTM event (that happens when a visitor submits a form) can trigger another Google Analytics Event Tag (that sends an event with the data of submitted form to GA event reports). Form Submission GTM event can also be used as a trigger to fire a Google Ads Conversion Tag (or any other tag you want – it’s up to your imagination)

To sum up, the Google Tag Manager event is an interaction on your website that is spotted by GTM and then placed in the Data Layer (p.s. Data Layer is automatically created on your website when GTM container code is implemented and published). That interaction on your website can be used as a trigger (condition) to fire your tracking tags (scripts), e.g. Facebook Pixel, Google Analytics Events, Mixpanel Events, Google AdsTags, etc.

So as you can see, Google Tag Manager is the middleman in your Digital Analytics implementation. It observes interactions that occur on your website, creates GTM events and then uses them to fire tags (e.g. Google Analytics Event). Although the term Event is the same in both Google products, in Google Tag Manager a GTMEvent is a trigger, while GA Event is a Tag.

What about Google Analytics Goals?

If you read all the comments below this post, you will notice several repeating themes. One of them: Google Analytics goals. How should one configure them with Google Tag Manager? In fact, that’s not how goals work and Google Tag Manager has no direct connection with them.

Speaking of the relationship between GTM and GA, Google Tag Manager is a way of data transportation, which sends various interactions (page views, events, transactions, etc.) over to Google Analytics.

Some of those interactions are more important than others (say, a newsletter subscription or visiting “Order confirmation” page) and they are called goals. How does Google Analytics understand which interactions are more important than others?

You do that by configuring GA (not GTM). You need to go to the Google Analytics Admin section > View > Goals and create a goal. It might be pageview-based, event-based, or engagement-based (e.g. visited > 3 pages). After a goal is properly configured, certain page views or events will be treated as important actions (goals).

In other words, you tell GA that some interactions (which are sent to GA) are more valuable to the business. And it does not matter how that interaction was sent to Google Analytics, whether it’s via GTM, or directly from the website’s code, or somewhere else.

Do you see the difference? GTM is a way to pass the interaction data to Google Analytics. Goals are valuable interactions that are configured in the GA itself.

Migration to Google Tag Manager

If you run a site that is using the hardcoded Google Analytics and you want to migrate to GA + GTM, there are several things you need to keep in mind. If migration is done wrong, you will break your setup and new data will be lost/corrupted.

In general, you will need to remove the hardcoded GA codes from your website and add the Google Tag Manager container code to all pages of the site. Then you will fire Google Analytics tags via Google Tag Manager.

Your historic data will not be lost but the migration can negatively affect your future data (if done incorrectly). Subscribe to my newsletter (below) and download a free E-Book Google Tag Manager for Beginners. That e-book contains a chapter on migration to Google Tag Manager + Google Analytics.

Google Tag Manager VS Google Analytics: Conclusion

I hope this blog post made sense to you, although some parts of it might look really tricky. In a nutshell: GA is the analytics tool that provides reports about activity on your site. GTM is a tool that fires your tracking codes based on defined rules. In the end, you can either implement GA code on your site directly, or you can implement the GTM code on a site and use GTM to fire your GA code.

If you want more specifics, here are the main points that should be emphasized once more when it comes to comparing Google Tag Manager vs Google Analytics:

Google Tag Manager is the middle-man of your digital analytics implementation on any website. If you want to add Google Analytics Tracking code or events, it’s recommended to do so with GTM, because you don’t need to do constant changes in the website’s code, therefore your deployment process is faster.

Google Tag Manager can exist without Google Analytics and vice-versa. Your developers can hard-code Google Analytics codes directly to your website. But if you constantly publish need changes, only developers can help you here. While with GTM you could add/edit/remove your Google Analytics Tracking codes all by yourself. You can also use Google Tag Manager to add Facebook, Google Ads or any other tracking scripts to your website (leaving Google Analytics behind).

Google Tag Manager Eventsare used as triggers that define when a certain tag must be fired. Google Analytics event in this context is a Tag. Example: GTM event formSubmission can be used as a trigger to fire a GA event tag called “Form submission”.