[WordPress] 外掛分享: AnGo Scroll Analytics

首頁 › 外掛目錄 › AnGo Scroll Analytics
10+
安裝啟用
—
尚無評分
剛更新
最後更新
—
問題解決
WordPress 6.8+ PHP 7.4+ v1.12.0 上架:2026-09-19

內容簡介

AnGo Scroll Analytics 外掛可記錄訪客在您的文章和頁面上滾動的深度,並在 wp-admin 的「可讀性」畫面中顯示結果。它能回答單純的頁面瀏覽數無法解答的問題:是否有訪客實際閱讀超過第一屏?

【主要功能】
• 記錄訪客滾動深度,提供詳細數據
• 支援多種內容類型,包括 WooCommerce 產品
• 提供可視化趨勢圖表,顯示滾動平均值
• 可選擇排除僅載入的訪問數據
• 顯示各文章的訪問數與滾動百分比
• 提供可讀性簡報小工具,快速查看數據

外掛標籤

開發者團隊

⬇ 下載最新版 (v1.12.0) 或搜尋安裝

① 下載 ZIP → 後台「外掛 › 安裝外掛 › 上傳外掛」
② 後台搜尋「AnGo Scroll Analytics」→ 直接安裝(推薦)
📦 歷史版本下載

原文外掛簡介

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 on the single page of every public post type — posts, pages, WooCommerce products, custom post types from any plugin (media attachments are left out) — 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”. A “Percentile mode” switch (Reach / Classical) feeds both this list and the table columns from either the reach computation — how far readers actually got — or the classical one: the standard PERCENTILE.INC percentiles, “X% of visitors reached no further than Y%”.
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 (the content type’s own name — Post, Page, Product), visits, average scroll, and a “Percentiles” group — seven sortable columns (5/10/25/50/75/90/100) showing the scroll depth each share of that article’s visitors reached. Every column header is clickable and sorts the table (first click ascending, second descending; numbers as numbers, titles alphabetically), so “most visited” or “worst-median depth” is one click away — the 50% column is the median. A “Search articles” box above the table narrows the rows as you type, matching titles case-insensitively; it composes with the active sort and survives an Apply.
A “Readability brief” widget on the admin Dashboard home screen: the same numbers for the last 7 days at a glance, with a link to the full report. It is a standard dashboard widget — visible to administrators, and movable, collapsible or hideable through Screen Options like every other box there.

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.

延伸相關外掛

文章
Filter
Mastodon