Three configuration issues affecting Google Analytics
Google Analytics is one of the most common tools used in online marketing and analytics. It is extremely powerful; able to ingest data relating to marketing campaigns, website pages, attribution and transactions. Best of all, you get a tonne of great functionality for free.
But Google Analytics is a complex tool and because most users set up the tool themselves, there are a lot of pitfalls that can affect data quality and reduce the effectiveness of the tool for decision making.
This article will focus on three of the most common configuration errors that Conjura has come across. There are dozens of additional pitfalls that we could go into, but this article will focus on those that affect users’ ability to use Google Analytics to assess online marketing performance. We will outline the causes, consequences and how to determine if you have fallen into the pitfalls. We will also provide some solutions to ensure that Google Analytics collects high quality data.
Using the Enhanced Ecommerce feature, Google Analytics can capture a wide range of data relating to transactions including the transaction ID, revenue, products, product ID, the marketing campaign and so on. Usually, Google Analytics captures this information based on an event such as an order confirmation page or a thank you page loading.
The risk with this is that it can result in Google Analytics capturing duplicate transactions. This usually manifests itself as the same transaction ID being captured multiple times across several dates and with the same transaction ID being associated with several different marketing campaigns.
So, why is this a problem?
Conjura believes one the best use cases of the Enhanced Ecommerce functionality in Google Analytics is that it provides access to your transaction IDs along with their attributed marketing campaigns. Companies don’t need to spend a lot of money on a third-party attribution tool in order to get this data – unless they wish to run complex attribution models. Companies can use the transaction ID data for a whole range of analytics and reporting, driving great quality marketing optimization and business decisions.
To provide a more concrete example of the power of this data, we will explain how Conjura would use this data. When Conjura is analyzing a company’s performance, we will export transaction ID and attributed marketing campaigns from Google Analytics via the API. We will match this with a company’s transaction and customer data from their Ecommerce platform via the transaction ID (which should be collected across both systems). By combining these data sets, it’s possible to determine exactly how many new customers were acquired through a given channel and at what cost. It’s possible to determine how valuable a customer acquired through paid search is compared to a customer acquired via paid social, affiliates, display and so on. It’s possible to calculate margin generated from each channel and campaign. The possibilities are endless, and extremely powerful!
However, if you are collecting duplicate transaction IDs, the above becomes much more difficult and less robust. It is not as easy to determine a customer’s acquisition channel if the transaction ID is associated with multiple channels across several dates. Ultimately, this problem reduces confidence in all these numbers and makes it very difficult to act on data.
Additionally, duplicated transactions data reduces the accuracy of the reports within the Google Analytics UI. Revenue, transaction counts, units sold information will all be inaccurate if duplicate transactions are captured.
What causes the duplication of transaction IDs?
The problem is that confirmation pages can be loaded multiple times. For example, a user can refresh the browser while on the confirmation page or navigate back to a confirmation page, causing the page to reload. Additionally, mobile devices often refresh pages on opening of the browser app. In these cases, the transaction ID will be captured a second (or even a third or fourth) time.
You can verify if this problem exists with your Google Analytics set-up by running a Custom Report. Find Custom Reports under the Customisation section in the left-hand menu of your Google Analytics UI. Click the “New Report” button and select the Flat Table option. In Dimensions, choose Transaction ID. In Metrics, choose Transactions.
Click “Save” to run the report. You will be shown a table with Transaction IDs and the number of Transactions associated with each Transaction ID. If there are any duplicated transactions, you will see the Transactions figure greater than 1. It may be necessary to sort the Transactions in descending order in order to spot any duplicates.
As you can see in this example, there are several duplicates for each transaction.
The good news is that it is possible to fix this issue. The bad news is that it requires some technical knowledge in order to do so. This article won’t address the solution, but this link provides a great article on how to configure your Google Analytics tags to prevent capturing transaction IDs more than once.
Channel groupings refer to the categories of marketing channels that Google Analytics uses to group traffic, users, sessions, transactions etc. They are incredibly useful for understanding the performance of your marketing activity across a number of metrics.
These channel groupings have default logic that Google Analytics uses to determine how traffic should be categorised. We won’t go into all the rules in this post, but this link from Google provides the definitions. Being default, these rules can’t account for all the different naming conventions that companies might employ to track their marketing activity and therein lies the issue. Using the default rules often results in some form of miscategorisation of traffic i.e. there will be some traffic that has been categorised into the wrong channel.
One of the most common examples affects Facebook campaigns and is caused by how the campaigns are tagged in the Facebook ad platform itself (via UTM parameters). With Facebook, users often tag campaigns with a source / medium of “Facebook / cpc” in the Facebook platform. This is problematic as one of the default rules in Google Analytics states that any source / medium containing “cpc” should be categorised as Paid Search. In this situation, the Facebook campaign will be incorrectly categorised as Paid Search, not Social.
Another common miscategorisation occurs when campaigns are tagged in such a way that none of Google Analytics’ default rules apply. In this case, the campaigns will be categorised in Google Analytics’ catch-all channel grouping which it calls ‘(Other)’. This commonly affects Email and Affiliate traffic, but Conjura has seen many examples where Facebook traffic is grouped into this channel. Google Analytics has rules covering each of these channels, so traffic being miscategorised as ‘(Other)’ is usually caused by a lack of tracking on the marketing activity in the ad platforms i.e. not using UTM parameters.
The above problems are detrimental to any efforts to perform accurate reporting and analytics on your online marketing activity. It is not possible to accurately calculate cost per acquisition, return on ad spend or lifetime value if you don’t accurately categorise your traffic.
How can you investigate your channel groupings?
There are many ways, but one of the easiest is to use Google Analytics’ in-built reports. Conjura likes using the Channels report in the Acquisition section. This report provides a view of default channel categorisations as well as several metrics including sessions, users, transactions and revenue.
By clicking on the ‘(Other)’ channel, Google Analytics will drill into the source / medium of traffic in this category.
In this example, it is possible to see several examples of incorrectly categorised traffic such as Facebook, Pinterest and newsletter traffic. These should not be categorised as ‘(Other)’.
Prevent Google Analytics incorrectly categorising traffic
To prevent this problem occurring in your data, Conjura recommends taking the following steps. The first step is to ensure that all your marketing activity is tracked with the appropriate UTM tags. Simple measures can be taken to ensure your traffic contains the appropriate information in the UTM tags. For example, your email activity should have the word “email” in the tag and your affiliate traffic should have the word “affiliate” as a minimum.
The second step is to set up custom channel groupings in Google Analytics. These allow users to set up custom rules to categorise traffic. These are very powerful when a company is using many types of marketing activity that may not be covered by the default rules. Additionally, they allow companies to set up brand new channels and add more granularity into their reports. The most obvious example relates to Paid Search. Google Analytics’ default rules do not split Paid Search into Paid Search Branded vs. Paid Search Generic vs. Paid Search Shopping. You can use custom channels groupings to do this, however.
This article from Google outlines how to set up custom channel groupings. Users should note that, even if they implement custom channel groupings, the new groupings will not apply to historical data. Google Analytics is an immutable database, so changes made now will only affect data from the point of the change being made. The only way to fix historical miscategorisations is to extract data from Google Analytics and make the required changes in your reporting or visualisation tool of choice.
It is important to frequently monitor how accurately Google Analytics is categorizing your traffic. Changes to naming conventions and new ad platforms can affect ongoing data quality.
Most Ecommerce companies have third party services that they use to process payments on their site. Platforms such as Shopify also have their own payment gateways that their customers can use. In either case, these payment gateways generally redirect a user away from the main ecommerce site at the point of payment. Then, once the payment has been processed, the user is sent back to the ecommerce site.
This sort of thing is extremely common in Ecommerce, but it can cause issues with the accuracy of data in Google Analytics. The problem is caused by the combination of users being redirected away from the Ecommerce site and the fact that Google Analytics uses last click attribution by default in its reporting.
When a user is temporarily redirected away from the site and then sent back, Google Analytics thinks this is a brand-new session. Therefore, it counts an extra session when there is none, resulting in incorrect session counts and conversion rates. As Google Analytics uses last click attribution, the transaction that has taken place will be attributed to the last channel in the conversion path. In this case, this is the payment processor. Because Google Analytics thinks that the redirected traffic is a new session, it thinks that the payment processor drove the transaction.
This can cause major issues for any company trying to use Google Analytics to perform analytics and reporting. Instead of transactions being attributed to the correct channel, they are instead attributed to the payment processor. It is not possible to determine what channels drove what transactions. Because Google Analytics is immutable, this data is lost (unless you pay for GA360).
Investigate whether payment processors are affecting Google Analytics data
One quick way is to look at the Model Comparison Tool in the Conversions section of the left side menu in Google Analytics.
This report allows you to view performance based on different attribution models. It’s an incredibly useful report for this reason. However, in this case we won’t be using this functionality. Instead, we’ll be using this report to assess the source / medium data contained under the “Referral” channel. Click on “Referral” to drill down into the source medium data.
As highlighted in the image, there are several payment processors contained in the data. These transactions are incorrectly attributed, affecting the accuracy of this company’s data.
As well as payment processors causing the above issues, social sign on can affect data quality in the same way. When users opt to authenticate their login via Google, they temporarily leave the site before returning once they have authenticated. Follow the same process above to investigate whether this is an issue affecting your data. Instead of searching for payment processors, search for “accounts.google.com / referrer”, the source medium related to Google’s social sign on.
Using Referral Exclusions in Google Analytics
The above issues are extremely common, and the solution is very straight forward. The solution involves using the Referral Exclusions functionality in Google Analytics. Referral exclusions effectively tell Google Analytics to ignore apparent new sessions from a set of selected domains, and instead use the data from the session immediately prior for attribution.
The referral exclusions functionality can be found in the Admin section of Google Analytics under the Tracking Info options.
Add in a list of the domains you wish Google Analytics to ignore in any session counts, attribution and so on. In order to maintain a high quality of data, this list should be frequently monitored and updated to ensure that your referral exclusions capture all relevant domains.
As explained above, because Google Analytics is immutable, creating a Referral Exclusions list will only affect future data quality, not historical.
There are many pitfalls that companies can fall into when using Google Analytics. We have examined the causes, consequences and solutions for the three that we consider to be most important for assessing the performance of your online marketing activity. It is important to determine whether the pitfalls affect your Google Analytics account and monitor your data quality regularly.
If you would like to discuss how we can help you analyse your online marketing activity, get in touch via firstname.lastname@example.org.