One of the fundamental new features of Universal Analytics is user-centric measurement. This includes measurement across multiple devices – computers, smart phones, tablets, kiosks, etc.
But this change introduces a number of new challenges for analysts and marketers. In order to do cross device measurement you need to understand some of the challenges and limitation. Let’s begin our exploration of cross device data with a discussion about how it works.
How Cross Device Measurement Works
You’ll recall that most analytics tools set an anonymous identifier to measure users. On websites the JavaScript code creates the identifier and stores it in a cookie. On mobile apps the SDK creates the identifier and stores it in a database on the device. (We call this default ID the Client-ID).
We actually discussed this concept in our Google Analytics Platform Principles course. Skip to 21 seconds for details – but the whole video is helpful :)
The User-ID feature lets you override this default behavior. So rather than letting the tracking code create the a Client-ID, YOU can create and use your own identifier. How do you do that?
Well, your business needs to have some way of identifying users. Don’t worry, most businesses do. A CRM system or customer database usually has a User-ID that you can use.
The important thing is that you can create the technology that moves the ID from your database into your website, app or other digital experience where your users interact with your content.

The User-ID value must originate from your systems. It must eventually appear in the tracking code on your site or in your app. The User-ID will then be sent to Google Analytics with each data hit.
In the above diagram the company would need to create code that pulls the User-ID from the database, then passes it through the web servers, and finally places it in the Google Analytics Tracking code that appears on the website.
I know – that seems like a lot of work! But a good tech person can make this happen.
After you add all the necessary code, and set up the User-ID feature in Google Analytics, then the actual id value that you supply is sent to Google Analytics with each hit (see my post on hits, sessions and users to learn about all the different hit types in Google Analytics.)
Then, as Google Analytics processes the data, it groups hits with the same User-ID together. It does not matter if the hits come from a website, mobile app or some other device.
In the above image there would be three unique users – one user with a User-ID=1
, one user with a User-ID=2
and one user with a User-ID=5
. Again – it doesn’t matter where the hits come from (mobile, web, kiosk, etc.).
But what about instances when the User-ID is not present? For example, what if the user is not logged in and we can not retrieve the User-ID? Good question.
In this case, Google Analytics will go back to its default behavior and generate it’s own User-ID (again, this is called a Client-ID, because the ID is specific to the client or device). Obviously this ID can not be used to measure across devices as it will only exist on the device where it is set.
But now we have a scenario where a user might have two different User-ID numbers for a single user? Isn’t this going to have an impact on the data? Aren’t we trying to avoid that? This sucks!
Well – it’s not that simple. Let’s talk about something called Session Unification.
Session Unification
The above scenario is very common. You will not always be able to set the User-ID in Google Analytics – even for known users. The result is some hits and sessions will have a User-ID value, and some with an automatically generated User-ID value.

It’s not always possible to send your own User-ID to Google Analytics.
Google Analytics has a feature called Session Unification. When activated, it will unify, or group, hits with the manually set User-ID and hits with an auto-generated User-ID together. This means that Google Analytics can associate some hits that were received prior to setting the User-ID.
Here’s the definition of Session Unification from the Google Analytics Help center (I think it’s pretty good!):
Session unification allows hits collected before the User-ID is assigned to be associated with the ID, as long as those hits happen within the same session in which a specific ID value is assigned for the first time.
This means that Google Analytics will only associate hits collected in the same session AND it must be in the first session where the User-ID is set.
This functionality is sometimes called “stitching” – and it differs from one tool to another.
Google Analytics will not go back in time and stitch every single session from a given user together. I can hear the groans now – and the comparisons to other tools. I hope to write about session unification in a later post. But I think a lot of people that are going to complain about this are missing the point. It’s not “can we stitch data together” it’s “should we stitch data together?”. Rant over.
So how does Session Unification impact the data? Well, to understand that we need to talk about another topic the User-ID View and reports.
The User-ID View
We all know the basic hierarchy of a Google Analytics account. Within your account you can create a number of properties. Under a property you can create a number of views – which were formerly called profiles.
Now you can designate certain views as User-ID views. This means that the view will be filtered and the only data in this view is data that contains hits where you set the User-ID value.

