{"id":150756,"date":"2025-03-23T01:24:15","date_gmt":"2025-03-23T01:24:15","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/leverage-usebeacon-and-beforeunload-in-google-analytics\/"},"modified":"2025-03-23T01:24:15","modified_gmt":"2025-03-23T01:24:15","slug":"leverage-usebeacon-and-beforeunload-in-google-analytics","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=150756","title":{"rendered":"Leverage useBeacon And beforeunload In Google Analytics"},"content":{"rendered":"


\n<\/p>\n

\n

This nifty little solution will let you calculate the time spent on pages that are not tracked in Google Analytics by default. These include both bounced landing pages and exit pages. Bounced pages and exit pages lack the necessary subsequent pageview, which Google Analytics uses to calculate time-based metrics.<\/p>\n

Before you go on, read this excellent article by Yehoshua Coren<\/a>:<\/p>\n

REAL Time On Page in Google Analytics<\/a><\/p>\n

Yehoshua gives a very nice use case for the technical solution I\u2019m about to explore. He also leverages the Page Visibility API<\/a> to get an even more accurate overview of visitors who actually digest content, and how much of that time that content is visible on their screens. Fundamental stuff, read it!<\/p>\n

So what we\u2019re actually doing here is this:<\/p>\n

    \n
  1. \n

    On each page, use the default gtm.start<\/strong> Data Layer Variable to calculate the time when the document has started loading<\/p>\n<\/li>\n

  2. \n

    When the user decides to leave the page, either by closing the browser or navigating to another page, first calculate the time when the beforeunload<\/a><\/em> event is dispatched. Then, use the sendBeacon()<\/code> API<\/a> to send a User Timing hit to Google Analytics without having to worry about the unload process cutting the request short.<\/p>\n<\/li>\n<\/ol>\n

    Hopefully, you\u2019ll end up with data like this:<\/p>\n

    \n

    <\/p>\n

    \"User<\/p>\n

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

    Here you can see the User Timings recorded for pageviews of bounced sessions.<\/p>\n

    Here\u2019s another report:<\/p>\n

    \n

    <\/p>\n

    \"Exit<\/p>\n

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

    In this report, you can view Exit Pages with the time spent on each page as a secondary dimension.<\/p>\n

    Naturally, this data would be far more useful when extracted out of the GA interface into a spreadsheet, where you can actually make calculations with the Custom Dimension values, for example. Hopefully, at some point, we\u2019ll have the possibility to calculate our own Custom Metrics, at which point it will make more sense to send this information as a metric instead. Also, read Yehoshua\u2019s article I linked to in the beginning of the post. He uses Custom Metrics, which makes actually a lot more sense if you want to extract the data.<\/p>\n

    Nevertheless, until such a time that we can calculate on metrics, this is a useful method for obtaining a more accurate time on page across your sessions (so also for bounces and exit pages).<\/p>\n

    To get it working, you\u2019ll need the following components:<\/p>\n

      \n
    1. \n

      New Custom Dimension<\/strong>, session-scoped, to capture this information in GA<\/p>\n<\/li>\n

    2. \n

      Data Layer Variable<\/strong> to capture the value for gtm.start<\/strong><\/p>\n<\/li>\n

    3. \n

      Data Layer Variable<\/strong> to store the time on page<\/p>\n<\/li>\n

    4. \n

      Custom HTML Tag<\/strong>, which sets the beforeunload<\/em> listener and does the dataLayer.push()<\/code> when the page unload begins.<\/p>\n<\/li>\n

    5. \n

      Timing Tag<\/strong> which uses the quite new useBeacon<\/strong> field available in Universal Analytics. This field is basically a helper for setting up the sendBeacon()<\/code> request.<\/p>\n<\/li>\n<\/ol>\n

      1. Custom Dimension<\/h3>\n

      Let\u2019s start with the Custom Dimension. We\u2019re using a session-scoped Custom Dimension for one simple reason: it will always have the last value sent during the session. This means that since we\u2019re sending the custom time on page on every single pageview, the session-scoped Custom Dimension should always have the exit page time for the session! Once we have this in place, we can add the custom dimension as a secondary dimension in the Exit Page report, giving us the dwell time for exit pages only.<\/p>\n

      Note that the session-scoped Custom Dimension fails if the user is inactive long enough for the session to expire (30 minutes by default). So it might actually be a good idea to modify the timing script to only allow values up to 1800000 milliseconds (30 minutes).<\/p>\n

      \n

      <\/p>\n

      \"Custom<\/p>\n

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

      Make note of the index the new Custom Dimension gets. This is important when you\u2019re setting up the Event Tag.<\/p>\n

      2. Data Layer Variable for gtm.start<\/h3>\n

      The next step is to create the Data Layer Variable for gtm.start<\/strong>. You might wonder what this \u201cgtm.start\u201d is, but it\u2019s actually a property in the very first dataLayer<\/code> object pushed into the Array by GTM, when the container snippet starts loading:<\/p>\n

      \n

      <\/p>\n

      \"gtm.start<\/p>\n

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

      The value for this variable is a timestamp in milliseconds of Epoch time<\/a>. You don\u2019t have to worry about what this means, since all we\u2019re going to use this for is to calculate the difference between page unload time and gtm.start<\/strong> to get an approximation of how long the user spent on the page.
      \nThe Data Layer Variable would look like this:<\/p>\n

      \n

      <\/p>\n

      \"Data<\/p>\n

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

      3. Data Layer Variable for timeonpage<\/h3>\n

      You\u2019ll also need to create a Data Layer Variable for timeonpage<\/strong>, which is where we\u2019ll store the time on page, pushed in the beforeunload<\/em> callback. So create another Data Layer Variable that looks like this:<\/p>\n

      \n

      <\/p>\n

      \"Data<\/p>\n

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

      4. Custom HTML Tag<\/h3>\n

      The next step is our custom beforeunload<\/em> listener. Create a new Custom HTML Tag, and set it to fire with the All Pages<\/strong> Trigger. Add the following code within:<\/p>\n

      \n
      script>\n  window<\/span>.addEventListener('beforeunload'<\/span>, function<\/span>() {\n    window<\/span>.dataLayer.push({\n      'event'<\/span> : 'unloadEvent'<\/span>,\n      'timeonpage'<\/span> : new<\/span> Date<\/span>().getTime() - {{DLV - gtm.start}}\n    });\n  });\nscript<\/span>><\/code><\/pre>\n<\/div>\n
      This attaches the beforeunload<\/em> listener to the global window<\/code> object. When the unload process begins, i.e. when the user chooses to leave the page, the callback is invoked, and a dataLayer.push()<\/code> is executed, with a custom \u2018event\u2019 value and also a value for the \u2018timeonpage\u2019 Variable we just created.<\/p>\n
      The time on page is calculated by getting the timestamp for the beforeunload<\/em> event, and subtracting the gtm.start<\/strong> timestamp from it. The result is the time in milliseconds between these two events. If you want to have a safeguard for session expiration, cap this time at 1800000 milliseconds, which is 30 minutes.<\/p>\n
      Now all we need is the Timing Tag, which sends the timeonpage<\/strong> value both as a Timing value and as a Custom Dimension value.<\/p>\n
      5. User Timing Tag<\/h3>\n
      User Timing<\/em> is a hit type that you can use to send your own timing events to Google Analytics. A common use case is to measure the load time of linked assets<\/a>, such as huge, bloated JavaScript libraries (I\u2019m looking at you, non-minified jQuery!).<\/p>\n
      But you can use User Timings for anything on the site that can be measured in milliseconds. So it works perfectly with page load time as well.<\/p>\n
      Before you create the Tag, you\u2019ll need the Trigger that makes the Tag fire. The Trigger is simply a Custom Event Trigger, that fires with event name unloadEvent<\/strong>:<\/p>\n
      \n
          <\/p>\n
          \"Trigger<\/p>\n
          <\/a><\/p>\n<\/div>\n
      Next, create a new Google Analytics \/ Universal Analytics Tag, attach the Trigger you just created to it, and set the Tag fields to look something like this:<\/p>\n
      \n
          <\/p>\n
          \"User<\/p>\n
          <\/a><\/p>\n<\/div>\n
      If you were to save this now and publish your container, the solution would be very unreliable. This is because the beforeunload<\/em> event signals the browser to start the unload process, and the unload process is brutal<\/strong>. Any threads that are running once the browser reaches the unload<\/em> stage are cut off, and all requests are cancelled. This is because the browser doesn\u2019t want to let anything impede the user\u2019s desire to leave the page.<\/p>\n
      Perfectly understandable.<\/p>\n
      It is for this reason that we\u2019ll leverage yet another little-known API: navigator.sendBeacon()<\/code>. This API turns any request made in its scope into an asynchronous, uninterruptible call to whatever endpoint you choose. So, even if the browser window closes or you navigate from the site, the request is allowed to complete before the browser instance is unloaded from memory.<\/p>\n
      Google Analytics were quick to react to this API, and they published their own shorthand for it: the useBeacon<\/em> field<\/a>. Read David Vallejo<\/a>\u2019s nice review<\/a> about this new feature to get acquainted.<\/p>\n
      !!! UPDATE<\/strong> !!!
      \nThe useBeacon<\/code> has been deprecated. Use the transport<\/code> field name instead, and set its value to beacon<\/code>. Read about the field       here<\/a>.<\/p>\n
      Anyway, useBeacon<\/strong> turns the call into a POST request (instead of the usual GET), and passes it asynchronously to the GA endpoint using navigator.sendBeacon()<\/code>.<\/p>\n
      To add this feature to the User Timing Tag, add useBeacon<\/strong> as a Field To Set<\/em>, and set its value to true<\/strong>.<\/p>\n
      Also, add the {{DLV – timeonpage}}<\/strong> as a Custom Dimension, using the index number you got from Step 1.<\/p>\n
      So now the More Settings of your User Timing Tag should look like this:<\/p>\n
      \n
          <\/p>\n
          \"Fields<\/p>\n
          <\/a><\/p>\n<\/div>\n
      Save the Tag, Preview & Debug the Tag, and Publish when you\u2019re ready.<\/p>\n
      Then read the caveats below. Or actually, it would be good if you read these before you publish.<\/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
      Caveats<\/h2>\n
      There is actually only one major caveat here. navigator.sendBeacon()<\/code> has horrible<\/strong> browser support. Like, dismal. Basically, Internet Explorer and Safari do not support it all. This is a big setback, as IE is one of the most popular desktop browsers, and Safari is among the most popular mobile browsers.<\/p>\n
      The thing is, you don\u2019t really have to write any fallback functions for browsers that don\u2019t support the API. The Universal Analytics library detects if navigator.sendBeacon()<\/code> is supported, and if it isn\u2019t, the hit is sent normally.<\/p>\n
      Depending on your site, there\u2019s still a good chance that the hit gets sent. This depends on how long it takes for the browser to unload your site.<\/p>\n
      If you want to play it safer, you could write your own click handler that intercepts external links, fires the Timing Tag, and only then lets the link redirect proceed. This would cover exits from your site to other sites nicely, but it wouldn\u2019t help with the most interesting use case of people closing browser windows and tabs.<\/p>\n
      This is a problem we\u2019ll just have to live with. However, as an eternal optimist, I see this as a solution that can only get better with time<\/strong>. Once navigator.sendBeacon()<\/code> gets better support and once we get calculated Custom Metrics, this solution will be so awesome.<\/p>\n
      Right now it\u2019s more of a prototype, but as Yehoshua shows you, it can already have very interesting analytics applications.<\/p>\n
      Well, I\u2019d be remiss if I didn\u2019t mention one other, small caveat. Triggering code on beforeunload<\/em> invalidates the back-forward cache (BFCache<\/a>) in Firefox. This means that the page state of the page is no longer cached, and if you\u2019re trusting e.g. form field values to this cache, you\u2019ll need to make adjustments.<\/p>\n
      Summary<\/h2>\n
      In this quite simple solution we\u2019re leveraging some pretty cool APIs again. The point is partly to give you a tool to get better data out of Google Analytics, but at the same time we\u2019re doing what I love best: using JavaScript and Google Tag Manager to get data from unexpected places.<\/p>\n
      As I say in the previous chapter, this solution will only get better with time.<\/p>\n
      Hopefully, once navigator.sendBeacon()<\/code> get better browser support, it will become the default request mechanism for all Google Analytics hits. It just makes so much sense. Also, it means that you won\u2019t need to protect your tags with setTimeout()<\/code> calls or the Wait For Tags<\/strong> method in Google Tag Manager.<\/p>\n
      But from the look of things, this is still a long way off.<\/p>\n<\/p><\/div>\n