Page views tell you nothing about whether your article was read

Robbie Haas · 8 min read

Four thousand views. Nine-second average time on page. That post didn't get read. It got clicked.

Somebody landed on it, took one look at the headline they'd already seen on LinkedIn, and left. Multiply that by a quarter and you have a slide deck full of arrival data being presented as evidence of interest. Views tell you a browser loaded a URL, and that is the entire scope of what they know.

By the end of this you should be able to look at anything you've published and say whether it worked, where "worked" means somebody read it and then did something. Setup is an afternoon.

Why the number stuck around anyway

Page views are popular for a boring reason: they're the easiest thing to pull, and they almost always go up. Publish more, get more views. Run a paid promotion, get more views. Change nothing at all and let a post age into a few more search impressions, get more views.

Every analytics dashboard leads with it. It's the first card on the screen, the biggest font on the page, so it becomes the number everyone learns to defend. You start the month hoping it climbs, and when it does, you feel like the work landed. That feeling is doing a lot of unearned work in your reporting.

The problem isn't that views are wrong. They're accurate. They just answer a question nobody is asking.

What you're actually trying to find out

The question is whether the writing moved anyone. Not whether it was seen. Whether it did work.

Views can't answer that in either direction. A post with 200 views that three buying committees read end to end before they ever spoke to sales did more for the business than a post with 40,000 views that pulled in a crowd with no reason to buy. Views can't tell those two apart, which means they also can't tell you whether to write more like the first one.

It gets worse when the number moves. A traffic drop reads as bad content when it can just as easily mean bad distribution, a search update, or a week when half your audience was at a conference. You end up rewriting something that was fine, or leaving something broken because the line went up.

What to measure instead

Scroll depth tells you how far down the page a reader got. Dwell time tells you whether they stayed long enough to have read it. The next action tells you whether the piece pushed them anywhere. Between them they answer "did this work" in a way traffic never will.

Do not put dwell time on a report by itself. A browser cannot tell reading from a tab left open in the background, so twenty minutes of inattention looks exactly like twenty minutes of close attention. Paired with scroll depth, most of that noise cancels out, and the pair is worth more than either half.

You also need to decide what "did something" means before you start measuring, because the answer is different for every business. A demo request. A pricing page visit. A newsletter signup. Write it down first, or you'll end up with behavioral data and no idea what counts as success.

Join the published URL to the behavior on it

Most teams can't answer the question because nothing connects what they published to what happened on it. The blog lives in one system, the analytics in another, the CRM in a third, and the join never happens.

Fix that connection before anything else. Every article needs a stable URL, and every behavioral signal needs to be tagged with it. Once the join exists, attribution stops being a modeling exercise and becomes a lookup: which URL, what did people do on it, what did they do next.

Plenty of teams wait for a full attribution model before they measure anything at all. The model isn't the prerequisite. The join is the only piece you genuinely cannot skip, and it's also the cheapest.

You don't need to know who the reader is

This surprises people, because the industry has spent a decade selling the opposite. Whether an article worked is a question about the article. Aggregate scroll depth on that URL, aggregate dwell time, aggregate next actions. None of that reporting depends on attaching a name to anyone.

Our own tracker works on that basis. No IP addresses are stored, there's no fingerprinting, and nothing in the content reporting requires you to identify a reader. One identifier sits in the browser so repeat visits can be counted as repeat visits rather than as strangers, and that is the extent of it. You drop a script tag in your site's head, say what your next actions are, and that's the install. Day one you see scroll depth and dwell per URL. Give it about three weeks and you can sort your whole library by read-through.

It doesn't replace GA4. Keep that for sessions, channels, and everything finance asks about. This answers the one question GA4 was never built for.

Read the report, then change something

Sort your articles by scroll depth and next actions instead of views. The ranking will look different from the one you're used to, with pieces you were proud of near the bottom and something you wrote in an hour near the top.

Then act on it. Where readers drop at 15 percent, rewrite the opening, because that's a hook problem rather than a topic problem. Where they read all the way through and then leave, you're missing a next step. Whatever sits at the top is the shape of the thing worth writing more of.

A report nobody acts on is a slower page view counter. The point of a smaller, more honest number is that you can move it on purpose. You can't make people care more by publishing more, but you can rewrite an intro that loses 90% of readers in the first screen, and you'll see that in the scroll data inside a month. Views would have gone up either way and told you nothing about which change worked.

A few things you'll probably run into

If your scroll numbers look impossibly good, check whether short posts are inflating the average. A 400-word page is easy to reach the bottom of by accident, and segmenting by length makes the picture honest again.

If nothing seems to drive next actions, look at whether your articles have a next action at all. A great many B2B posts end on a summary paragraph and leave the reader with nowhere to go except the close button.

If your traffic is too thin for any of it to mean anything, aggregate by topic instead of by article. Ten posts about the same problem, read together, will tell you something a single post with 40 visitors cannot. And if your category feels too technical for this to apply, it isn't. Scroll depth on a deep technical piece is more informative rather than less, because casual readers filter themselves out early and the ones still there at the bottom are the ones you wanted.

The number that survives a hard question

Once the join exists, there's a further step available to you, and it's the one that holds up when somebody pushes. Which deals touched a piece of content before the first sales call, and how many days earlier did they show up than deals that didn't. Two facts, and they're the ones a CFO can hear without a translation from marketing into English.

That step does need identity, and it's worth being straight about the trade. Measuring whether an article was read needs nothing about the reader. Tying a specific deal back to a specific post needs to know who that person was, which means a form fill, a login, or something else they gave you deliberately.

Attribution at that level is never perfect. Somebody read the post on their phone, forgot it, saw a colleague share it, then filled in a form three weeks later on a laptop that looks like a different person to your analytics. You're not building a courtroom case. You're building a defensible pattern: deals that touched content arrive warmer and earlier, and here's the count.

Smaller and honest beats bigger and meaningless

The trade nobody wants to make is walking into a meeting with a lower number on the slide. Views were 40,000. Halfway scroll rate was 9%. Eleven deals touched content before the first call. The second and third numbers look worse and they're the only ones you can do anything about.

Pull your top ten posts by traffic this week and sort them by scroll depth instead. The order will change, and the ones that jump to the top are the ones worth another 400 words and a second promotion. Then put those numbers in your next report and let the view count sit in an appendix, where it belongs.

You already publish the work. This just tells you which parts of it landed.

Common questions

How do you measure whether a blog post worked?

Look at how far down the page readers got, how long they stayed, and what they did next. Scroll depth and dwell time only mean something together, because a tab left open in the background produces the same long session as a careful reader. Sort your library by those signals instead of by traffic and the ranking will not be the one you expect.

Do you need to know who the reader is to measure content?

No. Whether an article worked is a question about the article, not about the person reading it. Aggregate scroll depth, aggregate dwell time and aggregate next actions on a published URL answer it without any of your reporting depending on knowing a name.

Why is time on page unreliable on its own?

Because a browser cannot tell reading from a tab left open. Twenty minutes of background tab looks identical to twenty minutes of close attention. Paired with scroll depth most of that noise disappears, which is why the two belong together rather than on separate lines of a report.

Do I need an attribution model before I start measuring content?

No. The model is not the prerequisite. The piece you genuinely cannot skip is the join between the published URL and what happened on it, because the blog, the analytics and the CRM usually sit in different systems and nothing connects them. Once that join exists, attribution becomes a lookup rather than a build.

Does this replace Google Analytics?

No. Keep GA4 for sessions, channels and anything finance asks about. This answers the question it was never built for, which is whether one specific article got read and whether the reader went anywhere afterwards.