A very common data analysis technique is called Cohort Analysis.

A Cohort is simply a segment of users which is based on a date. For example, a cohort could be all users based on their Acquisition Date (in Google Analytics this is really the Date of First Session).

Another cohort might be all users that completed their first transaction during a specific time period. This is a very common cohort used in ecommerce businesses. You’ll commonly hear ecommerce companies talk about the performance of new customers acquired during the holiday shopping season. This is simply a cohort. It’s all customers whose first transaction occurred between thanksgiving and Christmas (or some day before Christmas).

I’ve written about cohorts before. But to be honest, a lot of other analytics tools have been hard on Google Analytics for it’s lack Cohort functionality – and that was well deserved! For a long time the only way to do cohort analysis in Google Analytics was via segmentation – but that was really a hack.

Now Google Analytics has a real Cohort report that makes it much easier to perform cohort analysis.

Explaining the Cohort report

Let’s look at the various parts of the Cohort report. There are three main sections of the report: the report settings, the data over time graph and the tabular data.

[Click to enlarge] There are three parts to the Cohort report.

Now let’s talk about how to configure a Cohort report.

There are four main choices that you need to make when creating a Cohort report.

Cohort Type: Again, a cohort is segment based on a date. The Cohort Type is where you specify which date you want Google Analytics to use to create the cohort. Right now you probably noticed there is just one option here – Acquisition Date. This dimension is the date that the user first visited your site or used your app. It’s basically the Date of First Session.

I know – you’re probably all groaning that there is only one option. Me too! But stay tuned :)

Cohort Size: The cohort size is the time window that you want to use when looking at the Cohort type. So, choosing a day would mean “I want to see all users that have the same acquisition day.”

If you choose a Cohort Size of a week then it means “I want to see users whose acquisition date was within the same seven day period.”

Metric: This is the actual data that you will see in the report. There are aggregated metrics, like pageviews, and there are a number of per-user metrics, like sessions and revenue.

Remember, the analysis technique is to look at a specific metric for a cohort (a segment!) and see how that metric performs over time. The idea is to see if there are any dramatic changes to the metric between the different cohorts.

Date Range: This is the date range used to construct the cohort. When Google Analytics builds a cohort it uses the Date Range to evaluate the date specified in the cohort type – in this case Acquisition Date.

If I choose a Cohort Date Range of Last 7 days, and today is February 6, Google Analytics will look from Jan 30 to Feb 6 and align the data based on each user’s Acquisition Date. Here’s how Google Analytics would create the various ‘Days’ of data based on a user Acquisition date of January 30.

Day 0 = Jan 30
Day 1 = Jan 31
Day 2 = Feb 01
Day 3 = Feb 02
Day 4 = Feb 03
Day 5 = Feb 04
Day 6 = Feb 05
Day 7 = Feb 06

How Google Analytics creates Cohorts based on date.

And here’s how the ‘day’ data would break down for each cohort in the data table. Notice how each cell of data is for a different group of users on a different day?:

[Click to enlarge] Daily data by cohort

Remember, we’re talking about days here because we chose the Cohort Size to be Day. If we had chosen Week we would have seen Weeks in the graph; in that case, a week would be a 7 day period starting from yesterday backwards.

You’ll also notice that this time range is also represented in the tabular data.

NOTE: You will ALWAYS see 12 columns of data in this data table. It does not matter if you choose a cohort size of day, week or month. There will always be 12 columns. Why?

Most people will assume that if you choose a daily cohort for a 30 day time period you would see 30 columns and 30 rows, one for each cohort. But we found that most people don’t look at every single combination. For example, there are very little insights to be gained for the 17th day cohort 22 days from their initial visit.

However, if you do need to do that type of analysis it is possible to switch to a larger cohort size, like week, to observe what happened.

The amount of data in the cohort report depends on the cohort size and the date range that you choose.

When you choose a daily cohort (cohort size = by day) then you are limited to a 30 day lookback window.

When you choose a weekly cohort (cohort size = by week) then you are limited to a 12-week lookback window.

When you choose a monthly cohort (cohort size = by month) then you are limited to a 3-month lookback window.

Cohort Analysis Workflow

Ok, now that we’ve talked about the parts of a Cohort report, let’s look at a common workflow. Let’s say I’m a blogger (or publisher) and I want to understand the behavior of my weekly active users.

From a business perspective, I want people to come back to my site (or app!) very often. Knowing how many people are active within a week is really useful.

First I choose my Cohort Type – Acquisition Date because I can’t do anything else right now :)

Next, because I publish a lot of content, I want to set Cohort Size to daily. Now, for the metric, I am going to choose User Retention. This is the percentage of users that returned to my site (or app!) on a given day.

Finally, I’m going to set the date range to Last 7 days.

Now I have a report to look at!

To analyze this data I’m going to skip to the tabular data under the time trend.

Each row of data represents a different Cohort. I chose a daily Cohort, so each row represents a day. There will be 8 rows of data because my date range was 7 days and the EIGHTH row is the All Sessions data.

The tabular data shows the retention rate for each cohort for the past 7 days. To analyze the data I’m looking for any cells in the table that are a dark color. Or you can just look at the actual numbers to identify numbers that are abnormally high. But I’m lazy, so I’m just going to look at the color.

Here, in this report, I can see that users who first visited the site on Jan 27 returned at a much higher rate one day after their initial visit – much higher than all the other cohorts.

[Click to enlarge] Analyzing the data in a Google Analytics Cohort report.

What happened to these users? Why is their behavior different? Great question!

You need to add some of your own business context to this data as you scan the table. Think about your marketing activities. Were you running any specific campaigns that might have impacted the date?

It may be that you have no idea why this happened. Have no fear – Segmentation to the rescue!

Segmenting the Cohort Report

One thing that I really like about the new Cohort report is the ability to segment the data. You can apply up to four segments to this report. Each segment will create a new table of data below the “All Sessions” table.

Remember, a cohort is just a segment based on a date. So when you apply a standard GA segment you’re introducing another layer of segmentation. Here’s what the data would look like if I segment by Mobile and Tablet Traffic.

[Click to enlarge] Applying a segment to the Google Analytics Cohort report.

