No Unique Visitors

StatelessID does not count unique visitors. There is no cookie, fingerprint, or cross-visit join that could distinguish one person from another. The board shows visits — page loads — not people.

Why unique visitors require identification

Counting a person as unique on a second visit requires recognizing them. That recognition requires something persistent: a cookie carrying an identifier, a fingerprint computed from browser properties, a logged-in user ID, or an IP address treated as a proxy for a person. None of those mechanisms exist in StatelessID.

Without a recognition step, "unique" has no computable meaning. If the same person loads your homepage three times and three different people each load it once, both scenarios produce a total of three page loads. The system stores three in both cases, because three is all it knows.

What the visit count shows instead

The Visits number is a count of beacon events — one per page load. It tells you how many times pages were loaded during the selected period. Page load volume is the signal. If you run a campaign and the count rises, more pages are being loaded. That is a useful signal that does not require knowing how many distinct people produced those loads.

Page load counts are honest. They do not require a probabilistic algorithm that may overcount or undercount. A visit happened; the count rose by one. No estimation, no deduplication window, no expiry logic.

Fingerprinting is also absent

Browser fingerprinting combines properties like screen resolution, installed fonts, active plugins, canvas rendering, and WebGL characteristics to produce a probabilistic identifier that works without a cookie. asset.js does not collect any of those inputs. It does not enumerate fonts. It does not render a canvas for measurement. It does not read WebGL strings or plugin arrays.

The screen-size class and load band that asset.js does send are intentionally coarse. Thousands of different devices with different screen models produce the same class value. Thousands of page loads over different connections produce the same speed band. Those fields are designed to be shared by many visitors, not to distinguish one from another.

What this means for your privacy policy

Your privacy policy does not need to disclose a unique visitor identifier placed by StatelessID, because none exists. The beacon fires, a counter rises, and no link to the person persists. StatelessID does not give you a visitor count you can cite, which may seem like a limitation — and it is, by design.

Your own legal adviser can tell you what disclosures your jurisdiction requires for your site as a whole. StatelessID's specific contribution is: page load counts without personal identifiers. That is what needs to be disclosed, or not, depending on your legal context.

Troubleshooting

If you need a unique visitor count and want to add one through another mechanism, that is a separate tool and a separate implementation decision. StatelessID is not designed to answer that question and its architecture does not support bolting on that capability without introducing the storage model it was built to avoid.

If a third-party audit or report claims StatelessID tracks unique visitors, ask for the evidence. It may be testing against a cached or different version of the script, or it may be inferring from the presence of a script tag without analyzing what the script actually sends. Load asset.js in a clean browser session and inspect the beacon payload in the Network panel. There is no visitor identifier field.