I opened my own dashboard and it told me a lie.
The chart was clean. Four scroll buckets on the x-axis, conversion rate climbing left to right. People who scrolled further converted better, and the deepest bucket converted 2.18x the shallowest. Every analytics tool draws this chart. Mine draws it too, because I built it.
The advice writes itself: get people scrolling, and they convert. I had the post half-drafted.
Then I split the same data by page, and on the homepage it ran the other way.
Same 15,585 sessions. Same thirty days. Same definitions. The pooled chart was not measuring scrolling at all.
The chart that fooled me
Here is the pooled view, which is what an unsegmented scroll report shows you by default.
| Scroll reached | Sessions | Relative conversion |
|---|---|---|
| 0 to 24% | 9,100 | 1.00x |
| 25 to 49% | 2,837 | 1.80x |
| 50 to 74% | 1,053 | 1.45x |
| 75 to 100% | 2,595 | 2.18x |
Deeper is better, more or less monotonically, exactly the story everyone expects to see. It is the story Mailchimp tells: scroll deeper, and that “signals increased engagement and interest, leading to higher chances of conversion.”
It is an artifact of page mix. The deepest bucket is stuffed with lander sessions, which convert well. The shallow bucket is stuffed with homepage sessions, which do not. Nothing in that table is about scrolling. It is a table about which pages are short and which are long.
What was actually underneath it
The homepage. 5,890 sessions, each bucketed by the deepest point it reached, indexed against the shallowest bucket.
| Scroll reached | Sessions | Relative conversion | 95% CI |
|---|---|---|---|
| 0 to 24% | 4,150 | 1.00x | baseline |
| 25 to 49% | 940 | 2.00x | 1.72 to 2.32 |
| 50 to 74% | 313 | 1.60x | 1.24 to 2.06 |
| 75 to 100% | 487 | 1.29x | 1.02 to 1.63 |
Homepage. Relative conversion above the shallowest bucket, so the centre line is that bucket. The peak is the second bar, and the curve falls from there.
Getting someone past the fold is worth a great deal: bucket one to bucket two doubles conversion. After that it reverses. Comparing the deepest bucket directly against the peak gives 0.64x, 95% CI 0.50 to 0.83. The interval excludes 1.0, so the decline is not sampling noise.
A third of the way down that page is where the good visitors stop.
The lander. 1,206 sessions on a page with exactly one thing to do.
| Scroll reached | Sessions | Relative conversion | 95% CI |
|---|---|---|---|
| 0 to 24% | 943 | 1.00x | baseline |
| 25 to 49% | 150 | 4.32x | 2.05 to 9.13 |
| 50 to 74% | 39 | 7.56x | 2.92 to 19.57 |
| 75 to 100% | 74 | 8.76x | 4.22 to 18.19 |
Lander, same construction, same weeks, same tracker. It climbs the whole way. The intervals are wide because the deep buckets hold 39 and 74 sessions.
Opposite shape. Same instrument.
Why one climbs and one falls
This part is my read, not a measurement.
A homepage is a menu. Someone who scrolls it end to end has looked at every option and chosen none. The visitors who converted stopped a third of the way down, because that is where the thing they wanted was, and they clicked it instead of continuing.
A lander is a single argument with the action at the bottom. Scrolling it is reading. Reading it to the end is most of the way to acting.
If that holds, deep scroll on a hub page is not engagement. It is a visitor working, and losing.
Nielsen Norman Group has been circling this for years: their scrolling and attention work found attention concentrates above and just below the fold, and their reading behaviour studies found people scan rather than read. Neither says depth means the same thing on every page. That distinction is the whole finding here.
The reason your dashboard disagrees
What happened to me is Simpson’s paradox: a trend that holds in the pooled data reverses when you split it into the groups it was built from. Nothing about the statistics is new. What is worth saying is that the pooled chart is the default view, in every analytics tool I know of, including mine.
And if you are on GA4, it is worse than a default. It is the only thing available.
So the standard GA4 scroll analysis compares “reached 90%” against “everybody else”, pooled across every page on the site. That is the most confounded version of this metric it is possible to build, and it is what the platform hands you out of the box. It is also, I suspect, why almost nobody publishes the segmented version.
How to check this on your own site
Three steps, and the second is the one that matters.
If you check and get the tidy climbing version, you are looking at the pooled view. That is the finding, not a refutation of it.
What I would actually do on Monday
On hub pages, treat footer-reach as a leak. Pull the sessions that hit the bottom and look at what they did next. If they exited, the page failed them. The fix is moving the decision higher, not adding more below it.
On landers, stop cutting length because “nobody scrolls”. Most people do not. The ones who do are the entire point. The deep bucket here is 74 sessions carrying 8.76x.
Never act on a site-wide scroll report. It is an average of two opposite behaviours.
What this does not say
The number people will quote is 8.76x, and it is the most confounded figure in the post.
This is correlation. Scroll depth and conversion are both downstream of intent. A visitor who has already decided scrolls the lander and converts; the scrolling did not cause it. Nothing here supports lengthening pages, adding scroll-bait, or touching the scrollbar. The action is segment your report, not make the number go up.
One site, three pages, thirty days, one commercial vertical. A counterexample to the pooled reading, not a law. Whether hubs behave this way generally is untested here, and the honest version of this post’s claim is that pooling hid a reversal on this site, so it can hide one on yours.
The second hub is not a second proof. Another hub page in the data resembles the homepage’s shape, and I am deliberately not leaning on it: its deep buckets hold 35 and 111 sessions and the top bucket’s interval is 0.85 to 1.76, which crosses 1.0 and confirms nothing. One page carries the hub finding.
Thin deep buckets. 39 sessions in the lander’s third bucket. The intervals show that rather than hide it.
Coverage is 67.4%, and it is not random. Scroll depth rides on a page_hidden event that fires on internal navigation or tab-hide, and never when someone closes the tab. The missing third are disproportionately fast bouncers, so the shallowest bucket is under-counted, and converters navigate, which is the behaviour that emits the event. Both distortions inflate the baseline, which makes every ratio above a rough lower bound. The lander’s 8.76x survives that comfortably. The homepage decline compares two deep buckets with similar sampling behaviour, so it is largely immune.
The site is a client’s, so every figure is a ratio against that page’s own shallowest bucket, never an absolute rate. Counts and intervals are in every table so the ratios can be recomputed.
Method
One row per session per page: the deepest scroll it reached, joined to whether that session converted anywhere in the window.
WITH sc AS (
SELECT session_id,
MAX(CAST(json_extract(meta,'$.max_scroll') AS REAL)) AS depth
FROM events
WHERE event_type = 'page_hidden'
AND page = :page
AND json_extract(meta,'$.max_scroll') IS NOT NULL
AND COALESCE(CAST(json_extract(meta,'$.scrollable') AS INTEGER),0) = 1
GROUP BY session_id
),
conv AS (
SELECT DISTINCT session_id FROM events WHERE category = 'conversion'
)
SELECT CASE WHEN depth < 25 THEN '0-24'
WHEN depth < 50 THEN '25-49'
WHEN depth < 75 THEN '50-74'
ELSE '75-100' END AS bucket,
COUNT(*) AS n,
SUM(CASE WHEN conv.session_id IS NOT NULL THEN 1 ELSE 0 END) AS converted
FROM sc LEFT JOIN conv USING (session_id)
GROUP BY bucket;Ratios are relative risk against each page’s shallowest bucket; intervals are 95% by the log method, computed from the counts printed in the tables.
scrollable = 1 drops views where the page was shorter than the viewport, because those report 100% by design and would stack the top bucket with non-events. That removes 2,932 sessions whose only samples were on such pages, which is why coverage (18,517 sessions with any sample) exceeds the bucket totals (15,585). Known AI crawlers are counted by this tracker but emit no scroll events, so they never reach these tables. That blindness is its own measurement problem.
This is the second time a tool I built has reported something confidently wrong to me, and the second time the fix was to check the instrument before the finding. The first was an agent memory ledger that mis-counted its own writes. The general version of the lesson is not assuming the thing did what it said it did.
Sources
- Google, Enhanced measurement events. The
scrollevent and its single 90% threshold. - Mailchimp, Why Scroll Depth Matters and How to Improve It. The pooled reading this post is arguing with, stated plainly: deeper scroll “signals increased engagement and interest, leading to higher chances of conversion.”
- Nielsen Norman Group, Scrolling and Attention and How People Read Online.
- Simpson’s paradox, the reversal described above.
Related:
- Claude Code Memory: I Measured a 24.6% Delivery Rate
- Your Analytics Cannot See Most AI Crawlers
- You Are Invisible to Machines
Measured 2026-08-25. Behavioural rather than tool-bound, so it dates slowly. Re-check 2027-02-25.