How To Build Pageview Analytics From Scratch [12-29-2020]

@Dustin McCaffree

Why We Needed Pageview Analytics

We built Jolt Block a few months ago, which needed analytics that our customers could see in their dashboards, because it tracks bounces/skims/reads for blogs as part of the service.

Luckily, we'd also already built Plaudy to handle that. However, Plaudy only used static events for analytics (a single call to the server that logs an event). That works for most cases, but not consistently for pageview analytics, which was the exact use case of Jolt Block.

The State Of Pageview Analytics

In your browser, there's a type of event listener called onunload, which in the past was used for analytics. This is because if you want to know how long a person was on a page, how far they scrolled, if they bounced vs stayed and clicked through...

How would you track that though? The easiest way was to wait until the page was being "unloaded" or essentially when the visitor was LEAVING that page. Then you'd send a quick request to the analytics API to log the event data on their way out. Sounds good, huh?

Well, it turns out that it was unreliable and had some security concerns. That method has been officially deprecated for asynchronous calls and is hit or miss with synchronous ones.

The Modern Way (Or The Highway)

There is more than one way of doing this one right now, but let's just think about the requirements we have at this point:

• Time on page - We need to be able to know how long a user spends on a page. That means we have to fire the request at the last possible second still, without onunload.
• Bounce rate - This is also reliant on being able to get the event fired, even if the user is only briefly on the page.

These are the 2 most time-sensitive points of data to log for the analytics to work well, so we'll stick with those.

Our solution will be one you've probably heard of but maybe not in the context of analytics software (hint, this is the one we've used now for updating Plaudy).

Websockets, Baby!

So, if you don't know what a websocket is in the first place (and this link is confusing to you), we'll make it simple.

"A websocket is kinda like a normal API request, except for instead of being a one-time ping to the server that sends data back... It is a request (TCP) that stays open, and data can be sent back and forth without needing to make a new request every single time." - Us

The benefit here is that you can have a single open connection for each user causing events, and you can track and update those events in almost real time. This will allow your pageview analytics to be much more consistent and reliable, whether the user is on-page for less than a second or you want to change their logged event in the last second they are on the page. Cool, huh?

If you're interested in an in-depth tutorial on how to actually implement websockets into your application, try using socket.io! Here's their getting started guide, which is actually super clear and straightforward.

What did you think?

More Rad Reads

Productize Everything [12-28-2020]

Look Mom, No Hand(off)s [12-31-2020]