Enhancing "Bounce", "Spent time" and "Visit length" metrics quality by introducing "ping" events

published: 2021-03-25

The context

To demonstrate the problem let's take two examples! Consider the following sequence of actions:

use case #1

  1. User/reader visits PageA.
    At this point a pageview event is generated - so we know that the user is now on PageA.
  2. Then there is silence...
  3. ... until 4 minutes later user goes to PageB
    when a pageview is generated again. At this point we know that user is now on PageB
  4. silence... silence... more silence...
  5. Eventually the visit session times out as user never came back

use case #2

  1. User/reader visits PageA
    At this point a pageview event is generated - so we know that the user is now on PageA.
  2. silence... silence... more silence...
  3. Eventually the visit session times out as user never came back

Observations we can take

So what do we know? In use case #1

  • user visited PageA - it is a fact
  • 4 minutes later user moved to PageB - also a fact
  • visit session is not bouncer session any longer - as we have >1 actions

And what do we assume?

  • user spent 4 minutes on PageA

Well... please note: actually we just assume it! To be honest given the information we collected we have no clue what the user really did in this 4 minutes... Maybe (s)he really spent this time with reading the content of PageA... Or (s)he just went out for a coffee?

How about use case #2? It's even worse! There we can not even have any assumption about how much time the user spent on our PageA. Plus on the top of that: this would be classified as a bouncer session. Which is - in general means - something bad when we are observing the analytics of our pages. However depending on the real content we have placed in PageA it still might be a valuable visit actually!

But do not stop here! There is one more (also pretty important) metrics is affected here and this metrics is: "visit session length"... In use case #1 our assumption would be 4 minutes. In use case #2 we can not say anything...

As we speak most of the (even the key players) analytics tools are going with this model only. And of course this is not a coincidence why...

Conclusion / Problem

Please note: the lack of information simply makes the

  • "time spent on page",
  • "visit session length" and
  • "bounce" (rate)

metrics significantly inaccurate, however they are all very important metrics when you would like to check the performance of your content.

Could we do it better?

Yes! If we would be somehow able to know that
a) actually our user/reader not jumped out for a coffee in that 4 minutes (use case #1) but was in front of the machine and reading (or at least doing something on our page).
b) Not switched to a different browser tab to do something else and
c) in use case #2 (s)he spent 3 minutes with our PageA before actually closed the browser window
then we would be in a much much better position! In so much better position that maybe I do not even want to see this visit session (use case #2) as a classical "bounce" session any longer as I could say: "hey this was a valuable visit to me!"

How could we achieve this?

Let's introduce the "ping" event!

The basic idea is simple!

  1. Let's try to capture signs of user is sitting in front of the machine. A small mouse movement, a tiny scroll, typing on the keyboard, etc etc these are all signs! We can assume that the user is there.
  2. Client side (tracking script) after the pageview event was generated start a timer. Let's say 10 seconds.
  3. Once this 10 secs expired check: did we capture anything described in #1? If yes then fire a ping event towards the server saying: "hey I'm still here!".

Of course this is just a simplified mechanism. The real one should be much more sophisticated. But I think it is easy to see: if we would have a mechanism like this in place then we could make all these metrics much more accurate and valuable!

If this is so simple then why not every analytics tool is doing it?

The answer is obvious: because this means a huge extra load for the analytics system to handle!

Just think about it! Taking use case #1 the analytics tool needs to handle

  • 2 actions - without the ping, while
  • at least 26 actions - with the ping (assuming ping in each 10 secs), even assuming user closed the browser window very quickly after jumping to PageB

This is a massive increase in the load!

Bottom line

We decided @Keytiles that we would definitely like to start experimenting with introducing the ping events!

The key will be to find a very efficient and smart mechanism for the pings. A good balance between the "know nothing" and the "know enough" to be able to make those metrics much better. Let's see! :-) We will share the results definitely!