Aug 21 13

Single vs. Multiple Properties in Google Analytics

By

Should one single property be used for all sections of a website, or a number of separate properties the better choice?

This post aims at explaining why I believe that separated properties are sometimes better than a single property. I will, of course, try to provide you with all the necessary information for making an informed decision, and if you think of anything I may have missed, please leave a comment or contact me. Thanks!

 

Before we dive into the details, let’s make sure we are all referring to the same terminology…

  1. PropertyAccording to Google’s documentation, when using your Google Analytics account you can create a property for each domain, site, source or environment for which you would like to collect data. Each property has its own tracking code with its own unique ID for identifying data from that property.
  2. Views – Each property can contain one view or more. “A view is a defined perspective of the data from a property, and provides access to the reports for that property” (Google’s documentation). In other words, you can include a specific subset of data in a view by applying filters. For example, you can filter out all traffic that is not to a specific domain (should your property track more than one domain) or you can choose to only include organic traffic (if you want to provide a view for your SEO contractor).
  3. Google Analytics Account – Each Google Analytics account can include one property or more. Make sure not to confuse this with the term “Google Account”: One Google Account can contain up to 25 Google Analytics accounts (check out this post if you reach this limit but wish to have more than 25 accounts).

Please note that in some places Google uses the term profile instead of view, but as far as I can tell, both terms represent the same entity and I will use the term view throughout this post.

So now let’s begin with the main advantages of using multiple properties.

Sampled Data

The first reason why using multiple properties is my prefered choice is that in most cases it enables you to use complete data, not just sampled data.

 

Sampled data often occurs with relatively large sites when using a single property, and is of course not always optimal. If your query includes more than 500,000 visits, Google Analytics will only return sampled data. For example, if your site generates 1,000,000 visits per month, Google Analytics will use sampled data as the default on your reports.
You can overcome this by changing the date range to less than a couple of weeks, but this might not always be a long enough period for your analysis.

 

Although sampled data often suffices, it is difficult to work with if you want to dive deeply into specific cases, if you need precise numbers, or if you wish to tackle a certain issue with your tracking. This is especially true when receiving a sample rate of less than 70-80%. For more details check out this article.

 

You can solve the overall data sampling issue by creating subsets of your data using views – but that only helps with standard reports. Since session sampling is done on the property level, creating multiple views will not avoid data sampling when applying advanced segments or creating customized reports. You can find more information about data sampling here.

 

Google Analytics’ Limitations

The second reason why using multiple properties is my prefered choice, rather than using a single property of the free Google Analytics, are the limitations that occur when working with a large website:

  • Data Collection – Google Analytics has a limit of 10 million hits per month – or at least that’s what Google states. From my past experience, Google does process more than this amount, but I’m not sure if it processes all of the data, or just more than this stated limit.
  • Data Freshness – If you have more than 200,000 visits a day, Google processes the data once a day – which could lead to a delay of two days in your data refreshness. I have also noticed that with large numbers of visits, custom variable values in standard reports are not updated for up to 3 days, but I am not 100% sure that this is necessarily due to the large amount of data sent (the data is, however, available in the API, even if the GA reports have not yet been updated in the reports).

 

Clear Separation between Web Properties

Most websites today have more than one web property, such as the main site, a blog, support center, landing pages, etc.

 

When installing Google Analytics on a website, the first and most trivial thing to do is try to aggregate all of them under the same property. Why? Because it supposedly sounds right that a user who visits the main site and then moves on to the support site or blog will be only counted once by Google Analytics. The common misconception is that if you implement a different property with a different tracking code for each of the company’s websites (e.g., one for the main site, one for the blog, and one for the support site), then you will not be able to tell how many users in total visited your brand’s properties (as the user who visited the main site and then the blog will be counted twice instead of just once).

 

I believe that aggregating all your sites together, is in most cases the incorrect thing to do, but before expanding on why, I would like to give an example: Let’s say I have a Service-as-a-Software application, which includes two sections: (1) the main website (for potential clients), and (2) the authenticated web site where my clients can manage the services. It definitely makes more sense to divide the 2 into two separate sections.

 

Let’s take the KISSmetrics site as an example: Many people I know (myself included) read the KISSmetrics blog almost on a daily basis, but most of these people have never visited their main site and will never become their customers. That might be the reason why KISSmetrics divides their site into two separated properties in Google Analytics: one for the blog and one for the main site. Otherwise, think what their overall bounce rate would be, or their conversion rate from visits to registration, if their blog was defined as part of their main site property.

