Putting the “Universal” in Analytics: Best Practices



Google Analytics’ newest generation, Universal Analytics, is so-named because it goes beyond just the web, opening up new possibilities to bring together measurements across customer interactions in many environments.

The overall drive is toward a more holistic and complete view of our audience, whether it’s by rolling up data across sites, seeing behavior across devices and from web to mobile apps, or tracking non-web data using the Measurement Protocol for interactions such as offline transactions or email tracking.

All of this is great. But if there’s one guiding principle we can recommend, it’s this: In the quest to unify data, don’t lose sight of the particulars. We still want to be able to answer simple, straightforward questions like “How many visitors came to our website?”, and if we lump all of our data—web and non-web—together, that could become more challenging. It’s important to think through the issues of how we want to incorporate this data into Google Analytics before we just jump in.

Account structures

How you divvy up and organize the data in your Google Analytics account is one of the most important choices about how you’ll be able to use the data later. The exact details of how to structure your account(s), properties, and views in Google Analytics depend greatly on your organization, the number and types of websites you have, and how you need to deal with the data. For example, we’d take different approaches for each of these scenarios:

  • A single site example.com (Are there different departments or business lines? Do they control their own parts of the site and operate independently?)
  • Multiple brands or country sites like example.com, example.co.uk, and example.fr (Are the sites the same, just with localized content, or are they different? Are there different teams in each brand or country responsible for the sites, or is this function centralized in the organization?)
  • A software-as-a-service site with many similar sites all operating off a standard template (What are the needs for customer-specific data vs. platform-wide data?)

And that’s just the web. Layer on top of that with mobile apps and other data via the Measurement Protocol, and these questions become critical. To whatever extent possible within the limitations that exist, we want to make sure there’s a view in Google Analytics at the lowest reasonable level (for an individual site/app, or sometimes even a portion of a site).

A dedicated view allows us to easily use off-the-shelf reports in GA to answer questions for that site or app, without involving segments, custom reports, and other tools. Although those tools could also answer the questions we have, they require more expertise to use, are susceptible to sampling when large datasets are involved, and require the effort of recreating reports that essentially come for free if we have an appropriate view in GA.

Additionally, such a view gives us something comparable to our historic data: as we layer in new kinds of data (apps, offline, etc.), how do we make an apples-to-apples comparison for just the website? For instance, if we track our email opens and website visits into the same Google Analytics property, we’ll see in an increase in sessions. This makes complete sense as our sessions now include both web sessions and email sessions.

For all of these reasons, a dedicated view is preferred.

From there, we can use properties (including roll-up properties) to create higher-level views across sites. This allows us to continue our quest to unify data, without losing sight of the basics.

Tools to help

Some of the useful tools in separating and consolidating data in Google Analytics you may find helpful in structuring your account and data in meaningful ways:

  • View filters: We can filter views by portions of the URL such as hostname or subdirectories, as well as the (recently added) ability to separate web and app data.
  • Roll-up properties (Premium-only) or double-tagging for roll-ups
  • Segments and Custom Reports
  • APIs: Although this is certainly additional, custom work, the Google Analytics reporting APIs can pull together data across multiple accounts, properties, or views as well. This is especially useful for existing data that may predate a more proper account organization.

Jonathan Weber is our Data Evangelist, focusing on bringing the strategic value of data analysis to our customers. He spreads the principles of analytics through our training seminars and is currently writing a book on Google Analytics & Tag Manager. Before he caught the analytics bug, he worked in information architecture. Away from the computer you can find him as a flower farmer and plant geek.

  • Jeff

    Hi Jonathan. A challenge arose upgrading to “Universal” Analytics (UA).

    Prior to upgrading to UA, we parsed GA’s (legacy) utmz cookie, posted the campaign parameters with each lead, then matched offline sales with each lead’s last channel and source. We’ve discovered it’s no longer possible to retrieve the utmz cookie values because UA no longer stores campaign data in the cookie — only the user’s client ID.

    Is there a way to query/retrieve our utm values from GA’s server via GTM? (we now use GTM — wickedly cool!). The only alternatives I can think of involve messy “digital duct tape” workarounds:

    1. Using GTM, we could roll-back to legacy (ga.js) tags. But then we lose our new and valuable custom dimensions and custom metrics.
    2. We could write our own cookies to store the utm campaign parameters captured on landing pages. (see dm-guy’s utm-alternative: https://github.com/dm-guy/utm-alternative)

    I also read Sayf Sharif’s intriguing “Tracking Offline Transactions” post. But at this time, we don’t have the point of sale infrastructure to make this work. (see http://www.lunametrics.com/blog/2014/03/04/tracking-offline-transactions-universal-analytics/“)

    Thoughts? Thanks!

    • http://escapestudio.hr Zorin Radovancevic

      Hi Jeff,

      have you considered sending GA cid to both your CRM and to GA (as a Custom Dimension)? This way you could easily tie the traffic source and the client using cid as the key.

      Kind regards,

      • Jeff

        Hi Zorin,

        Thanks for the suggestion! If we do this, then our “CID” custom dimension will be set with a unique value for each user. A very high cardinality. Is there a limit on the maximum number of unique values Google will index for each custom dimension? (I didn’t find the answer via search). Assuming no limit, how would the CRM system translate the CID for the campaign info — via a query to the Google Analytics reporting API? Sound doable, but that will require development from our client’s CRM vendor. I’d prefer to pass the campaign info real-time upon lead submission. This used to be easy!


        • http://escapestudio.hr Zorin Radovancevic

          Hi Jeff,

          as for the cardinality issue there is an article here that kind of explains the situation http://www.lunametrics.com/blog/2014/09/24/remove-other-pages-content-reports/

          You could also opt to send the CD only when the actual lead is sent (CD should be user scoped).

          Depending on the lead volume and frequency API would be a sound choice (hourly, daily, ad hoc exports).

          If you want to do real time afaik then use, as you said, an additional js. Note that there could be a difference in how universal would treat the source and the custom script.

          Kind regards,

          • Jeff

            Hi Zorin,

            Both problems solved: cookies & cardinality

            1. Short term: I created a simple and effective workaround until the API is setup. Using GTM, I simply added a Classic GA event tag (non-interaction=true).That tag created the utm cookies! Our existing code will post these values to leads. Next, using custom javascript, I’ll add a condition to trigger the classic event tag only once per visit to avoid sending extra unnecessary event tags.

            2. Long term: “Sending the CD only when the actual lead is sent” is a fantastic idea! That decidedly solves our cardinality issue. I’ll recommend the API choice as the long-term solution.

            Thanks for your help and inspiration!

  • http://www.analyticsforfun.com/ mcpasin

    Great post Jonathan, very useful advice!

Contact Us.


24 S. 18th Street, Suite 100,
Pittsburgh, PA 15203

Follow Us




We'll get back to you
in ONE business day.