What is scroll depth?

It is a measure of visual travel, not of comprehension. It records that part of the document passed across the screen, and nothing more. The browser does not know whether the user read that passage, skimmed it looking for something else, or left a finger resting on the glass while glancing at the phone.

That is where the most widespread misreading comes from, which is treating the figure as a quality grade. A long journey can mean sustained interest, and it can mean exactly the opposite: someone who cannot find the answer and keeps scrolling in search of it. A help page with the solution in its second paragraph ought to produce short journeys, and that would be good news.

The percentage also depends on how the page is built. The same amount of text yields different figures if a long footer, a list of related articles or a comment block sits underneath, because all of that lengthens the document and pushes the threshold further down. On mobile the total height for the same content is far greater than on desktop, so figures across devices are not directly comparable.

The metric earns its keep when paired with something else: which element sat at that height, and what the user did next.

Google Analytics 4 collects it by default through enhanced measurement, and the exact detail is worth knowing because it is more limited than it looks. The event is called scroll and fires the first time a user reaches the bottom of the page, that is, when 90 % of the vertical depth becomes visible. It is sent once per page load, and the request carries the percent_scrolled parameter with the value 90, which can be checked in DebugView. The parameter table in the official help lists only engagement_time_msec, so the parameter name is better verified in the debugging tool itself.

The practical consequence is that there are no intermediate steps. GA4 does not record 25 %, 50 % or 75 % on its own: whoever reads the report only knows how often the foot of the page was reached and how often it was not.

For finer steps you have to leave enhanced measurement and build it with Google Tag Manager. The usual route is to switch off the scroll option in enhanced measurement so the 90 % event is not duplicated, create a scroll depth trigger with the percentages you want, and send a GA4 event carrying the percent_scrolled parameter tied to the threshold variable the trigger itself fills. One step gets forgotten often: registering percent_scrolled as an event-scoped custom dimension in the property admin, because without that registration the parameter arrives but cannot be broken out in reports.

The decision that hangs on this figure is one of placement. If the form, the contact button or the deciding argument sits below the point most people reach, that element does not exist for most people. Moving it up costs little and can be checked afterwards with the same measurement.

The second decision concerns length and structure. When a long page shows a sharp drop always in the same stretch, that stretch usually holds a specific obstacle: an ad block that interrupts, a table that overflows on mobile, a change of subject that breaks the expectation the headline set. Trimming or reordering that zone is a cheap intervention next to rebuilding the whole page.

The third concerns editorial priority, and here the interpretation has to stay honest. If content meant to settle a specific question forces a long descent before delivering the answer, the correct conclusion is not to celebrate the long journey but to move the answer up. Depth describes the user's effort, and effort is not always a sign of interest.

None of these decisions needs an external benchmark. All of them are made by comparing the page with itself before and after the change.

• Decide the thresholds before implementing them and keep them stable. Moving from three steps to five halfway through a quarter breaks comparison with earlier data.
• Switch off the enhanced measurement scroll if you are going to send your own event at 90 %, or use different event names, so the same movement is not counted twice.
• Register the threshold parameter as an event-scoped custom dimension as soon as you start sending it, and check in DebugView that it arrives with the expected value before signing off the implementation.
• Always analyse by template type and by device. Mixing product pages with long articles produces averages that describe neither.
• Tie each threshold to what sits at that height. The figure only becomes actionable when you know which element falls above and which below the drop-off point.
• Check the drop against a session recording or a heatmap before redesigning. The metric says where something happens, not what.

• Reading depth as a quality grade. A long journey can mean the answer was buried, and a short one that it was found straight away.
• Assuming GA4 measures 25 %, 50 % and 75 % out of the box. By default there is only one threshold, at 90 %, and anyone unaware of that reads gaps where there is simply no measurement.
• Comparing percentages between pages of very different length. 50 % of a short product page and 50 % of a long guide describe neither the same effort nor the same content.
• Sending the threshold parameter without registering it as a custom dimension. The data enters the property but appears broken out in no report.
• Ignoring the effect of the footer and of related-content blocks, which lengthen the document and push the event's firing point further down.