To analyze the data I like to compare the data from each segment to the All Sessions data. I’m looking for any segmented cohorts that perform differently than all of the sessions.

I also recommend segmenting by traffic source or specific campaign. This is especially important given that the only Cohort Type is currently Acquisition Date.

Which Cohorts should you choose?

Hopefully by now you have a good idea of how this report works and how you can use it. You’ve probably noticed that this is not something that you will need to use every day. Let’s look at a few common cohorts based on different business models, that you can create.

Remember, we’re a bit limited right now due to a singular cohort type – acquisition based cohorts.

Ecommerce

There are some really cool ecommerce-specific metrics that we can analyze with the Cohorts report. Things like Revenue per User, Transactions per User and total Revenue.

The key here is to remember that the cohort will be based on the date the customer first visited the site or app.

Also remember the granularity of the cohort and your customer buying cycle.

Analyzing customers who purchase expensive items, that are purchased less frequently, over a 7 day date range, will not yield many insights. Try switching to a weekly cohort over 10+ weeks.

Weekly Cohort, User revenue, last 12 weeks
Weekly Cohort, Transactions per User, last 12 weeks

If your customers purchase less expensive items, then they might purchase more frequently. Try switching to a daily cohort over 30 days.

Daily Cohort, User revenue, last 30 days
Daily Cohort, Transactions per User, last 30 days

Try adding some product segmentation. Here I added a segment based on a specific product and found that the revenue per users spiked 5 days after the first visit.

[Click to enlarge] Looking at a single segment in the Google Analytics Cohort report.

Also, try applying a segment for user-based revenue. Look at high-value customers and lower-value customer. How does their behavior, over time, change based on the acquisition date?

In App Purchases

This is one area where the cohorts report will really shine. This is a FANTASTIC way to understand user behavior after they initially launch your app for the first time.

The in app purchase model is very different than traditional ecommerce – In app purchases are MUCH smaller and usually very frequent. I would look at cohorts like:

Daily Cohort, User revenue, last 7/14/30 days
Daily Cohort, Transactions per User, last 7/14/30 days

I would also look at user-engagement cohorts for those that do NOT purchase. It will help me understand if users are actually using the app. Create the following cohorts:

Daily Cohort, Sessions per Users, last 7/14/30 days
Daily Cohort, Session Duration per User, last 7/14/30 days

Then apply a segment of Revenue per User = 0:

Publishers (Desktop & Mobile)

For publishing I want to better understand user engagement over time. Luckily there are a number of metrics that we can use when building cohorts. Try the following:

Daily Cohort, Sessions per User, last 7/14/30 days
Daily Cohort, User Retention, last 7/14/30 days
Daily Cohort, Pageviews per User, last 7/14/30 days
Daily Cohort, Sessions Duration per User, last 7/14/30 days

If you have revenue data in Google Analytics, from AdSense or some other calculation, I would suggest looking at cohorts similar to in-app purchase.

Also keep in mind your publishing schedule. If you’re the New York Times or Wall Street Journal you publish a lot of content every day. A 7-day date range is very helpful. But if you’re a blogger that only publishes twice a month, you might want to look at a 21 or 30 day date range.

Lead Gen

Similar to the previous items, your lead gen cohorts will really depend on how long it normally takes to get a lead. If you’re selling something expensive, look at a weekly cohort over a long time period. If you’re selling something less-expensive, look at daily cohort over a shorter time period.

One of the challenges here is that there is no metric for a single goal conversion. You could use the metric Goal Completions, but that looks at ALL your configured goals, and I’m assuming that most of you have more than one goal configured.

So your best bet for lead gen is to look at some engagement metrics. Look for cohorts that are showing lots of engagement based on time and sessions per user. This may indicate
A Final Tip

Hopefully this clears up why you should do Cohort analysis and how to do it with Google Analytics.

Here’s one more tip.

Use Shortcuts to save your specific cohort reports. This is a HUGE timesaver! You probably noticed that you need to configure the Cohorts report. If you look at a cohorts report often take the time to save your version using a shortcut. Then you can access it with one click in Google Analytics.

[Click to enlarge] Create a shortcut to make it easier to access your Cohort reports.

Cohort analysis is a useful way to understand how groups of users perform based on a common date attribute. I hope you will try cohort analysis and found this post useful.

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.

Make sure you check out these two posts for more information:
Integrating Google Analytics with a CRM
Understanding Cross Device Measurement and the User-ID

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:

www.google-analytics.com/collect?v=1&tid=UA-XX-Y&cid [UniqueID]&t=event&ec=Email&ea=Send&el=BackToSchool2014

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.

www.google-analytics.com/collect?v=1&tid=UA-XX-Y&cid=[UniqueID]&t=event&ec=Email&ea=Open&el=BackToSchool2014


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.

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.

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.

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.

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!

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.

So here it is – an updated script specifically for use with Universal Analytics.

This Google Analytics customization collects data as users scroll down a page. It uses events to track when a post loads, when the user scrolls more than 150 pixels, when the user reaches the bottom of the content and when the user reaches the bottom of the page.

This technique uses Google Analytics events to track a user as they scroll down a page of content.

The end result is some cool data about how many users actually read content. Here’s a sample of what the data looks like. This is just an basic event report with the Event Action and Event Label.

You can access the Reading data in your Event reports. Here we see a single article and how often users scrolled, read the whole article and got to the bottom of the page.

The Scroll Tracking Code

Here is the JavaScript code that measures user scrolling.

TIP – You can use the tabs at the top of the code window to try the script. Just click on Result.

What’s changed in this version?

First, the blog post title is now collected as part of the event. Specifically I’m pulling the page title from the HTML and putting it into the event label. This makes it easier to drill down and see which pages people are reading. This was possible before using the Page Title dimension, but using the event label makes it just a bit easier. See the image above.

Another thing I change is I now use a Custom Dimension rather than a Custom Variable, to collect the ‘reader type’. Custom variables do not exist in Universal Analytics.

This change will impact your data! You will no longer see data in the Custom Variables report – because you’re not using Custom Variables. Custom Dimensions are only available in Custom Reports and Custom Dashboards.

