A European travel marketplace of Booking.com's shape holds the same guest email twice: once captured at checkout so the booking confirmation can be sent, once captured at newsletter sign-up. The data team wants a single golden customer record and cannot see the objection. Which data model keeps the merge lawful?

The mechanism

Purpose does not attach to the value of the email address. It attaches to the act of collection. The checkout capture carries one purpose, one lawful basis and one retention period; the newsletter capture carries a different purpose, a different basis and a retention that ends the moment the person withdraws. Two separate facts happen to share a string.

A golden record collapses the string and loses the two facts. That is why a merge that looks like plain deduplication changes what the business is allowed to do.

The model that survives the audit

One identity row, keyed on a stable internal id, holding the contact details and nothing about permission. Beside it, an append-only table of purpose grants: one row per (subject, purpose, lawful basis, notice version, timestamp, source, expiry). Marketing does not read the identity row. It reads the grant table, filtered to its purpose, at the moment it builds the send list.

Evaluate at use time, not at collection time, because any flag copied into a downstream system is stale from the instant it is copied. A send list assembled from a nightly export of a boolean will mail people who withdrew that morning.

How it fails

The visible failure is an email to someone who never asked for one, traced back to "we already had the address". The invisible failure is worse: the two records had different retention. The booking record is kept for years because tax and dispute rules require it; the marketing grant should die on withdrawal. After the merge there is one row with one retention, and it is the longer one. Nobody notices until a subject access request asks why the company still holds a marketing relationship it was told to end in 2023.

Why the other options fail

• Keep one customer row and add a marketing opt-in boolean. The boolean records none of the things a regulator asks for: which purpose, on what basis, against which version of the notice, captured when and where. It also has room for exactly one purpose, and there is never exactly one.
• Keep two customer rows and never merge them. This is the operational answer teams actually take, and it breaks the two obligations that need a whole view of a person. You cannot answer "what do you hold about me" or erase completely from two rows that do not know about each other.
• Keep one customer row and delete it when consent is withdrawn. Withdrawing one purpose is not a request to be erased. Deleting the row destroys the booking record the company is required to keep, and an erasure right that deletes records held under a legal obligation is a compliance failure in the other direction.

When not to split the record

A product with one purpose, one basis and one retention period does not need a grant table. A single row with the collection timestamp and the notice version is enough, and the extra table is cost with no return. The model flips the day a second purpose appears with a different basis or a shorter retention, which for most consumer products is the day marketing is hired. Build the identity row so the grant table can be added beside it without a migration, and add it then.