All notes

Our own researchAct

Two tiers of consent, or analytics that store nothing

A cookie banner does not have to be a wall, and analytics do not have to start by writing an identifier to someone's device. Here is exactly how this site does it, and why.

Published
Topics
GDPR · cookies · analytics · privacy
0bytes written to your device before consent

The banner is not the problem

A typical cookie banner offers a choice between two bad options. Either it blocks the page until you click, or it is designed so that consenting is the only comfortable exit. Both rest on the same assumption: that without consent you can know nothing.

That assumption is false, and that is the whole point of this post. Consent is required to write something to a visitor's device and to recognise them across visits. It is not required to count how many times a page was opened.

Two states of the same library

The entire difference fits in a handful of configuration lines, and there is nothing clever about it:

Default state versus consented state
no answer / denied             after clicking "Allow"
-----------------             ----------------------
persistence: "memory"         persistence: "localStorage+cookie"
person_profiles: "never"      person_profiles: "always"
autocapture: false            autocapture: true
capture_heatmaps: false       capture_heatmaps: true
session_recording: off        session_recording: on (inputs masked)

The left column writes zero bytes to the device. The right one writes an identifier that outlives the browser session. That is the only thing the banner is asking about, which is why the question is not whether to collect data but whether to leave anything on your hardware.

Three things that are normally on by default are off here: automatic interaction capture, click maps and session replay. That is not cosmetic. Those three collect the behaviour of a specific person rather than a page count, so they wait for an explicit decision.

Do not take our word for it

The difference between these tiers is checkable rather than declarative, and that is the substance. A claim nobody can verify is worth exactly as much as trust in whoever made it, which is the same mistake we write about in the context of AI agent security. So check:

  • Open this site in a private window and do not click the banner.
  • Open devtools, the Application tab in Chrome or Storage in Firefox.
  • Look at Cookies and Local Storage for arklink.co. Nothing of ours is there, in particular no key beginning with ph_.
  • Click Allow, reload, and look again. Now the identifier exists, because that is what we asked about.

If you run a site and want the same: check whether your analytics tool has a cookieless mode with in-memory persistence, and whether autocapture and replay are genuinely disabled in it rather than merely unused. Those are two different states, and only one of them lets you honestly write that you store nothing before consent.


E/01What is confirmed
  • By default, with no answer to the banner at all, analytics run cookieless with in-memory persistence: nothing reaches localStorage or a cookie, and the data dies with the tab.
  • Autocapture, click maps and session replay stay off until explicit consent. Nothing is pre-ticked.
  • After consent, recordings mask every form field, including the support ticket form, so what a visitor types is never captured.
  • Events go to the European PostHog instance. Retention is 30 days for recordings and 12 months for events, as stated in this site's privacy policy.
E/02What we do not yet know
  • This is not legal advice. What any given deployment owes depends on that deployment, and the compliance judgement belongs to a lawyer and a supervisory authority.
  • We do not publish what share of visitors consent. The panel is recent and we have no sample worth presenting as a result.
  • Cookieless mode genuinely costs us analytics: we do not recognise returning people and we do not stitch visits into one history. We are not claiming it is a full substitute.