It's not a marketing claim. It's the constraint we designed the entire product around.
Where the browsers actually are
Safari blocked third-party cookies in 2020. Firefox enabled enhanced tracking protection by default the same year. Chrome's third-party cookie deprecation, after several delays, is now functionally in place for the majority of its users, with the rollout strategy moved from total deprecation to user choice. Privacy Sandbox, the proposed replacement set of APIs, has shipped some components and not shipped others. Topics is live. FLEDGE is live in name but not in practice. Attribution Reporting works in narrow cases.
The honest picture is that the proportion of e-commerce traffic for which third-party cookies meaningfully function is now closer to twenty percent than seventy percent. Ad-blockers cover another portion of that twenty. The fraction left isn't enough to build on.
Anyone selling a 2020 architecture in 2026 is selling around the problem.
The honest picture The proportion of e-commerce traffic for which third-party cookies meaningfully function is now closer to twenty percent than seventy percent. The fraction left isn't enough to build on.
What server-side tracking is and isn't
The industry's response to the cookieless transition has been to move the tracking call from the browser to a server. The argument is that the server can identify the visitor by other means, persist data first-party, and feed the same downstream pipelines.
It works, up to a point. The data still has to traverse a third-party identifier somewhere. Either the merchant's server attaches one before forwarding to the analytics provider, or the analytics provider attaches one when the request lands. In both cases, the architecture is now hiding the cross-site correlation rather than removing it.
That's a half-solution. It improves the legal posture by making the data flow first-party at the edge. It doesn't change what's being correlated.
We didn't want a half-solution.
What we built instead
Three architectural choices, which we'll describe at a level that's useful without giving away implementation details we'd rather not publish.
The tracker only ever writes cookies on the merchant's storefront domain. There is no Auraflow domain in the visitor's browser. No cross-site identifier. No federation across merchants. A returning visitor to a single store is recognised. A visitor across two Auraflow merchants is two different visitors. That's the trade-off we accepted, and we accepted it deliberately.
Behavioural signals are observed, normalised, and classified inside the visitor's browser. The raw observations don't leave the device. What leaves the device is a small vector of normalised features and the classification output. The merchant's analytics surface receives a probabilistic archetype assignment, not a recording of what the visitor did.
This is the principle that does the most privacy work. The merchant gets an answer. The visitor's session detail isn't sent anywhere.
Each merchant's data is isolated at every layer of the stack. The database enforces the isolation at the row level. The agent layer enforces it again at the query level. There is no shared visitor identifier and no shared training set. A Klaviyo integration on one merchant's store cannot see another merchant's data, even by accident, because there is no representation of it in the same scope.
The honest answer on returning visitors and cross-device
Cookieless can do some things well. It can recognise a returning visitor on the same browser. It can read enough behavioural pattern to assign archetype with growing confidence over multiple sessions. It can predict CLV from session one, because the prediction is conditioned on behaviour, not identity.
What cookieless cannot do is follow a single human across two devices unless that human chooses to identify themselves on both. There is no third-party identifier we could be using to do it. There is no signal we could correlate, because we deliberately built the system not to retain anything that would correlate.
If a visitor reaches a storefront on their phone, signs up for a newsletter with their email, and then returns on their laptop, we can connect those two sessions through the email they explicitly provided. That's first-party identity, freely given. That's the right kind of identity to build on.
If a visitor returns on a different browser without identifying themselves, we treat them as a new visitor. We say so when the merchant asks. Most cookieless tools don't.
What the compliance picture looks like
GDPR is satisfied because consent is collected, the legal basis for processing is documented, and the data-minimisation principle is honoured at the architecture level. CCPA is satisfied because the visitor's rights of access, deletion, and opt-out are operational, not paperwork. Shopify's Customer Privacy API is the input that controls what we do; the tracker reads the consent state the storefront publishes and behaves accordingly.
What we don't do is treat compliance as a marketing checkbox. The constraints the regulations describe are the constraints we built to. There isn't a separate "GDPR mode" that turns features off in EU traffic. The mode is on for everyone, because the architecture doesn't permit anything else.
Every analytics tool will tell you they're privacy-first. Most of them mean they read the GDPR PDF once. We mean the raw behavioural data never leaves the shopper's browser.