I also changed how the Custom Dimensions are set. This script will set a Custom Dimension when the user reaches the bottom of the post content – not the bottom of the page. When they reach the bottom of the content they are categorized as a scanner or a reader.

• A scanner is someone that simple scrolls to the bottom of the content in less than 60 seconds.
• A reader is someone that take more than 60 seconds to reach the bottom of the content.

This is hardly a scientific way to categorize users, but it works for me :)

Finally, I added three custom metrics to store the time metrics: time to scroll, time to content bottom and time to page bottom.

Remember, in order to configure Custom Dimensions and Custom Metric you must first add them via your Google Analytics admin settings.

Other than the above changes the functionality is still the same.

Implementing the code

Step 1: There are a few code changes that you must make in order for this code to work on YOUR site.

1. Turn off debugging: This flag will display alert messages, rather than send GA data, when the user scrolls, reaches the bottom of the content and reaches the bottom of the page. If you do not set this to FALSE your users will get all sorts of alert messages :)

2. Decide how far you want for scroll depth: I send an event after the user scrolls 150 px. You can change this value, but I believe it works fine and does capture user engagement.

3. Specify where the bottom of your content is: This is the most important setting. This script sends an event when the user gets to the bottom of a post. That’s determined by the HTML. For me, the HTML is identified as .entry-content, as shown in this code.