Once I’ve decided to separate the website into a number of properties, I like to start at the end and work backwards, first examining each section and deciding which of them should have a separate property. I always want to achieve as great a separation as possible (unless I have a good reason not to). As each web property is, in most cases, targeted at a different audience type (with different behaviors), it makes sense to separate the main website from the service site, just as it makes sense to separate the blog, the support site, and the landing pages.

 

My rule of thumb is to divide a site into properties based on the personas who will be using the site. For example:

  • Blog readers vs. potential clients vs. registered clients
  • Free vs. paying customers
  • Traffic from online marketing campaigns vs. organic traffic

The total number of visitors, visits, bounce rates, pageviews, etc. are of no interest whatsoever, and are not actionable. Acting based on such data could lead to significantly incorrect conclusions, and worse.

 

You might also be interested in: How to Link Events to a Specific User in Google Analytics Universal

 

Each persona uses a site differently. Let’s, for example, look at the differences between KISSmetrics blog readers and paying customers:

  • Most Blog Readers arrive at the site through organic searches, blog feeds, and social shares. Most will read a post and then leave the site. This translates into a high bounce rate, tons of unique visitors and visits, no. of pages per visits close to 1, extremely low conversion rate to customers, low visit duration, relatively high percentage of new visits, and so on.
  • On the other hand, Paying Customers arrive at the site in order to login. This leads to a low bounce rate, not many unique visitors and visits, a high number of pageviews and a high ratio of pages per visits, zero conversion rate to customers (since they are already customers), high visit durations, low number of new visits, and so forth.

You get the picture. If KISSmetrics only had one property, with many more blog readers than paying customers, their overall analytical metrics would be incorrectly influenced by the blog readers.

 

There are two alternatives that can be used instead of multiple properties: Google Analytics allows you to segment the data (using advanced segmentation) or you can separate the segments into separated views. That way you can have blog readers in one view and paying customers in a different view – but both under the same property. Be cautious, however, if you choose either of these methods, as I will now explain.

Advanced Segmentation – Not a Great Alternative

The advanced segmentation feature is considered less effective for long term segmentation purposes. It is a great way to run ad hoc queries, but if your SEO manager is interested in one specific segment, she will have to re-choose this segment each time she looks at the data. Moreover, if you want your SEO manager to only see SEO traffic, this feature will not help you achieve that.

 

And one more thing – when it comes to large sites, Advanced Segmentation always uses sampled data.

 

Separated Views under one Property – Also not a Great Alternative

At this point you might ask yourself why not just use separated views under one property. Although this method has advantages, it does have disadvantages as well – both of which I will present now:

 

Advantages:

  • It is much easier to manage from the developer point of view. You only have to deal with one tracking code for all of your sites, and everything else can be achieved in Google Analytics by the administrator.
  • Working with different views gives you the option to enjoy the best of both worlds: You can obtain a holistic view (in the default view without filters) and have separated views for the various personas

 

Disadvantages:
Besides the fact that setting up cross domain tracking can be a real pain, the main reason I prefer to keep away from this method is the fact that maintaining separate views under the same property is not an easy task – especially when it comes to large, complex sites, with numerous sections and domains. For example, you cannot undo changes in the filter once they have been made, and the lack of a good debugging tool for your filters can cause data to be inaccurate. (Plus as I mentioned earlier, when using multiple views, you cannot avoid receiving only data sampling on non standard reports.)

 

To emphasize these disadvantages, following is a true story of one of my clients. Most of their traffic came from display campaigns. All traffic to the main website and landing pages was collected by one property in Google Analytics, with three views: (1) Master (no filters at all), (2) Non-Media traffic (traffic to the site from non media sources) and (3) Media traffic (traffic to the site with campaign information passed in the URL).

 

At some point, one of the media buyers accidently created a Pop-Under Campaign to one of the landing pages – but forgot to set the campaign tracking parameters.

 

Of course, all traffic from that campaign went into the Non-Media Traffic View. Needless to say, this profile became useless from that moment on. All metrics went “crazy”, as Pop Under Campaigns have an extremely high bounce rate, low ratio of pages per visit, and a high number of unique visitors and visits. (Completely the opposite of Non-Media Traffic…). Oops.

 

