Enhanced ecommerce tracking for travel booking sites

Every online business presence has a goal. These goals (bookings, donations, subscribers, events, or purchases) are the reason for our efforts. But how many of us really track how our goals really perform? In this article, you will find out how to take these business goals and track them on Google Analytics with an ecommerce approach. This article is not about how to set up goals in Google Analytics, but if you are interested in finding out more about the setup or what there are, then read: Setting up a destination goal funnel in Google Analytics. The advantage of using an ecommerce approach for non-ecommerce websites is that after the setup is done, you have a basis to develop correct marketing strategies. You will know what channels brings you money, you will know what channels interact with each other and you can adjust your budget to maximise the ROI. If you're in the business of selling tickets (planes, concerts, conferences), book medical exams or collect donations, this article concerns you! I will show you a step-by-step guide on where to implement the Enhanced Ecommerce features and I will provide links for each to find out how to implement them. Let's say you are Wizz Air. You sell flight tickets and book cars and so on. Promotion impressions and promotion clicks Each time Wizz Air displays a banner with some kind of marketing communication that banner can be tracked as a "promotion" in Google Analytics. In Google Analytics, you can see the performance of each banner and make decisions to replace them, change the order or even make them bigger based on the tracking you implement. The technicalities: implementing via Google Tag Manager or implementing via Google Analytics. After you implement the tracking and create the tags (for GTM) you will be able to see the data in Google Analytics under Ecommerce > Marketing > Internal Promotions Based on the position, click-thru-rate, and revenue gained for each, Wizz Air can then rearrange banners, eliminate some of them or boost their visibility. Ecommerce activities (catalogue views, service page views, click on call to actions) Wizz Air provides multiple sections on the website where you can search for flights. These sections can be mapped as product lists. For WizzAir, the product lists are in the homepage section, timetable section, and maps section. Typically, Google Analytics and Google Tag Manager requests the fields below when sending a product list view (product impressions). I will provide you with a schema that will capture the flight booking particularities but you can use your own business specific examples. When you click on a red point on the map, the customer can see the flights from a particular city. We will send all the flight information from that city as product impressions. 'id': 'LTN - PRG',                          // The departure airport code - The arrival airport code 'name': 'London Luton - Prague',             // City name of departure - City name for arrival 'category': 'Flight',                        // WizzAir offers flight booking along with car booking, and hotel booking 'brand': 'WizzAir',                          // If this would be a tourism agency instead of WizzAir will be other company. 'variant': '010117',                      // If the page has the option to add the date we will add the date as a MMDDYY When the search button is present, you send the action "click". ga('ec:setAction', 'click', {                                    // click action. 'list': 'Maps'                                                          // Product list (string). }); After searching, the client can see the selection page from the product list. For Wizz Air customers, they can search the best price and see the package options. In the case of Wizz Air, these pages can be considered the product pages. The usual structure that needs to be sent to Google Analytics and Google Tag Manager is: 'id': 'LTN - PRG',                                    // The departure airport code - The arrival airport code 'name': 'London Luton - Prague',          // City name of departure - City name for arrival 'category': 'Flight',                                 // WizzAir offers flight booking along with car booking, and hotel booking 'brand': 'WizzAir',                               // If this would be a tourism agency instead of WizzAir will be other company. 'variant': '010117',                             // If the page has the option to add the date we will add the date as a MMDDYY Each time the client changes the day a new detail view should be sent. Clicking on the price box will trigger an Add to cart action. The usual content of an Add To cart activity is: 'name': 'London Luton - Prague',    // The departure airport code - The arrival airport code 'id': 'LTN - PRG',                               // City name of departure - City name for arrival 'price': '61.99',                                  // Selected price for the flight 'brand': 'WizzAir',                          // If this would be a tourism agency instead of WizzAir will be other company. 'category': 'Flight',                        // WizzAir offers flight booking along with car booking, and hotel booking 'variant': '010117',                         //If the page has the option to add the date we will add the date as a MMDDYY 'quantity': 1'                                   // Person number 'dimenstion1': 'LTN13432',           // Flight number 'dimenstion2': 'WizzGO'              // Package option (Basic, Wizz Go, Wizz Plus) Check out steps and booking In the case of Wizz Air, each "continue" button will send a checkout step to Google Analytics. Sending the checkout steps will provide insights about where the customers drop off and what process steps can be improved. Wizz Air has a 4-steps checkout (choose flight, choose passengers, services, and payment). The final thing to send is the transaction (the booking). The structure and implementation details for Google Analytics and Google Tag Manager are in the links and the fields, in this case, will be: 'ecommerce': { 'purchase': { 'actionField': { 'id': 'T12345',                                           // Transaction ID. Required for purchases and refunds. 'affiliation': 'booking.com'                    // Affiliation agent, 'revenue': '35.43',                                 // Total booking value (incl. tax, airport fees etc) 'tax':'4.90', 'shipping': '5.99',                                 //can use this field to capture airport fees or thir party operators fees 'coupon': 'SUMMER_SALE'              //if a discount cupon was used }, 'products': [{                                      //if the flight has a return flight then two products will be sent 'name': 'London Luton - Prague',     // The departure airport code - The arrival airport code 'id': 'LTN - PRG',                                // City name of departure - City name for arrival 'price': '61.99',                                  // Selected price for the flight 'brand': 'WizzAir',                           // If this would be a tourism agency instead of WizzAir will be other company. 'category': 'Flight',                         // WizzAir offers flight booking along with car booking, and hotel booking 'variant': '010117',                          //If the page has the option to add the date we will add the date as a MMDDYY 'quantity': 1'                                   // Person number 'dimenstion1': 'LTN13432',           // Fligh number 'dimenstion2': 'WizzGO'               // Package option (Basic, Wizz Go, Wizz Plus) 'coupon': 'SUMMER_SALE'         // Optional fields may be omitted or set to empty string. }, { 'name': 'Prague -London Luton',    // The departure airport code - The arrival airport code 'id': 'PRG -LTN',                               // City name of departure - City name for arrival 'price': '61.99',                                 // Selected price for the flight 'brand': 'WizzAir',                           // If this would be a tourism agency instead of WizzAir will be other company. 'category': 'Flight',                         // WizzAir offers flight booking along with car booking, and hotel booking 'variant': '150117',                        //If the page has the option to add the date we will add the date as a MMDDYY 'quantity': 1'                                   // Person number 'dimenstion1': 'LTN2143432',        // Flight number 'dimenstion2': 'WizzGO'             // Package option (Basic, Wizz Go, Wizz Plus) 'coupon': 'SUMMER_SALE'        // Optional fields may be omitted or set to empty string. }] } } Sending all these steps to Google Analytics about the customer activity, on any kind of website, will provide you with information about return on marketing spends, improve page layout performance, improve conversion rate, find out insights about customer needs and a lot more. Having the full enhanced ecommerce setup is very powerful and can bring many advantages. You can test the full setup on the Google Analytics demo account. Have any questions or need some help? Please get in touch or comment below!  

