Common Google Analytics Setup Errors and Omissions

We’ve seen our fair share of Google Analytics configurations here at UpBuild. The types of analytics accounts we get to work on run the gauntlet from completely broken configurations to some seriously inspired advanced tracking setups that even have us impressed. 

Even though every analytics setup is slightly different, most accounts we deal with share some pretty common errors or missed opportunities. I’ll go over those here, so hopefully, you don’t miss these while setting up your own analytics.

Property Settings Misconfigured Or Not Addressed

When configuring a Google Analytics account, there are a lot of things you need to click, agree to, or acknowledge. It’s easy to miss one (or five) of the various settings you should be addressing up-front.

These are the most commonly ignored Google Analytics Admin Settings that we see:

Default URL Is Not Set To HTTPS If The Site Is Using It

Selecting a Default URL

This setting will only affect the presentations of URLs in reports, but it should still be set up correctly to ensure reports are easy to read and understand.

Timezone Country Or Territory Is Wrong

Setting the default time zone

Timezone is set at the View level so that you could have different timezones for different Views. This is important because the timezone feature sets when day-to-day reports start and end. Meaning, if you have your timezone set to PST but you have a visitor to your site from EST timezone at 2:30 am on 9/2/2019 your report will still show that visit coming on 9/1/2019 because the time in PST at 2:30 am EST is only 11:30 pm on 9/1/2019.

Bot Filtering Isn’t Selected

Enable bot filtering

Google has identified a list of known bots that it will automatically filter from your data if you enable this option. This is only done at the View level so you can have some reports with bots filtered out and others that don’t if you choose. There are very few reasons most webmasters should not enable this feature.

Google Search Console Isn’t Linked

Linking Search Console

Linking Google Analytics and Google Search Console will allow you to see more data points in one place, giving you a better view of how your website is performing. If you have Google Search Console set up (and you should!) there is no reason not to link the two together.

Default View Should Be Set

Naming your views

Google Analytics, let’s you set the default View at the Property level. The “default view” will be the View used for integrated services like AdWords Express or Google Play. This means, data will be pulled from the Default View into other Google services. Be sure you’re using the correct View here so that your other Google services have accurate data.

Industry Category Should Be Chosen

Select an industry category

This feature lets you set the type of industry your website operates in. You’ll notice that the choices are pretty generic, so try to pick something close as possible. This feature is used by Google “to enable richer features in Google Analytics,” which translates into this feature being used for benchmarking. If you enable this feature, you can then use the Audience > Benchmarking report to see how well your site does compared to others in its industry.

Enable Demographics And Interest Reports

Enable demographic and interest reports

This feature is a little more complicated in how it works, but basically, if this is enabled, Google can collect data on a subset of your users based on a cookie they have installed and relay that information to Google Analytics. With this feature enabled you can get information on age, gender, preferences (“cooking enthusiasts”) among other information. To see more details on this feature see Google’s documentation on it.

Most of these settings, if not enabled or done incorrectly, will not torpedo your entire data analytics collection or processing — but they’re there, and they help make your analytics more accurate and usable, so why not use them?

Misusing Cross-Domain And Subdomain Tracking

An issue I’m seeing more and more frequently is confusion between cross-and sub-domain tracking.

In most cases, clients think or are already using one when they need the other. The misunderstanding here is between what a cross-domain would be versus a subdomain.

A subdomain still lives on the original host domain. For example, if a user goes from upbuild.io to welcome.upbuild.io they are going to a subdomain, not another domain. We would want to enable subdomain tracking here, not cross-domain tracking.

If a user clicked a link from UpBuild.io to e.g. upbuild.zendesk.com, then we’re going to a different domain.

In the first case (where we are going from upbuild.io to welcome.upbuild.io and then back to upbuild.io), we would want to set up subdomain tracking. In the other case where a user goes from upbuild.io to upbuild.zendesk.com, we’ll be configuring cross-domain tracking.

Identifying this issue is pretty easy, depending on the analytics implementation. It comes down to determining whether the cookieDomain is set and what’s in the referral exclusion list.  Mike from UpBuild has a great write up on cross-domain and subdomain tracking that you can check out.

Missing A Raw Or Unfiltered View

A common vulnerability that we see when auditing analytics configurations is the lack of a raw View in Google Analytics. A raw View would be a View that has no filters or advanced configurations set up—Google Analytics is “processing” this data as minimally as possible.

This type of View should act as a type of backup for your analytics data. If one of your other Views encounters an error or a data disparity that you can’t rectify, you can look at your unfiltered data and try to get some insights into what is going on.