Only a Google Analytics view with User-ID enabled will display information about cross-device users.
Obviously this view will have less data than a standard view where the User-ID is not enabled. But the idea is that this view will be able to provide deeper insights into how users who are logged in – a VERY valuable segment of your users – interact with your business across multiple devices.
To view all of the data, hits with and without a User-ID, you would use a standard view.
Let’s also consider the scenario from above – when a manually set User-ID is present in some sessions, but not others. The result is that the data from sessions without your User-ID will not be in the User-ID view.

Only hits that contain a manually set User-ID will be included in a User-ID view.
There are also some other significant differences between views that do, and do not, have User-ID feature enabled.
1. Certain metrics are calculated differently. Obviously if a User-ID view contains different data, then certain metrics will be calculated differently.
For example, the number of Users is calculated based on the number of unique User-ID values. This will provide a fairly accurate view of the number of users. It will probably be less than the number of users in a standard view because that that view will also include users where you do not set a User-ID.
2. Cross device reports. This is the HUGE benefit of a User-ID view. These reports provide some awesome insights into how users access your content from multiple devices. More info about the reports below.
3. Limited date range. When working with a User-ID view you can only change the date range to the past 90 days. This is consistent with the standard 90-day user look-back window in other features, like Multi-Channel Funnels and user segments.
Implementing Cross Device Measurement
Implementing the User-ID feature can be involved, depending on your specific infrastructure. Here’s a brief overview of the process.
1. First, you need to “turn on” the user ID feature for a given property.
2. Second, you need to add the actual user ID value to the data collection. For website, this means you need to modify the JavaScript tracking code. For mobile apps you need to change the SDK.
3. Third, create a User-ID view. This is a special data view that includes new reports.
Let’s get into a bit more detail.
1. Enable User-ID Feature
This is really important to read and understand the terms. For example, it’s important to note that you can not use personally identifiable information as the User-ID. This includes an email address, name, etc.

To use the User-ID feature you must read the User-ID policy and agree to the terms.
You also really need to take a look at your own privacy policy and make sure it complies with the following:
You will give your end users proper notice about the implementations and features of Google Analytics you use (e.g. notice about what data you will collect via Google Analytics, and whether this data can be connected to other data you have about the end user). You will either get consent from your end users, or provide them with the opportunity to opt-out from the implementations and features you use.
2. Implement User-ID in your Tracking Code
Now for the coding! Go get your nerds and Red Bull! Just kidding.
As I mentioned above, the User-ID value must come from you. You must generate the ID from one of your systems. Once you do that you must place it inside the tracking code. The hard part is writing the code that moves the User-ID from your systems and puts it in {{ USER_ID }} in the code snippets below..
Let’s look at some of the most common code formats.
Adding the User-ID to website tracking
Adding a User-ID to the JavaScript code is fairly easy – it’s a single line.
ga('create', 'UA-XXXX-Y', 'auto');
ga('set', '&uid', {{ USER_ID }});
ga('send', 'pageview');
Remember, the User-ID needs to be set before any hits are sent to Google Analytics. So make sure you call the set
command before a pageview, event, transaction, etc. is sent.
It’s also recommended that you include the set method on ALL of the pages, not just one page.
See the developer docs for more about JavaScript information.
Adding the User-ID to the Android SDK
t.set("&uid", {{ USER_ID }});
See the developer docs for more Android information.
Adding the User-ID to the iOS SDK
[tracker set:@"&uid" value:{{ USER_ID }}];
See the developer docs for more iOS information.
For both the Android code and the iOS code, you only need to set the User-ID once. Once it is set once the User-ID will be sent with all subsequent hits. But try to set it before any hit is sent to Google Analytics.
Adding the User-ID to the Measurement Protocol
Adding the User-ID to a measurement protocol hit is actually really easy. All you need to do is add the uid
parameter in each hit. So a hit might look something like this:
http://www.google-analytics.com/collect?v=1&_v=j16&a=164718749&t=pageview&_s=1&dl=http%3A%2F%2Fcutroni.com%2F&ul=en-us&uid=hsjfy4782jduyth6k4
Adding the User-ID via Google Tag Manager
A quick note that you can also set the User-ID with Google Tag Manager. You’ll find the setting in the ‘More Settings > Fields to set’. You’ll also need to create a macro to pull the actual User-ID value from a cookie or the data layer.

