Same customer, three records, which one do you keep. That is the question survivorship answers, and getting marketing cloud survivorship wrong is the fastest way to overwrite a customer's real data or mail someone who never opted in. This is the core of the broader system we covered in why Marketing Cloud is really an identity resolution machine: once you have pulled the same person out of every source feeding your platform, you still have to collapse those copies into one truth.
The problem: one person, several conflicting records
After you gather data from multiple sources, the same human shows up as more than one record, and the fields disagree. One copy has the current mobile number but a stale opt-in flag. Another has the right consent state but an old email address. A third came in from a batch import with a name spelled differently. You cannot keep all of them, because downstream every journey, every send, and every report assumes one row per person. You also cannot just grab the first row you see, because each copy is right about something and wrong about something else.
So you need a golden record: a single, deterministic winner for each person, produced by one rule applied the same way every time. Deterministic matters here. If the same input can produce two different winners on two different runs, you do not have survivorship, you have a coin flip writing to your production database.
The customer type hierarchy decides the winner
The main axis for picking a winner is the customer type, ranked by priority. When the same person exists as two records with different types, the higher type wins.
Rank
Customer type
Wins against
Lowest
NEWSLETTER
nothing
Middle
GENERAL
NEWSLETTER
Highest
VIP
GENERAL, NEWSLETTER
Written compactly, the order is NEWSLETTER below GENERAL below VIP. The comparison runs pairwise: you take the record coming from one source (say an API feed) and the record coming from another (say a User or ETL load), compare their types, and the higher type survives. The reasoning is that a higher tier represents a stronger, more deliberate relationship with the customer, so its data is the version you want to trust when two copies fight.
This is not just bookkeeping. The consent and contact details that survive belong to the record that won on type, which means the hierarchy directly controls who receives mail after a merge. If a marketer asks why a customer suddenly started or stopped getting a campaign after a dedup run, the answer almost always traces back to which type won.
The winning record carries all of its fields
Here is the rule that keeps survivorship safe, and the one teams most often break. When you have decided which record wins, you take all of the winning record's fields: email, contact key, name, mobile number, and opt-in state. You do not cherry pick. You do not take the email from the winner and the opt-in from the loser because the loser's flag looked more recent.
The reason is consistency between fields that are only meaningful together. Email and opt-in are the canonical pair. An opt-in is consent for a specific address to receive specific communications. If you keep record A's email but record B's opt-in, you have manufactured a consent state that never existed: you are now cleared to mail an address that was never the one the customer agreed on. Multiply that across a database and you have a compliance incident, not a data quality nuisance. The same logic applies more loosely to name and mobile, but email and opt-in are the pair that turns a sloppy merge into a legal problem.
So the rule is blunt on purpose. Pick the winning record once, then carry every column from that record as a unit. Mixing fields across records is the single most common way survivorship quietly corrupts data.
The derived online versus offline attribute
Beyond the type hierarchy, the logic usually derives one more attribute that is not stored directly on any source record: whether the customer originated online or offline. This is inferred, typically from the shape of the contact key. A key that starts with a known prefix marks an online signup, while keys in another format mark offline origin, and in some setups the customer type itself feeds the inference.
The reason to compute it during survivorship rather than later is that journeys branch on it. Online and offline customers often follow different paths, get different welcome sequences, or fall under different messaging rules. Deriving it once, at the moment you settle the golden record, means every downstream consumer reads a consistent value instead of re-deriving it (and disagreeing) in five different places.
Why this is the most dangerous code in the system
Here is the part that makes survivorship genuinely hard to maintain, not just careful to design. The query language cannot assign a winner once and then select all of that winner's columns. There is no winner = recordWithHigherType you can declare and reuse. Instead, the full set of comparison conditions has to be repeated for every single output column.
That means the exact same logic, decide which type is higher, pick that record, return its value, gets written out again for email, again for contact key, again for name, again for mobile, again for opt-in, again for the derived online flag, and again for every other field you carry. The expression does not grow linearly with your patience. In a real system this is a single query running close to twenty thousand characters, almost all of it the same comparison copied across columns.
The failure mode follows directly. If you change one priority condition, say you add a tier or adjust how a tie breaks, and you update it for email but forget mobile, you now have a record whose email came from the VIP copy and whose mobile came from the NEWSLETTER copy. The output looks plausible. Nothing throws an error. The data is just silently wrong, and you find out when a customer complains or an audit catches it. This is why the golden rule for touching survivorship is to understand the entire type hierarchy first, then change every column in lockstep, treating the repeated block as one logical edit even though the language forces you to type it many times.
Safety rules before you run it
Two non-negotiables follow from everything above. First, test on a copy. Run the survivorship logic against a clone of the data, then diff the output against what you expected: spot check known duplicates, confirm the right types won, and verify email and opt-in stayed paired on every surviving row. Second, never run dedup straight on production. There is no undo for a merge that overwrites the wrong fields across millions of rows, and because the corruption is silent, you will not get an alert telling you it happened. Validate on the copy, get the output reviewed, and only then promote it.
Takeaway
Survivorship is the heart of the identity resolution machine, and it is unforgiving. Define your customer type hierarchy explicitly, let the higher type win pairwise, and carry all of the winning record's fields as a unit so email and opt-in never drift apart. Respect that the query language forces the win condition to repeat across every column, so any change is an all-columns change. And always validate on a copy before production, because a desynced condition fails silently and there is no clean rollback.
If your team is wrestling with duplicate customers, conflicting opt-in states, or a survivorship query that has grown beyond anyone's confidence to edit, this is exactly the kind of work we untangle. Tell us what your data looks like at /contact, and see how we approach Marketing Cloud data quality at /service.
Top comments (0)