AnGo Scroll Analytics

Yes. Every arrival is a row, including the ones with 0% scroll: the percentiles describe all arrivals, not only those who read to the end. That is a deliberate decision, not lost data. The dashboard does distinguish two kinds of zero-scroll visits. A visit that sent nothing after the initial page-load beacon (max_scroll 0 and time on page 0) is “load-and-die” — on a live site those are usually bots, crawlers and link previews, not people. They are excluded from the statistics by default (the Visits card shows how many were left out), while a person who loaded the page and stayed without…

Yes — it has to be, because visitors are not logged in. POST /wp-json/ango/v1/depth is limited to 60 requests per minute per IP; the limit is changed through the ango_rate_limit filter, and a value below 1 disables the check. The IP itself is not stored, only a hash of it, for the duration of the window. Behind a proxy (Cloudflare and similar) REMOTE_ADDR is the proxy address, so the limit is shared by all visitors — raise it in that setup.

This plugin measures depth through the scrollable height of the page, not the share of the article that was on screen: a short page that fits on one screen records 100%. And it counts visits, not unique readers — a new tab or a new session is a new visit.

Timestamps in the table (created_at) are stored in UTC, while the dashboard computes day boundaries in the site timezone. Keep that in mind when writing manual SQL against {prefix}_ango_visits.

They are tracked by default: the script loads on the single page of every public post type, so a WooCommerce product, a forum thread or a knowledge-base entry all get measured the moment they exist. Media attachments are the one exception — they are public but are media-library artifacts, not pages a reader scrolls. If a plugin registers a public type you do not want counted (a page-builder’s template library, a popup type), remove it with the ango_trackable_post_types filter: add_filter( 'ango_trackable_post_types', function ( $types ) { unset( $types['my_popup'] ); return $types; } );

No. The chart is drawn by Chart.js 4.5.1, bundled with the plugin (assets/vendor/chart.umd.min.js, MIT license), so wp-admin makes no external request and the chart works offline and behind a filtering proxy.

Chart.js 4.5.1 (MIT) ships here as the minified UMD build that upstream publishes — assets/vendor/chart.umd.min.js, licence banner intact. Upstream has no unminified UMD to use instead: dist/chart.umd.js and dist/chart.umd.min.js in its package are both minified. The readable code is published, just in another build: the unminified ESM bundle is dist/chart.js (https://unpkg.com/chart.js@4.5.1/dist/chart.js), and the sources it is built from are at https://github.com/chartjs/Chart.js/tree/v4.5.1/src.

They are deliberately neutral: the tracking script is assets/js/scroll-depth.js and the public endpoint is /wp-json/ango/v1/depth, with no tracker/track in either. Those words are a common target for filter lists, and a blocked script or beacon loses data silently. Neither EasyList/EasyPrivacy nor the uBlock Origin and AdGuard filters matched these URLs (checked 2026-09-16 under the plugin’s previous name; the endpoint paths did not change in the rename), but the lists update daily — so do not rename them back “for clarity”.

Deleting the plugin removes everything it stored: the {prefix}_ango_visits table, the ango_db_version option and the throttle transients. Deactivating does not — the data survives a deactivate and reactivate cycle, so an upgrade or a temporary switch-off costs nothing. Clicking Delete on the Plugins screen shows a confirmation naming the statistics that will be lost. If you need the numbers after the plugin is gone, export them before deleting, or hold the cleanup back from a must-use plugin with add_filter( ‘ango_remove_data_on_uninstall’, ‘__return_false’ ).