You can set the User-ID value with Google Tag Manager.
In addition to adding the User-ID to your data collection code, you must also choose if you want to use Session Unification. See above for more information on session unification.

The second step in setting up the User-ID is to add the actual identifier to the tracking code for your site or app AND configuring the session unification setting.
Now it’s time to add a User-ID view.
3. Create a User ID View
As mentioned above, a User-ID view is a filtered view of your data. It only includes hits in which you have set the User-ID value. This view also contains reports that show cross device usage and other user-centric metrics.
Please note, this view is in ADDITION to the other views that you have for a property. This means that you will need to configure things like goals, filters custom reports, dashboards, etc. on this new view.
That’s really it. I don’t want to oversimplify the implementation. But most of the work is really creating the code that pulls your User-ID from your systems and then places it in the correct tracking code.
Data and Reports
We finally made it, let’s look at some data and figure out how we can use this.
Remember, in all of these reports we’re trying to understand the behavior of our users. And we’re not just looking at the behavior of everyone – we’re looking at the behavior of those users that have self identified. This is really important as this group is naturally very valuable.
User-ID Coverage
Let’s start by understanding what percentage of our users are actually logged in.
Remember, you’ll have two different profiles with data. One profile will just be all of the data, the other will be a User-ID profile that only contains information about logged in users.
The Coverage Report identifies the data that has a User-ID associate with it vs. the data that does not have a User-ID.

The User-ID Coverage report shows what percentage of your sessions have a User-ID associated with them.
Remember, you’re probably not going to get 100% User-ID coverage – unless your online experience requires authentication. But this depends on your specific business and your specific implementation.
You can use this data to get a better understanding of how big your data pool is – will you be making decisions on 1% of sessions or 50%?
Device Overlap
Ok this is where we start to get into the really interesting data. Here’s a visualization that shows the device overlap. That means the percentage of users that use various combinations of devices.

Device overlap shows the number of users and the value of users based on combinations of devices.
Rather than just looking at how many people use certain combinations of devices, let’s look at the associated revenue from those combinations. Notice that you can change the display using the selector at the top of the chart?

The Device overlap report also includes detailed information about how combinations of devices drive value.
So what’s the actionability here?
Do people who use a certain combination of devices behave differently than others? Are people who use tablet and desktop more valuable than those that use tablet and phone? If so – how do we encourage more of that behavior? Is it via marketing? Changes to the platform?
And don’t forget, you need to add a LOT of context to this data. You need to keep in mind your marketing initiatives along with the user experience that you offer your users on each device.
Device Pathing
Now let’s move on to device pathing. This report shows the device used for a sequence of sessions.

Device Pathing shows the user sequence of devices.
You can look at a specific path prior to, or after, a user action. The action could be a goal conversion, a pageview, a transaction or an event.

You can view the device path prior to, or after, specific user actions.
What’s the actionability here? Let’s look at a use-case.
If you have a SaaS business you may offer your users a free trial. In this case the user would create an account for the trial and then use your service. At the end of the trial they would need to upgrade to a real account.
The first thing you could do is look at the user’s device behavior after creating their free trial account. Did they perform any specific tasks on a specific device? Was one device more popular than another? If so maybe you can simplify the workflow on that device.
You could also look at the device path at the end of their trial, when they upgraded to a paying account. Did they perform the upgrade on a certain device? Or, more importantly, was the conversion rate higher on on a certain type of device? If so, you might want to simplify or optimize the process on that type of device.
Don’t forget to look back at the Device Overlap report to understand if a certain combination of devices yielded a more valuable customer.
Also notice that there are a lot of ways that you can configure this report to view different paths. One of the most important things to note is that you can not choose specific instances of each item. For example, if a user generates multiple transactions you can not choose a specific transaction.

You can choose to view the device path before or after various user actions.
My suggestion is to create a goal, page or unique event for the most important user actions – the ones that represent the transition from one phase of the customer lifecycle to another. That way you will always be able to see the device path before and after the action.
Device Acquisition Report
Finally we have the Acquisition Device report. This is similar to the Device Overlap report in that it helps you understand the value of users on a certain device. But the difference is that it shows the value based on the first device type.