2017-01-24

How to track your newsletter performance with Google Analytics - part 1

Newsletters are the most common form of digital marketing I have seen in the past years. I really don't know any website that doesn't send at least 1 newsletter a month, whether it's an ecommerce website, news website or a B2B presentation website. There are a lot of email marketing platforms, but the question is how profitable are these newsletters? Most platforms provide some form or analysis on the performance of each newsletter. Most providers can show you the numbers of emails sent, the number of users that opened your newsletter and the number of clicks in the email. Along with Google Analytics, you can see how impactful these newsletters are. I want to show you some hacks to dive deeper in analysing each part of your newsletter and improve your newsletter marketing. Analyse each section in the newsletter separate Most of the newsletter that I saw had several links in them so the best way to track them is to tag each link in a distinctive way using the Campaign Content parameter (utm_content). If you do not know what UTM parameters are, please take a moment to read this article: Why should you tag your campaigns? Using the blog post above create your tagged link and add the &utm_content=link1 OR &utm_content=second banner OR &utm_content=Discount banner (whatever works best for you when analysing the data) at the end. Here is an example: http://www.littledata.ro/?utm_source=newsletter&utm_medium=email&utm_campaign=20%25off&utm_content=banner1 Here is a newsletter as part of a campaign named: "black friday2" with 3 banners in it. You can see from the data bellow that the top banner had the most clicks, but, in fact, the second banner is the only one that converted. This means that in the future we should move the second banner as a primary banner to have a higher visibility and in this way increase the number of transactions. You can tag all your links in the newsletter (the logo, banners, hyperlinks, products and so on) And see how each section is performing and what is driving the customers to click in the email. In a real email marketing platform, I strongly recommend searching the provider blog to see if they already support this in any way. Here is MailChimp solution for tracking the newsletter performance in Analytics. If the platform you are using does not support Google Analytics at the moment you can just build the URL with Google's URL builder or our simple Littledata URL builder and add it as you normal do in the newsletter. Track users on how they get on your website from a particular newsletter We've tested some hypotheses and the first one is to make a group of users in Google Analytics that come from a newsletter. The standard way is just to tag the newsletter with UTM parameters and create an audience based on that traffic. But to be more precise and go further with the analysis, we can add a new UTM parameter to all the links in the newsletter that contained the User ID. So now this traffic is not random but it's from a customer we've engaged with already and I do have historical data. The benefit of doing so is that, in an era of mobile devices and cross-device interactions, people read newsletters on the move and react or buy on different devices at different times as a result of the same campaign. You, as a marketer need to understand the cross-device movement and so I recommend that you read about this in the blog post: User Tracking To be able to track the activity of each individual user in your newsletter, you need to build a URL with a User ID parameter in it. This step is similar to the one before so you can add on to the URL you already built for your banners and add the unique identifier number of each client like this: http://www.mywebsite.com/?utm_source=newsletter&utm_medium=email&utm_campaign=20%25off&userID=3D12345 The User ID is generated by the platform you're using, so please take your time and find out if your email marketing solution supports this, along with the email address you've imported and the User Id from your back end. We use Intercom, where you can just add it into the link with a simple click, like this: The platform you're using might be different but if there is an option to import the User Id along with the email address then it is likely that your platform supports this in some way. Once you've added this to the URL, you can then set up a URL variable in Google Tag Manager to pick it up and set up a field with the pageview that will be sent to Google Analytics. For more information, here's how to set a field in Google Tag Manager. Be sure to check back next week for part 2! If you have any questions or would like more help, please get in touch with one of our experts!   Get Social! Follow us on LinkedIn, Twitter, and Facebook and keep up-to-date with our Google Analytics insights.

