Right here’s an fascinating and hacky use case for you. It’s all about uncovering bounce metrics for visits which originate from natural Google search outcomes. Particularly, the metric we’re focused on is how lengthy person dwelled on the touchdown web page after arriving from natural Google search AND returned to the search engine outcomes web page (SERP) utilizing the browser’s again button.
The inspiration for this submit got here from an viewers query on the Greatest Web Convention in Lithuania, which I not too long ago attended as a speaker. They had been involved that Google is utilizing Bounce Price as a search rating sign, and I used to be pretty strongly opinionated that it’s merely not attainable, as all of the “native” GA metrics are very easy to control. Nonetheless, Dr. Pete from Moz wrote about dwell time in 2012, and it makes loads of sense. Google needs to be very how lengthy the customer stays out of the SERP when following a hyperlink. If customers have a tendency to instantly return to the SERP, it’s very possible the end result was not related for them.
So, impressed by this query, I needed to see if I can get some metrics from how lengthy individuals dwell on these touchdown pages earlier than returning to the SERP. I bought my outcomes, nevertheless it’s undoubtedly not a simple drawback to resolve. As typical, we’re utilizing a mix of Google Tag Supervisor and Google Analytics to carry out the operation.
(UPDATE 17 April 2016 I up to date this text, as I needed to make some modifications to the code. It’s barely extra sturdy now, and it lends itself higher to e.g. Customized Metrics, in case you favor to make use of these as an alternative of Person Timings.)
The result’s a listing of Person Timings, the place every touchdown web page could be scrutinized towards the time customers spent on there earlier than clicking the browser’s again button.
X
The Simmer Publication
Subscribe to the Simmer publication to get the newest information and content material from Simo Ahava into your e-mail inbox!
The thriller of the historical past
The issue is that when the person clicks the browser’s again button, we’ve got no data of the place the person is taken to. That’s browser safety for you. It could be extremely questionable if the web site had entry to the historical past of the net browser. Is sensible, proper?
One other problem is the precise browser again button. It’s not a part of the browser object mannequin, so we will’t really measure clicks on it. As an alternative, we will infer a again button click on from how individuals navigate with URL hashes! When a hash change is recorded, we will infer that it was attributable to browser again if we implement a bit hack, the place the hash is exclusive to natural Google search.
You see, by creating a brand new browser historical past entry for individuals touchdown from natural Google search, the again button click on doesn’t take them to the SERP, however quite to the unique touchdown web page that existed earlier than we redirected the person to the brand new historical past state. Utilizing that as an indicator, we will extrapolate that the hash change occurred attributable to a browser again button click on (or the backspace).
The method
The method is as follows:
-
If the person lands on the location by natural Google search, create a brand new browser historical past entry with the hash #gref
-
Later, if a hash change is registered, and the person continues to be on the touchdown web page, and the hash change is from #gref to a clean string, hearth a Google Analytics timing occasion, after which programmatically invoke the “Again” occasion within the browser historical past
Seems to be easy (really, doesn’t look easy in any respect), nevertheless it’s very hacky certainly. You see, we’re manipulating browser historical past by creating a brand new, fictional entry known as #gref. Then, when the person clicks browser again, as an alternative of taking them again to Google search, it really takes them to the earlier state, which is the URL with out the #gref.
THAT’S how we all know each that the person clicked browser again AND that they had been attempting to return to the SERP. All we’ve got to do is ship the Google Analytics timing hit, after which transfer the person manually to the earlier entry within the historical past (i.e. the SERP).
Why is it hacky? Effectively, you’re manipulating browser historical past, for one. You’re making a customized state, and also you’re forcing the person to undertake that state in the event that they land from natural search. Subsequent, you’re intercepting a legit browser again occasion, and as an alternative of letting the person immediately go away the location, you’re forcing them to ship the GA timing hit first, earlier than manually whisking them again to the SERP.
Whew! Numerous issues that may go flawed. Fortunately the JavaScript is strong and exquisite, however don’t neglect to check completely!
Wait, let me repeat that: check completely. Additionally, in case you’re operating a single-page web site, I can nearly promise you that this received’t work out-of-the-box.
The Customized HTML Tag
On the coronary heart of this resolution is a single Customized HTML Tag. It’s fired by two completely different occasions, to which we’ll return shortly.
To begin with, right here’s the code:
<script>
(operate() {
var s = doc.location.search;
var h = doc.location.hash;
var e = {{Occasion}};
var n = {{New Historical past Fragment}};
var o = {{Previous Historical past Fragment}};
// Solely run if the Historical past API is supported
if (window.historical past) {
// Create a brand new historical past state if the person lands from Google's SERP
if (e === 'gtm.js' &&
doc.referrer.indexOf('www.google.') > -1 &&
s.indexOf('gclid') === -1 &&
s.indexOf('utm_') === -1 &&
h !== '#gref') {
window.oldFragment = false;
window.historical past.pushState(null,null,'#gref');
} else if (e === 'gtm.js') {
window.oldFragment = true;
}
// When the person tries to return to the SERP utilizing browser again, hearth the
// Google Analytics timing occasion, and after it is dispatched, manually
// navigate to the earlier historical past entry, i.e. the SERP
if (e === 'gtm.historyChange' &&
n === '' &&
o === 'gref') {
var time = new Date().getTime() - {{DLV - gtm.begin}};
if (!window.oldFragment) {
dataLayer.push({
'occasion' : 'returnToSerp',
'timeToSerp' : time,
'eventCallback' : operate() {
window.historical past.go(-1);
}
});
} else {
window.historical past.go(-1);
}
}
}
})();
</script>
Let’s shortly stroll by this code. To begin with, the entire block is encased in an instantly invoked operate expression (IIFE) (operate() {...})();
, which protects the worldwide namespace. Additionally, the entire resolution solely works if the person’s browser helps the Historical past API: if (window.historical past) {...}
.
The primary vital code block is that this:
if (e === 'gtm.js' &&
doc.referrer.indexOf('www.google.') > -1 &&
s.indexOf('gclid') === -1 &&
s.indexOf('utm_') === -1 &&
h !== '#gref') {
window.oldFragment = false;
window.historical past.pushState(null,null,'#gref');
}
This code checks the next:
-
Was the Tag fired as a result of Web page View Set off (i.e. a web page load)?
-
Did the person land from a Google web site (
referrer
accommodates www.google.)? -
In the event that they did, make certain it’s not from an AdWords advert (test that the URL doesn’t have ?gclid) or customized marketing campaign.
-
Ensure additionally that the URL doesn’t already comprise #gref, which might indicate the person adopted a hyperlink with that hash or that the person already had a historical past entry with #gref, which means they’ve navigated elsewhere inside or outdoors the location after touchdown on it within the first place from the SERP.
If these checks move, then a brand new international variable oldFragment
is initialized with the worth false
. This implies merely that this can be a model new touchdown on the location by natural Google search, and we test towards this once we push the payload to dataLayer
. We solely need to ship the Timing hit for touchdown web page bounces.
Lastly, a brand new browser historical past state is created, the place the URL is appended with #gref to point out that the person landed from natural Google search.
The following code block is:
else if (e === 'gtm.js') {
window.oldFragment = true;
}
Right here, we test if the occasion is a web page load once more, however the URL already has #gref. On this case, we set the worldwide variable to true
, since clearly this entry isn’t a direct touchdown from the SERP however one thing else. This fashion, we’ll block the Timing hit from occurring, as we solely need to measure true touchdown web page bounces.
The ultimate code block is:
if (e === 'gtm.historyChange' &&
n === '' &&
o === 'gref') {
var time = new Date().getTime() - {{DLV - gtm.begin}};
if (!window.oldFragment) {
dataLayer.push({
'occasion' : 'returnToSerp',
'timeToSerp' : time,
'eventCallback' : operate() {
window.historical past.go(-1);
}
});
} else {
window.historical past.go(-1);
}
}
Once more, there’s a guidelines of issues:
-
Is the occasion a browser historical past occasion?
-
Is the outdated hash #gref and the brand new hash a clean string?
If all these checks move, it implies that the person tried to return in browser historical past to the SERP. Resulting from our manually imposed historical past state, they’re really taken to the #gref-less touchdown web page.
Subsequent, we test the dwell time on the web page, utilizing the distinction between the present time and the time when the GTM container snippet was first loaded. It is a affordable description of dwell time, however you need to use one thing else for begin time if you want.
Lastly, we test if oldFragment
is fake, which means we’re nonetheless on the touchdown web page. Whether it is, the payload is pushed into dataLayer
. The ‘eventCallback’ key has the precise return to SERP command, and it’ll solely be executed after any Tags that use the returnToSerp occasion have fired.
Hacky-dy-hack-hack! I like it!
All the opposite stuff you’ll want
Right here’s a listing of the belongings you should create for this to work. Be at liberty to improvise, if you want!
1. Constructed-in Variables
First, make certain the next Constructed-in Variables are checked in your container’s Variables settings.
In order that’s Web page URL, Occasion, Historical past Supply, New / Previous Historical past Fragment.
2. The Triggers for the Customized HTML Tag
The Customized HTML Tag runs on two Triggers.
The primary one is the default All Pages Set off.
The second is a Historical past Change Set off which appears to be like like this:
This Set off solely launches when a browser historical past occasion is detected which can be a popstate
, and the brand new historical past fragment is empty.
3. The Variables
Create the next Knowledge Layer Variables:
This one shops the time when the GTM container snippet was executed.
That is the place the time spent on the touchdown web page is saved.
4. The Set off for the Timing Tag
The Set off you’ll connect to the Timing Tag (created subsequent) appears to be like like this:
This Set off fires when the returnToSerp dataLayer
occasion is pushed through the Customized HTML Tag. It additionally checks that the dwell time pushed into dataLayer
is lower than half-hour. This fashion a brand new session received’t be began with the occasion, if the customer stays on the web page for an exceptionally very long time.
5. The Timing Tag
And right here’s the Common Analytics Timing Tag you’ll want:
We’re sending SERP Bounce because the Timing Class, the complete Web page URL because the Timing Variable, and the time spent on the touchdown web page as the worth. As talked about above, this Tag is fired by the Set off you created in step (4) above.
Viewing the outcomes
When you implement this, you’ll discover the outcomes below Website Content material > Website Velocity > Person Timings below the Timing Class labelled SERP Bounce.
To drill into the info, it’s helpful to view the Timing Variable as the first dimension, as that’s the one the place the touchdown pages are. Attempt to discover touchdown pages with an abnormally small common dwell time:
These pages have a really quick dwell time in comparison with web site common. Simply make it possible for the timing pattern is massive sufficient so that you can draw conclusions from. Pages with an abnormally quick dwell time from the SERP MIGHT point out a poor expertise or lack or related content material.
Additionally, the Distribution view is helpful if you wish to drill right down to particular person web page efficiency:
This report helps you to view the timing buckets. As you’ll be able to see, there are some anomalies right here, although the pattern is sort of small.
Abstract
I hope I’ve satisfied you by now that this can be a very hacky resolution. Bear in mind to check completely. I can even promise that you should have issues in case you attempt to implement this on a single-page utility (e.g. AJAX web site), which depend on the browser historical past API for navigation.
However, it’s an fascinating approach of uncovering potential points along with your touchdown pages. It could be fascinating to align this knowledge with key phrase knowledge, however that’s as much as you to resolve, since that knowledge is tough to return by lately, and Person Timings don’t align properly with acquisition dimensions like Key phrase.