The only person to blame here, besides the media buyer, was me – the person who created the profile. What I should probably have done was set the filter by the first page that the user viewed (as landing pages can only be accessed by Media Traffic).

 

Although this could also happen with multiple properties, in my experience, implementing the logic in your code as to which tracker to use (preferably via a tag manager):

  1. Makes maintenance so much easier.
  2. Reduces the possibility of mistakes.
  3. Debugging JavaScript is so much more simple to than Google Analytics filters.
  4. There is much more freedom when working with JavaScript, as decision can be based on additional information to that sent to Google Analytics.

If for example you use multiple views, with one view for registered users and another for everyone else, then you will not be able to create the filter without sending this information (registered or not) to Google Analytics (in the user defined value for example)
If on the other you were using JavaScript, then you could simply store the information in a cookie and decide which property to use for that visitor, based on the value of that cookie.

 

In the past there were certain disadvantages to using multiple views under one property, but they have been resolved. I will however mention them in brief, just to provide a complete picture:

  • In the past, you could not set different permissions for a user across views under the same property. Once you set users as an administrator, they had administration rights to all views. (Today, however, you can set permissions up to the view level so one user can be an administrator of one view and have no access to a different view).
  • The Real Time Reports presented raw data in the past, so you could not see filtered data for a specific view. (Today filters are applied on your real time reports).
  • Some metrics were calculated based on raw data. (Today all metrics are calculated only based on the filtered data).

 

What are the disadvantages of working with multiple properties?

I never said the choice was easy. I just said that you have to make an informed decision. So following are two main disadvantages to using multiple properties (with possible work-arounds)

 

Viewing all data in one place

Google Analytics does not provide a way to aggregate or view data from multiple properties. You cannot, for example, see an overview of all your traffic if your blog readers are being tracked in one property, your potential clients in a second one, and your existing clients in a third. On the other hand, there is no real value in obtaining overall numbers regarding different types of personas.

 

Having said that, I do understand why some people (usually the highest paid person in the company) may want to have a “dashboard” with these numbers. There are several relatively easy ways to achieve this information:

  • The most simple method is to define an additional Roll-Up Property that tracks all sections under one property and is only used to show high level metrics. This excellent article will explain you all about using a roll up property and multiple trackers in Google Analytics.
  • A different approach is to create a dashboard and obtain data from Google Analytics using the API. This may sound complicated but there are several ways of achieving this without any coding:
    • Using a dashboard service such as geckoboard or ducksboard – these excellent (and beautiful) services will allow you to display widgets from different accounts on the same dashboard. The biggest downside, however, to using these services is the fact you will need a programmer to create an aggregated KPI for all properties together.
    • Importing all the data to Excel and creating a summary sheet, using services such as Excellent Analytics that will transfer the data from your account to Excel.
    • Using Google Analytics Easy Dashboard Library, which with the help of some HTML and JavaScript coding creates a dashboard with data from multiple properties and views. You can read more about it here.
    • Using Google Analytics Report Automation Script created by Nick Mihailovski from Google. This is an awesome script that allows you to create an aggregated view of all of your properties and present it using Google Docs, spreadsheets or Google sites.

 

Total no. of users

If each property counts users separately, a user who visits two different sections of my site will be counted twice, instead of just once.

 

If you really care about the number of users you have overall, there is a relatively easy way to do so, as follows. This solution will also help you better understand the flow of your users across the different sections of your site. (Unfortunately, the Flow Report in Google Analytics is not good enough when you have numerous visitors, visits, pages and sections).

 

So what you have to do (and you can take the following solution and create your own variation based on your requirements) is mark each user on their very first visit to any of your sites. Once you have determined this, you can inform your Google Analytics using Custom Variable or Custom Dimension.

 

For example, let’s say all my properties (blog, support, landing pages, main site, forums, etc.) are under the same domain (as subdomains or subdirectories). Setting a domain level cookie (*.yourdomain.com) on all of your pages will share that cookie across all properties. That way, the first time the user visits any of your pages, this cookie will be empty and you will know that this is the first time the user has ever visited the site (or has cleared his cookies – which is the same for Google Analytics).

 

All you have to do now is filter the data on your dashboard by this custom variable (the condition will be: custom variable is not empty).

 

If you store the name of the section the user just visited in that custom variable, you will also be able to break down the number of visitors according to the first section they saw.

 

