Who It Is for

This analytics system fits site owners who need traffic counts, referrer data, and device-class signals — and who do not need to track individual visitors or session paths.

The site owner who reads the board once a week

The person this system was built for checks the dashboard on a regular schedule — maybe Monday morning, maybe after publishing a new piece — and reads three or four numbers: total page views for the period, top pages, top referrers, and device breakdown. From those four things, they understand whether the site is growing, which content is connecting, and where the audience is coming from. They do not need a 40-column report. They need a clean answer to "what happened?"

That use case covers a wide range of sites. A blogger who wants to know which posts are getting read. A documentation maintainer who wants to know which pages are most used and which might need updating. A small business owner who wants to know whether the contact page and the services page are getting traffic. A developer who runs a tools site and wants to know if the recent feature update drove visits. All of these are answered by the board.

The common thread is that the question is about aggregate traffic, not about individual visitors. None of these operators need to know the sequence of pages one person viewed. They need to know the total count across all visits, and they need that count to be accurate and easy to read.

Content publishers and informational sites

Sites where content is the output are a natural fit. When the job of the site is to publish articles, documentation, tutorials, guides, or reference material, the primary question analytics should answer is: is this content reaching people, and is it reaching more people over time? Page views by path, combined with the daily trend, answer that question directly.

Content publishers often have a secondary question about traffic sources: did a specific article get picked up by a newsletter, a link aggregator, or a social platform? The referrer section of the board answers that question. A spike in referrals from a specific domain on the day after publication confirms the pickup. The magnitude of the spike tells you roughly how much traffic the mention generated.

Content sites also tend to have audiences that span a wide range of devices. The resolution class breakdown is useful here for understanding whether the reading experience needs to be optimized for phone screens. If 60% of page views arrive from phone-class screens, that is a strong signal about where to invest in layout and typography improvements.

Operators who value privacy compliance simplicity

Running a site that collects analytics under GDPR, PECR, or similar frameworks involves legal obligations. If the analytics collect personal data — and session-based analytics generally do — those obligations include disclosures, consent mechanisms, data subject rights, and breach notification procedures. Each of these takes time and carries risk if handled incorrectly.

A stateless analytics system that does not collect personal data simplifies that picture significantly. The data the system collects — aggregate counts by page, date, referrer, and resolution class — does not identify individuals and is not personal data under the frameworks that most operators encounter. The privacy section of this help center documents the technical basis for that position in more detail.

Operators who run sites in sensitive topic areas — health information, legal resources, mental health support, political commentary — often find that the reduced data collection is important beyond mere compliance. Their visitors may be especially sensitive to the idea that their reading behavior is being recorded. A system that does not record it is a better fit regardless of what the law requires.

Multiple sites under one account

If you run more than one site, the dashboard supports multiple site records under a single account. Each site has its own board, its own date range selector, and its own set of counts. The sites do not share data, and traffic on one site does not affect the counts on another.

This is useful for agencies, developers, and publishers who maintain several properties. Each client site gets a clean, independent board. The operator can switch between sites without logging out and back in. The counts for each site are exactly the counts recorded for that site key, and there is no cross-contamination.

The access system distinguishes between site keys and access keys, which means you can give a client view access to their own site without giving them access to other sites on the account. The access key article covers how this works in practice.

Troubleshooting

If you are not sure whether your site's analytics needs match what the board provides, the clearest test is to list the three questions you most want analytics to answer. If those questions are about counts — how many, from where, on what device, over what period — the board will answer them. If those questions are about sequences or individuals — who converted, what path did they take, how many came back — the board will not answer them and a different approach is needed.

If you run a site that currently collects no analytics at all and you are deciding whether to add any, starting with aggregate counts is the lowest-friction option. There is no consent banner required for data collection that does not constitute personal data collection. You can add the script, read the board for a month, and then decide whether you need more.

If you have been using a session-based analytics tool and are considering switching, a useful transition approach is to run both systems in parallel for four to six weeks. Compare the page-view figures across both tools. When they align closely, you can be confident that the stateless system is capturing what the previous tool captured at the page-view level, even though it will not replicate session or unique-visitor figures.