2017-01-12

Online reporting: turning information into knowledge

Websites and apps typically gather a huge flow of user behaviour data, from tools such as Google Analytics and Adobe Analytics, with which to better target their marketing and product development. The company assumes that either: Having a smart web analyst or online marketer skim through the reports daily will enable management to keep tabs on what is going well and what aspects are not Recruiting a ‘data science’ team, and giving them access to the raw user event data, will surface one-off insights into what types of customers can be targeted with which promotions Having worked in a dozen such companies, I think both assumptions are flawed. Humans are not good at spotting interesting trends, yet for all but the highest scale web businesses, the problem is not really a ‘big data’ challenge. For a mid-sized business, the problem is best framed as, how do you extract regular, easy-to-absorb knowledge from an incomplete online behavioural data set, and how do you present / visualise the insight in such a way that digital managers can act on that insight? Littledata is meeting the challenge by building software to allow digital managers to step up the DIKW pyramid. The DIKW theory holds that there are 4 levels of content the human mind can comprehend: Data: the raw inputs; e.g. the individual signals that user A clicked on button B at a certain time when visiting from a certain IP address Information: provides answers to "who", "what", "where", and "when" questions Knowledge: the selection and synthesis of information to answer “how” questions Wisdom: the extrapolation or interpretation of this knowledge to answer “why” questions Information is what Google Analytics excels at providing an endless variety of charts and tables to query on mass the individual events. Yet in the traditional company process, it needs a human analyst to sift through those reports to spot problems or trends and yield genuine knowledge. And this role requires huge tolerance for processing boring, insignificant data – and massive analytical rigour to spot the few, often tiny, changes. Guess what? Computers are much better at the information processing part when given the right questions to ask – questions which are pretty standard in the web analytics domain. So Littledata is extending the machine capability up the pyramid, allowing human analysts to focus on wisdom and creativity – which artificial intelligence is still far from replicating. In the case of some simpler insights, such as bounce rates for email traffic, our existing software is already capable of reporting back a plain-English fact. Here’s the ‘information’ as presented by Google Analytics (GA). And here is the one statistically significant result you might draw from that information: Yet for more subtle or diverse changes, we need to generate new ways to visualise the information to make it actionable. Here are two examples of charts in GA which are notoriously difficult to interpret. Both are trying to answer interesting questions: 1. How do users typically flow through my website? 2. How does my marketing channel mix contribute to purchasing? Neither yields an answer to the “how” question easily! Beyond that, we think there is huge scope to link business strategy more closely to web analytics. A visualisation which could combine a business’ sales targets with the current web conversion data, and with benchmarks of how users on similar sites behave, would give managers real-time feedback on how likely they were to outperform. That all adds up to a greater value than even the best data scientist in the world could bring. Have any questions? Comment below or get in touch with our team of experts! Want the easier to understand reports? Sign up!   Get Social! Follow us on LinkedIn, Twitter, and Facebook and keep up-to-date with our Google Analytics insights.