[code lang=”js”]
if (bottom >= $(‘.entry-content’).scrollTop() + $(‘.entry-content’).innerHeight() && !endContent) {
[/code]

You must change this line of code to identify a piece of HTML on your site that signifies the end of the content. This is the hardest part of the implementation.

Step 2: Add the code before the closing [code][/code] on your site. Make sure it appears AFTER the Universal Analytics page tag. It should look something like this when complete:

[code lang=”js”]
<head>

… all sorts of tags …

<script>
//
// Universal Analytics page tag
//
(function(i,s,o,g,r,a,m){i[‘GoogleAnalyticsObject’]=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,’script’,’//www.google-analytics.com/analytics.js’,’ga’);

ga(‘create’, ‘UA-XXXXXX-YY’);
ga(‘send’, ‘pageview’);

//
// Scroll tracking script
//
jQuery(function($) {
// Debug flag
var debugMode = true;

// Default time delay before checking location
var callBackTime = 100;

// # px before tracking a reader
var readerLocation = 150;

// Set some flags for tracking & execution
var timer = 0;
var scroller = false;
var endContent = false;
var didComplete = false;

… More code here …

</script>
[/code]

That should be it. You should see data instantly in the Real Time Event reports.

I encourage you to read the instructions in my original post.

Finally, a lot of people have asked me about implementing this script with Google Tag Manager. This really warms my heart :) I love tag management!

You can use this script with Google Tag Manager – but it takes a bit of work. I’ll write a separate post on that topic.

That’s it. I hope you find this script useful. Feel free to modify it to fit your needs. I’ve really enjoyed the data that it generates – it’s helped me better understand my readers and content.

All digital analytics data is organized into a general hierarchy of users, sessions and hits. It doesn’t matter where the data comes from, it could be a website or a mobile app or a kiosk. This model works for web, apps or anything else.

Digital analytics data is organized into a hierarchy of hits, sessions and users.

Sometimes we use the terms visitors instead of users and visits instead of sessions – they’re analogous. The onset of mobile devices (and other devices, like set top boxes) have prompted us to introduce new terms into our vocabulary.

It’s important to understand each piece of the hierarchy and how it builds on the other to create a view of our customers and potential customers. Because, at the end of the day, we need to use this data to evaluate our decisions and look for new business opportunities.

Let’s start at the bottom, with hits, and work our way up to users.

Hits

A hit is the most granular piece of data in an analytics tool. It’s how most analytics tools send data to a collection server. In reality, a hit is a request for a small image file. This image request is how the data is transmitted from a website or app to the data collection server.

All data is sent using a hit. Most hits are actually the request for an invisible image file.

There are many different kinds of hits depending on your analytics tool. Here are some of the most common hits in Google Analytics:

Pageviews/Screenviews: A pageview (for web, or screenview for mobile) is usually automatically generated and measures a user viewing a piece of content. A pageview is one of the fundamental metrics in digital analytics. It is used to calculate many other metrics, like Pageviews per Visit and Avg. Time on Page.

Events: An event is like a counter. It’s used to measure how often a user takes action on a piece of content. Unlike a pageview which is automatically generated, an event must be manually implemented. You usually trigger an event when the user takes some kind of action. The action may be clicking on a button, clicking on a link, swiping a screen, etc. The key is that the user is interacting with content that is on a page or a screen.

Transactions: A transaction is sent when a user completes an ecommerce transaction. You must manually implement ecommerce tracking to collect transactions. You can send all sorts of data related to the transaction including product information (ID, color, sku, etc.) and transactional information (shipping, tax, payment type, etc.)

Social interaction hit: A social interaction is whenever a user clicks on a ReTweet button, +1 button, or Like button. If you want to know if people are clicking on social buttons then use this feature! Social interaction tracking must be manually implemented.

Customized user timings:User timings provide a simple way to measure the actual time between two activities. For example, you can measure the time between when a page loads and when the user clicks a button. Custom timings must be implemented with additional code.

That’s a lot of hit types!

All hit types are sent to Google Analytics via a tracking code. The tracking code variation depends on what you are tracking. If you are tracing a website then JavaScript code, named analytics.js, generates the hits. If you are tracking a mobile app then an SDK (either Android or iOS) generates the hits. If you are tracking a kiosk, then YOU generate the hits with the measurement protocol.

Regardless of the hit type, the hits are all formatted in a similar manner. They are a request for an invisible image and contain data in query string parameters.

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&de=UTF-8&dt=Analytics%20Talk%20-%20Digital%20Analytics%20for%20Business&sd=24-bit&sr=1920x1080&vp=1308x417&je=1&fl=12.0%20r0&
_utma=32856364.1751219558.1391525474.1391525475.1391525475.1&
_utmz=32856364.1391525475.1.1.utmcsr%3D(direct)
%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)&_utmht=1391525534970&
_u=cACC~&cid=1751219558.1391525474&tid=UA-91817-11&z=378275262

For all the nerds out there, the data hits can be sent via a GET request or a POST request. This is really important to know, because the amount of data can change. With a GET request you can only send 2048 characters of data. Technically a post can be any length (it’s a setting on most servers), but it’s around 8000 characters when sending data to Google Analytics.

The information in a hit is transformed into dimensions during processing. Every report is just a single dimension, and the corresponding metrics for each value. that you see in your reports.

Each report in Google Analytics shows all of the values for a single dimension, and the corresponding metrics for each value.

A quick note on mobile…

The mobile SDKs do not send data in real time. They actually store the hits locally and them send them in bursts. This is called dispatching and it’s used for a couple of reasons. First, mobile devices are not always connected to a network. So analytics must store the hits until it detects a connection and then it sends the hits. Second, sending hits in a bunches can help conserve battery life. Don’t worry, dispatching does not impact session calculations – which we’ll talk about right now :)

Session

A session is simply a collection of hits, from the same user, grouped together. By default, most analytics tools, including Google Analytics, will group hits together based on activity. When the analytics tool detects that the user is no longer active it will terminate the session and start a new one when the user becomes active.

Most analytics tools use 30 minutes of inactivity to separate sessions. This 30-minute period is called the timeout.

A session is a collection of hits. It ends when there has been 30 minutes of inactivity.

Google Analytics, and most tools, use the time between the first hit and the last hit to calculate the time on site. The time between hits is also used to calculate other metrics, like time on page. You can read more in my overview of how Google Analytics performs time calculations.

Most tools let you change the default timeout to better suit your needs. For example, if you have a lot of video on your site you might want to change the timeout – especially if your video last more than 30 minutes.

Why?

If a user is watching a 60 minute video (and by watching I mean that no other hits are sent to analytics) their session will end 30 minutes after the first hit. To insure that the session lasts until the end of the video you could change the timeout to match the longest video length.

OR, a better way to extend the session, would be to send additional hits while the user is watching the video. Think about it – more hits create more data points that can be used to calculate time. Trust me, take 12 minutes to read more about how Google Analytics performs time calculations.

Now that we know that hits are grouped together into sessions, let’s look at how sessions are grouped based on users.

Users

Here’s where things start to get interesting. A user is the tools best-guess of an anonymous person. Users are identified using an anonymous number or a string of characters. The analytics tool normally creates the identifier the first time a user is detected. Then that identifier persists until it expires or is deleted.

The identifier is sent to the analytics tool with every hit of data. Then the analytics tools can group hits (and thus sessions) together using the identifier in the hits.

Make sense?

Sessions from the same user can be grouped together as long as each hit has the same user ID.

Here’s how users are detected on some of today’s most common digital platforms.

Website Users

To measure a user on a website almost all analytics tools use a cookie. A cookie is a small text file. The cookie contains the anonymous identifier. Every time a hit is sent from the browser back to the analytics server identifier stored in the cookie is sent along with the data.

When measuring a website, the analytics tool usually uses a first party cookie to store an anonymous ID.

Now let’s have the cookie talk.

Google Analytics uses a first party cookie. A first party cookie is connected to the domain that creates it. A first-party can only be used by the domain that sets it. So on this site, the cookie has a domain of cutroni.com and can only be used by this website.

In Universal Analytics the cookie is named _ga and lasts for two years. In the previous version of Google Analytics the cookie was named __utma.

The good thing about a first party cookie is that almost all browsers will allow a first party cookie. It’s a very reliable piece of technology.

First party cookies are challenging when your site spans multiple domains. When a user leaves your site, and traverses to another site that you own, they do not take their first party cookies. In most situations, unless you configure analytics correctly, analytics will set another cookie when the user lands on the second domain.

Analytics uses a first party cookie to maintain a user identifier.

Now you have one user with two cookies. That could lead to double counting of users. Plus, if we want to create really cool metrics, like Revenue per user, it becomes very, very hard because we don’t know the true number of users.

The other type of cookie, a third-party cookie, can be set and accessed by domains other than the domain that creates it. Some analytics tools will let you use a third party cookie.

The value of a third party cookie is that the analytics tool can use a third party cookie to identify a user as they move from one domain to another.

A third party cookie can be used by multiple domains.

However, third-party cookies are not permitted by most browsers – that means no data.

Google Analytics does not use a third party cookie. You can read all about the Google Analytics cookies in the developer documentation.

So what’s the solution here? How do you correctly identify a user if your website spans multiple domains? In the Google Analytics world we use a feature called Cross Domain Tracking. I’m not going to talk about it in this post, but you can read about it in our support documentation.

Mobile Users

Now let’s move on to mobile platforms – something that is very popular :)

Mobile tracking is similar to web tracking. There is an anonymous identifier stored on the device. The identifier is generated every time the app is installed. So if a user deletes the app the identifier will also be deleted. But if a user updates the app the identifier will not change.

The big difference between mobile and web is that the identifier is not stored in a cookie. It’s stored in a database on the mobile device – but it basically functions the same way as a cookie. The identifier is sent on every hit back to the analytics server. The analytics server then uses the identifier to create metrics like unique users.

Here’s one challenge with user measurement on an app. Many apps are not just an app. They’re a hybrid app/website. They use a browser within the app to “frame” content from a website. This can mess up the data collection.

In this situation we have two technologies with two different user identifiers. The app will measure a user based on the ID stored on the device and the website will use a cookie when a page loads in the app.

Mobile apps that “frame in” content from a website, might be sending duplicate hits to the analytics tool.

There are some ways around this, but it’s a long solution that need it’s own blog post. But just be aware of this potential data issue.

Ok, so now we know about website users and mobile users. But what about other digital touch-points, like a kiosk?

Other Digital Touch-points

In today’s world a user can interact with your digital content on lots of different devices (computers, mobile, kiosks, set top boxes, etc.). And that can cause a lot of issues as tools try to de-duplicate users and get an accurate count of users.

One of the key features of Universal Analytics is the ability to track users on devices other than websites and mobile devices, things like a point-of-sale system or a kiosk. It does this using a technology called the measurement protocol.

But how does it actually work?

The measurement protocol works by – wait for it – collecting hits :) These are the same hits that I described above. The big difference is that you must manually build the hits. So if you want to implement analytics on a kiosk, you must create MORE code to build the hits that are sent to Google Analytics.

