Duplicates do not inflate a list, they inflate the number you report
Every list has two sizes: the number of rows and the number of people. They start equal and drift apart with every import. The drift is quiet, costs money per row at most providers, and shows up in the two places nobody re-checks - the size you quote and the accuracy percentage you claim.
Where the same person becomes several rows
| Source of duplication | What the rows look like | Why a dedupe by address misses it |
|---|---|---|
| Second source for the same person | Same name, same company, a different address shape (first.last@ vs initial+last@) | The two addresses are different strings, so neither looks like the other |
| Job change | The old address is dead, the new one is live, both rows exist | Both rows are "correct" for their own date - 23% of contacts change jobs in a year (ZoomInfo, 2025) |
| Re-import after a clean | The row came back from a file that was never retired | Nothing in the address says it was already processed |
| Aliases and plus-addressing | One mailbox, several spellings | The server accepts all of them, so all of them verify as deliverable |
| Shared and role mailboxes | One address, several people behind it | The string is identical, so a string-based dedupe keeps one row and loses the others |
Only the last two rows are string problems. The first three are identity problems, and they need a key that is about the person - company plus name, plus the date the row was last confirmed.
What the drift actually costs
- Per-row billing. Seat-and-credit models charge for the rows you keep, so duplicates are paid for twice and never noticed, because the invoice matches the list size you believe you have.
- Accuracy claims measured against the wrong denominator. "95% valid" over 5,000 rows that describe 3,900 people is not the same statement as over 3,900 people. Verification measures rows; quality is about people.
- Repeated sends to the same human. The second touch arrives from a pipeline that does not know the first one happened, which is the most common way a sequence looks like spam from the inside.
- Retired data that keeps coming back. Hard bounces and people who asked not to be contacted return with the next import if the retire list is not applied at intake.
A dedupe that survives a moving list
- Key on the person, not the string. Company domain plus normalised name is the practical identity; the address is an attribute of that identity, with a date on it.
- Count unique people, publish that number. Keep rows as evidence - they carry different sources and dates - and report contacts, not lines.
- Supervise the retire list at intake. Bounced addresses and opt-outs are applied on import, before the new rows exist, which is the only point where it is cheap.
- Let the newest confirmation win. When two rows conflict, the one with the more recent probe describes the current address; the older one is history, and history is fine as long as it does not get sent to.
- Re-probe at the moment of send. Deduplication answers "who is this"; it does not answer "does this mailbox still exist", and the two questions decay at different speeds.
What TAPAC returns for a duplicated source
Each contact arrives with the source page or profile it came from, the state of its mailbox, and the time of the probe. Two rows for the same person coming from different sources stay distinguishable - company, source and date are on the row - and the states are the honest three: deliverable, undeliverable, or unknown for catch-all domains. Nothing about that requires the address strings to match.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status # or hosted: https://tapacapi.com/mcp # or REST: POST https://tapacapi.com/v1/contacts/search
Checked contacts carry a published 2-5% bounce rate against 10-35% for static, resold databases; TAPAC is pay-per-use at $0.10-0.50 per contact with 100 free searches. For comparison, 42% of B2B data goes stale in a year (HBR, 2024), which is the rate at which a duplicated list keeps growing without anyone importing anything.
Related: why a lead list has a half-life, what cleaning a list can and cannot fix, and the delivery logs nobody keeps.
← Back to TAPAC