Category : Google Tag Manager

What is cross-domain tracking and why do you need to implement in your Google Analytics account?
Cross-domain tracking makes it possible for Analytics to see sessions on two related sites (such as an ecommerce site and a separate shopping cart site) as a single session. This is sometimes called site linking.
Cross-domain literally means that you are able to see a user in a single Google Analytics account in his journey across multiple domains that you control (e.g. mysite.com and myshoppingcart.com).
In the standard configuration of the Google Analytics script, every time a customer loads a page on a different domain a new session is generated, even if the branding looks seamless to the user and, unfortunately, the previous session has ended and this is even if the customer is still active and generates events and page views. Until you have implemented the cross-domain setting on your website you will not be able to have an accurate customer journey.
Why? Let’s take, for example, a standard website, www.siteA.com, and it's blog, www.blogB.com.
To track sessions, Analytics collects a client ID value in every hit. Client ID values are stored in 1st party cookies, and these cookies are only available to web pages on the same domain. When tracking sessions across multiple domains, the client ID value has to be transferred from one domain to the other. To do this, the Analytics tracking code has linking features that allow the source domain to place the client ID in the link URL, where the destination domain can access it.
Fortunately, with the release of Universal Analytics cross-domain tracking, it is easier to implement, and especially so with Google Tag Manager.
Setting up cross-domain tracking using Google Tag Manager
Add (or edit your existing) a basic page tracking tag (i.e. Tag Type = Universal Analytics; Track Type = Page View).
If you are using the same container for siteA.com and blogB.com, under More Settings → Fields to Set, enter the following:
Field Name: allowLinker
Value: true
Under More settings → Cross-Domain Tracking → Auto Link Domains enter "blogB.com" (without the quotes).
If you have multiple domains, separate them by commas: blogB.com, siteC.com
Leave the 'Use hash as delimiter' and 'Decorate forms' unless you have an unusual web setup.
Set the trigger to "All Pages".
Save a version of the container and publish it.
If you are using a separate container for blogB.com, repeat the steps above but in the Auto Link Domains field add: siteA.com
Add both domains to the Referral Exclusion List
When a user journey crosses from your first domain to your second domain, it will still appear as a new session in Google Analytics by default. If you want to be able to track a single session across multiple domains, you need to add your domains to the referral exclusion list.
Here’s an example Tag Assistant Recordings report that shows what it looks like when cross-domain tracking is not setup properly.
Setting up cross-domain tracking by directly modifying the tracking code
To set up cross-domain tracking for multiple top-level domains, you need to modify the Google Analytics tracking code on each domain. You should have basic knowledge of HTML and JavaScript or work with a developer to set up cross-domain tracking. The examples in this article use the Universal Analytics tracking code snippet (analytics.js).
Editing the tracking code for the primary domain
ga('create', 'UA-XXXXXXX-Y', 'auto', {'allowLinker': true});
ga('require', 'linker');
ga('linker:autoLink', ['siteB.com'] );
Remember to replace the example tracking ID (UA-XXXXXX-Y) with your own tracking ID, and replace the example autoLink domain (siteB.com) with your own secondary domain name.
Editing the tracking code on the secondary domain
ga('create', 'UA-XXXXXXX-Y', 'auto', {'allowLinker': true});
ga('require', 'linker');
ga('linker:autoLink', ['siteA.com'] );
Remember to replace the example tracking ID (UA-XXXXXX-Y) with your own tracking ID, and replace the example autoLink domain (siteA.com) with your own primary domain name.
Adding the domain to page URLs using filters
By default, Google Analytics only includes the page path and page title in page reports - not the domains name. For example, you might see one page appear in the Site Content report like this:
/contactUs.html
Because the domain names aren’t listed, it might be hard to tell whether this is www.siteA.com/contactUs.html or www.blogB.com/contactUs.html.
To get the domain names to appear in your reports you need to do two things:
Create a copy of your reporting view that includes data from all your domains in it
Add an advanced filter to that new view. The filter will tell Google Analytics to display domain names in your reports.
Follow this example to set up a view filter that displays domain names in your reports when you have cross-domain tracking set up. For some fields, you need to select an item from the dropdown menu. For others, you need to input the characters here:
Filter Type: Custom filter > Advanced
Field A: Hostname Extract A: (.*)
Field B: Request URI Extract: (.*)
Output To: Request URI Constructor: $A1$B1
Click Save to create the filter.
You can validate that filters are working as you expect using Google Tag Assistant Recordings. Tag Assistant Recordings can show you exactly how your filters change your traffic.
Get Social! Follow us on LinkedIn, Twitter, and Facebook and keep up-to-date with our Google Analytics insights.