Since data is already processed by the time it gets to you in Google Analytics, you cannot get completely unprocessed data. If you have filters set up on a given View, any data you’ve filtered out is gone—you can’t get it back. If you had a raw View, you could refer back to it in case you need to find a piece of missing data.

This one is straightforward to do—create another Vew in your analytics property and do not filter anything out. We like to name our properties in this format “Account Name [Raw, Unfiltered]” and “Account Name [Primary, Filtered.”]

Having Custom Dimensions But No Trigger To Apply Them

Most accounts we see have not configured any custom dimensions and probably never considered it. Occasionally, we find that a custom dimension is set in Google Analytics, but there is no event attached to it to apply it to a user. This means that the custom dimension never gets applied to any users, meaning our custom dimensions have no users and serve no purpose.

When considering and creating custom dimensions, be sure to consider how that dimension will be applied to the intended user. Do they need to fill in a form? Click a button? Start a chat?

Not Accurately Naming Views

We alluded to this in Error # 3 when we discuss the naming of a raw and unfiltered View. 

Google Analytics can be confusing enough on its own, and since much of it is not customizable, we should be leveraging every opportunity to make it our own and make it work for us.

One easy way to do this is by creating a uniform and representative naming scheme that you use throughout your analytics account. By uniform we mean a template or format where your mind can focus on finding a specific View rather than trying to understand what is in a View. By using a template, your mind can find things quicker and be sure you’re looking at the correct data set.

Making those View names accurate is vital. Most users will not often go into a View’s settings to see what filters and other settings have been tweaked that could affect what data shows up in that particular View. If the View is named “All Web Site Data” (which is Google Analytics’ default name for a new View), then the user is expecting all the data about the website. But maybe that isn’t what they’re getting? Maybe they’re getting some of the data about the website because there is a filter removing 30% of the site’s traffic before it even gets into Google Analytics? Not good. That View should probably be named “Account Name [Some reference to the filter that is applied here or its purpose, like “Mobile Users Only].”

Using a uniform and accurate naming format for your analytics accounts, Properties, and Views will make everyone’s life much easier and probably prevent some big misunderstandings or “whoops” moments at some point.

Here is how UpBuild tends to name its views in Google Analytics:

How UpBuild names views

We always have a “primary” account that is filtered, a raw and unfiltered view, and finally a test view where we can experiment with things. All these are named clearly so that another member of UpBuild OR the actual client can understand what they’ll find without any additional context.

Not Reviewing Who Has Access to Your Analytics Regularly

Managing users in Google Analytics

If a company is marketing their business online, then they’ve probably given analytics access to a consultant or vendor at some point. Some companies might give vendors access to part of their data only while on-site at their office, or using a tool’s built-in “users” feature, while others might just give their vendors the login details and trust them. Many tools that you’ll end up using for your analytics usually have a feature that allows you to grant access to “other users” outside your organization or outside of the person managing the account. This means you could be using Google Analytics and while being the administrator for the account you could “grant access” to UpBuild as a “user” who can then access certain analytics features and data points–which you control. This feature is great because you’re in total control; you can add or remove users whenever you need to which can be helpful when moving vendors, adding or removing team members, etc.

The most common (and the best method) is using a tool’s built-in user administration feature and adjusting permissions that way. Even if you use this method, we highly recommend quarterly (or more often) reviews of what vendors and users have access to your various analytics tools and suites. In the case of Google Analytics, it’s very easy to see which users have what access as long as you have at least “Read & Analyze” privileges. Go to Admin > User Management.

Make sure to remove users who no longer need access to your analytics. While nearly everyone is a “good egg” and will not do any evil with your data, there is no reason to leave that risk on the table.

Not Reviewing Filters Regularly

As with our users, filters should be reviewed regularly to ensure they are up-to-date. The cadence to which you check your filters should be relative to how often your team is making significant changes to your website. If things are changing daily, you might want to pay more attention to your filters than if the site was changing quarterly.

To do this, head to Admin > All Filters or Admin > View > Filters. Since we’re talking about filters and you’re already in your Admin panel for Google Analytics, let’s check our Referral Exclusion List and Search Term Exclusion List for updates that might need to be made due to business or landscape changes.

That’s Just the Easy Stuff

So those are the most common issues we see when auditing analytics accounts. Of course, we almost always encounter missing or broken Events and Goals or confusing reports (not to mention a myriad of other errors, problems, and inconsistencies), but those types of problems are not as quickly sorted out as the configuration-focused errors we’ve pointed out here.

Okay, take a look at your analytics accounts and make sure you’re not missing something easy.





Written by

Related Posts

Leave a Reply

Your email address will not be published.