{"id":106166,"date":"2025-02-24T01:16:22","date_gmt":"2025-02-24T01:16:22","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/track-browsing-behavior-in-google-analytics\/"},"modified":"2025-02-24T01:16:22","modified_gmt":"2025-02-24T01:16:22","slug":"track-browsing-behavior-in-google-analytics","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=106166","title":{"rendered":"Track Browsing Behavior In Google Analytics"},"content":{"rendered":"


\n<\/p>\n

\n
\n

Last updated 22 May 2019<\/strong>: Added expiration of currently open tabs.<\/p>\n<\/blockquote>\n

In this article, Jethro Nederhof<\/a> of Snowflake Analytics<\/a> fame and I will introduce you to some pretty neat web browser APIs. The purpose of these APIs is to find out more about how the user navigated to the current page<\/strong>, and what\u2019s going on with their browser tabs<\/strong>.<\/p>\n

\n

<\/p>\n

\"New<\/p>\n

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

There are so many things you can do with this new information. You can build proper<\/em> navigational path reports, rather than rely on the fuzzy and often incoherent flow reports in Google Analytics. You can identify how visitors interact with your content using browser tabs – a crucial bit of information if you want to make heads or tails of Google Analytics\u2019 time on page<\/a> metrics, for example. You can see how many redirects were involved in the current navigation action.<\/p>\n

The origins of this article are in a number of places, including an impromptu challenge thrown by Yehoshua Coren<\/a> in Twitter (with great contributions from Marek Leci\u00e1n, too):<\/p>\n

However, the main source of inspiration came from Measure Slack<\/a>, where a similar discussion around tabbed browser was being had:<\/p>\n

\n

<\/p>\n

\"Measure<\/p>\n

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

Jethro\u2019s idea got the ball rolling in my mind, so I contacted him immediately and asked if he wanted to co-author this article. As it turns out, he\u2019d been mulling around lots of different ideas for navigation behavior tracking, so we quickly sketched the outline of this article, and what you are reading now is the final product.<\/p>\n

I consider the enhancements introduced in this article just as necessary as those I introduced way back when in my article Improve Data Collection With Four Custom Dimensions<\/a>. Once you\u2019re done implementing these scripts, I\u2019m sure you\u2019ll agree.<\/p>\n

As said, this article is co-authored by Jethro and me. Since I am the editor, all mistakes and errors are entirely my fault, and any snarky comments should be directed at me and not my generous partner in crime (naturally, all snarky comments will be deleted, but I will read them and promise to be insulted).<\/p>\n

You can skip directly to the Solutions chapter, but I do recommend reading the Theory first. At the very least, make sure you read the Caveats chapter, because there are a couple of gotchas you need to be aware of if implementing this solution.<\/p>\n

Ah, damn it. Just read the whole thing, will you?<\/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

1. The why and how (theory)<\/h2>\n

The web, by default, is stateless<\/strong>. Your browsing behavior is confined to the current page only, and it\u2019s difficult to programmatically peer into the past (never mind into the future).<\/p>\n

Tools like Google Analytics<\/a> try to make sense of this stateless mess by collecting information in a chronological order. You send a pageview<\/strong>, then you send another pageview<\/strong>. Google Analytics interprets this as navigational behavior where you first viewed the first page and then the second page. Makes sense, right?<\/p>\n

But what about if you opened the second page in a tab<\/strong> and never even glanced at it? GA still interprets it as a page being viewed.<\/p>\n

What about if you reloaded<\/strong> the current page? GA still interprets it as a navigational step.<\/p>\n

What about if you pressed the back button<\/strong> of the browser to return to the previous page? Google Analytics makes no distinction – it doesn\u2019t know if you clicked a link, typed the URL in the address bar, or used the back button. It\u2019s all the same.<\/p>\n

\n

<\/p>\n

\"Google<\/p>\n

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

The flow reports<\/a> try to make sense of this mess by aligning everything into a navigational pattern (the \u201cflow\u201d). But the reports are quite difficult to interpret, as they sometimes show sequences that you are certain shouldn\u2019t be possible, lack necessary detail, and they don\u2019t really give you a robust way to query the information or to build a proper flow report yourself.<\/p>\n

And tabbed browsing is still<\/strong> a problem. Each tab initiates a new \u201csession\u201d in the browser (not to be confused with a Google Analytics session). Thus when GA tries to explain to you that everything is part of a linear navigational flow, the truth is actually more complex: each tab initiates a new branch<\/strong> of navigation!<\/p>\n

\n

<\/p>\n

\"Linear<\/p>\n

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

Add to this the fact that in Google Analytics, \u201cReferral\u201d is a reserved term for campaign attribution. Thus when you are navigating around the site, the referring page is not sent when navigating in-site. This would be really helpful when deciphering navigational paths, since the Previous Page Path<\/strong> dimension does not<\/strong> necessarily represent the previous page viewed (just the previous page for which a pageview was sent). To make some sense out of the mess, sending the referral string in a Custom Dimension is a good practice.<\/p>\n

\n

<\/p>\n

\"Referral<\/p>\n

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

There are other, more granular tracking solutions out there, of course. Snowplow<\/a>, for example, lets you track hit-level data in any way you like. You can include referral information, if you wish. However, since you\u2019re approaching Snowplow with the limitations of SQL queries, as soon as the navigation journey starts looping or has multiple pages, the joins you\u2019d need to make become frustratingly complex and, as a result, quite unwieldy over large amounts of data.<\/p>\n

So, we\u2019ve had this problem of analytics tools imposing a linear sequence on a non-linear navigational pattern for a couple of decades, ever since tabbed browsing was introduced around the turn of the millennium.<\/p>\n

What we\u2019re proposing in this article is to add another layer to the taxonomy of Google Analytics\u2019 rather rigid schema for browsing behavior.<\/p>\n

FROM:<\/strong> Users<\/code> > Sessions<\/code> > Hits<\/code>
TO:<\/strong> Users<\/code> > Sessions<\/code> > Tabs<\/code> > Hits<\/code><\/p>\n

This browsing behavior would be encoded directly into Custom Dimensions<\/strong>, so you don\u2019t have to infer behavior from GA\u2019s pageview model – rather, you can query the navigational information directly!<\/p>\n

1.1. The PerformanceNavigation API<\/h3>\n

The API we\u2019re going to use to identify browsing behavior is called PerformanceNavigation<\/code>. It comes with two read-only properties: performance.navigation.type<\/code> and performance.navigation.redirectCount<\/code>.<\/p>\n

The origin story of this API is firmly rooted in the difficulty of measuring performance of any given web page load. Redirects, network lag, and cached resources (locally, server-side, in CDNs) all contribute to the complexity of what the aggregate performance<\/strong> of any given page load is.<\/p>\n

\n

<\/p>\n

\"PerformanceTiming<\/p>\n

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

To help understand this complexity, web browsers implement the PerformanceNavigation<\/code> API. The two properties exposed by the API can be found under the global window.performance.navigation<\/code> interface, and they contain the following information:<\/p>\n\n\n\n\n\n\n\n\n\n\n
Parameter<\/th>\nDetail<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
redirectCount<\/code><\/td>\n–<\/td>\nThe number of 3XX<\/code> HTTP redirects the browser went through when loading the page.<\/td>\n<\/tr>\n
type<\/code><\/td>\n–<\/td>\nAn integer representing how the page was loaded.<\/td>\n<\/tr>\n
\u00a0<\/td>\n0<\/td>\nNormal navigation, typing the URL, clicking a link, opening a bookmark, entering via an app link, etc.<\/td>\n<\/tr>\n
\u00a0<\/td>\n1<\/td>\nPage was refreshed \/ reloaded while already open in the browser tab.<\/td>\n<\/tr>\n
\u00a0<\/td>\n2<\/td>\nThe page was retrieved from the browser history by using the Back or Forward button.<\/td>\n<\/tr>\n
\u00a0<\/td>\n255<\/td>\nAny other way to navigate to the page.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The 255<\/strong> value is interesting, because it is quite undocumented. In tests, it seems to only emerge with the Firefox browser, when the page goes through a client-side<\/strong> refresh, either using window.location.replace()<\/code> or <\/code>. Note that this goes against the W3C specification, which clearly states<\/a> that client-side redirects should<\/em> be contained within one of the regular navigation types.<\/p>\n

Now, even though we mention how this API was probably conceived to give more information about the performance timing metrics, where it really<\/strong> shines is uncovering the navigational paths the users take through your site.<\/p>\n

1.2. Browser storage<\/h3>\n

Ever since browser tabs were introduced to the delight of site visitors and web browser users, they\u2019ve been a source of annoyance for web analysts.<\/p>\n

In Google Analytics, for example, we simply don\u2019t know (by default) what the tab situation is of any given page. We don\u2019t know if the page was opened in a new tab, for one, since you can\u2019t attach listeners to the right-click context menu, and tracking just middle mouse button clicks doesn\u2019t give a comprehensive idea of the scope of the phenomenon.<\/p>\n

\n

<\/p>\n

\"Context<\/p>\n

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

The beauty of web analytics is that when we can\u2019t track things directly<\/em> (whether a user submitted a form, for example), we can track them indirectly<\/em> (page load of a \u201cthank you\u201d page). So maybe we can use this same indirect approach with browser tabs, too?<\/p>\n

If we can assign an identifier to every tab the user opens in the current website, we can identify individual navigation sequences! This can be achieved by checking against a common data store whether the given tab ID exists already, in which case the page load happened in a tab that was already open, and vice versa.<\/p>\n

However, thanks again to the statelessness of the web, there is the problem of persistence. We can\u2019t simply use a global JavaScript property to store the tab ID, because that gets demolished when the user unloads the page by reloading or navigating to another page.<\/p>\n

Cookies and localStorage<\/code> are \u201ctoo\u201d persistent, because they are only reset when they are manually cleared (localStorage<\/code>) or when they expire (cookies). We only want to store the ID of a tab for as long as that tab exists.<\/p>\n

\n

<\/p>\n

\"Session<\/p>\n

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

Enter sessionStorage<\/code>! It\u2019s a browser storage API that is unique to each tab in your web browser. By storing the tab ID in sessionStorage<\/code>, we can always check if the tab already has an ID (existing tab), or if we need to generate a new one (new tab).<\/p>\n

Combine this with some localStorage<\/code> logic, where we keep a running tally of how many tab IDs have been generated, remembering to remove any tab ID once that tab is closed, and we can also get a fairly reliable count of tabs open on your website at any given time.<\/p>\n

So, now we are getting close to having all the bits and pieces at hand. Once we combine the tabbed browsing metadata with that provided by the PerformanceNavigation<\/code> API, we can get a nice set of Custom Dimensions that expose a great deal of interesting information about how your visitors navigate your site.<\/p>\n

2. Caveats<\/h2>\n

Oh, there are plenty<\/strong> of caveats. The solutions below rely on a number of fragile components, which can get easily messed up due to how browsers act differently in certain circumstances.<\/p>\n

2.1. Cross-domain browsing<\/h3>\n

If your tracking crosses multiple domains, then each domain will get their own tab ID. That\u2019s because sessionStorage<\/code> and localStorage<\/code> are confined to the current domain only. And if your current domain sails between HTTP and HTTPS protocols, then those<\/em> will get their own storages, too. You could fix this by using URL parameters on the domain boundaries to pass the metadata from one domain to the next, but this is something you\u2019ll need to figure out by yourself.<\/p>\n

2.2. Firefox and Chrome go rogue<\/h3>\n

An additional point of concern is that Firefox and Chrome do not respect the specification that session cookies and sessionStorage<\/code> should only exist for as long as the tab is alive. Once the browser is closed, these session stores should be purged.<\/p>\n

On Chrome and Firefox, however, if you open the browser and you have the Show your windows and tabs from last time<\/strong> (Firefox) or Continue where you left off<\/strong> (Chrome) settings turned on, the session stores are restored, too! So even though the tab did<\/em> close, by restoring the tab it\u2019s as if the tab was never closed.<\/p>\n

\n

<\/p>\n

\"Firefox<\/p>\n

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

That sucks. Not much we can do about that.<\/p>\n

Also, and this is interesting, when you do restore tabs or continue where you left off, the browser claims that the navigation type was BACK\/FORWARD<\/code>, meaning it equates restoring tabs with using the back or forward button of the browser.<\/p>\n

This sucks, too. And there\u2019s not much we can do about this, either.<\/p>\n

2.3. Firefox and its client-side refresh dilemma<\/h3>\n

Then there\u2019s the problem with Firefox implementing OTHER<\/code> as the navigation type if a client-side refresh is done. This is unfortunate, but doesn\u2019t luckily mess things up too bad, because this behavior is contained within this particular navigation type alone.<\/p>\n

In addition to all of these, because the whole granularity of distinguishing between BACK<\/code> and FORWARD<\/code> needs to be coded using a programmatically maintained path of pages the user has visited, all it takes is for them to manually clear the sessionStorage<\/code> to break the whole setup (at least, for as long as the tab is open).<\/p>\n

\n

<\/p>\n

\"Clear<\/p>\n

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

That\u2019s why in the beginning of the solution you have the option of NOT tracking the back and forward button presses with detail. In this case, the string BACK\/FORWARD<\/code> is sent to Google Analytics in case either button is pressed. It\u2019s not as detailed but it does still tell you whether the user navigated using these buttons (or, as mentioned above, if the tabs were restored after restarting the browser).<\/p>\n

Our hypothesis is that with more data the averages will converge towards a more reliable dataset. So idiosyncrasies such as tabs being restored or users clearing storage will disappear into the data as more and more page views are accumulated.<\/p>\n

2.4. Browser support<\/h3>\n

There\u2019s also the matter of browser support, but unlike some online resources<\/a> claim, support for PerformanceNavigation<\/code> is pretty well supported in Chrome and Safari<\/a>.<\/p>\n

2.5. Single-page apps<\/h3>\n

You could implement this solution for single-page apps, but in that case you should add an additional, custom navigation type called VIRTUAL<\/code>, or something similar, if the navigation was a single-page transition and not a proper page load.<\/p>\n

Do note that window.performance.navigation.type<\/code> does not<\/strong> update when the user uses the browser\u2019s Back \/ Forward buttons and the transition is from one single-page app state to another. So you\u2019d need to code the logic for Back \/ Forward use when no page load is recorded.<\/p>\n

3. Solutions<\/h2>\n

OK, let\u2019s get to the good stuff! In this chapter, we\u2019ll introduce the technical solution in Google Tag Manager<\/a> (Custom HTML tag) that orchestrates the whole thing. In addition to that, each sub-section will detail how to send the respective piece of information to Google Analytics as a Custom Dimension. Basically, all you\u2019ll need to edit is your main Page View tag, since that\u2019s the only one that will be sending this data to Google Analytics.<\/p>\n

3.1. The Custom HTML tag<\/h3>\n

First, create a new Custom HTML tag<\/strong>, and add the following code within.<\/p>\n

\n