One of the benefits of being a freelance analyst is that I have access to dozens of different client instances of Google Analytics and Google Tag Manager. One common implementation I find is scroll tracking. Whether through a custom plug-in or GTM’s out of box tracking, clients often implement events that look like this:
From there, you can then add up the number of scroll events, divide them by the number of visits to the page, compare that number to other pages, and call it a day. You’ve successfully measured engagement across multiple pages.
Or have you?
A couple of things have bothered me about this approach:
Pages have different sizes which means that a 75% scroll event may be very unimpressive on a smaller page and very impressive on a larger page.
Users have different viewport sizes which means that a 75% event can trigger at different points on the page for different users.
Users with larger viewports will, by definition, trigger more scroll events on page load than users with smaller viewports.
I don’t have any silver bullets yet for #1 or #2, but I came up with a fairly elegant solution to #3 that I’m calling Differential Scroll Tracking. The idea is simple, we only track scroll events beyond what the user initially views on page load.
This is accomplished
through a simple JavaScript variable in GTM that calculates the percentage of
the document that the user can see on page load. We then tell GTM to only fire
scroll events for values above that number.
How about some examples. Here we see 3 users load the same responsive page and assume the organization wants to track scroll tracking in increments of 25%.
User A Valid Thresholds: 50%, 75%, 100%
User B Valid Thresholds: 75%, 100%
User C Valid Thresholds: 25%, 50%, 75%, 100%
We removed the possibility of a 25% event from Users A and B but allowed it for C. Additionally, User B will not trigger a 50% scroll event. Differential Scroll Tracking collects data on user engagement, rather than the out-of-box tracking which is often simply a proxy for the size of the user’s device.
Here’s how you can
configure this in GTM:
1. Create a new
JavaScript variable called “JS – Thresholds Greater than Initial
Viewport” and input the following JavaScript:
function(){
var thresholds = "";
// Calculate the % of document the user views on page load
var initial_verical_viewport_pct = document.body.clientHeight / document.documentElement.scrollHeight;
for(i = 25;i<=100;i+=25)
{
//Append thresholds only if greater than user's initial %
if(i / 100.0 > initial_verical_viewport_pct)
thresholds = thresholds + i + ",";
}
//remove last comma
thresholds = thresholds.replace(/,\s*$/, "");
return thresholds; //Example output: "50,75,100"
}
2. Create a new Scroll Depth trigger configured as follows. Note that we use our GTM variable from above in the “Percentages” field.
3. Create your GA scroll tracking tag as normal. Be sure to associate it with your new trigger.
I haven’t tried this in the wild. Let me know if you do as I’d love to hear any comments or feedback.
**Update: Google Data Studio now includes native support for GA Segments. The post below may still be relevant if you are looking to combine data from multiple sources into a single Data Studio report /Update**
Ever since Google released Data Studio in mid-2016, I’ve received a lot of interest from clients who find its data visualization and data sharing capabilities much easier to grasp than the standard Google Analytics reports. However, anyone who has put together a Data Studio report has noticed that its simplicity is both its strength and weakness. You can easily create visually compelling reports in minutes, but it lacks the sophistication of more feature-rich tools such as Tableau. One missing feature that I’ve seen users complain about is its lack of support for GA Segments. Fortunately, with the Google Sheets connector and Google Analytics add-on for Sheets we’re able to work around this limitation. Note that this same process works (and is slightly easier) with Supermetrics, but I’ll demonstrate my solution with the GA add-on for Sheets because it’s free.
Google Analytics holds a trove of information regarding the path that each user takes on your website. It’s not a leap, then, to imagine using past user behavior to predict the path that a current user will take on your website. What if we could use these predictions to download and render assets before the user requests them? Thanks to the HTML5 prerender command, we can! In this post I’ll discuss how creative applications of Google Analytics, R, Google Tag Manager, and the HTML5 prerender hint were used to create a snappier browsing experience for users of www.targit.com.
On August 2nd, Google announced the release of an updated and much improved autotrack.js plug-in that solves many common challenges that people face when implementing Google Analytics. One major change is that the autotrack library is broken out into 9 different discrete plug-ins that can be included in your solution independently of one another through the “Require” command. While there is thorough documentation from Google, I couldn’t find a nice concise description of each plug-in so I’ve provided that here.
While listening to an interview with an analytics vendor the other day, I heard a phrase that is too often repeated and can be summarized as “… we flag users as highly engaged when they type your website address directly into your browser”. The problem with this statement is nuanced but will become clear in a second.
*autotrack.js has been updated! See this post for more information*
Just 2 days ago, the Google Analytics team released a plug-in called autotrack that packs a lot of new functionality into Google Analytics. The thinking behind autotrack is that far too many clients deploy the default GA snippet and stop there. By packaging up advanced GA tracking capabilities into one, easily deployed plug-in, clients will gain more value out of their GA account. These tracking capabilities include:
Event Tracking – Track when users click on any HTML element with a certain data attribute
Media Query Tracking – Track breakpoints, orientation, and resolution
Outbound Form Tracking – Track when users submit forms that land them off-site
Outbound Link Tracking – Track when users click on an outbound link
Session Duration Tracking – More accurately track the duration of sessions by firing an event when the user closes their browser window
Social Button Tracking – Track when users click on social sharing buttons
URL Change Tracking – Track when the URL changes but the page does not refresh (important for single page applications)
While utilizing these enhancements goes beyond a “beginner” understanding of GA, by packaging them up in this easy-to-use plug-in it brings them from the clouds and into the hands of anyone with a basic understanding of GA and HTML.
For the many customers of Brightcove’s video platform, understanding user engagement (ex: play, pause, percentage watched) with their videos is key. And while Brightcove offers reports showing user engagement, there are many advantages to tying that data into a broader analytics platform such as Google Analytics. One particular advantage of this approach is that AdWords remarketing lists can be generated based on video engagement. Did a user watch your video but not convert? Remarket them!
I recently completed a Brightcove/GA integration and learned some things along the way worth sharing.
I recently completed a project with MIT Press Journals (MITPJ) as part of the Analysis Exchange, an online marketplace that connects mentors and students in order to provide free web analytics services to non-profits. The program is intended as a vehicle for providing recent entrants into the web analytics field with real-world experience while assisting non-profits with services that are typically out reach due to budget and staffing considerations. It’s a great program that I can’t recommend enough so I’ve put together the following case study that can hopefully inspire others to get involved. With permission from MIT Press, I’ve released all the deliverables for the project on Google Drive so that others can borrow/steal from our work as much as possible.
The project spanned 4 weeks and can be broken out into the following 4 phases:
Anyone responsible for measuring campaign performance has likely run into either incomplete or missing data due to incomplete campaign tagging. This can show up in the form of (not set) values in Google Analytics or in artificially inflated (direct / none) traffic.
The typical solution is to ask that everyone in your organization generate campaign links with UTM parameters such as:
However, these links and parameters are often cumbersome to generate and are prone to human error. Any typos will result in misleading data in your reports.
The question came up recently within the Digital Analytics Association member forum regarding whether one could interchange the Google Analytic’s “Unique Views” metric found when viewing a Content Group and the “Sessions” metric found when using Advanced Segments. They were asking because they had a preference for using Advanced Segments, but wanted to make sure they were comparing apples to apples. The question boiled down to this:
If I create a content group defined as “contains /blog/” and an advanced segment defined as “sessions that viewed pages which contain /blog/”, will the “Unique Views” metric for the content group be the same as the “Sessions” metric for the advanced segment?
The answer is yes. Let’s look into why.
When you create a content group and view the “All Pages” report with your content group selected, you’ll notice that the first 2 metrics displayed are “Pageviews” and “Unique Views”. Don’t be thrown off here. You may be familiar with “Pageviews”, but “Unique Views” is not “Unique Pageviews”. It’s a metric only available when viewing content groups.
Noise to Signal 
