Technology & law
How VAREEN measures visits
VAREEN measures which content on a website is found and read - and whether AI systems cite it. How much is captured about individual visitors is your decision, per project: from classic, consent-requiring recognition all the way to plain page-view counting with no recognition at all.
This page describes in full what happens in each mode, what is stored and what is not - and how that is to be assessed legally, including the contested points.
This is the English version of a page written for German and EU data protection law. Where German statutes are named, the German wording governs; the translation is provided for convenience. The German original is available at vareen.net/tracking.
Contents
- Why measuring visits matters in the age of AI
- Basic principle
- The four modes compared
- The modes in detail
- What is stored - and what never is
- Legal assessment
- Is this fingerprinting?
- What can be verified from outside
- Objection, DNT and GPC
- Bots and AI crawlers
- Retention and data minimisation
- Wording for your privacy policy
Why measuring visits matters in the age of AI
When AI assistants answer questions directly, something fundamental shifts: the brand gets named without anyone clicking. Reach then happens away from your own website - and conventional statistics show a decline that is in fact a displacement.
That is precisely why measuring visits becomes more important, not less. Four reasons:
- Visibility is not impact. The fact that a model cites your page says nothing about whether anyone arrives because of it. Only by connecting citation and visit do you see which mentions carry weight - and which merely look good.
- Two audiences, one page. Content is read by people and retrieved by AI crawlers. A page no AI crawler ever fetches cannot be cited; a page that is cited but reaches nobody is dead inventory. Both findings only emerge if you measure both kinds of access.
- Provenance gets blurrier. Some traffic from AI assistants arrives without a referrer and lands under “direct”. What remains is behaviour: time on page and scroll depth show whether a page answered the question someone arrived with.
- Content decisions need the cross-check. Which page to expand, merge or delete cannot be derived from citations alone, nor from visits alone - only from the two side by side.
Hence the standard this measurement sets itself: as much explanatory power as necessary, as little personal reference as possible. None of the above requires recognising individuals over weeks. That is why the consent-free modes exist - and why, for many questions, the most restrained of them is already enough.
Basic principle
A small JavaScript file is embedded in the website to be measured. For each page view it reports a few details to the VAREEN server - nothing more. There is no sharing with ad networks, no enrichment by third parties and no cross-site tracking. The data resides solely in your project.
There is also a <noscript> pixel so that visitors with JavaScript blocked, as well as crawlers, remain visible. The pixel follows the same rules as the script: if the mode is set to “Off”, or an objection has been lodged, nothing is stored.
The difference between the modes comes down to a single question: how does the server know that two page views belong together? The legal assessment hangs on exactly that.
The four modes compared
| Standard | Consent-free | Page views only | Off | |
|---|---|---|---|---|
| Recognition | on the device (localStorage) |
server-side, same-day only | none | none |
| Storage on the device | yes | no | no | no |
| Cookie banner required | yes | no | no | no |
| Returning visitors | yes, across days | no (same-day only) | no | — |
| Sessions, paths, entries/exits | yes | yes | no | — |
| Page views, referrer, language, device type | yes | yes | yes | — |
| Time on page, scroll depth | yes | yes | yes | — |
| Bot and AI-crawler capture | yes | yes | yes | — |
| Legal basis | consent (Sec. 25(1) TDDDG) |
Art. 6(1)(f) GDPR |
Art. 6(1)(f) GDPR |
— |
The mode is set per project and takes effect from the next page view. Switching does not change data already collected.
The modes in detail
Standard consent required
On the first visit the script places a random identifier in the browser's localStorage (_som_vid) and a short-lived session identifier in sessionStorage (_som_sid). If the same person returns later, the identifier is read back - which is what produces returning visitors and journeys spanning several days.
Because this stores information on, and reads information from, the terminal equipment, this mode requires consent under Sec. 25(1) TDDDG - regardless of the fact that it is not a cookie in the technical sense. The provision covers any storage on, and any access to information in, terminal equipment. VAREEN ships its own configurable consent banner for this; alternatively it can be wired into an existing consent management platform.
The limits of recognition. localStorage itself never expires. Browsers, however, impose their own limits: Safari deletes script-writable storage after 7 days without interaction with the website under Intelligent Tracking Prevention - which also affects every iOS browser, since they are all WebKit underneath. In private mode recognition ends with the session. In Chrome and Edge it persists indefinitely. “Returning visitors” is therefore a lower bound, not a complete figure - markedly lower for Apple-heavy audiences.
Consent-free (server signature) no banner
The script stores nothing on the device - no cookie, no localStorage, no sessionStorage. Recognition happens on the server instead: from the IP address and the browser identifier - both of which every browser sends with each request anyway - a pseudonymous signature is computed via HMAC-SHA256. The key for that computation changes daily.
The IP address is not stored, and neither is the full browser identifier. Because the key rotates, linking across days is technically impossible: to resolve yesterday's signature you would need yesterday's key and the original IP address - neither of which still exists.
What it costs: “visitors” becomes a same-day figure. Someone who visits on three days counts three times. What remains: sessions (30-minute window), visitor paths, entries and exits, time on page, scroll depth and events. That trade-off is precisely why no consent is required; you cannot have both, by design.
Two levels of precision are available:
- Precise - the full browser identifier feeds into the computation (it is not stored). Reliably separates multiple devices behind the same IP address, such as in offices, universities or behind NAT.
- Data-minimising - only browser, major version and device type feed in. Minor versions, build numbers and device models stay out, so the distinguishing surface is smaller. In exchange, people using the same browser behind the same IP address count as one visitor.
Page views only no banner
The most restrained measurement that still yields data: it only counts which page was requested when - much like a classic server log file analysis. There is no recognition whatsoever: nothing on the device, and no signature on the server either. The IP address is never converted into a pseudonym in the first place.
What remains: page views, the time series, referrer (without parameters), language, device type, time on page and scroll depth per view, plus the complete bot and AI-crawler capture. Time on page and scroll depth still work because they are matched via a random number per page view that connects only the beginning and end of the same view and is meaningless afterwards.
What is lost: visitors, sessions, visitor paths, entries and exits, bounce rate. Those figures then read 0 - they are not estimated. This mode makes sense when all you want to know is which content is found and read, and you would rather avoid any debate about recognition.
Off
Nothing is captured - not even if the script is still embedded in the website. Incoming reports are discarded server-side, not stored.
What is stored - and what never is
In the measuring modes, the following is recorded per page view:
- time and page requested (full URL, including parameters such as
utm_source- they are needed for campaign analysis) - referring page without parameters - search terms, tokens or real names otherwise end up there
- generalised details of browser, operating system and device type, e.g.
Chrome/125 Windows - browser language setting
- time on page and maximum scroll depth
- optional: time spent per type of content element (heading, paragraph, image) - the element type and the duration are recorded, no content
- optional: defined events (a click on a button, say) and clicks on links to other websites (target host only)
Never stored, in any mode:
- the IP address
- the full browser identifier of visitors (for bots it is retained - there it is diagnostically necessary and carries no personal reference)
- names, email addresses or form contents
- mouse coordinates, keystrokes or screen recordings
- parameters of the referring page
There is no profiling within the meaning of Art. 22 GDPR, and no special categories of personal data under Art. 9 GDPR are processed.
Legal assessment
Two levels have to be kept apart, and they frequently are not.
Level 1: Sec. 25 TDDDG - the terminal equipment
Sec. 25(1) TDDDG (Germany's implementation of Art. 5(3) of the ePrivacy Directive) requires consent for storing information on terminal equipment and for accessing information already stored there. What matters is not whether it is a cookie - localStorage, sessionStorage and comparable techniques are covered just the same.
- Standard: stores on and reads from the device → consent required.
- Consent-free and Page views only: store nothing and read nothing → Sec. 25 TDDDG does not apply. Only the GDPR question remains.
The objection marker (see below) does sit in localStorage, but it is strictly necessary under Sec. 25(2) no. 2 TDDDG in order to give effect to the user's express wish - and is therefore itself exempt from consent.
Level 2: GDPR - the processing
Even without access to the terminal equipment, the processing itself still needs a basis. In the consent-free modes it rests on Art. 6(1)(f) GDPR - legitimate interest in the statistical evaluation of website usage. Arguing in favour of the balancing test: no cookies, no stored IP address, no cross-site tracking, no combination with other data sources, no profiling, a short recognition window and an objection available at any time.
The processing must be disclosed transparently in a privacy policy (Art. 13 GDPR); the right to object under Art. 21 GDPR applies and is supported technically.
What is contested - stated plainly. The assessment of the consent-free mode follows the practice of established vendors and is well arguable. It is, however, not uncontested:
- The European Data Protection Board's Guidelines 2/2023 on the technical scope of Art. 5(3) ePrivacy read “gaining access to information stored in terminal equipment” broadly. It is also argued that merely triggering a transmission through client-side code may fall within it.
- The German Data Protection Conference (DSK) has commented critically on “cookieless tracking” where recognition in fact still takes place.
- There is no supreme-court ruling on this precise arrangement - a server-side, daily-rotating signature without access to terminal equipment.
Anyone wanting to avoid that uncertainty entirely should choose “Page views only”: there is no recognition there to argue about.
This is not legal advice. This page describes what the software does technically. Whether the processing can be based on Art. 6(1)(f) GDPR in your specific case is a legal assessment - please have it reviewed by a lawyer before making commitments to clients.
Is this fingerprinting?
A fair question, since the signature is formed from IP address and browser identifier. The honest answer: it is related, but not the same thing. Point by point:
| Classic device fingerprinting | VAREEN, consent-free | |
|---|---|---|
| Characteristics | dozens, actively read out: canvas, WebGL, fonts, audio, screen, time zone, plugins … | two that the browser sends anyway: IP address and browser identifier |
| Access to the device | yes - properties are queried deliberately | no - nothing is read out |
| Stability | months to years | one day (the key rotates) |
| Across websites | yes, that is the point | no, separate per project |
| Purpose | recognising people, often for advertising | counting sessions within a single day |
The decisive difference lies in stability and reach: a fingerprint is designed to recognise the same person for as long as possible and across as many websites as possible. The signature is confined to one day and one project, and cannot be resolved afterwards. Anyone who nonetheless classifies it as fingerprinting-adjacent is not wrong - which is why the “Page views only” mode exists.
What can be verified from outside
Trust should not rest on assurances. Part of what is claimed here can be checked with any browser's developer tools - and part of it cannot, because it happens server-side. That belongs in the open too:
| Claim | Verifiable | How |
|---|---|---|
| No cookies | yes | Application → Cookies stays empty |
No localStorage/sessionStorage | yes | Application → Local Storage stays empty |
| No identifier in the payload | yes | Network tab: request to /api/track, fields vid/sid are empty |
| Source code of the measurement script | yes | /api/track.js is freely retrievable and readable |
| Objection takes effect | yes | after objecting, no further requests are sent |
| IP address is not stored | no | server-side - demonstrable only via contract, documentation or audit |
| Key changes daily | no | likewise server-side |
| Retention period | no | likewise server-side |
A complete payload in consent-free mode looks like this - vid and sid are empty because the server derives the attribution itself and deliberately discards anything the client sends:
{"t":"<site identifier>","u":"https://example.com/page","r":"","vid":"","sid":"","pvid":"mrxdw7jaisyka1","lang":"en-GB"}
Objection, DNT and GPC
Three functions are available on every measured website, ready to be attached to a link or button in your privacy policy:
vareenTracking.optOut()- lodge an objection; nothing further is sentvareenTracking.optIn()- withdraw the objectionvareenTracking.status()- query the current state
The objection applies to this device and this browser. If browser data is cleared, it has to be declared again - storing it across devices would be exactly what this approach sets out to avoid.
Independently of that, the browser signals Do Not Track (DNT) and Global Privacy Control (GPC) are honoured automatically: if either is active, no mode collects anything. IP ranges and domains can additionally be excluded per project - your own office or staging systems, for instance.
Bots and AI crawlers
A core purpose of VAREEN is the question of which AI systems retrieve which content - GPTBot, ClaudeBot, PerplexityBot, Googlebot and others. That capture concerns machines, not people: the bot name, the URL requested and the time are stored. For bots the full identifier is retained, because it is needed to tell them apart and carries no personal reference.
Crawlers usually do not execute JavaScript. For complete capture there are therefore server-side collectors (WordPress, TYPO3, PHP, Cloudflare Worker) that report the request. Bot capture is independent of the mode - except in “Off”.
Retention and data minimisation
The retention period is set per project; data is deleted automatically once it expires. For visit data we recommend 90 days - enough for quarter-on-quarter comparisons while keeping the volume small. Longer periods should be justified.
Data minimisation is built in at several points and cannot be switched off: the browser identifier is generalised before storage, referrers are stripped of parameters, and in consent-free mode the server discards client-supplied identifiers rather than trusting them.
Wording for your privacy policy
For the consent-free modes a ready-made passage is available for you to adopt into your privacy policy - with placeholders for the provider and the retention period, an example of the objection button, and the table of what is externally verifiable. Inside the application you will find it under Project → Tracking, directly beneath the mode selection; it can be read, copied and downloaded there. A note states which section applies to the mode you have selected.
In Standard mode the passage does not apply - there, consent has to be obtained and the processing described in the consent banner.
Questions about the assessment? Write to steven@broschart.net. For the processing on this website itself, see the privacy policy.
How this page came about. The description was written with AI assistance directly from the source code of the measurement components - not from a product description - and editorially reviewed. Where claims can be verified from outside, the section above says how. Where they cannot, that is stated too. Responsible for the content: Steven Broschart Consulting (see imprint).