Why Deduplicating Leads on Email Alone Loses Most of Your Matches
Most deduplication is built on one key: the email address. For a large share of businesses that key is missing on the majority of their contacts, so the dedup silently does nothing. Here is what a second key changes, and why formatting breaks matching more often than missing data does.
Why Deduplicating Leads on Email Alone Loses Most of Your Matches
Almost every deduplication rule in marketing starts and ends with the email address: if two records share an email, they are the same person. It is a reasonable default and it quietly fails on two fronts. For a large class of businesses the email is simply absent on most contacts, so the rule never fires. And where a second key does exist, the way it was written down is usually enough to split one person into two records anyway.
Key takeaways
- Deduplicating people and deduplicating events are different problems with different solutions - collapsing a repeated delivery of one event is not the same as recognising one human across two records.
- Email-only matching assumes email coverage, and in phone-first businesses that assumption is wrong by a wide margin.
- Formatting breaks matching more often than missing data does: the same phone number written two ways is two identities until it is normalised.
- A number with no country code cannot be matched safely at all - guessing a prefix manufactures false matches, which is worse than leaving the record unmatched.
- Every additional matching key carries a privacy cost, because you now retain that value for every contact, so each one should be a deliberate decision rather than a default.
Teams that never audit their matching keys end up reporting on a contact base that looks smaller and more fragmented than it is, and attributing one person's journey to two or three separate sources.
Identity resolution: the process of recognising that several records - a form submission, a website visitor, a CRM contact, a phone enquiry - belong to the same person, and linking them.
Matching key: a field whose value exists only to be compared against other records, never to be displayed or measured. An email address or a phone number used this way is a matching key; a deal value is not.
Person-level and event-level deduplication are not the same job
The operational pain this creates for anyone told their stack already has deduplication: the two problems get the same name and have almost nothing in common. Event-level deduplication answers "did this same conversion arrive twice", and it is solved by giving each delivery a stable key so a repeat arrival collapses into the record already there. Person-level identity answers "are these two records the same human", and no key is handed to you - you have to construct one from fields the contact happened to provide.
The practical consequence of conflating them is a false sense of coverage. A stack can be perfectly protected against double-counted conversions and still show the same lead three times, because nothing ever compared the three records to each other. Server-side and browser-side event deduplication is the narrower of the two problems and has its own setup - having solved it tells you nothing about whether your people are deduplicated.
Run marketing on one source of truth
Every source in one brief, so the team stops reconciling exports.
14-day trial after the call · no card required
Why email coverage is the assumption worth checking first
The ICP problem this creates for teams in services, legal, medical, local, or any category where enquiries arrive by call or messenger: the email address is the field the contact never had to give. A caller leaves a number. A messenger lead leaves a handle and a number. The email appears only if a form was involved somewhere in the journey, and often no form was.
On one account we examined, 340 of 369 CRM contacts carried a phone number and only 76 carried an email address at all. An email-only dedup rule on that account is not a weak rule, it is an inert one - it has nothing to compare on four contacts out of five. The practical first step is therefore not to tune the matching logic but to measure coverage per candidate key: count how many of your contacts actually carry each field before deciding which field the matching stands on. Validity's research on marketing data quality makes the downstream case plainly - poor contact data produces revenue loss, compliance exposure, and delayed campaigns, and those costs land whether or not anyone has looked at coverage.
Formatting splits more records than missing fields do
The ICP problem this creates for teams who add a second key and assume the problem is solved: two records can carry the same phone number and still fail to match, because the number was written differently. On the account above, keeping the leading plus sign on international numbers turned a single number into two separate identities - 291 of 326 numbers carried the plus and 35 did not, so the same human could sit on either side of that split depending on which system captured them.
Normalising to digits only fixes that case, and it exposes the next one: 16 nine-digit numbers in local format could not be keyed at all. A number with no country code is genuinely ambiguous, and the correct handling is to leave it unmatched rather than assume a prefix - a guessed country code produces confident false matches, which corrupt reporting in a way an unmatched record does not. A 2025 Gartner survey found 73% of enterprise data leaders rank data quality as the top barrier to AI success, ahead of model accuracy and compute cost, and normalisation rules are exactly the unglamorous layer that decides whether that barrier is present in your own data. The same forward-only-versus-retroactive question applies here as it does to channel definitions: a normalisation rule corrected today is only worth what it can be replayed across.
Prooflytics matches on two keys rather than one - a normalised email and a normalised phone number, both hashed before they are stored - and accumulates links from website visitors, server-side events, and CRM imports into the same identity, so a contact who arrived by phone is matchable even with no email on file. Repeated deliveries of the same event collapse through a separate mechanism, because that is a separate problem. One honest limitation worth naming: a CRM contact linked without an email is treated as its own state rather than folded into the headline count of known people, so the number you see is not quietly inflated.
Bottom line
- Deduplicating events and recognising people are separate problems; solving one does not touch the other.
- Measure coverage per candidate key before tuning any matching logic - an email-only rule is inert on a contact base that has no emails.
- Normalise before you compare; the same number written two ways is two identities, and that splits more records than missing fields do.
- Leave genuinely ambiguous values unmatched rather than guessing - a false match corrupts reporting more than a gap does.
- Book a walkthrough to see how Prooflytics links contacts on both email and phone, across website, server-side, and CRM sources.
Frequently asked questions
Is it safe to match leads on name and company instead of email?+
Treat that as a suggestion rather than a match. Names collide, abbreviate, and transliterate, and company names are written a dozen ways. Fuzzy matching on those fields produces merges that are very hard to unwind later, so it is better used to flag candidates for review than to merge automatically.
Should I merge duplicate records or just link them?+
Linking is the safer default. A merge destroys the original records, so a matching rule you later discover was wrong cannot be reversed. Linking keeps both records and records the relationship, which means a corrected rule can be re-applied.
How do I know how bad my duplicate problem is?+
Count coverage per field first - what share of contacts carry an email, a phone, a normalised phone - then count how many distinct records share each key value. The ratio tells you both how much matching is possible and how much is currently being missed, and it takes a single query rather than a project.
Does adding more matching keys always improve results?+
No, and each one has a cost. A new key means retaining that value for every contact you hold, which is a privacy decision as much as a data one. Add a key when you can show coverage that justifies it, not because it is available.
You can read independent reviews of Prooflytics on G2 and compare it to other marketing intelligence platforms in the category.
Run marketing on one source of truth
Every source in one brief, so the team stops reconciling exports.
14-day trial after the call · no card required
Continue reading
Meta Pixel and Conversions API Event Deduplication: How to Set It Up Correctly
Running Meta's Pixel and Conversions API together without deduplication double-counts every conversion both systems capture. Here is exactly which fields have to match, the 48-hour matching window, and how to verify it is actually working.
Your Tracking Plan Was Written for Product Analytics. Marketing Needs a Different One.
Every tracking plan template you can download specifies event names and properties, because they were all written for product teams instrumenting a feature. A team buying media and attributing revenue has to specify four more things, and none of them appear on those templates.
Why Email Open Rate Is an Unreliable Metric Now (and What to Track Instead)
Apple's Mail Privacy Protection pre-fetches every image in an email the moment it arrives, registering an open whether or not a human ever reads the message. Here is why open rate can no longer be trusted alone, and what actually replaces it.
Why Your Marketing Numbers Don't Match Across Platforms (It's the Timezone)
A campaign reporting 50 conversions in one platform and 47 in another isn't necessarily a tracking bug - each platform may be attributing the same conversions to a different calendar day. Here is how to find and fix a timezone mismatch before it wastes an afternoon of investigation.