As part of my job, I’ve audited many Google Analytics implementations for small and large businesses, and despite the documentation and many resources out there, many issues are still not systematically tackled.
In this post, I share some of the biggest, and yet common mistakes in Google Analytics setup implementation and settings.
Error #1: Collect Personal Identifiable Information (PII)
PII include name, physical and email addresses, phone numbers, etc.
First rule of GA – Do not collect PII.
Doing so is against GA terms of service and you could have your GA account terminated. GA is not a CRM tool, although CRM data can be sent to GA.
In most cases, PII are unintentionally collected, most likely due to sneaky URL parameters such as www.example.com/submit?email=george.abidbol@gmail.com
Solution #1
Add these query parameters in the Exclude URL Query Parameters field in the view settings, for all views, even unfiltered.
Solution #2
Do not use any URL query parameters returning sensible data in the first place.
Error #2: Self-Referral Issues
From third parties:
Third parties solutions like payment gateways or content optimisation tools are on different domains. Therefore they are tracked as referrers by GA.
A quick way to see if you have a self-referral issue is to look at your Acquisition > All Traffic > Referrals report and sort referrers by ecommerce conversion rate (descending). Your payment gateways will most likely have the highest conversion rate.
From your own site:
Referral traffic may also comes from your own domain if you forgot to implement the GA tracking code on all your site pages. It may also comes from other domains using the same GA property ID but not configured with cross-domain tracking.
Solution #1
Add the third party and/or your domains to the Referral Exclusion List in the Admin section of the Property > Tracking Info. This will ignore them and traffic will be attributed to the last true source.
Solution #2
Make sure all your pages are tagged with the GA tracking code using Tag Assistant chrome extension, GA Checker, screamingfrog.co.uk/seo-spider/, etc.
;
Solution #3
For cross-domain related issue, you will need to amend your GA tracking code with the Linker plugin and the allowLinker parameter as explained here.
Error #3: Duplicate Transactions
Although it affects one of the most important KPI – revenue, this one remains incredibly common. Duplicate transactions occur when the order confirmation page is reloaded, sending ecommerce and pageview hits again to GA. this is not uncommon especially on mobile devices, where the latest page of session remains opened on the next browser session.
Solution #1
Do not make the transaction confirmation page re-loadable, even within the same session. Each confirmation page should be loadable only once, ever. Some sites even automatically redirect users to another page after a predefined period.
Solution #2
Setup a server-side logic that checks transaction ids with your database and if a match is found, prevents the GA tracking code from being executed.
Solution #3
Create a first party cookie storing transaction ids and configure the GA tracking code so it only sends ecommerce data if the current transaction id is not already in this cookie.
Check out Simo Ahava’s solution to configure this in GTM and David Vallejo’s for Enhanced Ecommerce (as transaction data are normally sent alongside a pageview hit).
Error #4: Local Revenue Not Converted
In GA, you can choose how the currency transactions are reported in (in the View Settings > Currency displayed as), but setting this up doesn’t mean transactions made with a different currency are automatically converted!
Solution
For hard-coded GA Universal Analytics ecommerce, you need to call the currencyCode tracker property alongside your ecommerce data. The currencyCode accepts the following currencies.
You can use either ‘&cu’ or ‘currencyCode’:
ga(‘set’, ‘&cu’, ‘AUD’);
ga(‘set’, ‘currencyCode’, ‘AUD’);
if you have implemented GA via GTM, you’ll need to call the currencyCode variable in the dataLayer on your confirmation page, then in GTM create the dataLayer variable ‘currencyCode’ and add it to the GA transaction tag as a field.
Note: If you use Enhanced Ecommerce feature, you’ll need to add the currencyCode field whenever a price value is sent to GA.
Error #5 : No Raw, Main, Test Views
These 3 views are the bare minimum to have:
Raw view
A view without any filters for backup purpose in case something gets wrong in your main view(s) (bad filters or goal set up).
Main view
A view with filters to include relevant hostnames only, exclude your own traffic, force lowercase URLs, etc.
Test view
A view that includes your own traffic only so you can test goals, events, filters etc. before applying them to the main view.
Then it’s also a good idea to create one main view for each of your key geographic markets with the appropriate time zone (in view settings) so you can have accurate time-related reports.
Tip:
Same view structure should be applied for user-id enabled views.
Error #6: Misleading Duplicate Page Paths
Let’s say you track both www.example.com and sub.example.com. In your pages report, you will see only one rows for the page ‘/’ for actually two different pages. This is not a major issue as you can still identify subdomains by adding the hostname as a secondary dimension (or use a segment).
But to avoid any possible confusion (and to use the secondary dimension for something more useful) rename the page to include the hostname.
Solution
Create the following filter:
Error #7: Virtual Pageviews Sent with Classic Pageviews
Sometimes you need to create (or rewrite) the page path sent to GA when you want to track a page content that does not trigger a new page load with a different URL, or when you simply want to have more meaningful URLs.
To do this, you use virtual pageviews and send your own page path to GA. In most cases it’s OK, but if the virtual pageview is there to overwrite the page being loaded, then you need to make sure the “default” pageview is not sent to GA:
Solution #1
If GA is hard-coded on-page, make sure your GA code with the page field replaces the default one.
Solution #2
If GA is implemented via GTM, make sure you block the classic pageview tag by adding the following blocking trigger:
This is assuming your custom event (e.g. ‘event’: ‘virtualPageview’) fires before the event used for the classic GA pageview tag (gtm.js, gtm.dom or gtm.load).
Tip:
Name the page title field for virtual pageviews by starting with “Virtual Pageview – …” so you can easily identify them in your page reports.
Error #8: Events Skewing The Bounce Rate
By default, an event is considered as an interaction, which therefore will be taken in to consideration in the bounce rate calculation.
For example, if a user lands on a page, triggers an event (like click to play a video) then leaves from that same page, the bounce rate won’t be 100%. This is the expected result as the user did interact with your site.
However, what if you have an event tracking mouse scroll, impressions of an element, or a video starting on page load? Then you will most likely end up with a bounce rate close to 0%, which is of course unrealistic. It is advised to not consider this type of “passive” events as interactions.
Solution
Set the Non-Interaction field to ‘true’:
If the GA event is hard-coded on the site:
ga(‘send’, ‘event’, ‘Videos’, ‘play’, ‘Fall Campaign’, { nonInteraction: true });
If the GA event is implemented via GTM:
Error #9 : Bad Use of Regular Expression (regex)
In GA, you can use regex to define goals, segments, view and report filters, channel and content groupings, etc.
In short, regex quickly become essential so it’s important to know how to use them well.
Below some common regex characters:
- ^ : starts with
- $ : ends by
- ? : precedent character optional
- () : defines a group
- | : or
- \ : escapes character
More here.
And always validate your regex before applying them with tools such as https://regex101.com/.
Error #10: Campaign Tagging Issues
This one is so common it hurts 🙁
Too many times, I see source medium reports with duplicate traffic sources (facebook / cpc and Facebook / CPC) or with unstructured naming convention leading to hard to read reports.
Here are some recommendations:
- Create a naming convention, share it internally and externally to your advertising agencies;
- Keep a record of tagged campaigns (a Google spreadsheet can be convenient for that);
- Be consistent in your naming convention, e.g. banners ≠ banner;
- Use lowercase only because utm_ parameter values are case sensitive, e.g. Yahoo ≠ yahoo;
- Do not use a campaign name as a source or medium;
- Tag your campaign so you can group them intelligently.
You can use Google’s Campaign URL Builder to create your links.
Last but not the least: do not use utm_ parameters for internal links! This would start a new session and therefore totally skew your acquisition and attribution reports.
And Some More Common issues…
- Duplicate home page URLs reported as page (/ and /index.php). See more;
- Google Adwords and Search Console not linked;
- Site search tracking not setup;
- Meaningless interactions used as goals or worst, no goal set up…
In Conclusion
Yes, GA is one of the greatest analytics solution, but you can’t expect a one-for-all solution to work 100% accurately for your site without having to do some customisations. Make sure you get the basics right, then do some more customisations with events, custom dimensions/metrics, calculated metrics, user-id, Enhanced Ecommerce and more!
So how good/bad do you think your GA data collection is? Do you see any other common mistakes people do?
Let’s throw some ideas around so we can all improve our data. Send us a message or give us a call at +64 9 9201740.
