Contact model & SubscriberKey work

The problem

SubscriberKey is the closest thing Marketing Cloud has to an identity decision, and it is the one that is hardest to reverse. Accounts that started with email address as the key eventually accumulate duplicate contacts, split engagement history, and sends that count one person several times.

Approach

Start by measuring the shape of the problem: how many distinct keys map to the same person, where those records came from, and which of them still receive sends.

Pick a stable key that exists before the first send and never changes — usually a CRM identifier — and define what happens for contacts that do not have one yet.

Plan the migration as a sequence with a rollback point at each step, because the intermediate states are the dangerous part, not the end state.

Keep a mapping table between old and new keys for as long as historical reporting needs to be joined back.

What I took away

Most duplicate-contact problems are not data-quality problems. They are the visible result of an identity decision that was made implicitly, often in the first week of an implementation.