Every analytics tool has to answer one question before it can show you a single chart: is this the same person as before?
The classic answer is a cookie. Drop an ID in the browser, read it back on the next visit, done. It works, and it's also why half the web greets you with a consent banner. Once you store an identifier on someone's device, ePrivacy rules kick in, and you need permission first.
Pulsora doesn't store anything in the browser. No cookies, no localStorage, no sessionStorage, no IndexedDB. So how does it count visitors? With a hash it builds on the server, from data every request already carries.
The visitor hash
When a pageview reaches Pulsora, a queue worker computes this:
visitor_hash = SHA-256(ip_address + user_agent + site_id + site_salt)
Each input has one job.
- The IP address tells visitors apart. It's used for the hash and for the country lookup, and then it's gone. It's never written to the pageview.
- The user agent tells apart people on the same network, like two colleagues in the same office.
- The site ID makes the hash different on every site. The same person visiting two sites that use Pulsora gets two unrelated hashes, so nobody can follow them from one to the other.
- The site salt is a random 64-character secret per site. Replace it, and every earlier hash stops matching.
The stored pageview keeps the hash, the page, the referrer, the country, and the browser, OS and device type read from the user agent. Not the IP address, not the user agent itself.
The salt is what makes it private
A hash of an IP address and a user agent on its own isn't anonymous. Anyone with a list of IPs could compute the same hash and check for a match. The salt stops that, and rotating it limits how long any hash means anything.
By default, Pulsora replaces each site's salt every 24 hours. An hourly job picks up every salt older than its site's rotation period and swaps it for a new random one. After that, the old hash can't be recomputed and can't be linked to the new one. Not by you, and not by us.
You can pick the period per site: 24 hours, 3 days, 7 days, 14 days or 30 days. You can also rotate it by hand at any time from the site's settings.
What it gets wrong, on purpose
A cookie follows one browser. A hash follows a combination of network and browser. That trade has edges, and it's better to know them than to discover them in a report.
- Two people, one network, same browser count as one visitor. Think of two identical laptops on the same office Wi-Fi.
- One person, two networks counts as two. Reading on Wi-Fi at home and then on mobile data on the train is two visitors.
- After a rotation, everyone is new. With the 24-hour default, someone who visits on Monday and again on Tuesday counts as two unique visitors over the week.
None of these are bugs. They're the cost of not storing an ID on the visitor's device. For the questions most sites ask, like which pages work, where traffic comes from and which campaigns convert, the numbers hold up. Pageviews, sessions, sources and revenue don't depend on recognizing someone across days at all.
Picking a rotation period
This is the one setting worth thinking about.
A longer period recognizes returning visitors for longer. If you care about weekly unique visitors, 7 days gives you a more accurate number than 24 hours. A shorter period means each hash can be linked to fewer visits, which is better for your visitors' privacy.
My advice: pick the shortest period that still answers your questions. For most marketing sites that's the default. If you run a product where people come back every few days and you want to see that, go for 3 or 7 days. Changing the period rotates the salt right away, so you can try it without much ceremony.
Why not fingerprinting?
Browser fingerprinting reads canvas rendering, installed fonts and hardware details to build an ID that survives clearing cookies. It's built to follow a person around, which is exactly what we don't want.
The visitor hash uses only what every HTTP request already sends, changes on every salt rotation, and is different on every site. It's built to be forgotten.
Sessions
Sessions work the same way, without storage. The tracker creates a random session ID for each page load and keeps it in a JavaScript variable. Client-side navigations in a single-page app keep it. A reload or a new tab starts a new one. Nothing about it survives closing the page.
Do you still need a consent banner?
On Pulsora's side, there's nothing for ePrivacy consent rules to cover, because the tracker stores nothing on the visitor's device. GDPR still applies to what the server processes: the IP address is personal data while it's used, and the hash is pseudonymous. Most site owners rely on legitimate interest for aggregate analytics like this.
Whether your site needs a banner depends on everything else running on it, and on where you are. We can't decide that for you, and this isn't legal advice. The privacy and compliance docs list exactly what Pulsora keeps and for how long, which is a good start for your own privacy policy.