What Pulse collects, and what that proves.
Pulse is built to collect less. This page lists what the script sends, what the server keeps, and how the visitor identifier works, all read from Pulse's code on 10/29/2026. It also says where the code stops: a design that collects little is not a legal opinion, and this site makes no compliance claim.
The script
What p.js does in a visitor's browser.
| Cookies | None. The script never reads or writes a cookie, and its requests are sent with credentials omitted. |
|---|---|
| Browser storage | None. It uses neither local storage nor session storage. |
| What it sends on a pageview | The page address (with any query string), the page title, the referrer, the screen size, and the browser language. |
| What it sends on an event | The page address, the event's name, and the properties your own code or data attributes supply. |
| What it sends on its own | Outbound link, file download, form submission, and 404 events, and, when the visitor leaves, Core Web Vitals numbers. Heatmap clicks and scroll depth go only for a site that turned heatmaps on. A form event carries the form's id, name, and action, never a typed value. |
| When it stays silent | In a browser that reports it is under automation, and, on a site that sets the attribute, when the visitor has Do Not Track on. |
What Pulse stores
For each pageview Pulse stores the full address and its path, the page title, the referrer and its domain, the screen size, the language, the campaign tags from the address, the time, a visitor hash, a session hash, and what it works out from the connection and the browser: browser and version, operating system and version, device type, and country, region, and city.
It does not store the visitor's IP address (no table has a column for one), and it does not store the user agent string, only what it parses from it.
| Stored | Address, path, title, referrer, screen, language, campaign tags, time, visitor hash, session hash, browser, operating system, device type, country, region, city. |
|---|---|
| Not stored | IP address, user agent string, any cookie or storage identifier, typed form values, element text. |
| Stored only when a site opts in | Heatmap click and scroll positions as percentages, with timestamps shifted by up to two seconds; a hashed user id from pulse.identify. |
The visitor hash
How Pulse tells two visitors apart without remembering either.
Combine
Pulse joins the site's id, the connection's IP address, the browser's user agent string, and a salt that changes at midnight UTC.
Hash
It runs SHA-256 over the result and keeps the first 16 hex characters. The address and user agent are used for this and for the location lookup, then dropped.
Rotate
Tomorrow's salt is different, so tomorrow's hash for the same person is unrelated. The session hash does the same on an hourly salt.
Look back once
To call a visitor returning, Pulse recomputes the hash they would have had yesterday and checks whether it was seen. That is a one-day lookback; nothing longer is kept.
The salt starts from a secret. Pulse refuses to start in production while that secret is still the default, because with a public salt the hash could be guessed address by address.
Where the code stops
Things this design does not do, and a few it cannot see.
- The full page address is stored, query string included. If a site puts a name, an email address, or a token in its URLs, Pulse keeps it. Keep personal data out of the addresses of tracked pages.
- Pulse reads the IP address to make the hash and to look up the country, region, and city. It is not written to Pulse's database. Servers and load balancers in front of Pulse keep their own access logs, and this site cannot speak for them.
- pulse.identify() is an opt-in call for signed-in areas. It stores a hashed user id that does not rotate, so retention can be measured over weeks. The hash is keyed to the site and to a secret, so the same person on two sites gets two unrelated values. Use it only where your users have agreed.
- Custom event properties are whatever your code sends. Pulse does not inspect them.
- A public dashboard shows a site's numbers to anyone with its link.
- Do Not Track is off unless a site sets the attribute.
- Whether a notice or consent is needed, and whether a hashed identifier counts as personal data, depends on the law and the facts. That is a question for a lawyer, and this page is not legal advice.
Controls a site has
- Allowed domains: a hit counts only when its page address is on the site's domain, an allowed domain, or a subdomain of either.
- Excluded addresses: a list of IP addresses or ranges whose visits are not counted, such as an office.
- data-pulse-auto-events set to off, or to a list, picks which automatic events run; data-pulse-no-track on an element keeps clicks and form submissions inside it out.
- data-do-not-track set to true makes the script honor Do Not Track.
- Heatmaps are off for every site until switched on.
- Known bots are dropped by their user agent on the server, and a request with no user agent counts as a bot.
Third-party data
IP geolocation by DB-IP (db-ip.com). The IP to City Lite database is licensed under Creative Commons Attribution 4.0 and is downloaded into Pulse's image when it is built. The lookup runs inside Pulse, and no visitor address is sent to DB-IP or anyone else.
Questions about this tool?
Write to Renkara Media Group and a person will answer.