But what about measuring users when you use the measurement protocol?

When you create the hit you must insert a user identifier into the hit. Google Analytics will then use this identifier as the unique identifier when it processes the data.

To measure users when tracking other devices, like a kiosk, you must insert your own identifier and generate your own data hits.

Unlike websites and mobile apps, there is no cookie or database to store the identifier. So the ID does not persist from one hit to another, or from one session to another. You must manually insert the identifier into every hit in every session.

Your code must control the generation of the identifier and the storage of the identifier.

Let’s end it there. That’s a pretty good overview of digital analytics data.

I know this was a really geeky post, but it’s an important subject and will become more and more important.

Now it’s your turn. Thoughts? Please feel free to leave a comment.

In this post I’ll talk about how to actually use the data and walk through some examples for various business types.

If you have not set up content groupings, please check out my post on how to set up Google Analytics content groupings.

Standard GA Reports

Your content groupings are available in Google Analytics behavior reports. Navigate to the Behavior > Site Content > All Pages report. Notice at the top of the data table there is a selector for the primary dimension. This drop down list all of the content groupings that you added to Google Analytics.

Use the selector to choose a specific content grouping in your Google Analytics Content reports.

This selector also exists in the navigation flow, so rather than viewing how users move from page to page, you can view how users move between the different types of content on your site.

You can also use your content groupings in the Navigation Summary report.

Very handy for understanding the behavior of users!

It also exists in many other content reports, like the Landing Pages report and the Site Speed Page Timings report.

But who uses the standard reports these days? :) Analysis driven organisations use Custom Reports and Dashboards. Let’s look at how you can use content groupings in both features.

Custom Reports & Dashboards with Content Groupings

When you create a content grouping, Google Analytics will create a dimension for each content grouping.

Remember, a content grouping contains a number of groups, and each group can contain a number of pages or screens.

Each content grouping contains multiple content groups. A content group contains multiple pieces of content.

This means that the values for the content grouping dimension will be all of the content groups that you created within that grouping.

You can create up to five content groupings in Google Analytics, therefore you could have five new dimensions, one for each content grouping.

Use the content grouping dimensions just like you would any other dimension. Here’s a simple custom report that shows some a potential content grouping for a blog.

You can use your content groupings in a Google Analytics custom report.

Then, when you look at the report, you’ll see something like this:

When you add a content grouping to a Google Analytics custom report, the data will be aggregated based on content group.

Note: I added this custom report to the Google Analytics solutions gallery. You can add it directly to your account here.

You can also use the content grouping dimension in your dashboards. Here is a very simple example using the page value metric and the content grouping dimension.

You can also use the Content Grouping dimension in a Google Analytics Custom Dashboard.

That’s really all there is to using content grouping in Google Analytics custom reports and custom dashboards. No go and give it a try!

One other note – the content grouping dimensions are hit level dimensions. This means that you can only use them with hit level metrics, like pageview, time on page, etc. You can not use them with session level metrics, like conversion rate, or revenue per visit.

Content Grouping Strategies

To really take advantage of content groupings you need to plan your content grouping carefully. You need to understand how your organization wants to analyze this data. So let’s look at a how different types of businesses might use content grouping.

Ecommerce: Patagonia.com

Patagonia sells outdoor equipment for men, women and children. They’re known for their ethos that you should travel “fast and light” when in the outdoors – take only what you need. They’re also known for their environmental advocacy. They incorporate both of these messages into their marketing stories.

Effectively breaking down the content structure could help each department at Patagonia better understand their marketing initiatives and site optimization efforts.

So how might we create a content grouping strategy based on their business?

Google Analytics Content Grouping can be used to organize the content on an ecommerce website.

Product pages: I would start by grouping all product pages together. It’s really important to understand what percentage of your users are making it to product pages. If people don’t look at product pages then they usually can’t buy something. And I’d take it one step further – group product pages by product line. I’d also be sure to differentiate category pages from the generic product pages.

You can mimic your product architecture with your content groupings.

Special selling tools: One cool feature that the Patagonia site has is the ‘kit builder’. This is a tool that let’s a customer build the best clothing combination for different conditions or activities. This is another section that could really use it’s own content group.

Special shopping tools can be categorized in their own group.

Checkout pages: Next I’d group all checkout pages together. These are all the pages in your checkout process. The percentage of people that see checkout pages might be very small, but I like to put these pages in their own group. They’re not product related, and they’re not marketing related. So they need their own group.

Account management pages: Many ecommerce sites let customers manage account settings, check the status of their order, manage returns, etc. I would lump all of these pages together in an Account Management group.

Marketing pages: Now we get into a large chunk of the content – marketing pages. Patagonia has a lot of information about their brand, and initiatives. Rather than lump all of this together as just Marketing pages, I would actually break all of this up into groups based on the different initiatives.

In the case of Patagonia I would use all of these different groups that you can see in the navigation.

Use a Google Analytics Content Grouping to categories marketing pages.

Support pages: Business is all about relationships – and that’s represented by different types of support content. We can create a support group that containing any materials related to support. Again, you can create sub-groups for different types of support content (product support, order support, etc.)

Error pages: I like to group all error pages into a single group, then I can drill into the group and view the specific errors. This group can contain all different kinds of errors, depending on your personal preference. It could be technical errors, like 404 or 502 errors. Or it could be more functional errors, like when a user adds an incorrect credit card number during their purchase.

Software as a Service: Mailchimp.com

Mailchimp is a popular service that helps businesses manage their email marketing initiatives. Like all SaaS sites it’s primarily divided into two sections: a marketing section and an application section. The content grouping will mimic this general structure of content.

Product marketing pages: If people are going to sign up for the Mailchimp service then they need to know about the features! Product marketing page are pages dedicated to product information, this includes information about price, features, etc.

For a SaaS site, create groups for different kinds of marketing content.

In addition to specific product information, there’s also a lot of thought leadership material to help drive marketing.

Marketing content pages: These pages are non-product marketing pages that help you demonstrate your thought leadership. It may be blog pages, or other content. In our example of mailchimp.com, there might be multiple groups. For example, they have a blog, but they also have a ton of research about email marketing. I would put this material in a marketing content group. Or even better, in the Reports group!

