The Google Analytics platform has been changing from a web analytics tool to a user-centric digital measurement tool (we’ve been calling it Universal Analytics). This evolution includes a number of changes to the system and completely new features. But what can you do when you put all of these pieces together? I wanted to write […]
The Google Analytics platform has been changing from a web analytics tool to a user-centric digital measurement tool (we’ve been calling it Universal Analytics). This evolution includes a number of changes to the system and completely new features. But what can you do when you put all of these pieces together?
I wanted to write a quick post about how a business could use the entire platform to better market to users on the web based on non-website activities. We’ll explore how to use offline and online data to create remarketing lists in Google Analytics.
Before I start a hat-tip to my buddy Dan Stone – a product manager at Google Analytics who often talks about this type of usage.
Influencing Display Advertising using Email Behavior
Businesses interact with users via many different channels – search, display, social, email, etc. And they’re always looking to better understand how one channel impacts another channel. That’s why we have attribution modeling.
But sometime we want to take direct action, or even automated action, in a channel based on user behavior in a separate channel.
For example, I may want to change my search or display strategy for users on my email list. Perhaps I want them to see different display ads because I have a better relationship with them.
Here’s an example.
With Analytics we can collect data from email marketing tools, send it to Google Analytics and then use that information to change display campaigns.
We can send data from email marketing tools, to Google Analytics, then use the data to drive Remarketing.
The Implementation
With some of the new features in Google Analytics it is very possible to change a user’s display advertising experience based on behavior in other digital environments.
The first thing we need to do is bind the data in Google Analytics to the data in our own systems. This might be the data in a CRM or some other customer system. We’re going to use an old-school method that I describe in the post integrating Google Analytics with a CRM.
Here’s a summary…
When a user visits your site (or your app) Google Analytics sets a unique, anonymous identifier. This identifier is called the Client ID or cid for short.
What we need to do is extract the client ID value from the Google Analytics cookies and pass it to your CRM system. Once it’s in your systems you should be able to join your internal customer IDs with the GA ID. I should note – this is not some task you finish in an afternoon. You need some nerd help and it could take a while.
You can extract the GA identifier from the tracking cookie and send it to your own system.
Now that we have the two data sets joined we can do something really cool – we can send user-specific data to Google Analytics from other systems. This means that when we send out an email, or some other user-specific actions happens in our system, we can send that behavioral data to Google Analytics. How?
To send data to GA from other systems we use the measurement protocol. This technology let’s us send data to Google Analytics from any system that can connect to the internet. It defines how to send data to GA. We’ll use the measurement protocol to send data about email activities.
When we send an email to a user we will also send a measurement protocol hit to Google Analytics.
When an email is sent from your system, you can send a hit to Google Analytics using the measurement protocol.
Specifically, we’ll send an event piece of data. The event will indicate that an email was sent to this user and the type of email:
If we want to be really fancy then we can also send a second hit to Google Analytics when the user receives the email and another hit when the user opens the email. For example, if the user opens the email then we can trigger a pixel within the email that sends a hit to Google Analytics.
I need to stress, you need to write a bunch of code that generates these hits. The implementation will really depend on your systems.
The data in the above hits indicates that this email was part of the BackToSchool2014 campaign (look for the event data ec for Event Category, el for Event Label, ea for Event Actions. If we looked in Google Analytics the data would look something like this:
Offline email actions can be captured with the measurement protocol as events.
All of these hits include a specific parameter named cid. This is the Client ID for the particular recipient of the email that I discussed earlier. When Google Analytics processes these hits they will be merged with the dame user data from the website – because they have the same cid value.
OK, now we have user data coming from two separate systems and Goole Analytics is merging it together.
Here’s where the fun comes in.
Because all of this data is in one place, we can segment users in Analytics based on behavior, then use that list of users for remarketing.
after all of our work, we’re using the GA data measuring sent emails to create a remarketing list.
For those that have not use Remarketing, this is one of my favorite features in Google Analytics. Remarketing let’s you segment user on your website then send that list of users to Google AdWords (or DoubleClick if you use Analytics Premium) for use as a remarketing list.
The remarketing segment would look like this:
Segmenting users that received and opened an email.
This segment is all users that opened the back-to-school email. I could also add a condition that the user received the email, but that’s not really necessary.
Now we can use this list of users in AdWords. How? I may want to use the same creative for their ads. Or perhaps I offer them the same deal that was in the email.
This technique is not just for email – you can use the measurement protocol to send data from any system. That means behavioral information from other digital experiences can be used to drive remarketing lists.
Hopefully this example gives you some idea of how multiple Google Analytics features can be used together to drive real business results.
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. […]
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).
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.
Hits from the same user can be grouped together as long as each hit has the same User-ID.
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.
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:
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.
You must create a new User-ID view to see the Google Analytics cross device reports.
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!
We’ve been talking about Universal Analytics for a long time – over a year. In that time Universal has always been in beta because it was not 100% compatible with the existing version of GA. Sure, various parts of the Universal platform have rolled out, like the Measurement Protocol and Dimension Widening, but we were […]
We’ve been talking about Universal Analytics for a long time – over a year. In that time Universal has always been in beta because it was not 100% compatible with the existing version of GA. Sure, various parts of the Universal platform have rolled out, like the Measurement Protocol and Dimension Widening, but we were missing things like Remarketing and Audience data. But no more :)
I’m excited to say that as of today, April 2, 2014, Universal Analytics is out of beta!
Let’s run through everything you need to know about the announcement.
100% Feature Compatibility
Universal Analytics now supports all standard Google Analytics features. This includes:
Remarketing with Google Analytics. This is one of my favorite analytics features – and it made me very sad that Universal Analytics did not support it. But that’s in the past – You can now use the remarketing feature with Universal Analytics.
Audience reporting. The audience reports are an awesome way to understand who is using your site. They include data like gender and interest categories. This can be incredible helpful when trying to understand if the correct audience is using your site. Now you can use this feature with Universal Analytics.
Premium SLA Support. For all of those using Google Analytics Premium, all of your standard SLAs now apply to Universal Analytics. This includes data collection, data processing, etc.
Full Google Tag Manager support. Google Tag Manager now fully supports all Universal Analytics features, this includes audience data and the new User ID feature (discussed below).
I’ve said it many, many times – I’m a big fan of tag management. If you are going to migrate to Universal Analytics you might as well migrate to Tag Manager (or any tag management solution) now!
Universal Analytics is Google Analytics – and vice versa. Everything that Google Analytics can do, Universal Analytics can do – and more :)
Cross Device Measurement
In addition to complete feature compatibility, cross device measurement, via the User-ID feature, is now available.
The User-ID feature let’s you measure the user journey across multiple devices – and even in stores.
As you recall, this feature lets businesses use their own User-ID to measure customers across multiple devices. This feature includes some awesome reports to help businesses understand which devices and behaviors generate value. Here’s a quick overview:
Device Overlap: This report can help you identify what types of devices your users use to access your service or content.
The Device Overlap report
Device Paths: This report will show the last five devices that were used prior to a conversion. It’s a bit like the Multi-Channel Funnels report – but for devices.
The Device Path report
Acquisition Device: This report shows revenue based on the device that generated the first conversion. It’s can help you understand if users on a certain device have a larger impact on revenue.
The Acquisition Device Report
Understanding cross device measurement, and implementing it correct, is a huge topic – way more than I can cover in one post. I’ll be publishing a few other articles that explain cross device measurement in Google Analytics ASAP.
Time-zone Based Processing
In addition to the above features, there’s one more piece that is rolling out today. Google Analytics users can now specify the time-zone where their data is processed. In the past all data was processed in the Pacific Timezone (because that’s there Google is).
But now data processing will occur in the time zone of each data view.
The time zone setting for a view now controls when your data is processed.
While most people will not notice a big difference, this is a HUGE improvement for many users in Australia, Japan and other parts of Asia.
This also means that, for some users, automated daily reports will arrive on the correct day!
Do you need to migrate?
Ok, so that’s a brief overview of what’s happening today. But the big question that everyone will ask is, “do I need to migrate to Universal Analytics?”
No, you do not need to migrate to Universal Analytics – at least not now.
However, you need to start planning to migrate.
Universal Analytics is the new platform – all new features will be developed for UA. So if you want to use the new shiny things in the future you need to be on UA.
But migrating t can be a lot of work depending on your specific measurement plan. I’ll address that in another post.
Ok, that’s it for this post. But there is a lot more on Universal Analytics coming.
There are lots of different ways to put data in Google Analytics. You can collect data from a website with JavaScript. You can collect data from an app using an SDK (Android or iOS). Or you can collect data from any network connected device using the measurement protocol. But there’s another way to add data […]
There are lots of different ways to put data in Google Analytics. You can collect data from a website with JavaScript. You can collect data from an app using an SDK (Android or iOS). Or you can collect data from any network connected device using the measurement protocol.
But there’s another way to add data to Google Analytics – you can import data using a feature called Dimension Widening.
You can add data to Google Analytics a number of ways – including Dimension Widening.
With Dimension widening you can import additional dimensions and metrics directly into Google Analytics via a CSV upload or programmatically import data via an API.
Let’s take a look at how you might use Dimension Widening to augment the data in your account, and ultimately do better analysis.
Why Add More Data?
Analytics is more valuable when you can align the tool more closely with your business strategies and tactics. Adding additional data, like customer history, content publishing information, advertising cost data, etc. can help provide context to your data, thus making it easier to gauge performance and identify opportunities for improvements.
Adding additional data can also streamline your reporting (yes, basic reporting still happens) by consolidating all of your data in a single system that everyone has access to.
That’s where Dimension Widening comes in.
It is a mechanism to move data into Google Analytics.
How Dimension Widening works
You can upload two types of data to Google Analytics: Dimensions and Metrics.
A dimension is an attribute of a user or the sessions she creates.
A metric counts something – like time, money, clicks, etc.
When you use Dimension Widening you are uploading values for one or more dimensions or metrics.
You can upload values for existing dimensions/metrics or you can upload values for new dimensions/metrics that do not exist in Google Analytics.
When Google Analytics process the data it will join your custom data to the the existing data using something called a key.
The key binds your data, the data uploaded in a CSV file or sent programatically, to the Google Analytics data. When Google processes the custom data it will look at the value for the key, and then try to find the same value in the Google Analytics data.
If Google Analytics finds a matching keys then it will take the data in that row of the custom data and pull it into Google Analytics.
The key links your custom data to the data in Google Analytics.
There are four basic steps to configuring Dimensioning Widening.
1. Identifying the data you want to import.
Step one is really simple, identify the data that you want to add to Google Analytics.
Remember, you can import a value for any dimension or metric that currently exists in Google Analytics. OR you can import values for custom dimensions and custom metrics that are not normally found in GA – more on this below.
When choosing the data you want to import ask yourself this – what data to I need to understand the behavior of my users? How can I make my analytics life easier by consolidating data in Google Analytics?
You also need to define your key. This is obviously critical. If you can’t define a key then you can’t import data.
2. Create the schema in Google Analytics.
Once you define your key and the dimensions/metrics you want to import it’s time to add the schema to Google Analytics. Think of this step as telling Google Analytics how to interpret the CSV file (or data feed) that you will import.
Choose a property in the admin section, then choose Data import and Dimension Widening.
The Dimension Widening settings are in the Data Import section of a property.
To begin you need to name the data set you will import. You can actually upload multiple data sets (more on this later), so make sure you name it something very descriptive, like “Campaign Data” or “Content Information”.
Then choose the view where you would like the data applied.
Every data set must have a name, and you must specify which views to apply the data to.
TIP: Dimension widening will permanently change the data in a reporting view! It’s a good idea to test your dimension widening on a TEST view before applying it to your main reporting view.
Now add the schema. First, add the key that you’ve defined for your data.
Next, specify the dimensions and metrics that you want to add.
You must enter a schema into Google Analytics. Add the key along with the dimensions you would like to widen.
Here’s something cool – as you choose your key and dimensions Google Analytics will automatically show you the column headings that you will need to add to your CSV file.
As you add your schema Google Analytics will provide the column headers for your CSV file.
Notice that they’re not the names that appear in the drop down boxes. They’re the dimension/metric names that are used in the API. Fear not – you don’t need to understand what they mean.
3. Build your CSV file.
Once you finish defining your schema choose save.
You’ll be presented with two options: get more details of your CSV file OR get an API key to upload your data programatically. Let’s focus on the Get Schema option.
Once you define your dimension widening schema you can download a CSV template or get an API key.
Click the Get Schema button.
This window contains some really useful information. First, a list of the column headers that you need to add to your CSV file. This includes your key and all the other dimensions that you are adding to Google Analytics.
There’s also a way to download a CSV template for your specific data. The template is just an Excel file with the headers added to the first row.
Google Analytics will provide the column headers for your CSV and provide a CSV template that you can fill with your data.
4. Upload your CSV file or Send Data via API
Remember, there are two ways to add your data – via an API or manually via a file upload process. Let’s focus on the later – the file upload.
This isn’t too complicated, just click upload :) Once the file is uploaded Google Analytics will widen your data as it is processed.
You can check on the processing of your data using the Refresh button.
NOTE: when you use Dimension Widening the data you import is NOT applied to historical data. Your data is only applied going forward.
I find that GA can process the file very fast (minutes). You may want to refresh your list often to determine if the new data has been added.
That’s it! That’s the basic process.
But you probably want to use Dimension Widening to import custom data, not data that’s already in Google Analytics. Let’s take a look at how to do that.
How to add Custom Data
You can also add custom dimensions and custom metrics to Google Analytics via dimension widening. The process is almost exactly the same. The only difference is that you must first define your custom dimensions or metrics in the Google Analytics admin section.
To upload a dimension or metric that does not exist in Google Analytics you must first define those custom dimensions or metrics.
There’s not a lot of configuration here. Just give your dimension a name and choose a scope.
NOTE: You can only widen between dimensions and metrics of same scope. For example, you can’t widen from user scope Key to Hit scope dimensions. Check out this (somewhat old) article on Custom Variables to learn more about scope.
That’s it. Now you can choose these custom dimensions (or metrics) when you add your schema for Dimension Widening.
Once you define a custom piece of data it will be available in the Custom Data schema interface.
Then create your CSV file with the correct headers and upload your data.
Let’s say I’m a publisher. I want to add the publication year, author for each article. My key to join my data with GA data is the URL of each page. I already defined two custom dimensions, one for page publication year and one for page author.
I’m going to define my data schema in Google Analytics.
Defining a custom data in your dimensions widening schema.
Now I build my CSV file using the correct headers for my key and dimensions that I would like to widen.
A sample CSV file with custom dimensions.
Next I upload my file…
And finally, I have data in my custom dimensions. Here I can see the data in a Custom Report.
Custom Dimensions can be used in a Custom Report, Unified segment or other customization features.
Best Practices for Managing CSV files
You might want to widen your data based on multiple keys. For example, you might want to widen your product data (using the product ID as a key) and your campaign data (using campaign name as a key).
In this case you’ll need to define two different schemas and upload two different CSV files. Make sure you name them something logical!
Another thing to consider is when to update your CSV files.
For example, let’s say that you’re a publisher, and you’re uploading new data about your content. But you’re publishing new content every day. And probably multiple times a day. You would need to upload a new CSV file every time you publish content. This is too manual. In case you probably want to consider a programmatic solution.
Use the CSV file for things that do not change often. Use the API for things that change a lot!
What about JavaScript and real-time collection?
Given my previous example, you may be asking yourself, “can’t I just collect custom data in real-time using JavaScript?”
Absolutely!
You could do something fancy, like add the data to a data layer, then pull it into some custom dimensions. No problem!
The point is that you don’t always have the time or the IT resource to implement the data collection. Even if you use a cool technology like tag management, it may be that the data you want to add comes from an isolated system. And that it would take too much effort to transport the data from it’s home all the way to the web server.
Dimension widening can be seen as a somewhat faster, less IT intensive way of joining your data together.
Things to be aware of…
Ok, a few things that you need to be aware of when using Dimension widening.
1. Your data is NOT applied to historical data. Your data is only applied going forward.
2. You can NOT widen on ALL dimensions. You can NOT widen on the following dimensions:
custom variables
product dimensions and metrics
campaign dimensions
time-based dimensions (hour, minute, etc)
geo-dimensions (country, city, etc)
3. If you would like to expand your dimensions and populate Custom Dimensions you MUST use Universal Analytics. The reason is that Custom Dimensions only exist in Universal Analytics. They do not exist in the previous version of Google Analytics.
4. You can not change a schema once it has been entered into Google Analytics. You must delete the schema and then define your new schema.
I know some of these caveats may seem limiting, but remember, this is just the initial version. I know the team is working hard to expand the functionality.
Do you think you will use Dimension widening? If so how? Feel free to share your examples below!
