Rethinking Web Analytics: A Better Way to Measure Content Performance

The Analytics Dilemma: Finding the Right Tool

As I’ve put together this blog, I’ve asked myself: how will I measure its performance?

With my background, I’d love to use Adobe Analytics, but I won’t spend that cash on a little personal blog with no traffic yet. This leaves me with several options:

• Google Analytics - the most common choice
• PostHog Analytics - a newer, more flexible platform
• Building something custom (more on this later)

Given my background as an Adobe Analytics consultant, I hate Google Analytics. Its methodologies are okay, but the out-of-the-box reporting drives me crazy. So I’m striking out Google Analytics.

A Better Alternative Emerges

PostHog Analytics speaks my language. It’s much more versatile - you’re not forced into their box or any given box to do things their way. I’ll probably implement PostHog because it’s quick to set up.

What Metrics Actually Matter for Content Websites?

This got me thinking about which metrics matter most for content websites:

1. Headline performance
2. Time on page/site
3. Page depth (if someone viewed this content, how many pages did they consume afterward?)
4. Conversion rate (typically tied to newsletter signups for content sites)

The Ugly Truth About Time on Page

Here’s the reality: time on page metrics suck across all platforms.

Why? They calculate this based on:

• The timestamp of the page load
• The last tracking beacon that came in

Most websites only track page loads, not scroll depth. If someone starts at the top of a 2000-pixel webpage but only scrolls to pixel 800 (less than half), this isn’t captured accurately.

Companies with cash to burn solve this by:

• Firing image beacons every few seconds (rare because of cost)
• Using scroll depth tracking (triggering beacons at 50%, 75%, and 100% marks)

The Video Analytics Inspiration

This approach made me wonder: is there a better way?

When I consulted at comScore, my team built a web analytics prototype during a hackathon that used the video analytics platform. Video analytics send heartbeats, so we rigged the system to operate on websites where:

• Heartbeats would be sent regularly
• Any data could be attached to these heartbeats
• Tracking was continuous rather than event-based

The prototype worked! But we didn’t win the hackathon. (The winning project? An automatic scorekeeper for the break room foosball table using lasers).

WebSockets: The Future of Analytics?

Based on my experience with video tracking, I’ve always thought web analytics should move from standard HTTP requests to something like video heartbeats.

WebSockets seem perfect for this approach:

• Set up a WebSocket API to send data automatically
• Lighter and cheaper than full HTTP requests
• The disconnect event could provide truly accurate time-on-page metrics

Building a Better Analytics Solution

I’m thinking of building a WebSocket API that gives true time-on-page analytics. You could still send additional data through it, but without worrying about beacon counts.

Different analytics providers bill based on:

• Number of beacons processed
• Number of users
• Number of sessions

Our cost structure would likely be tied to session count, with the entire session stored in the database along with:

• Accurate time on site
• Pages visited
• Visit order

My Proof-of-Concept Plan

I’m going to build my own WebSocket API analytics tool! Here’s my timeline:

• Two days for the proof of concept
• One day for the landing page
• Outreach to publishers and content providers (who would benefit most)