Visitor statistics without a cookie banner
Most analytics need a consent banner because most analytics store something on the visitor's device: a cookie, an entry in local storage, an identifier that survives until tomorrow. That storage is what European law regulates most directly — and what makes a banner necessary before anything happens at all.
This counter stores nothing on the device. Not a cookie, not local storage, nothing. That much is checkable: the browser script contains no reference to document.cookie, localStorage, sessionStorage or IndexedDB, and the counter image sends no Set-Cookie header.
How a visitor is recognised anyway
Distinguishing a returning visitor from a new one within the same day usually needs an identifier. Here it works differently: the IP address goes into a hash together with a secret salt and the current date, and only that hash is stored. The IP itself is never written to the statistics.
Two consequences follow, and the second is the interesting one.
The hash cannot be turned back into an address — that is the point. But because the salt changes every day and is deleted after a short retention, the same visitor on Monday and on Tuesday produces two hashes that cannot be linked to each other. Not by us either. There is no way to build a profile across days out of this data, because the material for it does not exist.
That is a limitation, and it is deliberate. "Returning visitors over thirty days" is a number this service cannot show and will not be able to show. It is the same design decision that makes the counting work without asking anyone for permission.
What that means for a site owner
The legal basis for the counting itself is legitimate interest in measuring reach — Article 6(1)(f) GDPR — not consent. With the standard embed code there is no device access to consent to either. A site that embeds nothing else can run this counter without a banner.
One switch changes that. A site owner who adds data-screen="1" to the script tag has the script read the screen resolution, the width of the browser window and the pixel ratio from the visitor's device. That is an access to the device, and depending on the law that applies to the site it may need consent. Without the switch it stays off.
Two honest qualifications. First: a page that carries advertising, or embedded video, or anything else that does store on the device, needs a banner for those regardless, and the counter's position changes nothing about it. Second: this describes how the software works and what data it holds. It is not legal advice, and the responsibility for a site's own disclosures stays with whoever runs it. The full detail, including the retention periods, is in the privacy policy and on the page about embedding that every counter links to.
What we can say precisely is what the statistics contain: daily totals, countries and cities at aggregate level, pages, referrers, browsers and devices, hours of the day. No addresses, no identifiers, no cross-day linkage. That list is short on purpose.
Update, 11 September 2026: From 27 August 2026 the script read the screen resolution, the width of the browser window and the pixel ratio again, on every site that embedded it. Since 11 September 2026 it does so only where the site owner switches it on with data-screen="1". Without that attribute the current script reads none of the three, and the server no longer stores them from older copies either.