I would create a Google Analytics content group for the research reports on the MailChimp site.

Application pages: The other side to a SaaS site is the actual application. This is the section of the site where you log in and actually use the product. Like the marketing pages, there can be many different types of application pages. Let’s go back to our example of Mailchimp.com. I would break down the content based on product features.

Perhaps we could use the application navigation as a template for the content structure.

You can create different groups for each part of the online application.

Account management pages: Here’s another example of grouping different parts of the application together. We could easily group together the pages that control account management. And you can see from the image above that there are sections of the app dedicated to other functionality – all should be grouped accordingly.

Error pages: Like other types of sites it’s a good idea to group all error pages together. See the ecommerce section above for more details. These groups can be both website errors or application errors – like a login error page.

Gaming Application: Clash of Clans

We all use our mobile devices for incredibly important things, like waging medieval warfare on other clans! HA! Anyone out there like Clash of the Clans?

You can categorize app content using Google Analytics Content Groupings.

In reality, gaming apps are very similar to other business models – like publishing and commerce. Some games generate revenue from in-game ads while others up-sell users on features, like new levels. Some do both. We can group games content together just like we do ecommerce.

Game level screens: Most of the content for a game is probably level based. We can replicate this base structure in Google Analytics. If you’re a fan of Clash of the Clans then you there are other parts to the game in addition to levels. There are attack screens, chat windows, etc. All of these screens can be added to groups to roll-up the data.

Ecommerce screens: These screens are used to sell the user on pay features. In the case of Clash of Clans you can buy more gems, which can then be used to purchase other items, like more armies!

I would put all ecommerce app screens into a separate content group.

Configuration screens: Most apps have a configuration section. This is where the user can change everything from the language, to colors, etc.

Error screens: Last but not least we have error screens. Again, these can be technical app errors or functional errors, like login issues.

For Publishers: MarketingLand.com

Let’s face it, content grouping was made for the publishing industry! They’re the ones that have to organize thousands of pages of content. I don’t want to dwell on publishing too much, but let’s take a look at MarketingLand.com, a popular destination for anyone working in the digital marketing world.

I’ve actually written about how to customize google analytics for publishing sites in the posts Custom Variables for Publishers and how to measure how far users scroll down a page. I think both of those techniques still apply.

But now, if you’re a publisher, you can also use content groupings to organize the data about your content. This provides one more way to roll up data for analysis.

Content Category: Almost all publishers group content by category – and now this can be done with the content grouping feature.

Publishers can create content groups based on the organization of their content.

Some publishing sites organize content in other ways, like by author or publication date. I would suggest creating content groups for topic categorization, and custom dimensions for any secondary organization (author, date, etc.)

Account pages: Some publishers, like the New York Times, offer a premium membership service. This is not the case with MarketingLand.com. But, if it did have a member’s section, you could group all of those pages together.

Error pages: Do I need to go over this again :)

I hope this post provides some inspiration for how you might use Content Grouping for your business. Ultimately how you organize your content groupings will be based on your organization. There is no right or wrong – just use a structure that is useful.

Questions or comment? Leave a note below – and happy grouping!

This feature let’s you categorize your content based on your own business rules. Then, rather than view your data based on page URL or screen name, you can view based on your specific groups.

In this post I’m going to talk about how content grouping works and how you set it up.

Key Vocabulary: Groupings and Groups

There is a little terminology we need to cover before we get into the setup: groupings and groups.

You can create multiple content groupings in Google Analytics.

Within a grouping you can create multiple content groups.

A group is a collection of content. It could be pages in a certain section of your website. Or it might be screens from a certain part of your app. It can be just about anything.

A grouping is just a bunch of groups.

Each content grouping contains multiple content groups. A content group contains multiple pieces of content.

You can create multiple content groupings in Google Analytics and switch between them in the reports.

Here’s an example. For my blog I created a grouping called Blog Content Categories.

Within that grouping I create a number of groups to categorize the different types of content on my blog. There’s a group for posts, a group for about me pages, a group for error pages, etc. In the configuration I created a rule that puts each page in a group based on the structure of the URL.

You can view your content data based on groups, rather than URL, screen name or title.

Any item that is not added to a group will appear in the (not set) content group.

It’s important to know that there is not one specific report where you access this data. When you create a grouping it’s literally becomes a new dimension of data. You choose to view that dimension in almost all of the content reports.

Let’s take a look at how you actually create a grouping and groups.

Creating Groupings & Groups

Google Analytics does not automatically create content groupings – you must configure the tool to do that. Navigate to the settings for a specific view and choose Content Groupings.

Content Grouping is a view level setting.

Here you will see a list of all your groupings. You can choose to create a new group or edit an existing group.

Here’s a list of your Google Analytics content groupings. You can add or edit groupings here.

There are three methods you can use to create a content group – let’s take a look at each.

Tracking Code Method

This method requires you to add a small piece of code to each page on your site or in your app. The code will literally set the name of the content group when the page or screen renders. Here’s how the code would look for Universal Analytics:

ga('create', 'UA-XXXXXXXX-Y', 'example.com');
ga('set', 'contentGroup5', 'Group Name');
ga('send', 'pageview');


Or, if you’re working in iOS the code might look like this:

id tracker = [[GAI sharedInstance] trackerWithTrackingId:@"UA-XXXX-Y"];
[tracker set:[GAIFields contentGroupForIndex:5]
value:@"Group Name"];

The code for a content group is similar to the code for a custom dimension. You can set 5 content groups using the tracking code. Each group is associated with a number, one through five, as shown in the example above.

Check the Google Analytics support documentation for more code examples.

Basically this method let’s you suck in the group name, via code, from some other system. It might be a CMS, a data layer, or just the HTML of the page.

The key is that you somehow add the name of the group to the Google Analytics code.

Pros: Using the tracking code method you can use code to automatically adjust to changes in your content and new content groups.

Cons: It requires IT involvement to set up. But once it’s configured very little IT support.

I should also mention that content grouping is coming to Google Tag Manager. This will provide another way to programmatically set the content group – so stay tuned.

Extraction Method