A lookup table in Google Tag Manager makes it much simpler to manage lots of values in your tracking setup. It can drastically reduce the number of tags required and turn your messy GTM into a neat environment.
It's especially useful with larger setups where you have multiple tracking requirements and flexible to accommodate new tracking needs as they arise. You can easily add or remove values from your lookup tables, and not worry about having to change any codes.
The lookup table variable allows you to define a set of key-value pairs where the output variable (the value that you are sending to Google Analytics) is linked to the identifier (the key).
It works like this: When [input variable] equals to _______, set [this output variable] to_______.
For example, you could use the lookup table for:
Assigning different Google Analytics property IDs for various domains/hostnames, eg. when [website hostname] equals to littledata.co.uk, set [property ID] to UA-010101 (see example below)
Setting different pixel or conversions IDs for different country websites, eg when [website country code] equals to 2, set [pixel ID] to 88779 (requires having website country code variable defined)
Defining your event categories, actions and labels (see example below)
Remember! There’s no limit to how many values you can have in the lookup table, but the fields are case sensitive.
So if you have multiple capitalisations of some input, then include all of them in the lookup table and assign the same output for each.
I have previously explained setting up the tracking of user actions as events in GTM, but when you need to track multiple events, one tag just doesn't cut it anymore.
And instead of creating several tags to cover each event or action, here's how you would create the lookup table to cover multiple values in one place.
Creating lookup table variable for event parameters
In the Littledata software interface, you get an option to switch between different report types or view them all.
I want to track when people click on different report types, so instead of creating 5 different tags for each user action, I will set up a lookup table to cover all of them in one place.
But firstly I need to know which variable to use as the input. You can only have one type of input variable per the lookup table so you want to pick a variable type that applies to each (ideally).
For this, I will check how each report type option has been set up in the code by inspecting the element (inspect/inspect element depending on the browser you're using and usually accessible via right click).
Here's how each report type has been set up:
<a href="/report-list/m2i4MnmXcewDSzZ3c/all" class="current" id="ga-all">All <span class="count">120</span></a>
<a href="/report-list/m2i4MnmXcewDSzZ3c/trends" class="" id="ga-trends">Trends <span class="count">80</span></a>
<a href="/report-list/m2i4MnmXcewDSzZ3c/pages" class="" id="ga-pages">Pages <span class="count">37</span></a>
<a href="/report-list/m2i4MnmXcewDSzZ3c/tips" class="" id="ga-tips">Tips <span class="count">3</span></a>
<a href="/report-list/m2i4MnmXcewDSzZ3c/benchmark" class="" id="ga-benchmark">Benchmark <span class="count">0</span></a>
Looking at the above, I can see that each report type has a unique ID - here that's the best one to use.
Now to set this up, go to Variables, click ‘New’ and select 'Lookup Table' as your variable type.
For the input variable, I will use {{Click ID}} as explained above, but you, of course, use whatever unique identifier you have available.
For your output, you want to define the event action you are going to send to the Events report in Google Analytics.
Should you set the default value?
You can set a default value for the output when there is no match found in your table.
With the event tracking, I sometimes find it useful to enable to identify if I set up my tag correctly. If my trigger ends up being too broad, the default value option will pick up additional values not defined in the table. I will then see these values in Google Analytics reports and this way I can tidy up the trigger to be more accurate.
So this is what your variable should look like now.
Click ‘Create Variable’ and there you have it.
In your GA event tag, the newly created variable would look like this.
Other uses
Multiple Google Analytics properties
If you have a single GTM container installed on multiple domains but you're tracking them across different Google Analytics properties, you want to ensure that you're sending the data to the correct one.
Instead of having multiple variables to store different property IDs, you can have them all neatly in the same table defined by the hostname.
This way any tracking activity on each site will go to its own dedicated property.
Excluding test or other data
If you want to make sure that any data outside of your main site goes to a test or other Google Analytics property, you can do so by setting the default value.
The default value is the output that is not found in the table. With this setup, any activity tracked on www.mainsite.com goes to property ID UA-121212.
If the activity wasn't on www.mainsite.com, then it sent to property ID UA-121212-2.
Use lookup tables for something else? Confused? Get in touch or comment below!

Events in Google Analytics are important for understanding how people interact with your website. They give you additional insight into their behaviour and how effective your pages are for leading users towards a conversion.
With event tracking you could see how many users clicked on a button or played a video, scrolled down a page or clicked on your contact and social media icons.
I mostly use Google Tag Manager (GTM) for analytics setup so I will show how to set up event tracking for clicks on buttons with GTM. Instead of hard coding events in the code, GTM allows you to create, test and amend tags within its interface.
Before you go ahead creating your event tags, make sure your built-in pages and clicks variables are enabled. This will avoid you having to go back and forth between different sections.
The setup below covers only one action - a click on a specific button - but if you have multiple actions to track, then look into implementing a lookup table variable.
Tracking button clicks
Here's my scenario.
I want to track our BENCHMARK YOUR SITE button that allows users to sign up to our free software plan and get benchmarked against competitors.
And here's how to set it up.
1. Create a tag
It will be a Universal Analytics tag type where tracking ID is a constant string variable (you need to create this variable before using it) and track type 'Event'.
Think of your event tracking parameters as a way to organise the events into a hierarchy:
Category – the main aim of the button or its placement
Action – what the user clicked or the action
Label – provides additional information like on what page the button was clicked or the outbound link they clicked on
Value – if you have a numerical value to set for your click (not in my case tho)
In my example, the category is ‘Get started’ because we have a number of similar buttons across the site with the same purpose to get the user started with the signup, so all of them have the same event category.
For action, I specify the type of button that was clicked on so I can compare how these different buttons perform - 'Benchmark your site' in this case.
My event label is the {{Page Path}} where they clicked on the button. The buttons take the user to the same place so I’m more interested in which pages these buttons were clicked on. Alternatively, if you have buttons that take people to different URLs you might want to track that instead.
Is it a non-interaction hit?
This is an important one to keep in mind.
By default this is set to False. If you don’t want this event to impact your bounce rate, then change it to True, which you would do if the click or action didn’t take the user to the new page, or if you didn't want it to be included in your bounce rate calculations.
Now click 'Continue' to go to the trigger setup.
2. Create a trigger
Trigger is like a rule that allows you to tell the tag, ie specify the conditions, when it should fire.
Under 'Fire On' select ‘Click’ as your trigger type and then ‘New’.
For configuring the trigger, you have a choice between two types:
Just Links – use this when the target is a link or anchor tag <a>
All Elements – use this when the target is any other element that’s not a link
To determine what’s best for your purposes you need to have a look at how your button is set up. You can do this by selecting ‘inspect element’ or simply ‘inspect’ depending on what browser you’re using. It’s usually available when you right click on the button or element.
Our button has been set up the following way:
<a href="https://littledata.uk/signup" class="btn btn-ltd btn-green">benchmark your site</a>
It has a link so I will use 'Just Links' for targets and I have a choice between three elements to use in further configuration:
https://littledata.uk/signup as click url
btn btn-ltd btn-green as click class
benchmark your site as click text
It is best to use a unique condition if you can. This way, if similar class or click url gets reused in other parts of the website you don't have to go back to this trigger to update it.
With 'Just Links' you will get additional configuration options:
Wait for tags - delays opening of links until all other tags have fired or the wait time has lapsed, whichever happens first
Check validation - fires the tag only when opening the link was a valid action, without the tag will fire whenever the user clicks on the button/link
Enable when - this options is shown only when either of the above is ticked so you can be specific about where you want the trigger to be active
If you want the trigger to listen to the interactions on all pages, then set that section to be URL or Page Path matches regex .*. (without that very last full stop - that one's for the sentence)
In my case, I only want it to work on benchmark pages and all of them start with /benchmark/.
The very last step in trigger setup is specifying on which actions or clicks the tag should fire.
As said above, I'm using the button's click class here.
All done?
This is what your tag should now look like.
Click 'Create Tag'.
3. Test
Test your tag in GTM's preview mode by checking two things:
the tag fires in the preview interface,
and the tag is seen in Google Analytics real time view under 'Events' with the event parameters you specified
I hope you got on with the setup above just fine, but if you have questions or clarifications, feel free to ask below.
Further reading:
Know who converts on your site with Google Analytics goals
Using lookup table variable in Google Tag Manager
Intro to Google Tag Manager's key concepts and terminology
Image: Courtesy of suphakit73 at FreeDigitalPhotos.net

Demographics and interests reports in Google Analytics give you additional insight about your users, allowing you to do analysis based on age, gender and interest categories. You get a much better idea of who your users are and the setup is so quick to do, there's no reason not to.
To get this information, you need to do minor tweaks to your Google Analytics and Google Tag Manager. Those changes will allow Google to share anonymised data about your site or app visitors, and once set up, you can use this information to understand the behaviour patterns of your users by different profiles.
You will be able to see:
If a particular age group converts more
Whether you get more visits from males or females from a particular country or city
If your users are more into travelling, movies or social media
You'll also be able to:
Build remarketing lists
Build segments for more detailed information about your users
Target your ads to specific users
What reports will you get?
Demographics Overview: snapshot view of your users by age and gender
Age: Acquisition, Behaviour and Conversions metrics by age group (below 18 are not included)
Gender: Acquisition, Behavior and Conversions metrics by gender
Interests Overview: top 10 interests of your users in 3 areas: Affinity Categories, In-Market Segments and Other Categories
Affinity Categories (reach): view of users by their lifestyle with Acquisition, Behaviour and Conversions metrics broken down by Affinity Categories
In-Market Segments: view of users by their product-purchasing interests with Acquisition, Behaviour and Conversions metrics broken down by In-Market Segments
Other Categories: more specific view of users with Acquisition, Behaviour and Conversions metrics broken down by Other Categories
How does Google get this data?
Google collects demographics and interests data from the third-party DoubleClick cookie for web traffic and anonymous identifiers for mobile app activity, like the Android Advertising ID and the iOS Identifier for Advertisers.
But Google is unable to collect this data if the cookie or anonymous identifier isn't present, or if there's no profile information available. As a result, this data may only be available for a subset of your users. This will be shown on the report as a % of traffic the report represents.
When is threshold applied?
There are occasions when data is withheld from your reports to ensure the anonymity of users. For example, this might happen when you don’t have enough data for a particular age range or gender.
When the threshold has been applied, you will see a notification below the report title.
3 simple steps to set this up
1. Enable the feature in Google Analytics
Go to Admin > Property > Property Settings.
Scroll down to Advertising Features, and set the option to Enable Demographics and Interests Reports to ON.
Now save.
2. Enable the feature in Google Tag Manager
Go to edit your GA pageview tag > Configure Tag.
Under the tracking ID, tick the Enable Display Advertising Features box.
Save the tag, and you've got one last step to do.
3. Enable the report in Google Analytics
For this go to Audience > Demographics > Overview report.
Click Enable, and you're all set.
You should see your demographics and interests data within 24 hours of enabling the feature.
We also provide consultancy services if you need help with more advanced setup.
Further reading:
Tracking registered users with Google Analytics and GTM V2
How to use demographic targeting in AdWords

Wondering if Samsung Galaxy is more popular than iPhone when engaging with your content? Then set up the User-ID view to see your logged in users’ activity and evaluate behaviour by the device.
With the activity data you collect in the registered users view, you can improve the analysis of your customers' behaviour by seeing which devices are used to sign up and access your website.
To summarise the benefits:
You get access to the Cross-Device reports, which allow you to analyse which devices your users use to engage with your content. See what the Cross-Device reports look like.
You improve your understanding of logged in users who often engage with the site's content differently than those who aren't registered.
You get a more accurate user count. In your standard analytics view, a new user is counted every time your site visitor switches to a new device or starts a new session. With the registered user view, you give each user a unique ID, which helps to stitch together various activities carried out by the user.
You can find out which devices users prefer for different engagement activities across multiple sessions. This helps with tailoring your campaign and content to different devices and activities.
To set this up, you need to have the user ID stored in the data layer. If you don't have it set up, scroll to the bottom for an advanced hack.
Now let’s look at how to set up the tracking by using Google Analytics and Google Tag Manager V2.
Looking to implement the User-ID in your tracking code?
Check Google’s guidance.
Enable the feature in Google Analytics
Firstly, enable the User-ID feature by going to Admin > Property > Tracking info > User-ID.
Read through the short policy on what you’re allowed to track and not.
Google is very strict about tracking personally identifiable information so you are not allowed to send any personally identifiable information, such as names and email addresses. But numbered IDs or hashed emails are fine to use.
To agree to the terms, follow the steps and click ‘create.’
Create the variable in Google Tag Manager
Now go to GTM variables and click 'new'.
Select Data Layer Variable type and use the name stored in your data layer, e.g. uid or user ID
Add the variable to your pageview tag
Go to edit your pageview tag and click on More settings > Fields to set.
Click Add field, enter the field name as &uid and select the variable you’ve just created - eg {{uid}} or {{userID}}.
Test you're seeing activity in the newly created registered users view with your login, or a test one if you have it.
Don't forget to publish your GTM container for tracking to work.
Advanced hack
If for some reason you can't get your developer to store a user ID in the data layer, there is a way around it.
We've created a javascript variable to get a username off the page and hash it prior to sending it to GA.
For this, you need to pick a custom Javascript type variable and enter the script below into the custom javascript field.
This javascript requires either your developer or you to customise it to work on your page (see the notes in the second and third lines).
function() {
//dependent on using Jquery selectors
//replace '.menuTitle small a' with the selector for your username
var name = $('.menuTitle small a').text();
var hash = 0, i, chr, len;
if (name.length == 0) return hash;
for (i = 0, len = name.length; i < len; i++) {
chr = name.charCodeAt(i);
hash = ((hash << 5) - hash) + chr;
hash |= 0; // Convert to 32bit integer
}
return hash;
};
If you need help with any of the above, don't hesitate to comment below or get in touch!

Do you know how many people start completing forms on your website, but don't complete them? Do you know which fields cause them difficulties? This is a guide to field-by-field form tracking using GTM.
By tracking each element of the form separately, you will see how many people start filling out the form but then decide not to submit it.
Once you understand where people drop off you will be able to identify any parts of the form that may need improving.
The enquiry form on our website has four elements that I am going to track: the name, email and subject fields, and the button to submit the query.
In summary, the set up will work like this:
Create a trigger that will act as the firing rule for the tag
Create a tag to track clicks on the field
Repeat for each field
So to set up the tracking of form fields and submits in GTM V2, follow these steps.
Enable built in variables
Firstly, you will need to enable built in variables.
You will need Form ID variable and if similarly to our site you have the same enquiry form placed on several pages, then Page Path variable as well.
These variables will allow you to track clicks on the form and on which pages the form was clicked on.
The page path variable returns the URL part that comes after your main domain, eg /blog.
Create the trigger
For your trigger, you will need to find out the field ID you want to track.
To find out the ID, if you are using Chrome browser, right-click on the field and select ‘Inspect Element’
It will look something like id=”name” so name here is the unique ID that you need to use with the trigger.
If you do not have a unique ID associated with the field you want to track, ask your developers to add it in. This will make the tracking much easier.
Now in GTM, go to Triggers tab on the left and click 'New'. You are creating a 'click' trigger, which you want to fire on 'all elements'.
Save the trigger.
Create the tag
Go to Tags tab and click 'New'.
Select Google Analytics and tag type 'Universal Analytics'.
I send the following event tracking parameters to GA:
Category: Enquiry form
Action: Click on name
Label: {{Page Path}}
Now select 'Click' to select the trigger ‘Click on name’ as your firing rule.
If there are any pages where you don’t want this tracked, then you will need to create a separate blocking trigger.
Here is an example of a trigger for a contact us page that I want to exclude from tracking here.
You can create your blocking trigger in a pop up window without leaving the tag.
Repeat
Follow the steps above to create the trigger and tag for each following field, and amend form ID’s and event field values for each.
Test your tags in GTM debug mode and GA real time to make sure the details sent through are what you want.
Once tested, publish your container and if you need any further help with any of the above, leave a comment below.
Further reading:
How to track file downloads in Google Tag Manager V2
Tracking registered users with Google Analytics and GTM V2

Setting up tracking of file downloads in GTM V2 is much easier thanks to the new configuration wizard. It is more intuitive and takes you through the set up step-by-step.
Let’s have a look at the basic configuration for sending tracking of file downloads from Google Tag Manager to Google Analytics as events.
To set up this events tag you need to firstly create a trigger.
Create a trigger
This trigger will recognise every time someone clicks to download the file you want to track.
In the given example I am using a simple regular expression to capture a number of file types I want to track -.(zip|exe|pdf|doc*|xls*|ppt*|mp3)$
Here the * means it will capture any repetitions of the file types it is next to, ie it will include file types doc and docx for Word documents, xls and xlsx for Excel spreadsheets, ppt and pptx for PowerPoint presentations.
Save the trigger and create a new tag.
Create a new tag
Give your tag a meaningful name so you can easily recognise what the tag is for.
We have previously created a variable (formerly known as macro) that stores our GA tracking code, which I use in the configuration settings.
This way I do not have to re-enter the GA property ID every time I need it. This variable does all the work.
Select your track type as 'Event' and insert your tracking parameters.
Here I use the following but modify the fields based on what works for your business:
Category is Download
Action is Click
Label is {{element url}
Element url in the label field will store the URL of the file that was downloaded.
Advanced tracking
For advanced tracking, you can create a custom javascript variable with a code that will strip out the title of the downloaded file and store it in your GA. Have a look at Simo's example of returning file name.
Set your tag to fire
Last step is to add a firing rule, ie select a trigger that will fire your tag.
Select the previously created trigger 'Click to Download' and you're all set.
Test
For extra care, test the tag both in GTM debug mode and GA real time.
Publish
Now publish the container with your newly created tag.
If you need any further help, do leave a comment below.
Further reading:
Tracking registered users with Google Analytics and GTM V2
Tracking web forms in Google Tag Manager V2

Most companies will see a discrepancy between the transaction volumes recorded via web analytics and those recorded via internal sales or financial database. This article focuses on how to find and reduce that discrepancy, to give greater credibility to your web analytics data.
Following on from our article on common Google Analytics setup problems, we are often asked why Google Analytics ecommerce tracking is not a 100% match with other records, and what is an acceptable level of difference.
Inspired by a talk from Richard Pickett at Ensighten, here is a checklist to run through to reduce the sources of mismatch. The focus here is Google Analytics Ecommerce tracking, but it could apply to other systems.
In summary, you wouldn’t ever expect there to be a 1:1 match, due to the different paths the two events take over the internet. The general consensus is that anything less than 4% of difference in transaction volumes is good, but could sometimes persist up to 10%.
Factors that affect this target rate include how many users have got ad blockers or disable Google Analytics (popular in Germany, for example), what proportion are on mobile devices (which suffer from more network interruptions) and how the purchase thank you / confirmation page is built.
So on to the list.
1. Are other Javascript errors on the page blocking the ecommerce event in certain situations?
The most common reason for the tracking script not executing in the browser is that another bug on your page has blocked it (see GDS research). The bug may only be affecting certain older browsers (like Internet Explorer 7), and have missed your own QA process, so the best approach is to use Google Tag Manager to listen for any Javascript error events on the confirmation page and send these to Google Analytics as custom events.
That way your users do the testing for you, and you can drill into exactly which browsers and versions the bugs are affecting.
2. Is the tracking code as far up the page as it could be?
If the user drops their internet connection before the whole page loads then the ecommerce event data won’t get a chance to fire. The best approach is to load the script at the bottom of the <head> element or top of the <body>. The Google Analytics script itself won't block the page load, and arguably in this one purchase confirmation page, the tracking is more important than the user experience.
3. Is the tracking code firing before all the page data has loaded?
The inverse of the previous problem: you may need to delay firing the tracking code until the data is ready.
This is particularly an issue if your ecommerce transaction data is ‘scraped’ from the HTML elements via Google Tag Manager. If the page elements in question have not loaded before the ecommerce tracking script runs, then the product names, SKUs and prices will be empty – or returning an error.
4. Is the problem only your ecommerce tracking script or just page tracking is general?
It could be that the way you are sending the transaction data (e.g. product name, price, quantity) is the problem, or that the page tracking overall is failing in some cases. You can pinpoint where the problem lies by comparing the pageviews of the confirmation page, with the number of ecommerce events tracked.
Caveat: on many sites, there’s another route to seeing the purchase confirmation page, which doesn’t involve purchasing (for example as a receipt of a historic purchase). In that case, you may need to capture a unique purchase event, which only fires when a new purchase is confirmed – but without any information on the transaction or products.
5. Are events from your test site excluded?
Most companies will have a development, staging or user acceptance testing server to where the website is tested, and test users can purchase. Are you blocking the tracking from these test sites?
Some possible ways to block the test site(s) would be:
Set up sub-domain specific blocking rules in Google Tag Manager
(or better) Divert the tracking from your test subdomains to a test Google Analytics account, using a lookup macro/variable
Set up filters in the Google Analytics view to exclude
6. Is your tag set with a high priority?
Tag manager only.
If you use Google Tag Manager and have multiple tags firing on the tracking page it’s possible that other tags are blocking your ecommerce data tag from firing. Under ‘Advanced settings’ in the tag editor, you can set a higher priority number for tag firing; I assume the ecommerce data to Google Analytics is always the first priority.
7. Are any strings in the product name properly escaped?
A common problem is apostrophes: if your product name contains a quote mark character, then it will break the following Javascript. See Pete’s bunnies – the strings in yellow are valid, and everything after the stray apostrophe will be misinterpreted.
The solution is to run a script across any text field to either strip out the quotation marks or replace any quotes with their HTML equivalent (eg &quot;).
8. Are your quantities all integers?
One of our clients was selling time slots, and so had the ‘quantity’ of the ecommerce tracking data equivalent to a number of hours. Timeslots sold in half-hours (e.g. 1.5 hours) were not tracking… because Google Analytics only recognises a quantity which is a whole number, so sending ‘1.05’ will not be recognised as 1.
9. Are any possible ‘undefined’ values handled?
It may be that the data on your products is incomplete, and some products that people buy do not have a name, price or SKU.
The safest approach is to have some fall-back values in your Javascript tracking code to look for undefined or non-text variables and post a default value to Google Analytics. E.g. If ‘product name’ is undefined then post ‘No product name’, or for price, the default should be ‘0.00’.
These will then clearly show up in your Ecommerce Product performance reports and the data can be cleaned up.
10. Are users reloading the page and firing duplicate tracking events?
Check whether this is a problem for your site by using our duplicate transactions custom report to see multiple events with the same transaction ID.
A solution is to set a ‘has tracked’ cookie after the ecommerce tracking has been sent the first time, and then check whether the cookie is set before sending again.
11. Are users going back to the page and firing the tracking at a later date?
The sessions column in the transactionID report in step 9 should give you an idea of whether the problem is repeat page loads in one session, or users revisiting the page in another session.
If you see duplicate transaction IDs appearing in other sessions there are a couple of possibilities to investigate:
Could users be seeing the page again by clicking on a link to an email, or from a list of historic orders?
Are there any back-end admin pages that might link to the confirmation page as a receipt?
In both cases, the solution is to have a different URL for the receipt that the one where the ecommerce tracking is fired.
If there are any other troubleshooting steps you have found helpful, please let us know in the comments or get in touch!