One Customer, Four Identities: Why Your Return Counts Undercount People

Fragmentation is the default state of returns data

A single customer returns under her work email, her personal email, a guest checkout with a typo in the address, and her partner's name on a shared card. Four records, four tidy low return counts, zero flags. Multiply by every household that shares an address and every shopper who has ever checked out as a guest, and the identity layer underneath returns reporting is mostly Swiss cheese.

This cuts in both directions, which is what makes it a sifting problem rather than a fraud problem. Fragmentation hides the genuine serial abuser inside the noise. It also splits a loyal bracketing shopper's history so no single record shows her keep rate, and a good customer gets scored like a stranger. Every rate, threshold, and review queue downstream inherits the error.

Match on the strong keys first, then argue about the weak ones

The reliable join keys, in order, are payment instrument tokens, account IDs, and normalized phone numbers. Card tokens survive email changes and guest checkout, which is why processors tokenize them. Email is a middling key: real, but plural per person. Address is the weakest key of all, shared by households, dorms, and offices, and it should corroborate a match, never create one alone.

Build the match as a confidence ladder, not a merge button. Token plus email is the same person, merge it. Email plus address is probably the same person, link it for reporting but keep the records separable. Address alone is a household, useful for spotting return patterns run through family members, dangerous for accusing an individual. When a case matters, a human reviews the ladder before a customer hears about it.

What clean identity does to the numbers you report

Expect two uncomfortable movements after deduplication. Your count of distinct returners falls, sometimes by a fifth, because the fragments collapse. And your worst actors list gets worse, because the abuser who was five polite records becomes one record with a rate and a velocity no threshold can wave past. Both movements are the truth arriving, and leadership should be warned before the first clean report, not after.

The National Retail Federation put returns at 16.9% of US retail sales for 2024. At that scale, a few points of identity error is not a data quality footnote; it is the difference between a returns program aimed at real behavior and one aimed at artifacts of your own checkout flow. Sift the identities first. Every later decision gets cheaper and fairer at the same time.

Frequently asked questions

Why do return reports undercount repeat returners?

Because one person appears as several records: different emails, guest checkouts, a partner's name or card. Thresholds evaluate each fragment separately, so a pattern that is obvious across the full history stays invisible in every individual record.

What is the most reliable way to match a customer's returns?

Payment instrument tokens are the strongest key, since they persist across emails and guest checkouts, followed by account IDs and phone numbers. Email is a useful but plural key, and street address alone identifies a household, not a person.

Can address matching identify a serial returner?

Not fairly by itself. Addresses are shared by households, roommates, and offices, so address only matches should corroborate stronger signals, not trigger action. Address patterns can still flag cases for human review when combined with payment or contact matches.

What changes after returns data is deduplicated?

The number of distinct returners usually drops as fragments merge, while the true high rate returners become visible for the first time. Thresholds and review queues built afterwards are aimed at real behavior instead of checkout artifacts.