The extraction method extracts (get it) the name of your content groups from an existing dimension of data. The idea is that you use a regular expression to parse the dimension and automatically extract the name of your group.

For example, the name of your content groups might be in the page title, like this:

Your website might use the name of the content in the Page Title or Screen Name dimension.

I would need to specify that my group name is in the Page Title dimension, and then provide a regular expression that extracts the appropriate value.

The content grouping extract method will automatically pull the name for a content group from a dimension of data.

For those of you that do not use regular expression, the value in the parenthesis will automatically be extracted. Google Analytics will then use the value as the group name.

You can see that this one rule will work for every product page on my site – as long as they are well formatted.

Pros: No coding involved. Flexible collection.

Cons: You might need to update your regular expressions when you add new content to your site or app. Specifically something that does not match your existing rules. Believe me – updating settings SUCKS. People forget to do it all the time.

In you’re new to regular expressions check out this reg ex tutorial in the Google Analytics help center.

Rules Method

The rules method is almost exactly like the extract method. The ONLY difference is that you have to MANUALLY name the group. The value for the name is not automatically pulled from a dimension of data.

The content grouping extract method will automatically pull the name for a content group from a dimension of data.

Like the extract method you can create rules based on different dimensions of data- the page title, page url or the screen name. If the dimension value matches the rule then the content is added to the group.

Pros: No coding. Don’t need to know regular expressions.

Cons: You need to remember to update your rules when you add new content or if your site urls or app screen names change. Again – updating your analytics settings SUCKS. People forget to do it all the time.

Which method should you use?

That’s a tough question. Personally, I think page category is a critical piece of data that should be added to a page data layer. If you take this approach then using the tracking code method is very scalable.

I also like the extract method. It’s very flexible and reliable – as long as you have processes in place to maintain your implementation :)

Important things to know

Ok, so here are a few very important things to know.

You can use all three methods for creating groups within the same content grouping.

The grouping logic is applied to your data sequentially. That means that Google Analytics first applies the tracking code method first. Then it applies the extraction method. And finally it applies the rules method. You can use all three methods for your implementation.

When a page or screen matches a rule it is added to that group.

A page or screen can only be in ONE content group at a time! That means that an page or screen can only belong to one group at a time.

And finally, content groups are NOT applied to historical data. They are only applied from the moment you configure the feature.

A Best Practice

Because Google Analytics applies all grouping methods to your data, it is possible to use a combination of grouping methods.

But, because they they are applied SEQUENTIALLY, it’s a good idea to put your very specific grouping rules first, followed by your general rules. This way the later, general rules will catch anything that slips through the early, specific rules.

All three content grouping methods are applied to each piece of content. They are applied sequentially.

It’s really, really important to try and get your groups right the first time. While you can edit your groups, there is no way to change the data that has already been processed.

Make sure you test your groups first before announcing them to your entire team.

It’s also a good idea to add an annotation to Google Analytics so everyone knows when the data was added.

Ok, I think that’s it for how to implement this feature.

Don’t worry – I’ll explain how to use content groups in a couple of days.

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.

Note: Custom Dimension and metrics are only available in Google Analytics customizations – this includes custom reports, custom segments and dashboards. They can also be used in certain analysis tools, like secondary dimensions.

An Example: Uploading simple publisher 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!

Auto Event Tracking let’s you track almost any user action without any additional JavaScript. It automatically captures user actions like clicks and form submissions.

TL;DR: watch this video.

For all you Google Analytics users, this means that it is no longer necessary to add JavaScript to track PDF downloads, outbound links or other user clicks. Those tasks, and many others, can be automated with Google Tag Manager.

I know – it’s exciting! Less coding = faster data collection = more reliable data quality = better insights.

There are a number of new additions to GTM that make auto-event tracking possible. Let’s take a look at how the system has changed to make this possible.

How Auto-Event tracking works

Here’s a brief overview of how the new auto-event tracking works.

Listen, Capture Collect. How the Auto-event tracking works for Google Tag Manager.

1. Listen: A new type of tag, called an Event Listener tag, will listen for different types of user actions, like clicks or form submissions.

2. Capture: When the Event Listener tag detects an action it identifies it and captures it (technically it pushes a Google Tag Manager event onto the data layer).

3. Collect: You can then automatically collect the action using additional tags, like an analytics tag.

Remember, this all happens without any additional coding. All you need to do is add the necessary settings in GTM.

There are three new pieces of functionality that make this possible:

1. The new Google Tag Manager Event Listener tag.

2. New events that indicate a user action has occurred.

3. New macros that collect information about the user’s interaction with the content.

The Event Listener Tag & Automatic Events

Let’s start with the new tag, called The Event Listener tag. This is a special tag that – wait for it – listens for a user action on a page :)

When the tag detects an action it automatically collects the action and identifies it. From a technical perspective is pushes a Google Tag Manager event to the data layer.

There are four different types of user actions that the tag can detect. Again, each action results in a Google Tag Manager event.

Click listener: this tag will listen for clicks on a page. This includes button clicks, link clicks, image clicks, etc. When a click occurs, the Google Tag Manager event gtm.click is automatically generated.

Form listener: this tag will listen for any form submissions. When a form submission occurs the Google Tag Manager event gtm.formSubmit is automatically generated.

Link click listener: same as the click listener, except it only captures clicks on links. When a link is clicked, the Google Tag Manager event gtm.linkClick is automatically generated.

Timer listener: the timer listener will collect data at some regular interval that you specify. For example, if you specify an interval of 10,000 milliseconds, GTM will fire an event every 10 seconds.

Obviously, if you want to automatically listen for user actions you must include one of the above tags on the page where you would like to capture the user action.

For example, let’s say you want to capture clicks on outbound links (this means links to other websites). Chances are you have outbound links on all of your pages. So you should add the Link Click listener tag to all pages of your site.

Remember, to add a tag you need to specify a rule that governs when the tag is added to a page. Here’s the default rule to add a tag to all the pages on your site.

Use the GTM All Pages rule to add a common event listener to every page on your site.

But let’s say you want to capture a form submission, like a contact form. There really isn’t any need to include that tag on all of your site pages. So you can create a rule to add the tag to just your form page, like this:

To control the form listener tag, restrict the placement with a rule.

