An improved model of Pageviews?

For data modelers & consumers
1

Philip Walton, a Google engineer who has worked on Google Analytics autotrack functionality, published an article today that addresses the shortcomings of traditional pageview events: https://philipwalton.com/articles/how-we-track-pageviews-is-all-wrong/

The article articulates some interesting points and proposes solutions for some of the major drawbacks of the traditional pageview event in analytics trackers like GA and Snowplow. The suggested fixes include bifurcating the traditional pageview event into two events: pageload and pageview. This fix also helps with measuring pageviews when tracking analytics on a Single Page App or Progressive Web App, and also better tracks pageviews during tabbed browsing.

I’m curious if 1) any Snowplow users have already implemented some measure of this model and 2) would the Snowplow Analytics team ever consider modifying the Javascript tracker to behave in this way by default?

1 Like
2

Personally, I avoid at all costs any implementation that involves pageviews and clicks. These terms, and measurements mean nothing. We have invented them to sell ad inventory at the dawn on internet civilization. It doesn’t work that way any more. It makes no sense to measure something for the sake of measuring itself.

1 Like
3

I agree with you generally, but this proposes a redefinition of pageview to something more useful, which makes some sense to me.

If your events don’t include pageviews and clicks, what events are you using to signify interactions with your pages and calculate session times?

4

I’ve seen certain instances where analyst configure their page load tag to only fire when the page is visible, helping to mitigate against users opening pages in background tabs when they don’t even look at them.

It is important to remember that the page-view -> session model that’s been with us since the dawn of web analytics does not match the reality of how real users browse the web, or how modern day websites are built. Thankfully Snowplow does allow us to take things like page pings and scroll depth into account when analysing page performance, but I agree we do need to slightly reassess how we classify people looking and consuming web pages beyond just the page being rendered to the screen.

5

Version 2.7.0 of the Snowplow JavaScript Tracker recently addressed this issue.

If you have the webPage context enabled, that will generate a UUID for each new page view. Historically a new UUID was generated each time the tracker loaded (ie with each page load). That wasn’t working so great for Single Page Apps, for the reasons outlined in Walton’s post.

Since v 2.7.0 a new page view UUID is now generated whenever you call the trackPageView method. You just have to make sure that the method gets called on the occasions that you want to track as new page views.Snowplow Javascript Tracker 2.7.0 released