Third-party tracking cookies are blocked by default in Safari and Firefox. iOS14 broke attribution. Privacy Sandbox isn't replacing it. Most analytics tools are quietly retrofitting around the problem. We built Auraflow assuming the problem had already won.
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 had turned on Enhanced Tracking Protection by default the year before. Chrome's third-party cookie deprecation, after several delays, never arrived: the rollout strategy moved from total deprecation to user choice, and in April 2025 Google said (opens in a new tab) it would keep its current approach, so third-party cookies still work by default in Chrome. Privacy Sandbox, the proposed replacement set of APIs, shipped some components, and in October 2025 Google said (opens in a new tab) it would retire most of them, Topics, Protected Audience (formerly FLEDGE) and Attribution Reporting included.
The honest picture is that third-party cookies meaningfully function for only part of e-commerce traffic. Ad-blockers cover another portion of that part. The fraction left isn't enough to build on.
Anyone selling a 2020 architecture in 2026 is selling around the problem.
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. 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.
No tracker cookies, and a visitor ID instead of a name
The tracker sets no cookies. To recognise a returning visitor it uses a pseudonymous device identifier instead, and our Cookie policy explains how. A visitor is a visitor ID, not a name. A returning visitor to a single store is recognised.
The answer, not the recording
Behavioural signals are analysed server-side and reduced, live, to a single probabilistic archetype. What the merchant's analytics surface shows is built on that pseudonymous assignment, processed inside the per-store boundary, not a recording of what the visitor did.
This is the principle that does the most privacy work. The merchant gets the answer. It is pseudonymous, per-store, and never pooled across merchants.
Isolation you can check
Each merchant's data is scoped to their store: queries carry the store's tenant filter, and an automated isolation suite runs on every change and blocks release if a query loses it. A subset of tables also carries Postgres row-level security. The agent layer enforces the same scope again at the query level. There is no shared training set.
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. The identifier we use to recognise a returning visitor is derived from the browser and device in use, so a different device looks like a new visitor.
If a visitor reaches a storefront on their phone, signs up for a newsletter with their email, and then returns on their laptop and gives the same email there, 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.
What the compliance picture looks like
Auraflow is built to help merchants meet their GDPR and CCPA obligations. Consent is honoured at the tag, and the visitor's rights of access, deletion, and opt-out are operational, not paperwork: Shopify's mandatory GDPR webhooks (customer data request, customer redact, shop redact) are wired in, the merchant can hard delete from Settings, and Global Privacy Control and Do Not Track are honoured. 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: when consent is withheld, it creates no visitor record and sends no signals.
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 same consent gate runs for each visitor, wherever they are, and it follows the privacy settings the storefront publishes.
Every analytics tool will tell you they're privacy-first. We mean pseudonymous by design, isolated per store, with the behavioural reading done server-side and never pooled across merchants.