From Cookie Analytics

Cookie-based analytics tools build their reports around persistent user identifiers. StatelessID counts page loads without any identifier. The numbers are different by design, and understanding why makes it easier to read what the dashboard is actually telling you.

What cookie analytics measures versus what StatelessID measures

Cookie-based analytics assigns a persistent identifier — typically stored in a browser cookie — to each browser the first time it visits. On the second, third, and hundredth visit, the system reads that identifier and recognizes the same browser again. This is how cookie-based tools produce "unique visitor" counts: they count distinct identifiers, not distinct people, and use returning-identifier rates to estimate new-versus-returning breakdowns, session counts, and journey paths.

StatelessID does not assign any identifier. There is no cookie, no localStorage entry, no fingerprint, nothing that persists between page loads. Each page load produces one beacon. The beacon carries the path, the referrer host, a screen-size class, and a speed band. Nothing in the beacon connects one load to any previous load by the same person or the same browser.

The result is a different kind of number. StatelessID counts page loads, not unique visitors. One person who visits your homepage five times in a day contributes five to the page view count, the same as five different people visiting once each. There is no mechanism to distinguish the two scenarios, because that distinction requires linking page loads through a persistent identifier — and StatelessID does not have one.

Why your totals will look different

If you install StatelessID alongside a cookie-based tool and compare their numbers, the counts will differ. StatelessID's page view count will match or exceed the cookie tool's page view count for the same period, because both are measuring page loads and StatelessID includes loads from browsers that blocked the cookie tool's script. StatelessID's count will have no unique visitor number to compare against.

If your cookie-based tool reported 1,000 unique visitors and 3,500 page views in a given month, StatelessID may show something in the range of 3,000–4,000 page loads for the same month, depending on how many visits the cookie tool missed due to blocking. The StatelessID number is page loads; the cookie tool's unique visitor count does not have an equivalent in StatelessID at all.

Do not interpret the difference as an error in either tool. They are measuring different things with different methodologies. The question to ask is which number answers the question you actually care about. If you care about how many times your content was loaded, StatelessID's page load count is direct. If you need to count distinct people who visited, you need a tool that uses identity.

Metrics that do not exist here

Several metrics that cookie-based analytics reports as standard do not exist in StatelessID because they require linking page loads through a persistent identifier. Bounce rate — the share of sessions where only one page was loaded — requires knowing which page loads were part of the same session. Session duration requires timestamps on both the first and last page of a session. Pages per session requires counting how many page loads shared a session identifier.

None of these metrics are present in the StatelessID dashboard, and they cannot be derived from the data it collects, because the data does not contain sessions or identifiers. This is not a missing feature; it is a consequence of the design choice not to track people. If your use of the dashboard has been heavily based on session depth, bounce rate, or user journey analysis, those workflows require a different tool.

What you gain instead is visit data that is not subject to cookie consent banners, not reduced by visitors who decline consent, and not dependent on cookie persistence across browser updates. The count that appears in the dashboard represents actual page loads under actual conditions, including visits from browsers and devices that reject or clear cookies.

Reading the dashboard on its own terms

The dashboard is built around answers to the question: how many times was each page loaded, from where, on what kind of screen, at what speed, in what period? The Pages section shows load counts per path. The Sources section shows where traffic came from — which external hostnames referred visitors. The Devices section shows the screen-size class distribution. The Speed section shows the load-band distribution.

These dimensions answer real questions. Which pages are most visited? Which external sites send the most traffic? Is the audience predominantly on narrow screens or wide ones? Did a performance change shift the share of fast versus slow loads? Those questions are answerable without user identifiers. The transition from cookie-based thinking is easier when you start with a question the dashboard can answer rather than looking for a number the dashboard does not produce.

Troubleshooting

If you are comparing StatelessID counts to a previous cookie tool and the numbers look dramatically different, check the comparison period. Cookie tools often report session counts or unique visitor counts on their default dashboard, not page view counts. Make sure you are comparing StatelessID's page load total to the cookie tool's page view total, not its session or user total. Page view totals from both tools should be closer to each other than session or user totals would be to page view totals.

If StatelessID shows lower counts than your cookie tool did for the same period, consider how the cookie tool counted. Some cookie tools count page views including those from visitors who later declined consent and had their data deleted — or they count pre-consent page views before the consent banner renders. StatelessID counts real page loads. If the cookie tool's count included data that was later altered by consent withdrawals, the StatelessID count may be genuinely lower on a fair comparison.

If you are running both tools simultaneously and want to compare them for a period, install StatelessID first, let it collect data for at least two weeks to smooth out variation, and then compare the page view totals for overlapping periods. Differences in the first few days of overlap are common due to caching, CDN propagation of the new script tag, and audience sampling variation.