You can expand of this method for many other uses – and is useful even if you only work with a single property. If you are wondering how to use the same method on a site with multiple domains (not subdomains) where you cannot share the same cookie (as cookies are per domain), you can sync the cookie using an iframe that will be called from all domains and will return the cookie value as a parameter in the URL.

 

(By the way, using an iframe to sync cookies is much more accurate and reliable compared to using the cross domain tracking code suggested by Google, but that is completely off topic and I will write a separate post about it in the future. You are welcome to contact me in the meantime if you would like to hear more about this method.

 

Summary

To summarise this long post, here are my rules of thumb that I follow when implementing Google Analytics on a new site:

  1. Segment your traffic by personas rather than by traffic sources
    Apply the user-centered design principle when designing your analytics solution by using the same personas you’ve created during your product planning and design.
    Ideally, in my opinion, you should create a separate property for each persona. 

    Different personas will enter your site in various ways so don’t worry too much about traffic sources. Even if you have roles that are evaluated by a specific traffic source (such as an SEO manager), it will make more sense to have different “reward levels” for different personas (just as it makes more sense to look at the number of visits per persona, not the total amount). If your SEO manager is compensated by the number of visitors that arrive at the site from organic searches, then you probably already have a different price for potential clients and existing ones.

  2. Choosing between properties vs views
    If you have a large volume of traffic (that exceeds the limits of the free Google Analytics version), I suggest you go with multiple properties.
    And if you have a JavaScript programmer on board, I also suggest you go with multiple properties (using JavaScript is much easier and much more powerful than working with GA filters).
  3. Using a tag manager
    A tag manager will help you, regardless to the method you choose, but it will especially make life easier when choosing multiple properties. If you use Google Tag Manager, the following script will help you to store persistent data in the data layer object.
  4. Combined multiple and single properties
    If you go with multiple properties, consider adding a roll up property that will contain an aggregated view of all of your site activity. After all, Google Analytics is free, so you should take advantage of this 😉

 

  • Anonymous

    I forgot to mention that if you use multiple properties with a single adwords account, Google Analytics will show you the total number of clicks and cost (not only the clicks for that specific property). This might explain discrepancies between clicks and visits when working with multiple properties so keep it in mind if you go that path.

  • Hans van Putten

    Great article!! Finally one that does not discuss the technical features of GA but actually why and how to use it. very rare…am impressed, Thank You!

    • Anonymous

      Thank you! 🙂

  • Awesome post mate. Thanks for the advice!

    • Anonymous

      thanks!

  • Aaron

    Hi Shay

    Great article and you make some interesting points.

    I have a question though. Assume you are a KISSmetrics and have it setup with 3 seperate properties; Marketing site, blog, application.

    How would you setup goals like ‘Signup’ and ‘Upgrade’ in your marketing site or blog property when those things happen in the application, which is a completely seperate property with a seperate JS script and a seperate cookie?

    For me, the main point of GA is to see what channels/sources are converting best, or what blog posts are leading to the most signups and that setup seems to make it more difficult.

    I was initially thinking you’d just setup Custom Events for ‘Signup’ and ‘Upgraded’ and pass them into each property via some custom JS, but then how would that work considering you have multiple cookies for the same person?

    • Anonymous

      Hey, in your example, if you want the marketing and blog to get application related events (like signup or upgrade), you should send the events to those properties (although I am not sure if it is possible to run multiple trackers on the same page with KISSmetrics).

      Maybe a better way to deal with it is to look at the blog and the marketing site as marketing channels and measure their value in the application property (by looking at the referrer). KISSmetrics provides the first and last touch attribution which will show you if the blog/site was used to convert the user.

  • Hey Shay,

    Really interesting stuff here, has caused many hours of thought. I’m still hesitant to break up my properties, I think mostly due to not being able to see combined stats, but considering using a roll-up property for that. Because I am really getting killed by sampling…

    Which leads me to the question I can’t seem to find an answer for. It is regarding Events. Do you know if Events (non-interaction) will add to the session count that is used for calculating sampling? I have some high volume events in my main property and am trying to figure out if I need to break them out into a separate property. Haven’t been able to find anything about it in any official documentation.

    Thanks!

    • Anonymous

      Hey, besides the bounce rate and the time on site/page, non-interaction events are treated as “normal” events on other metrics so even if you have a session with only non-interaction events, there is a chance it will be part of the sampling sessions.

      Hope it helps!
      Shay.

  • Pingback: Single vs. Multiple Properties in Google Analyt...()

  • Anonymous

    Hey Shay,

    Great article! I appreciate you taking the time to dive into this!

    • Anonymous

      thank you very much!

  • Anonymous

    Been working with web analytics for over a decade now and this does the best job of explaining how to frame this discussion. thank you!

    • Anonymous

      Thank you!!

  • Robin Wouters

    Hey Shay, great blog. I’m thinking about following your advice and using separate properties for my site (domain.com) and blog (blog.domain.com), as the blog is just a traffic source for our site. I added utm params (just like Kissmetrics does) to all links from our blog to our site, to optimize blog to site conversion.

    Now, with Universal Analytics, a default property setting is that “domain.com” is an excluded referrer. I’m not sure what to do with this setting. Remove it, risking that other clicks between pages will cause self-referrers? Or keep it?

    I did some tests, and keeping this settings seems to block tracking traffic between both properties (both as referrer and campaign, tracking it as “Direct” traffic). So not sure what to do now. What’s your advice on this?

    Thanks!

    • Anonymous

      Hey Robin,

      This is actually a very good question 🙂

      Based on my understanding of the processing flow (https://developers.google.com/analytics/devguides/platform/campaign-flow), if there are campaign parameters in the URL, Google Universal should use the campaign data regardless to if the referring domain is excluded or not. So the campaigns details should be correct while the traffic source should be “Direct”.

      I will run some tests and get back to you with an answer. In the meantime, a simple fix might be to change the excluded domain from “domain.com” to “www.domain.com” (assuming your site is under http://www.domain.com and not domain.com).

      If you want to discuss it further, you are more than welcome to send me an email.

    • Anonymous

      Hey Robin,

      It looks like Google Universal handles campaign tracking as described in the processing flow document (https://developers.google.com/analytics/devguides/platform/campaign-flow).

      So it means that you can keep “domain.com” in the exclusion list and if your campaign tracking parameters are properly set, Google Universal will identify the traffic correctly (regardless to the fact the domain is excluded).

      Please feel free to contact me if you have any questions.

      Thanks,
      Shay

      • Robin Wouters

        Hi Shay,

        Thanks for testing & clarifying this! I’ll keep “domain.com” in the list of exclusions and use utm params to see refs in the reports. Great.

        Thanks,

        Robin

  • The benefits from the games: KiziPou GamesK7x will help you banish the stresses of everyday life

  • Prithvi Raj

    Hi Shay,

    I have a question. Let’s say i have a site “xyz.com” and a subdomain “abc.xyz.com”(subdomain is basically a application form process page) . Both the domains are reported in two different properties of GA.

    Site user scenario
    – User visits “xyz.com” from Organic search
    – and then from “xyz.com” he goes to “abc.xyz.com”

    Now as an analyst if I want to see how many users came to “xyz.com” from Organic search, and then visited “abc.xyz.com” how do i see that?

    Best regards,
    Prithvi

    • shaysharon

      Hi Prithvi, I am afraid that without additional code you will not be able to do that as you work with two separated properties. I would mark organic traffic on xyz.com (using JavaScript and cookie) and pass that information using campaign tracking (utm_source, utm_medium etc) when the user goes to abc.xyz.com from xyz.com.

      I will let you know if I can think of a better way.

  • Katherine Watier Ong

    Shay,

    This is SUCH a helpful article. I have one question though – it’s the GA hit limit per account? At which point separate properties would not help with avoiding the data collection issues once you hit that limit…

    • shaysharon

      Thanks Katherine!

      I have to admit that GA limitation was never a reason for me to choose separate accounts over one account with multiple views (usually, I split my accounts just to avoid data sampling).

      I’ve never had a problem with the data collection even when I had ~30M hits per month but I assume that if you do have a large site and you see data collection issues, splitting them to multiple properties will solve it.

      I hope it answers your question.

  • Very helpful. This is the first time I feel like I understand the differences between properties / views and the implications of choosing one over the other. Thanks

    • shaysharon

      Thanks!!

  • Pingback: Questions and Answers | Anne Pinney()

Subscribe for Our Latest SharePoint Analytics Updates

Signup to get the latest SharePoint Analytics posts straight to your inbox!