This is Part 2 of a series. You can read the first post here. Also, don’t forget to find the Tom Lehrer reference.
Last we met, I said that content effectiveness is a murky concept at best and you’ll never find the metrics to measure it. So what do you think I’m going to give you in this post?
A metric to measure it.
It’s a proxy metric. We will never know for sure if the user’s eyes twinkled. Did they yell “EUREKA!” when they scrolled to the bottom?
But we need a metric to use so we can understand differences. Differences between content. Differences in content performance after an update. If all you measure are pageviews, you may never get a sense if content changes were effective. (Note, there will be entry in this series to talk about when measuring pageviews is an appropriate measure of content engagement, but not now).
Lots of folks turn to scroll tracking as a proxy for user engagement. I used to be one of them. But it’s seldom been an effective measure.
- If you use the typical 25/50/75/100% scroll tracking, then all your content better be the exact same length. Otherwise, you can’t compare apples to apples.
- Got anchor links?
- Once you toss universal scroll tracking at four points into the mix, you are going to get A LOT of events. If you’re still in Universal, then holy sampling batman. A larger site in standard GA4 will hit their BigQuery export limits.
- Ever met a nervous scroller – you know, someone who scrolls up and down a page while on their 7th Zoom call of the day? No? Well, nice to meet you, I’m Marissa. This is what I do during meetings.
Others turn to time on page, (or, in GA4, engagement time). But as in life, we need to ask ourselves “is time even real?”
- It definitely wasn’t in UA (Read my previous post on the topic – it’s old, but I still stand by it)
- Because GA4 is event based, it’s getting better;
- But even if time is real, is it a good measure of effectiveness? (I also wrote about this a while back, and I still stand by it).
Unless you determined a “time-to-task” for content: “It should take a user at least 3 minutes to fill out this form, but no more than 10”, I mostly refuse to look at time on page metrics. Because like time, it has no meaning.
So if scroll tracking is a terrible proxy metric, and time on page is a terrible proxy metric, what should we use?
We want people to scroll. We want them to stay on the page for a while. So we fire an event when they do both. We shall call it the dwell and scroll.
(I didn’t coin the term dwell and scroll. I think it might have been Simo Ahava. I mean, pretty much everything I do, I do because Simo said so.)
“Did she just say she’s going to take two crappy metrics and make one, glorious metric out of it?”
Yes she did.
“But wait! You said this tracking would be no good if your content had different lengths.”
Ah, you ask a silly question, you get a silly answer.
It’s true, I did say that scroll tracking isn’t great for different content lengths. But…
It’s common, when doing a dwell and scroll, to do a static trigger: the user is on the page for 30 seconds, and they scroll to at least 50%. But what if we could change the time, depending on the length of the content. Now hold on, because there’s a bit of new math here.
- There’s a lot of research that has gone into reading times on the web. I’ve seen research on average reading speeds on the web to be anything from 200-400wpm. If you can, observe your users and consider the content. Is it a blog post? A scientific article? Instructions for a complex task? In this example, we’re going to split the difference and say 300.
- Next, we count the number of words in the body content. Let’s say we’ve written something between a blog post and scholarly article, at 3000 words.
- So, if the average reader is going at 300 wpm, we’d expect them to be on this page for 10 minutes.
- We’d also want them to scroll. In general, I have the scroll go off at 50%, but again, think of the content. If it’s imperative the user gets to the bottom to get something out of the content, set it to 90%.
So, in GTM, I’d set up a trigger that says “if the user stays on the page for 10 minutes AND scrolls past 50%, fire a “dwell_and_scroll” event.”
Now, don’t worry about all this math. I’ve put together a GTM export file that will do the math for you. You don’t need different triggers for different lengths of pages. But please be kind with me. While I’ve made GTM exports before, this is the first time I’ve shared one. I probably screwed something up.
Now, we have a better sense if users are hanging around AND scrolling.
Perfect, right?
No. This isn’t perfect. Everyone surfs the web in their own unique way. I can ctrl+f a page and hop to the bottom. And trust me, I can nervously scroll for hours.
But this isn’t about achieving perfection. This is about adding a metric to your toolkit to measure change and improvement.