Skip to content
Ithildin Labs EST · MMXXVI

Cookie-free analytics, in concrete terms

Published on 3 min read

The phrase “cookie-free analytics” travels around as if it were an obvious property. It is not. Behind the label sit three technical questions that are rarely separated in public, and that are worth separating in order to make a deliberate decision.

Three questions, not one

  1. Does the tool deposit cookies in the visitor’s browser?
  2. Does the tool send personal data — full IP address, persistent identifiers — to a third party?
  3. Does the tool require explicit consent under the GDPR or the ePrivacy directive?

A tool can use no cookies and still fail questions two and three. Another can use strictly necessary cookies and pass all three. The marketing label collapses the three into one.

What that means for us

On this site we picked a product that satisfies the three conditions by design:

  • It deposits no cookies of any kind.
  • It does not send the full IP address to the backend — it is truncated client-side before transmission.
  • It does not require consent because no personal data leaves the browser.

In exchange we give up a layer of information that many marketing playbooks take for granted: we do not know which visitor came back, we do not attribute conversions to individual campaigns, and we do not build longitudinal cohorts. For a studio that measures success in completed engagements rather than click-through rates, the trade is trivial.

What it looks like in code

An honest integration fits in a handful of lines. This is the script we serve to the client, unwrapped and unaltered:

<script
  defer
  data-domain="ithildinlabs.tech"
  src="https://cloud.umami.is/script.js">
</script>

Five attributes. defer so the script does not block render. data-domain so the analytics panel routes page views to the right project. The external source is a vendor-dedicated domain, declared in the site’s Content-Security-Policy. There is no <noscript> fallback, no conditional loading, no A/B variants.

The reason for the simplicity is practical: every extra line here is a surface that one day will need to be justified to a visitor, to an auditor, or to a successor.

What we actually measure

The only raw inputs we measure are page hits with their referrer, the user-agent aggregated to browser family, the country derived from Accept-Language, and the truncated IP that never reaches the backend. That is it. If a metric cannot be derived from those four fields, we do not chase it.

The operating rule

Before adding an identifier, decide which question you intend to answer with it, and to whom you intend to answer it. If the question is not there, the identifier should not be there either.

That rule governs any future change to the site’s analytics layer. If you want to see the same discipline applied to the entire architecture, Small, durable systems walks through it from another angle.

— Ithildin Labs