What GA4’s scroll tracking actually measures
Turning on enhanced measurement makes a scroll event appear in your reports, and it is easy to assume you now have scroll data. You have one bit of it, per visit.
If you run a WordPress site through Google Analytics 4, scroll tracking is on by default. It sits in the enhanced measurement panel next to page views and outbound clicks, and it needs no configuration. That last part is the problem: there is nothing to configure.
scroll event once, when the visitor passes 90% of the page depth. There is no 25%, 50% or 75% threshold, and the 90% figure cannot be changed in the interface.
So the event answers exactly one question: did this person reach the bottom of the page, yes or no. That is a genuinely useful question. It is not the question most people think they are asking.
What you cannot see
Consider a 2,500-word service page with eight sections and a contact form at the end. GA4 tells you 14% of visitors passed 90%. What it will not tell you:
- Whether the other 86% left at the first section or the seventh.
- Whether the people who did reach the bottom read anything on the way, or hit End.
- Whether the section you rewrote last month is where they stop.
- Whether the drop-off is different on phones, where that same page is four screens longer.
All four are answerable questions. None of them are answered by a single boolean.
The 90% figure is stranger than it looks
90% of the document height includes your footer, your cookie notice if it pushes layout, related-post grids, and comment forms. On a page with a tall footer, a reader can finish the last paragraph of the actual article and never trigger the event. On a short page, the whole thing fits on one screen and the event fires immediately for everyone, telling you nothing.
This is why the same threshold produces wildly different-looking numbers across a site without anything about the writing changing.
The usual fix, and what it costs
The standard answer is to build scroll depth triggers in Google Tag Manager: fire at 25%, 50%, 75%, 100%, send each as an event. It works, and if you have GTM already it is an afternoon.
What you get back is still percentages of a page, not parts of a page. “Half of readers passed 50%” only becomes actionable when you go and look at what happens to be sitting at the halfway mark, on the screen size you happen to be checking. Change the page and every previous measurement now refers to a different piece of content. The numbers do not survive the edit that they were supposed to inform.
What to measure instead
The question an editor actually has is not “how far down did they get” but “which part lost them”. Those differ in one important way: the second one has an answer that survives a redesign, because it is attached to a piece of content rather than to a coordinate.
If you want to answer it with what you already have, the honest minimum is:
- Build the GTM thresholds, so you have more than one data point.
- Record the date of every structural edit to the page, by hand if necessary, so you know when a comparison stops being valid.
- Check phone and desktop separately. A section that is comfortably above the fold on a laptop can be three screens down on a phone.
That is a real amount of work per page, which is why most sites do not do it, and why “traffic looks fine” ends so many conversations about a page that is not working.
Why we wrote this
We make Block Insights, a WordPress plugin that measures reach, dwell time and clicks for every block on a page, so the drop-off has a name and a position instead of a percentage. It records structural edits too, so a comparison knows when the page changed underneath it.
It is a paid plugin, and it only measures pages built in the block editor. If you use a page builder, the GTM route above is your answer, and it is a perfectly good one.