What Consent-Per-Identifier Means for Your Customer Data

Consent-per-identifier means every identifier in your customer graph carries its own consent record: the email address, the phone number, each device ID, each cookie. Not one flag on a customer row. A record per identifier, storing what the person agreed to, under which law, from which form, and when.

That sounds like a schema detail. It decides whether you can honour a deletion request in a query or in a fortnight of spreadsheet work.

One person, six identifiers, six different answers

A returning customer on your Shopify store might be six things at once to your analytics stack. A cookie from a Facebook click in April. A different cookie on their work laptop. A hashed email from checkout. A phone number from an SMS opt-in. A device ID from your app. An order ID.

Each of those arrived through a different door, and the person made a different decision at each one.

They accepted analytics cookies on mobile and declined them on desktop. They opted into SMS but never agreed to have that number matched back to their browsing. They ticked the marketing box at checkout in 2025 and withdrew it in 2026. All of that is normal behaviour, and all of it is legally meaningful.

Most tools store one answer.

How consent usually gets stored

The common pattern is a boolean on the user or account record. marketing_consent: true. Sometimes there are three or four booleans for different purposes, which is better, and sometimes the consent management platform holds the record while the analytics tool holds the data, which is worse, because the two only agree when someone remembers to sync them.

The failure shows up in two places.

First, identity resolution. The moment your tool decides the desktop cookie and the mobile cookie belong to the same person, it has performed cross-device tracking. If the consent flag lives on the merged customer record, that merge already happened before anything checked whether it was allowed. The check runs after the fact, on data that should not exist.

Second, erasure. When a person asks to be forgotten, an account-level flag tells you nothing about where their data went. You need to know which cookies, which device IDs and which sessions belonged to them, and that mapping is exactly what a flat consent model throws away.

How the graph stores it instead

NodeNarrative keeps identity in a Neo4j knowledge graph. A Person node connects to the Identity nodes representing each identifier, and every Identity node has its own ConsentRecord nodes hanging off it.

Each ConsentRecord stores the purpose (analytics, cross-device matching, marketing, personalisation), the lawful basis you are relying on, the status, the jurisdiction that applies, the source it came from, and the timestamps. A record can carry an expiry, which matters in jurisdictions that treat consent as perishable.

Consent granted on one identifier can propagate across the cluster when the person has clearly given it for their whole profile. It does not propagate by default, because inferring agreement from silence is the thing the regulation exists to stop.

The useful part: the graph refuses work

The reason to put consent in the graph rather than beside it is that identity resolution can then read it mid-query.

NodeNarrative runs probabilistic matching behind a consent gate. Before the resolver links two identifiers into the same person, it checks whether those identifiers carry cross_device consent. If they do not, the link is never created. The desktop cookie and the mobile cookie stay separate people in your data, because that is what the customer asked for.

You lose some attribution coverage doing this. That is the trade, and any vendor telling you there is no trade is not gating anything.

Right to erasure, by traversal

Article 17 requests are where the architecture pays for itself.

A request arrives naming one identifier, usually an email address. The erasure service starts at that Identity node, walks every link out of it to the connected identifiers, sessions and touchpoints, and anonymises the personal data at each stop. Identifying fields are overwritten. The person’s status is marked as erased, and an audit node records what was done and when, which is the evidence you produce if a regulator asks.

The graph structure survives. That is deliberate. Recital 26 puts genuinely anonymous data outside the GDPR, so overwriting the identifiers discharges the obligation, and keeping the shape of the graph means last quarter’s revenue by channel does not quietly change every time someone exercises their rights. Deletion would give you compliance and a broken reporting history.

No manual data mapping. No spreadsheet of which systems hold a copy. The traversal finds the connections because storing the connections is the entire point of the database.

Why a Shopify brand should care

Three reasons, in order of how soon they will bite.

The first is that you are the data controller. Your attribution vendor is a processor acting on your instructions, which means the erasure request lands on you and the fine lands on you. A tool that cannot answer “where did this person’s data go” leaves you holding a question you are legally obliged to answer.

The second is that consent is getting more granular, not less. The trend across GDPR enforcement, the ePrivacy rules, CCPA and the newer state laws runs the same direction: per-purpose, provable, revocable. An architecture that models one flag per customer will need rebuilding. One that models a record per identifier per purpose already fits.

The third is quieter. Being able to tell a customer exactly what you hold, and prove you removed it, is worth something to the kind of brand whose customers ask.

What this does not do

It does not make you compliant. Consent-per-identifier is machinery for enforcing decisions you have already made about lawful basis, retention and disclosure, and it will enforce a bad policy as faithfully as a good one. You still need the policy, the privacy notice and the DPA.

The consent gate is also opt-in per account rather than on by default, because switching it on mid-flight changes which identities resolve, and that changes your historical numbers. Turning it on is a decision you make with us, not a surprise.

We are also stating a capability, not an audit. No competitor in the Shopify attribution category documents consent at this level, based on our own review of their public material in August 2026, and we would rather you verify that than take it from a vendor’s blog.

Read how the identity graph is built on the identity resolution page, what we collect and retain in the privacy policy, and how the attribution models sit on top of the same graph in the methodology.

Ready to see privacy-first attribution running against your own store data? Book a demo and we will walk the graph with you.