Private because there is nothing to keep.
Tidemark is designed so that individual visitors can’t be followed, profiled or reconstructed. This is how.
| Topic | What Tidemark does |
|---|---|
| Cookies | None. The tracking script and its endpoint set no cookies and use no local storage on your visitors’ devices. |
| IP address | Used in memory to derive a visitor id and, optionally, a country. Never written to the database. |
| User agent | Used in memory to derive a visitor id and browser and device type. The raw string is never stored. |
| Visitor id | A salted hash of site, IP and user agent. The salt changes every day, so a visitor cannot be followed from one day to the next. |
| What is stored | Aggregate-friendly visit rows: pages, referrer, UTM values, country, browser, operating system, device type and any custom events you define. |
| Personal data sent by accident | Email addresses, UUIDs, tokens and long numbers in page addresses, referrers, campaign values and event names or properties are replaced with a placeholder such as [email] before they are stored. Only a daily count per kind of match is kept, never the values. On Tidemark Cloud this is always on; if you self-host it is on by default and a site can switch it off. |
| Query strings | Page addresses are stored without their query string. A site owner can allow-list parameters to keep; names that look like they carry a secret or personal data, such as email or token, are refused. |
| Referrers | Stored as the referring address, or only its domain if the owner chooses to keep just the domain. |
| Location | Country, region and city by default. An owner can keep only the region and country, or only the country, for visits recorded from then on. |
| Global Privacy Control and Do Not Track | Each site can choose to respect either signal: visitors who send it are not counted at all. |
| Small groups | A site can set a minimum so that public dashboards and shared links leave out rows with fewer visitors than that, and a filter cannot narrow a public view below it. People who belong to the site see everything. |
| Bots and spam | Crawlers, headless browsers, cloud and hosting provider addresses, referrer spam and floods from one visitor are left out of the numbers. The request is judged in memory; only a daily count of what was filtered, by reason, is stored, never an address or a user agent. |
| Where | On Tidemark Cloud, in our database on servers we run. If you self-host, in your own database on your own server: nothing is sent to us or to any third party except an optional update check that asks GitHub for the latest version number and sends no site or visitor data. |
How a visit is counted
When a page loads, a small script sends the page, referrer and screen width to Tidemark. The server hashes the site, IP address and user agent with a secret and the current UTC date, keeps the first 32 characters of that hash, and discards the inputs. Hits from the same hash within 30 minutes of inactivity extend one visit.
Because the date is part of the key, the same person gets a different id tomorrow. Tidemark can tell you how many people visited today. It cannot tell you that one of them also visited last Tuesday.
What we won’t claim
We don’t say Tidemark is “GDPR compliant”, and we make no legal promises on your behalf. Compliance depends on how you use it, where you operate and what else your site does. Tidemark removes the need for visitor-level data, which makes your obligations smaller and simpler. Ask a qualified adviser about the rest.
How we handle your personal data, as a Tidemark Cloud customer, is in the privacy notice.