2016-12-12

Android users buy 4x more than Apple users. Why?

Looking at a sample of 400 ecommerce websites using Littledata, we found mobile ecommerce conversion rates vary hugely between operating systems. For Apple devices, it is only 1% (and 0.6% for the iPhone 6), whereas for Android devices the conversion rate is nearly 4% (better than desktop). It’s become accepted wisdom that a great ‘mobile experience’ is essential for serious online retailers. As 60% of all Google searches now happen on mobile, and over 80% of Facebook ad clicks come from mobile, it’s highly likely the first experience new customers have of your store is on their phone. So is it because most websites look worse on an iPhone, or iPhone users are pickier?! There’s something else going on: conversion rate on mobile actually dropped for these same sites from July to October (1.25% to 1.26%) this year, even as the share of mobile traffic increased. Whereas on desktop, from July (low-season) to October (mid-season for most retailers), the average ecommerce conversion rate jumped from 2% to 2.5%. It seems during holiday-time, consumers are more willing to use their phones to purchase (perhaps because they are away from their desks). So the difference between Android and iOS is likely to do with cross-device attribution. The enduring problem of ecommerce attribution is that it’s less likely that customers complete the purchase journey on their phone. And on an ecommerce store you usually can’t attribute the purchase to the initial visit on their phone, meaning you are seriously underestimating the value of your mobile traffic. I think iPhone users are more likely to own a second device (and a third if you count the iPad), and so can more easily switch from small screen browsing to purchase on a large screen. Whereas Android users are less likely to own a second device, and so purchase on one device. That means iPhone users do purchase – but you just can’t track them as well. What’s the solution? The only way to link the visits on a phone with the subsequent purchases on another device is to have some login functionality. You can do that by getting users to subscribe to an email list, and then linking that email to their Google Analytics sessions. Or offering special discounts for users that create an account. But next time your data tells you it’s not worth marketing to iPhone users, think again. Need help with your Google Analytics set up? Comment below or get in touch!   Get Social! Follow us on LinkedIn, Twitter, and Facebook and keep up-to-date with our Google Analytics insights.  

2016-11-02

Making the detection of significant trends in your traffic easier to see

