{"id":139257,"date":"2025-03-17T09:09:58","date_gmt":"2025-03-17T09:09:58","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/measure-serp-bounce-time-with-gtm\/"},"modified":"2025-03-17T09:09:58","modified_gmt":"2025-03-17T09:09:58","slug":"measure-serp-bounce-time-with-gtm","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=139257","title":{"rendered":"Measure SERP Bounce Time With GTM"},"content":{"rendered":"


\n<\/p>\n

\n

Here\u2019s an interesting and hacky use case for you. It\u2019s all about uncovering bounce<\/strong> metrics for visits which originate from organic Google search results. In particular, the metric we\u2019re interested in is how long user dwelled<\/em> on the landing page after arriving from organic Google search AND<\/strong> returned to the search engine results page (SERP) using the browser\u2019s back button.<\/p>\n

\n

<\/p>\n

\"Dwell<\/p>\n

<\/a><\/p>\n<\/div>\n

The inspiration for this post came from an audience question at the Best Internet Conference in Lithuania, which I recently attended as a speaker. They were concerned that Google is using Bounce Rate as a search ranking signal, and I was fairly strongly opinionated that it\u2019s simply not possible, as all the \u201cnative\u201d GA metrics are really easy to manipulate. However, Dr. Pete from Moz wrote about dwell time<\/em><\/a> in 2012, and it makes a lot of sense. Google should be very<\/strong> interested how long the visitor stays out of the SERP when following a link. If users tend to immediately return to the SERP, it\u2019s very likely the result was not relevant for them.<\/p>\n

So, inspired by this question, I wanted to see if I can get some metrics from how long people dwell on these landing pages before returning to the SERP. I got my results, but it\u2019s definitely not an easy problem to solve. As usual, we\u2019re using a combination of Google Tag Manager<\/a> and Google Analytics<\/a> to perform the operation.<\/p>\n

(UPDATE 17 April 2016<\/strong> I updated this article, as I had to make some modifications to the code. It\u2019s slightly more robust now, and it lends itself better to e.g. Custom Metrics, if you prefer to use those instead of User Timings.)<\/p>\n

The result is a list of User Timings, where each landing page can be scrutinized against the time users spent on there before clicking the browser\u2019s back button.<\/p>\n


\n X<\/span><\/p>\n

\n
\n The Simmer Newsletter<\/strong>\n <\/p>\n

\n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n

<\/span><\/p>\n

The mystery of the history<\/h2>\n

The difficulty is that when the user clicks the browser\u2019s back button, we have no knowledge of where the user is taken to. That\u2019s browser security for you. It would be highly questionable if the website had access to the history of the web browser. Makes sense, right?<\/p>\n

Another difficulty is the actual browser back button. It\u2019s not part of the browser object model, so we can\u2019t actually measure clicks on it. Instead, we can infer<\/em> a back button click from how people navigate with URL hashes! When a hash change<\/em> is recorded, we can infer that it was due to browser back if<\/strong> we implement a little hack, where the hash is unique to organic Google search.<\/p>\n

You see, by creating a new browser history entry for people landing from organic Google search, the back button click doesn\u2019t take them to the SERP, but rather to the original landing page that existed before<\/strong> we redirected the user to the new history state. Using that as an indicator, we can extrapolate that the hash change occurred due to a browser back button click (or the backspace).<\/p>\n

The process<\/h2>\n

The process is as follows:<\/p>\n

    \n
  1. \n

    If the user lands on the site through organic Google search, create a new browser history entry<\/strong> with the hash #gref<\/strong><\/p>\n<\/li>\n

  2. \n

    Later, if a hash change<\/strong> is registered, and the user is still on the landing page, and the hash change is from #gref<\/strong> to a blank string, fire a Google Analytics timing<\/a> event, after which programmatically invoke the \u201cBack\u201d event in the browser history<\/p>\n<\/li>\n<\/ol>\n

    Looks simple (actually, doesn\u2019t look simple at all), but it\u2019s very hacky indeed. You see, we\u2019re manipulating browser history<\/strong> by creating a new, fictional entry called #gref<\/strong>. Then, when the user clicks browser back, instead of taking them back to Google search, it actually takes them to the previous state, which is the URL without<\/strong> the #gref.<\/p>\n

    THAT\u2019S how we know both that the user clicked browser back AND that they were trying to return to the SERP. All we have to do is send the Google Analytics timing hit, and then move the user manually to the previous entry in the history (i.e. the SERP).<\/p>\n

    Why is it hacky? Well, you\u2019re manipulating browser history, for one. You\u2019re creating a custom state, and you\u2019re forcing the user to adopt that state if they land from organic search. Next, you\u2019re intercepting a legitimate browser back event, and instead of letting the user directly leave the site, you\u2019re forcing them to send the GA timing hit first, before manually whisking them back to the SERP.<\/p>\n

    Whew! Lots of things that can go wrong. Luckily the JavaScript is solid and beautiful, but don\u2019t forget to test thoroughly!<\/p>\n

    Wait, let me repeat that: test thoroughly<\/strong>. Also, if you\u2019re running a single-page website, I can almost promise you that this won\u2019t work out-of-the-box.<\/p>\n

    The Custom HTML Tag<\/h2>\n

    At the heart of this solution is a single Custom HTML Tag. It\u2019s fired by two different events, to which we\u2019ll return shortly.<\/p>\n

    First of all, here\u2019s the code:<\/p>\n

    \n