AnGo Scroll Analytics records how far visitors scroll through your posts and pages and shows the result on a “Readability” screen in wp-admin. It answers the question a pageview count cannot: did anyone actually read past the first screen?

The tracking script is loaded only on single posts and pages (is_singular for the post and page types) and measures how far the page was scrolled during a visit. That is depth through the scrollable height of the document, not the share of the article visible on screen: a page that fits on one screen records 100%.

A visit is registered as soon as the page loads — a visitor who scrolls nowhere still gets a row, with 0%. After that, data is sent to the server only when reading progress actually advances (checked every 5 seconds), and always when the visitor leaves the page or switches tabs (via navigator.sendBeacon, or fetch with keepalive where it is unavailable). A failed send is retried at the next check.

One visit is one row in the table, updated as the reader gets further down. A new tab or a new session is a new visit.

What the dashboard shows

The period, chosen by hand (the last 30 days by default), with an “Apply” button and grouping by day or by month.
A summary for the selected period: number of visits, average scroll %, median.
Percentiles 5/10/25/50/75/90/100, phrased as “X% of visitors scrolled at least to Y% of the article”.
An “Exclude load-and-die visits” checkbox (on by default): visits whose only beacon fired at page load — on a live site mostly bots and link previews — are left out of the statistics, and the Visits card shows how many were excluded. Uncheck it to see the raw population.
A trend chart: average scroll as a line, visits as bars.
A table per item: title, type (post/page), visits, average scroll, median, 90th percentile, sorted by visit count.

Performance at scale

The plugin computes the statistics on the fly with database queries. At very large volumes (hundreds of thousands of visits) caching (transients) or cron-based aggregation is worth adding. A typical blog does not need it.

Rate limiting and the database

Without a persistent object cache, each beacon writes the throttle counter to the options table, so the limit costs two queries per beacon. That is cheap at the scale this plugin targets — it is a spam brake, not a firewall.