How Varde handles visitor data
This page describes what the code behind Varde actually does with each visit, step by step, including the limits of the approach.
1. The browser sends a small event
The Varde script sets no cookies, uses no local storage and does no fingerprinting. For each page view it sends one request with: your site ID, the event name, the page URL, the referring URL, the screen width, and any event properties you add yourself.
The only thing the script ever stores in a browser is an opt-out flag, and only when someone opens your site with ?varde_ignore=true to exclude their own visits.
2. The server sees the IP address, briefly
Like every web request, the event reaches our server with the visitor's IP address and the browser's user agent string. The request enters Vercel's network at the edge location closest to the visitor, and the code that handles it runs in Stockholm or Frankfurt.
The handler first drops bots and automated browsers. It then uses the IP address and user agent in memory for four things only:
- making the daily visitor hash (step 3),
- reading the visitor's country, which Vercel derives from the IP and passes as a two-letter code,
- reading the device type, browser and operating system names from the user agent,
- a short rate limit, which is keyed by the hash, not the IP.
Neither the IP address nor the user agent string is written to the database or to our logs. When the request is done, they are gone from Varde.
3. The daily visitor hash
To count unique visitors without cookies, Varde computes:
visitor_hash = first 64 bits of SHA-256( daily_salt | site_id | ip_address | user_agent )- daily_salt is 32 random bytes, created by the database the first time it is needed on a given day (UTC). It is never sent to browsers or customers.
- site_id is included, so the same person gets a different hash on every website. Visits can't be linked across sites.
- Only the 64-bit result is stored with the event. That is enough to count unique visitors per day.
4. The salt is deleted every day
A scheduled database job runs at 00:05 UTC every day and deletes every salt older than the current UTC day. New visits from that moment use the new day's salt.
Without the old salt, an old hash can't be recomputed from an IP address, even by us, so the same visitor can't be followed from one day to the next. This is also why Varde counts unique visitors per day: a visitor who returns tomorrow is counted as new.
What this does and doesn't protect against
We prefer to be precise about the limits:
- During the current day, the salt exists in our database. Someone with full access to the database could, in principle, test guessed IP addresses and user agents against that day's hashes. The salt table has no access rules for signed-in users, so only our server code can read it.
- Our database provider keeps automatic backups. A backup taken during a day contains that day's salt until the backup expires.
- Vercel, as our hosting provider, necessarily processes the IP address to deliver the request. Vercel's data processing terms apply to that.
- The hash is pseudonymous, not anonymous, while the salt exists. That is why we treat it as personal data.
What is stored for each event
| Stored | Not stored |
|---|---|
| Time and event name | IP address |
Hostname and path, with the query string removed (UTM tags and ref/source are kept as campaign fields) | Full user agent string |
| Referring site and path | Query strings and URL fragments (fragments are kept only if you turn on hash routing) |
| Country code, device type, browser and OS name | Screen width (used to pick the device type, then dropped) |
| Daily visitor hash (64 bits) | Cookies or any ID that lasts longer than a day |
| Event properties you send |
Don't put names, email addresses or other personal data in URLs or event properties. Varde stores what you send.
Access and storage
- The database is in Stockholm, Sweden (Supabase on AWS eu-north-1).
- Every table uses row-level security: a signed-in user can only read the sites they own or were invited to. Invited members are either admins or read-only viewers.
- Server credentials stay on the server and are never sent to browsers.
- Stats API keys are shown once. Only a SHA-256 hash of each key is stored.
- All traffic uses HTTPS.
AI reports and Ask your data
AI reports and answers in Ask your data are written by Anthropic's Claude. It receives aggregated daily numbers only (totals, top pages, sources, countries, devices, campaigns and goal counts), your site's domain, and for Ask your data, the question you typed. Individual events and visitor hashes are never sent.
Who processes data
| Provider | What for | Where |
|---|---|---|
| Supabase | Database and user sign-in. Stores all analytics data and account data. | AWS eu-north-1, Stockholm, Sweden |
| Vercel | Hosting, content delivery and the collection endpoint that hashes visits. | App functions run in Stockholm (arn1). The collection endpoint runs in Stockholm (arn1) or Frankfurt (fra1). Requests enter Vercel’s global edge network at the location closest to the visitor. |
| Resend | Sending emails: sign-in links, team invites and scheduled reports. | EU region (eu-west-1, Ireland). Open and click tracking is turned off. |
| Anthropic | Writing AI reports and answering Ask your data questions from aggregated numbers. | USA |
See also the privacy page and the privacy docs.