Our core belief at Littledata is that machines are better at spotting significant changes in your website’s performance than a human analyst. We’ve now made it easier for you to get specific alerts, reducing the time spent wading through data. This is the story of how we produced the new trend detection algorithm. Enjoy! Back in 2014, we developed the first version of an algorithm to detect if today or this week’s traffic was significantly different from previous periods. This allows managers to focus in on the aspects of the traffic or particular marketing campaigns which are really worthy of their attention. Although the first version was very sensitive, it also picked up too many changes for a single person to investigate. In technical language, it was not specific in enough. In June and July, Littledata collaborated with a working group of mathematicians from around Europe to find a better algorithm. The European Study Group with Industry (ESGI) originated in the University of Limerick’s mathematics department in Ireland and has helped hundreds of businesses link up with prominent mathematicians in the field to solve real-world problems. Littledata joined the latest study group in University College, Dublin in July, and was selected by a dozen mathematicians as the focus for their investigation. Andrew Parnell from the statistics department at University College, Dublin helped judge the output from the four teams that we split the group into. The approach was to use an algorithm to test the algorithms; in other words, we pitted a group of statistical strategies against each other, from clustering techniques to linear regression, through to Twitter’s own trend detection package, and compared their total performance across a range of training data sets. Initially, the Twitter package looked to be doing well, but in fact, it had been developed specifically to analyse huge volumes of tweets and perform badly when given low volumes of web traffic. In between our host’s generous hospitality, with Guinness, Irish folk music, and quite a lot of scribbling of formulas on beer mats, myself and our engineer (Gabriel) worked with the statisticians to tweak the algorithms. Eventually, a winner emerged, being sensitive enough to pick up small changes in low traffic websites, but also specific enough to ignore the random noise of daily traffic. The new trend detection algorithm has been live since the start of August and we hope you enjoy the benefits. Our web app allows for fewer distractions and more significant alerts tailored to your company’s goals, which takes you back to our core belief that machines are able to spot major changes in website performances better than a human analyst. If you’re interested in finding out how our web app can help you streamline your Google Analytics’ data, please get in touch! Further reading: 7 quick wins to speed up your site analysis techniques Online reporting turning information into knowledge Will a computer put you out of a job?

2016-09-08

How to use Enhanced Ecommerce in Google Analytics to optimise product listings

Ecommerce reporting in Google Analytics is typically used to measure checkout performance or product revenue.  However, by analysing events at the top of the funnel, we can see which products need better images, descriptions or pricing to improve conversion. Space on product listing pages is a valuable commodity, and products which get users to click on them – but don’t then result in conversion – need to be removed or amended.  Equally, products that never get clicked within the list may need tweaking. Littledata ran this analysis for a UK retailer with Google Analytics Enhanced Ecommerce installed.  The result was a scatter plot of product list click-through-rate (CTR) – in this case, based on the ratio of product detail views to product listing views – versus product add-to-cart rate.  For this retailer, it was only possible to buy a product from the detail page. We identified three problem categories of product, away from the main cluster: Quick sellers: these had an excellent add-to-cart rate, but did not get enough list clicks.  Many of them were upsell items, and should be promoted as ‘you may also like this’. Poor converters: these had high click-through rates, but did not get added to cart. Either the product imaging, description or features need adjusting. Non-starters: never get clicked on within the list. Either there are incorrectly categorised, or the thumbnail/title doesn’t appeal to the audience.  They need to be amended or removed. How we did it Step 1 - Build a custom report in GA We need three metrics for each product name (or SKU) - product list views, product detail views and product add to carts - and then add 'product' as a dimension. Step 2 - Export the data into Excel Google Analytics can't do the statistical functional we need, so Excel is our favoured tool.  Pick a decent time series (we chose the last three months) and export. Step 3 - Calculate List > Detail click through This website is not capturing Product List CTR as a separate metric in GA, so we need to calculate as Product Detail Views divided by Product List Views.  However, our function will ignore products where there were less than 300 list views, where the rate is too subject to chance. Step 4 - Calculate Detail > Add to Cart rate Here we need to calculate Product Adds to Cart divided by Product Detail Views.  Again, our function will ignore products where there were less than 200 detail views. Step 5 - Exclude outliers We will use an upper and lower bound of the median +/- three standard deviations to remove improbable outliers (most likely from tracking glitches). First we calculate the median ( =MEDIAN(range) ) and the standard deviation for the population ( =STDEV.P(range) ).  Then we can write a formula to filter out all those outside of the range. Step 6 - Plot the data Using the scatter plot type, we specify List > Detail rate as the X axis and Detail > Add to Cart as the Y axis. The next step would be to weight this performance by margin contribution: some poor converters may be worth keeping because the few sales they generate are high margin. If you are interested in setting up Enhanced Ecommerce to get this kind of data or need help with marketing analytics then please get in contact.   Get Social! Follow us on LinkedIn, Twitter, and Facebook and keep up-to-date with our Google Analytics insights.

