Measuring Time on Last Pages

Your web site might not sell anything. Instead, your friendly marketer might look at the time that visitors spend on the content.

Let’s not discuss how accurate or useful that metric is. Someone else has likely discussed this with your friendly marketer at length. But she wants the metric, so you have to make it happen.

Technically, SiteCatalyst Adobe Analytics tracks Time Spent on Site and Time Spent for pages anyway. With one exception — the last page of a visit. Because the system uses the load time of the next page to figure out how long the page before it was on screen, the duration for the last page a visitor saw cannot be calculated.

Hm.

The issue with that is Google. If you’re a retailer, you might have a good part of your traffic that just looks at single product pages, then leaves. The same goes for sites that have information — news sites, blogs, etcpp. Let’s face it: a lot of people use Google as our site navigation.

Often, it is really important to know whether the visitor left immediately, or whether she spent some time and read the page or looked at the information.

Workarounds

In order to build a workaround, we need to manually calculate and send the time into Analytics.

I can think of three technical approaches:

• use the beforeunload event
• use a timer
• use user activity (like scrolling)

And there might be a fourth one:

• outside the box – use Video Tracking

I’m sure there are more ways, feel free to chime in.

Use the beforeunload event

The ideal idea would be to use the onbeforeunload event handler which is called in case of a beforeunload event.

Inside that handler, we could place some simple code that ultimately calls s.tl() or a Direct-call Rule.

My hunch would be that some browsers might close tabs so fast that the call wouldn’t have time to go out. I cannot quantify that, to be honest, but a quick test shows none of my browser actually sends any tracking, even if I make it so the page pops up a “leave/stay” dialog. I tested with Chrome, FF, Opera, Edge, and Vivaldi.

Clearly not a workaround at all.

Use a Timer

As long as a page is open in a browser tab, we can use Javascript to our heart’s content.

One thing we could do, for example, is to define a minimum time that we consider relevant for the consumption of the page — say after 30 seconds, the page has not just been opened, but actually been consumed.

Nothing stops us from sending tracking information after that specific interval.

In our case (using Adobe Analytics), we would send a Success Event plus an eVar carrying the name of the page. This would later allow us to see two things for every page: how often has it been loaded, and how often was it still open 30 seconds in. We can even make a Calculated Metric called “Consumption Rate”.

From a technical perspective, this is a pretty straight-forward solution.

Unfortunately, in the eyes of your friendly marketer, it has some issues.

1. what interval should you use?
2. how about pages of different length?
3. what about people who open pages in a background tab? Or those who go to lunch?
4. what about cost?

For starters, it is not straight-forward to decide what interval you should use! How long do people look at your pages? How long before you’d say they have now really looked at a page? Does it depend on what type of page it is? How long does it take to scan a product page? How long for a Medium blog post?

And then there are those who use tabs like short-term bookmarks — “open link in new tab”. Would I really want to consider those read after some time? No, I wouldn’t.

In the good old triangle of “complete”, “accurate”, and “not too costly”, the timer isn’t great on any of the attributes. “Complete” versus “accurate” is a trade-off, at best, and if you want to improve on those, cost goes up quickly, because you would likely implement more than one timer and therefore send multiple tracking calls per page.

Still, the solution does provide data, and a lot of people work successfully with this kind of data.

Use User Activity (like Scrolling)

We want to know whether the visitor “is interacting with the page”, or maybe just “is on the page”, which technically, we cannot detect. She might have loaded the page and stepped out, or she might have loaded it in the background.

So how about detecting interaction? Scrolling would be an indicator, as would be some mouse events (I know people who highlight text while they read it. Yeah! I know!), or maybe even tab focus events.

Scrolling is almost obvious: if a visitor is moving around on the page, she’s likely more “engaged” with it than if the page is just sitting there.

I wrote “almost obvious”, because even scrolling is only a vague indicator. Scrolling to the bottom very quickly could be a sign of “where’s that ‘Next’ button?” Remember how Simo Avaha added a timer to his scroll tracking (which I mirrored)?

I guess we’re looking at a combination of timers and activity.

I’m no UX expert at all, so I don’t even know whether there is any research about types of information and how humans interact with it. The epic You Won’t Finish This Article rant only looks at time and fluffy “engagement”, Nielsen research points to F-shaped pattern.

It probably makes sense to start with something simple, to be honest. Should I leave the security of my field of experience and ramble on?

Rambling

Ok, here we go.

What would that “combination of timers and activity” look like?

For starters, we would use the Page Visibility API to figure out when the page is actually visible or not. Create your own actuallyVisibleSeconds variable and keep track of how long the page was in focus.

Set some flags, like hasScrolled, hasFocussedOnField, or hasUsedMouseOnContent, as they happen.

Use setTimeout() to check the variables and flags after a short timeout, then send a request if any one of them is true.

This should give you a reasonably not-bad indicator of the page being in focus of the visitor.

And because I don’t want to assign any meaning to this, much rather quantify “being in focus”, I would simply send one Success Event, which I would call “Page Interactions”.

In a funnel, this would yield slightly lower numbers than the Page Views metric, and slightly higher numbers than the “Scrolls to Bottom” metric.

And then?

Yes, that is a very valid question: what do we do with the data?

I’m tempted to say that for most actual business questions, time on page is only an indicator, and there are very likely better metrics to look at.

Example product pages: I’d like to know whether people read the reviews, which sometimes are below the fold. Well, why not use the “enters viewport” built-in DTM Event-based rule trigger? The same goes for recommended products.

This has the advantage that tracking happens right when it matters, as opposed to having to wait for a timeout. The latter comes with the risk that the visitor closes the tab that they temporarily gave you — breaking our tracking attempts.

But what the data will tell your friendly marketer is what proportion of visitors leave without any sort of interaction. And for some sites, that is pretty valuable information.

Retail: those people coming straight from a search engine and only looking at a single product page … do they stay long enough that we might have a theoretical chance of getting them to convert?

Media: do they read the article they found via search engine? Can we ask for more money for the ads knowing that they do?

Finance: does the brochure ware site actually contain any useful information for visitors? I.e. do they give up, or do they close the tab because they found an answer?