What PageHum counts
PageHum keeps counts and histograms per site per day. It never keeps a raw event stream, a visitor's path through the site, an IP address, or an identifier.
Pageviews, pages, sources, and devices
- Pageviews count each page load and each client-side route change.
- Pages are cleaned paths: lowercased, without query strings or fragments, with numeric and long hexadecimal segments folded to
:id. Each day keeps up to 40 distinct pages by name; pages first seen after that fold into “other”. - Sources are the
utm_sourceparameter if present, otherwise the referring site’s host withoutwww.. Your own site and sign-in providers count as direct. Each day keeps up to 20 distinct sources by name. - Devices are desktop, mobile, or tablet, read from the browser’s user agent and never stored with anything else.
Unique visitors and sessions
A browser counts once per range, however many days it comes back, and without any identifier. On a browser’s first visit of a day the snippet sends only the number of whole days since its previous visit day (0 for a first visit). Each day keeps a small tally of those gaps, and a range counts a visit when it is new or its previous visit fell before the range began.
The daily chart shows each day’s visitors; range totals count each browser once. Clearing site data or switching browsers counts as new. Days recorded before unique counting started are counted once per day, and the board says “partly estimated” until they age out.
Sessions are browser-tab sessions: a new tab or window is a new session. The board shows sessions and pages per session.
Load time and Web Vitals
On each page load the snippet reads the browser’s own timing: full load time, time to first byte (TTFB), largest contentful paint (LCP), and cumulative layout shift (CLS). Each lands in a histogram bucket, so the board reports medians and 75th percentiles without keeping individual timings. After a client-side route change there is no new page load, so only layout shift and responsiveness are counted for it.
Responsiveness (INP), interaction to next paint, is how long a tap, click, or key press takes to show a response. When the page is hidden or left, the snippet sends the page’s slowest interaction (past 50, one in 50 is skipped), in five buckets from under 100 ms to over a second. Under 200 ms is good; 500 ms and over is poor. Browsers that don’t support the Event Timing API send none, and the board shows a dash.
By page and device: load, LCP, and INP buckets are also kept for each device class and for up to 20 pages a day; pages first seen after that count under “other”. A page or device needs 20 samples before the board calls it slow.
Engagement and success
A visit is engaged after 15 seconds on the page or scrolling halfway, once per session. Success is whatever you mark: add data-pagehum-success to the button, link, or form that completes a signup or purchase, or call window.pagehum?.track("success") after a confirmed server response. The success rate is successes over visits (pageviews). See the JavaScript reference.
Client errors
Uncaught JavaScript errors and unhandled promise rejections are counted per page and message. Up to 5 per page load are sent, the message is cut to its first line and 80 characters, and query strings and fragments are removed. No stack traces are kept. Each day keeps 8 distinct page-and-message pairs by name; the rest count under “other”. On the board, open an error to see its history and copy an AI prompt to fix it.
Each error is also counted by browser family and major version (“Safari 17”, “Chrome 129”), worked out on our side from the request’s user agent. The user agent itself is not stored.
Failing requests
Calls your pages make to your own host with fetch or XMLHttpRequest are watched for two outcomes: a 5xx status, or no response at all (a network error, CORS failure, or dropped connection). PageHum keeps the method, the cleaned path, the status, and the page that made the call, never the body, headers, or query string. Failures while the page is being left, the tab is hidden, or the browser is offline are not counted. Each failing call is sent once per page load, up to 5 per page; each day keeps 20 by name. Turn it off with data-requests="off" on the script tag.
Rage clicks
Three or more clicks within about a second in one small spot count as a rage click on the page: usually something that looks clickable didn’t respond. Only the page is kept, not the element, its text, or the position. Triple-clicking text to select it, and clicks in form fields, don’t count. Up to 3 per page load are sent; each day keeps 20 pages.
Broken links and 404s
A page that loads with a 404 or 410 status, or whose title says it was not found, counts as a broken hit on its path. So does an image, script, or stylesheet on your own site that fails to load. These are paths real visitors hit; PageHum doesn’t crawl. Up to 8 are sent per page load and 20 paths per day are kept by name.
Each broken hit also notes the page on your site that led there: the page the visitor came from for a missing page, or the page that loads a missing asset. Up to 30 path-and-page pairs a day are kept, so the board can say which link to fix. A hit from another site, a bookmark, or a typed address has no linking page.
Heartbeats
While a page is open, the snippet sends a tiny heartbeat once a minute. It tells the board visitors are arriving right now, which keeps a failed homepage check from being reported as an outage while people are clearly using the site.
Past your monthly pageviews
Each site counts every pageview up to its plan’s monthly allowance. After that, beacons are sampled 1 in 10 and weighted by 10 until the month turns (UTC), so the board keeps working and nothing is cut off, and you are never billed for overage. The board marks sampled days.
| Plan | Pageviews counted in full, per site per month |
|---|---|
| Free | 20,000 |
| Starter | 100,000 |
| Pro | 500,000 |