Universal Analytics – Now Properly Namespaced

May 21, 2013Joe Christopher

Google’s new Universal Analytics platform has a lot of great features. We recently wrote about quite a few of them and there are also many great posts by Justin Cutroni that do a fantastic job of explaining the benefits. One feature has flown under the radar and hasn’t been talked about as much: the ability to properly namespace. This is partially because the audience that would need such a feature is probably smaller than the mass audience that can benefit from the more publicized Google Analytics Universal Analytics features.

This ability drastically changed from the classic version of Google Analytics. Read on to learn why exactly would someone want to do this and how it is useful.

Why namespace your tracker?

The primary reason you’ll namespace your tracker is when you have more than one tracker on your site.

Let’s say you have international sites and you want a web property for just the US site and a separate web property for each country. BUT, it is also important to see aggregated numbers across your entire ecosystem. For that, you’ll use a second tracker for a web property that captures all data across US, Canada, Mexico, Europe, etc. There are a lot of benefits to this, and it is easier than ever before to set this up. Here’s an example of using multiple trackers and sending data to two web properties:

There are a few other reasons why you’d want to namespace your Google Analytics code. Provided below are a few examples that we’ve encountered:

• You are allowing other websites to embed a widget into their pages and you want to track how often this widget has been embedded and by whom. We assume that you have properly notified the users of this widget that you’ll be tracking this data of course.
• You operate a service like TypeKit or other technology that is embedded into websites but you want to track usage per account or by website.
• You are providing landing page assets to a 3rd party that will be promoting your service and want to capture the number of visits to that landing page (again, we assume you are properly notifying them that you’ll be tracking data on page visits).

Problem with Classic Google Analytics

The one concern that all three of the above examples have in common is that there may already be Google Analytics code on the website and you definitely do not want to impact the existing Google Analytics implementation and metrics. Prior to Universal Analytics, this was both a real and common occurrence. We constantly came across vendors that were forcing their own tracking on top of a website’s existing Google Analytics implementation and unfortunately there were battles for the same cookies and different settings that caused conflicts like having each pageview be a new visit (and more). It was painful to see all of this happen and in some cases more painful to see some vendors that just didn’t get it and refused to properly track things without impacting their own customer’s data.

From a more technical perspective, in classic Google Analytics, the tracker objects were forced to share the same first-party cookie location; this was the root of the problem. There were a few things we could do to combat this, but it was unreliable when you start to scale out to hundreds of websites. Classic Google Analytics does not have a way for you to namespace the actual cookie; only the code itself. In fact, the classic Google Analytics code would continually battle for ownership of the same cookie and this caused attribution issues, visit accuracy issues, and more.

Solution with Universal Analytics

With the introduction of Universal Analytics, Google has increased the capabilities of the product in numerous ways. One specific way is by allowing namespacing of not only the code and function names, but more importantly the actual cookie (note that there is now only one cookie that Google Analytics uses instead of 5 in Classic Google Analytics).

So, let’s explore the solution from the point of view of a vendor that has a widget that is going to get placed on hundreds of websites. Let’s just make something up and say my widget company is called WidgetFactoryXYZ.

Step 1 – Create a new Universal Analytics web property.

Step 2 – Grab the provided Google Analytics Universal Analytics code that is provided via the interface after creating the new web property. This default code will look like this:

Step 3 – Modify the above code to make it properly namespaced so that there is absolutely no way that you can interfere with someone’s existing Google Analytics code (both Universal and Classic). Here’s where it gets a little trickier, but we’ll walk you through each code change required for this:

• Yellow Highlight: We first rename the function from ‘ga’ to ‘_gaWFXYZ’.
• Blue Highlight: This is done both on the main code block as well as for the Google Analytics tracking functions.
• Green Highlight: Then, we removed the domain part of the string since we don’t know where this code will be placed. Universal Analytics, by default is going to store the Google Analytics cookie on the top-level domain (excluding the leading dot). The next step is to give our custom tracker its own distinct cookie name. For this, I kept it the same as the function name, but it could really be called anything you want as long as it doesn’t conflict with an existing cookie – just keep it unique.

By making the above code changes, we’ve completely separated the logic of the Universal Analytics code from any other on-page logic that a website may already be using. We can be confident now that we’re not going to cause any conflicts with the existing setup.

For any calls that we make, instead of calling the ga() function like it shows in the documentation, we can just call _gaWFXYZ(). Pretty simple!

Note: You may be wondering why we didn’t just keep it as ga() and pass in a tracker name. Technically, this works. The reason why I opted not to do this was to first show you the gamut of customization that is available now, and secondly because if that website is using the getAll() method to grab all tracker objects, I don’t want them to include mine and send data that I don’t want. Another reason in the future is that I don’t want to collect any custom clientID value that is stored in the primary GA cookie (just in case it is violating the TOS and contains PII, etc).

Unique Needs?

Do you have any unique Google Analytics tracking needs that you are looking to solve? We help clients with a wide-variety of challenges all the time. Contact our team if you’d like to work with us to solve your unique tracking challenges.

About the Author

Joe Christopher

As Vice President of Analytics at Blast Analytics, Joe leads a team of talented analytics consultants responsible for helping clients understand and take action on their vast amounts of data, to continuously improve and EVOLVE their organizations. With over 20 years of experience in analytics and digital marketing, Joe offers a high-level of knowledge and guidance to clients across all industries. He is an expert in all major analytics platforms including Google Analytics and Adobe Analytics, as well as various tag management systems such as Tealium and Adobe Launch. He also consults on data visualization, data governance, and data quality strategies. Having extensive expertise in many areas, has enabled Joe to become a well known thought leader and speak at industry events such as Tealium’s Digital Velocity series. Joe remains on the pulse of various information technology, programming languages, tools and services, keeping Blast and its clients on the leading edge.

Connect with Joe on LinkedIn. Joe Christopher has written 51 posts on the Blast Digital Customer Experience and Analytics Blog.