Track page read not page views

When I first started to work on the web, I had no way to track how users interacted with my websites. I created HTML websites and the only way I could think of to know how many people visited was to use those all too familiar page counters. Fast forward a few years, there are so many analytical tools available. But just like page counters, we use analytics mainly for page views.

It was an emotional battle for me with my early work. When the numbers went up on my websites I was excited, when the numbers were down I'd be sad. The page view data was only an emotional motivator that had very little practical use.

What are page views anyway?

When you click on a link or type a URL on your browser, a page opens. That's a page view. When you then press the browser back button and the browser takes you to another page, that too is a page view. Sometimes you suddenly notice audio playing on a different tab that you don't remember opening, not surprisingly, it is a page view.

A page view, unlike the name implies, doesn't require a page to be viewed. A page view can be defined as a page being accessed. It can be willful, without your knowledge or completely automated by a bot.

In the web world, the page view metric is used as a selling point to count the popularity of a website. News articles usually feature a page view number right next to those Facebook likes and twitter share. The bigger the number the more popular the work seems.

The problem is, the page view itself is merely a metric, and it doesn't tell the whole story. It says that the page was accessed. That's it.

Now analytical tools like Google Analytics or Omniture try to make sense of this number by tracking the time and session to determine the story of the user, and that's good. But by default it is still limited.

For example, when this blog was still new, it received around 12 page views a day. One day, I posted a link on hackernews and the number soared to a whooping 500 page views. It was a relatively impressive number, only there was another interesting number next to it. It showed the bounce rate to be as high as 90%.

Bounce rate: the percentage of visitors to a particular website who navigate away from the site after viewing only one page.

The success of a blog post was defined as getting as much exposure as possible and the page views were only an illusion of exposure. Out of those 500, only 10% or 50 people clicked on another link.

Using page views and bounce rate gives us a clearer idea of what is happening. It is certainly better then just knowing how many times a page was accessed. But still, the two metrics don't tell us the full story. I think for a blog post or article to have any value it needs to be read. Knowing that a person clicked on the first link, then clicked on another doesn't tell me whether they read it or not.

Page Reads

The web is text based and most content is consumed by reading. If there was a universal button that lead people to click after they have finish reading, then I could stop this article right now and go on with my day.

But unfortunately it's not that easy. There is no simple way to detect if a user is reading. JavaScript doesn't have an onread event built in. Instead we have to be creative and try to solve this problem by ourselves.

First there is one piece of information we can extract, it is generic and and not 100% accurate but it is still better then no data at all. The time the user spends on the page and the average speed of reading.

Determining when the user is done reading is hard, instead we can focus on tracking if the user hasn't read. This can be done by tracking how long it takes the user click the back button after the page loads.

If the user leave in less then a minute, chances are they haven't read the article. Relying solely on this number could also be problematic, sometimes I open 10 links on a different tab and only get to them much later. Sometimes I close them all together without ever reading.

To combat this problem, we can add the element of interaction on the page. When the user opens a page, there are many other things they are doing. The user will interact with the page by scrolling, moving the mouse, clicking, or typing. Any of these or a combination thereof can be used to track interactivity from the user.

Using these we can come up with an algorithm to determine if the user has read the article. Here are the metrics:

• page view
• time spent on page
• average reading speed and length of the article
• user interactivity (scroll, mouse click, scroll to the end of the document, etc)

This combination make those numbers tell a better story. Not only we know how many people accessed a page but also if they read the article on it.

Now that we have a metric that tells a better story, we can customize it to our own needs to make it more specific. For example, if we add a like (and/or dislike) button that only appears after the criteria of Read has been met, then we can tell with much more confidence if the user liked the article or not. Unlike the traditional Facebook like that is very ambiguous and you often see people liking a post saying "a grand mother has died", all because of a lack of options.

We can even make comments only appear of the user has read.

---

Book, poison, rat, wizard, are just words. By themselves, they are no different then the number of page views on an article. But by observing their source and context, we can reconstitute them to tell the story they were meant to tell. Instead of just saying we had 10 page views, we can say 10 people read the article, and among those 5 liked it, 3 disliked it, and we have no clue what the two other thought.

The whole point of using analytics tools is to understand what the user is doing on our page. Page views by themselves are generic and can be interpreted in a million ways. Using page reads is a step up that starts to tell us a more accurate story.

---