What we won't do
No multi-touch attribution. No session reconstruction. No individual identification. No fingerprinting. Why this is a position, not a limitation.
Most analytics vendors talk about what they do. This chapter is about what we don't — and why. Each section names a feature you might expect, says we won't ship it, and explains the reasoning. Together they describe the shape of the product as much as any feature list could.
None of what follows is a technical limitation. Each "no" is a feature we could ship and a market we could expand into. We are choosing not to. This chapter exists so that you know which trade-off you are buying into before you sign anything.
We won't do multi-touch attribution
The pitch for multi-touch is seductive: every channel that contributed to a conversion gets credit, weighted by some model — linear, time-decay, position-based, data-driven. The math is sophisticated. The marketing decks are colorful.
The problem is the input. Multi-touch attribution requires per-user, cross-session, cross-device journey reconstruction. In Europe, after consent rejection, ITP, and ad blockers, the population you can actually stitch together is roughly the same 13% that GA4 sees. Multi-touch on 13% is multi-touch on a biased sample of consenting Chrome users. The output isn't measurement — it's an algorithm hallucinating about what the other 87% did.
We do last-click on 100% of events. It's an older model. It's a less impressive demo. It moves budget more correctly because it isn't making up the inputs.
Last-click attribution on 100% of measured events, with channel-level revenue resolution.
We won't reconstruct sessions
Session reconstruction stitches events together by user identifier into a chronological journey — landing page, time on site, scroll depth, interaction sequence, exit or conversion. It's the data model behind customer journey analytics, funnel diagrams, and session replay tools.
To do it, you need a persistent identifier per visitor — cookies, localStorage, fingerprint, login state. Each one creates regulatory exposure under ePrivacy article 5(3) and reintroduces the very data we exited to avoid.
What we do instead is aggregate event measurement. We can tell you that 4,221 visitors landed on /product-X yesterday, that 312 added to cart, that 47 converted, broken down by source and device. We cannot tell you that visitor #15732 spent 4:12 on the page and scrolled to 87% before leaving. That data does not exist in our system.
If session-level inspection is critical to your workflow, tools like Hotjar, FullStory, or Contentsquare were built for it. We were not.
Aggregate event measurement — counts, revenue, conversion by channel and device, never per individual.
We won't identify individuals
Identifying individuals — by login, email hash, deterministic fingerprint, or enriched third-party data — is the foundation of most "modern" analytics stacks. It's how CDPs work. It's how Salesforce, HubSpot, and Segment build profiles.
We won't store an identifier that can be resolved back to a person. Not pseudonymously. Not "hashed but reversible". Not "under legitimate interest". This is structural — there is no personal data in our database to expose, to subpoena, to request under GDPR access rights, or to leak.
The trade-off is real: we cannot do retargeting cohorts, CDP enrichment, or personalized email triggers. Those workflows belong in tools designed for them, with the legal framework they require — and they are downstream of measurement, not part of it.
Anonymous event measurement at population scale. No identifier survives long enough to resolve to a person.
We won't fingerprint
Browser fingerprinting — combining user agent, screen resolution, fonts, canvas hash, audio context, and a few dozen other signals into a near-unique browser identifier — is the loophole many "cookieless" tools quietly use to keep cross-session tracking working. Under ePrivacy article 5(3), it is legally equivalent to setting a cookie and requires consent.
We strip fingerprint vectors before storage. User agents are generalised to family and version. IPs are not stored. Canvas, fonts, and audio context are never collected. What lands in ClickHouse cannot be re-identified to a browser, let alone to a person.
This constraint costs us a little — some bot-detection signals would be easier with fingerprint inputs, so we use other heuristics instead. We will not use the technique just because it works.
Server-side validation with non-identifying heuristics. Cookieless in name and in fact.
Each "no" is the shape of the product.
If we shipped multi-touch on partial data, we would sell a hallucination. If we reconstructed sessions, we would introduce regulatory exposure for our customers. If we identified individuals, we would become responsible for data we should not hold. If we fingerprinted, we would be cookieless in name only.
Each refusal makes the product narrower. Each refusal also makes it defensible — by us, in front of a DPO, in front of an auditor, in front of an algorithm being held accountable for what it optimised.
You can build a wider product or a defensible one. We chose the second.
If the vocabulary in this chapter sounded specific, that's because it is. The glossary defines every term we use across Open — including the ones where we disagree with the rest of the industry.
Was this chapter useful? Tell us →