The new Events are important because they identify that an action has happened. I’ve got some example below.

Understanding the New Auto Event Macros

In addition to the new tags & events there are also a number of new macros that help collect the action that occurred.

A macro is a piece of data that you can use in your tags. Some macros are automatically populated, like the url macro (which is the url of the page), the hostname macro (which is the hostname of the site), or the referrer macro (which is the HTTP referrer).

With the Auto Event Tracking macros you can automatically add data about the element the user interacted with to your analytics tag (or any other tag).

There are five new macros that can provide elements information:

Element url: This macro stores the value of the href or action attribute of the element that triggered the event. For example, a click on the link < a href="http://www.cutroni.com">Analytics Talk< /a> would result in an value of http://www.cutroni.com.

Element target: This macro stores the value of the target attribute of the element that triggered the event. Nerd Bonus: The value is stored in the gtm.elementTarget variable in the data layer.

Element id:This macro is the value of the id attribute of the element that triggered the event. For example, a click on the link < a href="http://www.cutroni.com" id="outbound_link">Analytics Talk< /a> would result in an element id value of outbound_link. Nerd Bonus: The value is stored in the gtm.elementId variable in the data layer.

Element classes: This macro is the value of the class attribute of the element that triggered the event. Nerd Bonus The value is stored in the gtm.elementClasses variable in the data layer.

Element: This macro is also the value of the action or href attribute of the element that triggered the event.

Let’s put this all together and look at some of the common analytics tracking tasks you can implement with data layer.

Tracking Clicks

Sometimes we need to track user clicks – a click on a button, image or link. Before Auto Event Tracking we would need to add extra JavaScript to the site in order to fire analytics code. Now we just use the Click Listener tag to detect a click.

Let’s walk through how to track ALL clicks on a page and capture them with a Google Analytics event.

First, add the Click Listener tag to the necessary pages. You can add it to all pages, or just a select few. It depends on what you need to track.

The Click Listener tag will listen for user clicks and execute when a click is detected.

Next, we add our Google Analytics tag to execute, and thus collect, when the click happens. Notice that I am hard-coding the Event Category to be click but the Action and Value will be dynamically populated with data from the HTML element that the user clicked on.

We can use a GTM macro to automatically capture the HTML element that the user clicked on.

The value of the action is capturing the generic name of the HTML element. This might be [object HTMLInputElement] for a form element or [object HTMLBodyElement] for the body of the page. These are fairly descriptive and can help you understand what happened.

But a better strategy would be to capture the element class or element id. These are usually more descriptive.

Here’s the rule that determines when to acctualy collect the click. Basically it will collect EVERY click on the page using a Google Analytic event. We’ll look at a few examples later that will restrict the collection to only certain elements.

The gtm.click event indicates that a user clicked on something. This causes the Google Analytics tag to fire.

I should note that this approach will NOT work for content that is in an iFrame. For example, if you embed a YouTube video in your page, you can not capture clicks on the buttons, etc.

Using this general approach can generate a lot of data – crappy data! Let’s look at reducing the amount of data by tracking certain types of clicks.

Tracking Outbound Links

We all want to know where people go after they visit our site. Did they leave using a link in an article or did they just navigate away?

To track a click on an outbound link we follow the same general process we outlined above. The big difference is we need to make sure we only track clicks on links that go to another site.

First, we add the Link Click Listener tag to the necessary pages. Because there usually outbound links on every page, I apply the Link Click Listener tag to every page on the site.

The Link Click Listener tag will listen for user clicks on links.

Now we need to add an analytics tag to collect data when a click happens. Let’s use Google Analytics and collect the data in an event! Notice that I am hard-coding the Event Category value to outbound-link.

The Event Action will be dynamically filled with the destination URL. That’s the URL of the page the user will land on. This is all made possible thanks to the element url macro.

The element url macro will automatically add the destination url to the Google Analytics event.

Here’s the important part – the tag rule. Notice that there are two parts to the rule. First I need to check for clicks on links. But I also added an additional condition that stipulates the link must not match cutroni, which is the domain of this blog. Now the Google Analytics tag will only fire and collect the click if the link is to a different domain.

Add a rule to specify what is an outbound link clicks on your site.

Tracking file downloads

File downloads are very similar to outbound link clicks. I just use a different Listener tag.

Let’s just skip to the analytics tag that will collect the data.

I’m using a Google Analytics event again. The category is hard coded as file-download. The event action will be the URL of the file and it will be dynamically populated using the element url macro.

The element url macro will automatically add the PDF url to the Google Analytics event data.

Just like I did with the outbound link tracking, I need to modify the rule to include a condition. The condition specifies that the user clicked on a link that contains .pdf.

To track a PDF link click add a condition to your tag firing rule.

Hopefully you can use this example and track clicks on any type of file that you want.

Tracking Form Submissions

Now let’s move on to forms. You could track a form using the Click listener tag. Basically you would track all of the clicks on the Submit button. But the form

We start with the Form Submission listener tag. Rather than add this tag to every page on the site, I like to only add it to pages where there is a form.

The form listener tag can be configured to delay the form submission while data is collected.

ALso notice that you can configure the form listener tag to delay the form submission to insure that the data is collected.

The tag will delay the form for up to two seconds only. Anything longer than that will create a bad user experience. GTM is smart like that :)

Just like the click tracking, there is also a form-submit event that will be generated when a user submits the form. We use this event to set up our analytics tag with a rule to control the execution.

This rule will only fire the Google Analytics event tag when a form is submitted.

I can actually pull some of the data in the form elements directly into my analytics tag using a macro.

For example, let’s say I have a form element named Gender. I can use a macro to capture the data, then use that macro when I define my Google Analytics Event, like this:

You can collect data from a form element using a macro and send the data to Google Analytics.

REMEMBER it’s not cool to collect personally identifiable information.

Here’s a bit more information on creating and using macros.

But overall, tracking a form submission is fairly straight forward. Very much like the other scenarios above.

There you have it, some of the common ways to use the new Auto Event Tracking feature.

That was a really looooong post. Hopefully it gave you a good understanding of how this feature works and how you can use it to make data collection easier to implement and maintain.

Give auto-event tracking a shot and be sure to share your experience in the comments below.