2016-03-31

5 myths of Google Analytics Spam

Google Analytics referral spam is a growing problem, and since Littledata has launched a feature to set up spam filters for you with one click, we’d like to correct a few myths circulating. 1. Google has got spam all under control Our research shows the problem exploded in May – and is likely to get worse as the tactics get copied. From January to April this year, there were only a handful of spammers, generally sending one or two hits to each web property, just to get on their reports. In May, this stepped up over one thousand-fold, and over a sample of 700 websites, we counted 430,000 spam referrals – an average of 620 sessions per web property, and enough to skew even a higher traffic website. The number of spammers using this tactic has also multiplied, with sites such as ‘4webmasters.org’ and ‘best-seo-offer.com’ especially prolific. Unfortunately, due to the inherently open nature of Google Analytics, where anyone can start sending tracking events without authentication, this is really hard for Google to fix. 2. Blocking the spam domains from your server will remove them from your reports A few articles have suggested changing your server settings to exclude certain referral sources or IP addresses will help clear us the problem. But this misunderstands how many of these ‘ghost referrals’ work: they are not actual hits on your website, but rather tracking events sent directly to Google’s servers via the Measurement Protocol. In this case, blocking the referrer from your own servers won’t do a thing – since the spammers can just go directly to Google Analytics.  It's also dangerous to amend the htaccess file (or equivalent on other servers), as it could prevent a whole lot of genuine visitors seeing your site. 3. Adding a filter will remove all historic spam Filters in Google Analytics are applied at the point that the data is first received, so they only apply to hits received AFTER the filter is added. They are the right solution to preventing future spam, but won’t clean up your historic reports. To do that you also need to set up a custom segment, with the same source exclusions are the filter. You can set up an exclusion segment by clicking 'Add Segment' and then red 'New Segment' button on the reporting pages and setting up a list of filters similar to this screenshot. 4. Adding the spammers to the referral exclusion list will remove them from reports This is especially dangerous, as it will hide the problem, without actually removing the spam from your reports. The referral exclusion list was set up to prevent visitors who went to a different domain as part of a normal journey on your website being counted as a new session when they returned. e.g. If the visitor is directed to PayPal to pay, and then returns to your site for confirmation, then adding 'paypal.com' to the referral exclusion list would be correct. However, if you add a spam domain to that list then the visit will disappear from your referral reports... but  still, be included under Direct traffic. 5. Selecting the exclude known bots and spiders in the view setting will fix it Google released a feature in 2014 to exclude known bots and spiders from reports. Unfortunately, this is mainly based on an IP address - and the spammers, in this case, are not using consistent IP addresses, because they don't want to be excluded. So we do recommend opting into the bot exclusion, but you shouldn't rely on it to fix your issue Need more help? Comment below or get in touch!

2015-05-28

How to audit your Web Analytics Ecommerce tracking

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!  

2015-03-17

Get the Littledata analytics app

Start your free 14-day trial

Learn More