We see a lot of funky (and some awesome) Google Analytics setups. Doing it right can be magical, doing it wrong can have you throwing Macbooks across the room. There can be reasons for a setup outside the standard outline, but lack of knowledge isn’t a good one. Check out these best practices:

Hierarchy

Google Analytics is broken down into Accounts which are broken down into Properties which are broken down into Views. It should be noted that a single Google account (identified by an email) can have multiple Google Analytics Accounts associated with it.

Accounts

This is the highest level functional group in Google Analytics. It is meant to represent a business, organization, or digital presence. Accounts are primarily distinguished by permissions. When you grant a someone privileges to a Google Analytics Account, the privileges should represent one digital presence. An illustration please. Consider an app company. They have apps of their own, but they also have apps that they build for clients. If all their own apps share the company branding, like a product suite, they should be in the same account. Their clients’ apps should be in separate accounts. If our hypothetical app company ever did something their clients didn’t like and business discontinued, their clients should have the ability to revoke the app company’s privileges and take their business and their data elsewhere. This is starting to sound like Dwight’s fantasy from the Office. “You mean in your wildest fantasy you are co-running a bed and breakfast with the devil?” We shouldn’t be dreaming up our perfect, fantasy app company that loses clients! Only a fantasy digital marketing agency would do that.

Ok, onward. You could make an argument that your own apps deserve their own GA Accounts if they act like separate businesses. Your investors might want to sell one off and it isn’t related to the “suite” of others. That deserves a separate Account. Separate Accounts can be shared to multiple Google Accounts. The app company should probably have a manager account (like the MCC in AdWords, now manager account) that has access to all the company’s and clients’ apps.

Properties

This is where we see the most misunderstandings. A Property just represents a domain, right? Not entirely. A Property represents a logical grouping of data for a business. 

Do I Want to See This Data Together?

An example please. Consider a SaaS company. They have a website that tells all about their company and product features and leads visitors down their sales funnel ending in a subscription. They also have the best web app man has ever beheld. For branding and ease of use the app and the site are on the same domain, amazing.com. From an architecture perspective, it would be wise to build the site and app on different subdomains (www.amazing.com for the site and app.amazing.com for the app). Now for the GA, one Property or two? Two. In the case of the site, the data is all about how people progress toward a purchase or lead. In the app, the data is all about how people use the app. The group of people planning the site don’t wanna wade thru the app usage data when they are looking for marketing performance. The developers on the app don’t wanna wade thru landing pages to debug UI flows.

Alright, you say, then subdomains are a logical separator? Nope. This is the biggest mistake that we see. Consider an ecommerce store with a checkout on a different subdomain or a different domain altogether. The data here is by definition connected. Putting your cart on a different property from your site means that you can’t see which landing pages lead to transactions, which sessions bounced once they hit the cart. This will kill your data analysis.

Facilitating the above often requires cross-domain tracking. That sounds scary. It isn’t. Contact us, we do it all the time.

Other Considerations

What about multiple languages? This deserves a little thought. Is the site structure the same? Are the sales funnels related? But the main question to ask is “Do I want to see this data together or separate?” If the answer is together, then put them in the same Property. You can always filter down with views. Without some third party tools, you can’t aggregate data across Properties.

What about when my sales group needs to see initial app signins for conversions? Fire a single conversion for an initial sign in to the web site Property. Sync the sessions if needed. Tag Manager is awesome for this, but don’t make your dev team hate you by having all your blog posts mixed in with their usage.

Views and Filters

This is the second most common area for mistakes. Views are distinguished by a subset of your Property data defined by usage type. Again lets try some examples. Your company’s employees use your website differently that your customers do, make an Internal View for them. Your dev team uses differently, make them a view. If multiple languages are used across a Property and if their usage differs make views for them. You can control user access per view.

The difference between one View’s data and another is created by a filter. Stay tuned for an upcoming post on Filters. Every Property should have at least 4 views (or sets of filters): Unfiltered/All Website Data, Master, Internal Only, and Testing.

Unfiltered has, you guessed it, no filters. This is your backup for everything. You have to have an unfiltered view or you could end up in Macbook-throwing land.

Master has a filter that excludes dev and internal company traffic. This ideally should show only data from your actual live orders and actual live potential customers, not developers, not automated tests, not internal employees, not bots… you get the idea.

Internal Only has a filter that shows only internal traffic (if you have big teams maybe there is an internal one for your content people and an internal one for your devs). As a dev, it is difficult to setup new tracking when you are trying to figure out which sessions are yours in the GA interface.

Testing usually has no filters on it, but because adding a filter is a destructive process, you need a view to try them out on before you just slap them on Master, hence Testing.

As hinted at earlier, you may have reasons to create more views than this. Maybe you have mature paid campaigns and content campaigns and you have groups of people that only care about paid traffic or organic traffic. Views for those would be helpful.

When you are making your view decisions, remember filters are destructive. If you apply a filter to a view, you can’t get filtered data back. Similarly, filters are not retroactive. It is good to setup Views with some foresight the first time. Creating a copy of a View will not copy its data, just its settings.

Also remember that filter application can take up to 24 hours according to Google. We usually see filters applied immediately (if you are watching where sessions get sent to from Tag Assistant of GA Debug), but they take 30 min to an hour to start showing up in reports in the GA interface.

Conclusions

There is a ton that we didn’t cover here, but these are the basics. Armed with this knowledge you can carefully step outside the guidelines if necessary, but these principles should still be echoing in your mind. 

A great Google Analytics setup will be your best and most profitable friend, a bad one will leave you with untrustworthy data and one less Macbook.

An ounce of prevention is worth a pound of cure. Let us help.