The Google Analytics platform has been changing from a web analytics tool to a user-centric digital measurement tool (we’ve been calling it Universal Analytics). This evolution includes a number of changes to the system and completely new features. But what can you do when you put all of these pieces together? I wanted to write […]
The Google Analytics platform has been changing from a web analytics tool to a user-centric digital measurement tool (we’ve been calling it Universal Analytics). This evolution includes a number of changes to the system and completely new features. But what can you do when you put all of these pieces together?
I wanted to write a quick post about how a business could use the entire platform to better market to users on the web based on non-website activities. We’ll explore how to use offline and online data to create remarketing lists in Google Analytics.
Before I start a hat-tip to my buddy Dan Stone – a product manager at Google Analytics who often talks about this type of usage.
Influencing Display Advertising using Email Behavior
Businesses interact with users via many different channels – search, display, social, email, etc. And they’re always looking to better understand how one channel impacts another channel. That’s why we have attribution modeling.
But sometime we want to take direct action, or even automated action, in a channel based on user behavior in a separate channel.
For example, I may want to change my search or display strategy for users on my email list. Perhaps I want them to see different display ads because I have a better relationship with them.
Here’s an example.
With Analytics we can collect data from email marketing tools, send it to Google Analytics and then use that information to change display campaigns.
We can send data from email marketing tools, to Google Analytics, then use the data to drive Remarketing.
With some of the new features in Google Analytics it is very possible to change a user’s display advertising experience based on behavior in other digital environments.
The first thing we need to do is bind the data in Google Analytics to the data in our own systems. This might be the data in a CRM or some other customer system. We’re going to use an old-school method that I describe in the post integrating Google Analytics with a CRM.
Here’s a summary…
When a user visits your site (or your app) Google Analytics sets a unique, anonymous identifier. This identifier is called the Client ID or cid for short.
What we need to do is extract the client ID value from the Google Analytics cookies and pass it to your CRM system. Once it’s in your systems you should be able to join your internal customer IDs with the GA ID. I should note – this is not some task you finish in an afternoon. You need some nerd help and it could take a while.
You can extract the GA identifier from the tracking cookie and send it to your own system.
Now that we have the two data sets joined we can do something really cool – we can send user-specific data to Google Analytics from other systems. This means that when we send out an email, or some other user-specific actions happens in our system, we can send that behavioral data to Google Analytics. How?
To send data to GA from other systems we use the measurement protocol. This technology let’s us send data to Google Analytics from any system that can connect to the internet. It defines how to send data to GA. We’ll use the measurement protocol to send data about email activities.
When we send an email to a user we will also send a measurement protocol hit to Google Analytics.
When an email is sent from your system, you can send a hit to Google Analytics using the measurement protocol.
Specifically, we’ll send an event piece of data. The event will indicate that an email was sent to this user and the type of email:
If we want to be really fancy then we can also send a second hit to Google Analytics when the user receives the email and another hit when the user opens the email. For example, if the user opens the email then we can trigger a pixel within the email that sends a hit to Google Analytics.
I need to stress, you need to write a bunch of code that generates these hits. The implementation will really depend on your systems.
The data in the above hits indicates that this email was part of the BackToSchool2014 campaign (look for the event data ec for Event Category, el for Event Label, ea for Event Actions. If we looked in Google Analytics the data would look something like this:
Offline email actions can be captured with the measurement protocol as events.
All of these hits include a specific parameter named cid. This is the Client ID for the particular recipient of the email that I discussed earlier. When Google Analytics processes these hits they will be merged with the dame user data from the website – because they have the same cid value.
OK, now we have user data coming from two separate systems and Goole Analytics is merging it together.
Here’s where the fun comes in.
Because all of this data is in one place, we can segment users in Analytics based on behavior, then use that list of users for remarketing.
after all of our work, we’re using the GA data measuring sent emails to create a remarketing list.
For those that have not use Remarketing, this is one of my favorite features in Google Analytics. Remarketing let’s you segment user on your website then send that list of users to Google AdWords (or DoubleClick if you use Analytics Premium) for use as a remarketing list.
The remarketing segment would look like this:
Segmenting users that received and opened an email.
This segment is all users that opened the back-to-school email. I could also add a condition that the user received the email, but that’s not really necessary.
Now we can use this list of users in AdWords. How? I may want to use the same creative for their ads. Or perhaps I offer them the same deal that was in the email.
This technique is not just for email – you can use the measurement protocol to send data from any system. That means behavioral information from other digital experiences can be used to drive remarketing lists.
Hopefully this example gives you some idea of how multiple Google Analytics features can be used together to drive real business results.
A while ago I wrote Advanced Content Tracking – a post about how to measure if users are actually reading your content. I’ve been getting a lot of requests to update this code for Universal Analytics. So here it is – an updated script specifically for use with Universal Analytics. This Google Analytics customization collects […]
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
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.
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.
Implementing analytics, or any type of conversion tracking, is a big pain in the ass. There, I said it! But it’s been getting easier and easier with adoption of Tag Management tools. Google Tag Manager is going to make it even easier with the introduction of a new feature called Auto Event Tracking. Auto Event […]
Implementing analytics, or any type of conversion tracking, is a big pain in the ass. There, I said it! But it’s been getting easier and easier with adoption of Tag Management tools. Google Tag Manager is going to make it even easier with the introduction of a new feature called Auto Event Tracking.
TL;DR: watch this video.
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.
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.