This article offers an overview of the 12 most common mistakes in Google Analytics and how to avoid them.
Free, easy to implement and rich in analytic options, Google Analytics is without a doubt one of the most important website analysis tools. However, what happens if the output data are wrong, filters are configured incorrectly and data is not interpreted correctly?
The first mistake usually occurs with the integration of Google Analytics into the website. You copy the tracking code and simply put it 1:1 into the source code. The problem: This code is not compliant with data protection laws. IP addresses must be anonymized with the code extension "anonymizeIp". In doing so, the last octet of the IP address (the last 8 characters) is set to zero. This means manual extension of the code is still needed. If you have integrated the code via Google Tag Manager, you can input it directly in the tag, under the fields to be defined.
In addition to the anonymization of the IP address, you should note the following if you want to integrate Google Analytics so that it is privacy-compliant:
Enter into a written service agreement with Google that includes a data processing agreement
Give users the ability to opt out of Google Analytics data acquisition
Refer to the use of Google Analytics in the privacy policy
The legal obstacles have been removed. Now nothing can go wrong, can it? Make sure that the tracking code is not only in the right place, but also on every page. This might sound trivial, but oftentimes parts of the website are forgotten. Incidentally, doubling up doesn't hold up any better. If you double-embed the code, every page view is also double tracked in Analytics.
You can easily check with the Website Success module in Ryte whether Analytics has been embedded on each subpage in the source code. Under Content -> Custom Fields -> Google Analytics ID, you can analyze if Google Analytics has been stored on all of the pages.
Figure 1: Check in Ryte if the Google Analytics ID is stored on all pages.
If the Analytics Code has been properly integrated on all pages by IT or via Tag Manager, the next error often occurs. For the development, all page views / events / e-commerce data are sent to the Google Analytics account of the live instance. This data should not be in a live account.
I recommend that you set up a separate Google Analytics account for the development and staging environment. Tag Manager can be used to easily set up a switch. There are usually different domains or host names for staging and live. Depending on which host name is currently being called up, tracking will run to the matching Google Account.
Of course, a corporate website is often called up by its own employees or the respective web agency. Some companies set their own website as the browser home page for their employees. All of these requests generate direct traffic on the page and also in Google Analytics. Such page views and sessions can influence or even falsify the tracking or further analyses.
For this reason, it is important to exclude your own internal traffic in Google Analytics. The simplest way to do this is to exclude the company's IP addresses using filters in Google Analytics. IP filters can be set up under Manage -> Data View -> Filter:
Figure 2: Set up IP filter in Google Analytics
Figure 3: Set up IP filter in Google Analytics
Since the IP address is transferred anonymously and thus Google Analytics sets the last octet to zero, you have to work with the filter type "starts with". However, this also means that all 255 possible IP addresses that fall into this range are also not tracked. For large companies, this is usually not a problem as they will have their own Class C network. In this case, the first three number blocks are the same. Only the last octet varies. As a result, only internal traffic data are filtered out.
When you create a Google Analytics account, Analytics creates a new view called "All webpage data". No filters should be set up for this view. It is important to have a data view in every Google Analytics account, in which all of the data are unfiltered. If we want to exclude the internal traffic, a new data view is created and the IP address is excluded.
If, for example, something doesn't work when filtering or something changes in the data to be filtered, there could be erroneous data, unless there is a separate, unfiltered view. Although the filter can be deactivated again, it only takes effect after deactivation. All previously collected data would then be lost. Therefore, you should create a second data view immediately after initially setting up Google Analytics.
Cross-domain tracking is set up in order to track visitors across a company's different websites. If, for example, a company website can be found at www.domain.de, but the shop is internally linked under shop.domain.de, the visitor information should be collected across the subdomains. The data itself is stored in a cookie with the domain on the computer. Shop.domain.de cannot access the cookie information of www.domain.de.
In doing so, a visitor who moves from the corporate website to the store would start a new session with the same Analytics code. With cross-domain tracking, this information is passed on to the other domain and the domains are correctly linked.
Businesses should not only keep sales goals in mind, as measurable goals are also important to the website itself. In many cases, the Google Analytics code will be integrated into the website without further setup. Metrics such as page views, sessions or bounce rates are used as metrics for website success. However, which goal definitions are significant and meaningful is company-specific.
The following questions could be interesting, for example:
How often has the contact form been sent?
Who made a purchase?
Has a user downloaded my PDF brochure?
By setting up goals in Google Analytics, the user behavior that led to the triggering of the goal can be analyzed more closely and the website can subsequently be optimized.
The data from Google Analytics can be linked to other data sources. This makes it easy to see AdWords and Google Search Console data in Google Analytics. Data such as clicks, impressions, and more are aggregated with sessions and bounce rates. The values of clicks and sessions have a degree of correlation, but do not represent the same values.
This allows the Google Search Console to measure clicks that are not measured in Google Analytics - for example, when a user calls a PDF document via search or when the search navigates away immediately before the Analytics code has been loaded. This is why it is important to look at the data separately.
Until 2011, it was still possible to evaluate all keywords entered in the organic search in Google Analytics. Since the introduction of Secure Search, 98% of the organic search terms report "not provided". Only about 2% of keywords that have not been transacted via Google Secure Search will still be displayed. Now, it is important not to make the mistake of calculating this 2% of the displayed keywords up to 100%. A direct comparison of these keywords with the keywords you are looking for in the Google Search Console shows that the data are not right at all.
Not every metric or dimension is suitable for every website. The best example of this is the bounce rate. The bounce rate tells you how many visitors viewed only one page and left the page without further interaction. By definition, a high bounce rate would have to be negative in any case. However, it turns out that this depends on the site and the search intention.
Thus, on a one pager, the bounce rate can be at 100%, because the visitor cannot request a secondary page. But even with a search, the user can arrive at a page where he finds all the information he needs and subsequently quits the browser again. Or a user performs a navigation query and clicks on an e-mail link. In this case, it would count as a bounce, but the visitor actually made a micro-conversion.
Direct traffic in Google Analytics summarizes those requests that were entered directly into the browser bar. However, not only these requests are tracked, but also all other requests that Google Analytics cannot assign. Thereby the source "direct" and the medium "none" are a catch-all for all non-assignable sources. In addition to entering the URL directly, these can include:
Links from emails and newsletters
Traffic from mobile apps
Traffic from a page with SSL, if the own page did not activate SSL (https -> http)
Bookmarks
URL-shorteners
...
In order to reduce the traffic via "direct/none", it is important to tag the URLs. Google Analytics allows you to use Google URL Builder to set important campaign parameters, such as setting source or medium by parameter:
https://de.ryte.com/?utm_source=newsletter&utm_medium=email
Thus, links from newsletters or emails could be assigned to a suitable source.
It is advisable to view all collected data in an aggregated form to get an overview of the web analytics data. But the actual web analysis begins only with segmentation of the data. In doing so, the data are filtered into subareas so that you can view them across all reports in Analytics. This means, different traffic sources can be considered more closely, for example. How do, for example, visitors coming to the site through search engines behave? Which pages do they request most often? How do these users behave in relation to the rest of the users?
Anyone who uses Google Analytics on a daily basis will certainly be familiar with one or more of these mistakes. The basis of good web analysis is the data. If the dataset is flawed, then correct analysis cannot be performed. If you avoid these mistakes and follow the tips, you'll not only get a good database, but you can also use the full potential of Google Analytics.
Practice makes perfect!
Analyze your website with Ryte's Website Success for FREE
Published on Nov 20, 2017 by Thomas Czernik