Use the Device Acquisition report to understand if users acquired on a certain device generate revenue on the same device or different devices.
What’s the actionability here? Do users acquired on a specific type of device generate more value on the same device or on other devices? If so how can you drive more of that behavior?
Segmentation
One final thing to mention. You may have noticed that you can apply segmentation to all of these reports. Segmentation will work the same in these reports as it does in all other GA reports.
If you create a session based segment then Google Analytics will show all the paths that include a session that meets your criteria.
If you create a user based segment then Google Analytics will show all of the paths generated from users that match your criteria.
Did you make it to the end? I hope this post gave you some insights into how Cross Device Measurement works. There’s going to be a lot of chatter about User-ID and cross device measurement – some positive, some negative. And I have a lot more to say – but this post is long enough!
Very happy to read your post, Justin. Your writing is always so lucid, and it’s good to hear the voice of someone from the GA team (even though this is you’re personal blog, of course, and not the official views of Google).
I must admit, I’m one of the “groaners” when it comes to Session Unification vs. Visitor Stitching. :-) And I agree with you that the question isn’t about “can we” but indeed about “should we”. (I think we “should”, though it’s obviously a very complex issue that is more nuanced that ‘yes’ vs. ‘no’). Looking forward to your future post where you’ll address those issues directly so that the discussion can be had in its proper place.
In any case, the practical implementation steps you lay our are very clear and I’m sure that loads of people are going to find this post helpful.
@Yehoshua: I totally get it :) Glad you found the post useful!
Justin, thank you for a great write up on this exciting new feature. I’m most interested in learning how I can access the User-ID feature.
Is it being rolled out gradually? When will it be available for everyone?
Could you show a screenshot of the previous page to this — http://cutroni.wpengine.com/wp-content/uploads/2014-04-01_11-25-46.png — so I know where to access it from.
I’ve tried to find it in Google Analytics Admin | Account | Property | Tracking Info but can’t find it as yet.
@David: That screen shot is from the admin section for a property. User ID is rolling out gradually – so it may be a month before it hits your account.
Great blog post (as always). Is there any clarity on when the roll-out will be done? I’m looking at some GA Premium profiles but can’t see any option (yet) for User ID activation.
@Koen: It will be rolling out over the next few weeks. Due to the nature of the rollout it’s hard to predict when it will hit all accounts. But that should give you enough time to plan things :)
Great post as always Justin. I’m jealous of your code/nerd to human translation ability :). I have one question based on this “It’s also recommended that you include the set method on ALL of the pages, not just one page.”
That makes sense and I will make those recommendations but what if it can’t be on every page for some reason. Have you seen any and good solutions to ensure that the proper User ID is assigned for example, something like decorating a URL and pulling the User ID out of it?
I’m pretty sure I read through all the documentation but there might have been something obvious I missed.
Thanks!
Nico
@Nico: The best practice is to call the set command on every page. But how you get the User ID is really up to you. You could pull it from the URL or you can store it in your own cookie. You can use any part of the web ‘stack’ to help you manage the ID. Hope that helps!
Great! Yep that helps. Thanks
Hi Justin,
great post. But I have a question about the js code.
Looking at the javascript documentation I see this line of code to set userId
$gacode = “ga(‘create’, ‘UA-XXXX-Y’, { ‘userId’: ‘%s’ });”;
where they set a the field userId
Previously that you publish this article i was using
ga(‘set’, ‘userId, %s);
is this codeok? if not why we need to use ‘&uid’ field with the setting call and on create we have to use ‘userId’ field?
@Filippo: There are multiple ways to set the User ID – and the code that you included is perfectly fine! I’ll update the post with more info. Thanks!
@Justin: thank you :)
Excellent post, as always – thank you so much for a lot of clarification on that key topic!
Just to make sure: What about following sessions of a user in which he might NOT sign in – at some time AFTER a signed-in user-ID session and not having deleted cookies til that time?
Will there be a session unification in that case too?
I guess it will – facing that user-ID supersedes client-ID and is stored in a persistent cookie.
@Christoph: This is an interesting question. If the user is not signed in, and you do not have a User ID, then GA will use a client ID. BUT, if the user is not signed in, but you still have the User ID in a cookie, then you could still use your User ID. Does that make sense?
Really awesome article. Thanks for sharing knowledge :)