One person many email addresses and why exact match joins lose her

Somebody asks how many of this year's registrants came to the same show two years ago. The query is a join on email, it returns 6,400 out of 21,300, and the number goes in the deck as a 30 per cent repeat rate. One person with many email addresses is the reason that number is wrong, and it is wrong in a direction nobody checks.

Here is the buyer the join loses. In 2024 she registered with her work address at a regional distributor. She changed jobs in 2025. In 2026 she registered from her phone in a hotel lobby, could not remember the new work password, and used a personal address. Her assistant registered her for the sister show in between, from a shared inbox with the assistant's own name in it.

Three addresses. Three registrations. No two of them share a single character before the at sign, and two of them do not share a domain either.

Three addresses, and where each one comes from

The addresses arrive by different routes and each route has a signature you can recognise in a file.

• The work address. Firstname.lastname at the employer domain, captured when somebody registers at their desk. It dies when the person changes employer, and it is the address most likely to appear in your CRM.
• The personal address. A free webmail domain, usually captured on mobile, often at the last minute, sometimes because the work address bounced a confirmation. It survives job changes and tells you nothing about where the person works.
• The delegated address. An assistant, a team inbox, a travel coordinator. The name on the row belongs to the attendee and the address belongs to somebody else, which makes it the most dangerous of the three, because the same address will appear on rows for several different people.

That third category is why deduplicating on email alone can be actively harmful. If [email protected] registered nine executives over four years, an email based merge collapses nine buyers into one.

What does an exact match join actually return?

Work the smallest possible case by hand. Three rows, one person, three possible pairs: 2024 with 2025, 2024 with 2026, 2025 with 2026.

An equality join on lowercased email evaluates each pair and returns false three times. The test has nothing to weigh. Two strings differ, so the join emits nothing and moves on, and the evidence sitting in the other four fields is never consulted. Zero of three pairs recovered from a person who is unambiguously the same human being to anyone reading the rows.

Now put a mobile number on two of the three rows and run a second test, surname equal and mobile equal. That fires on the 2024 to 2026 pair, so one of three pairs is recovered. Add a third test, surname equal and normalised employer equal, and the 2024 to 2025 pair fires. Two of three, from two rules that took an hour to write.

The 2025 to 2026 pair is the interesting one, because the buyer changed employer between them and the assistant row carries no mobile. Nothing links it directly. It links transitively: 2024 connects to 2025 and 2024 connects to 2026, so all three land in one cluster if your pipeline takes the transitive closure of pairwise links. That single design decision moves the answer more than most model tuning, and it is also how a bad link contaminates a whole cluster, which is the argument for keeping merges reversible.

Why does agreement on several weak fields beat agreement on one strong one?

This question was settled in 1959 and most registration reporting has not caught up. Newcombe, Kennedy, Axford and James, writing in Science that year, built the first automatic computer based record linkage system and applied it to birth and marriage records in British Columbia, where the two files shared no identifier of any kind. They had family names, first initials, birth places, some ages, and the location of each event.

Their move was to stop asking whether a pair agreed and start asking how surprising the agreement was. Two records agreeing on an uncommon surname is strong evidence. Two records agreeing on a common one is weak evidence. Several weak agreements accumulate into a strong conclusion, and each field contributes in proportion to how unlikely that particular agreement would be between strangers.

Reviewing the work in Science Advances in 2022, Binette and Steorts report that about 98.3 per cent of the true matches were detected, that about 0.7 per cent of the links made were wrong, and that the hardware managed roughly ten records a minute. A 1959 file with no email addresses, no phone numbers and no postcodes reached a link rate your registration archive probably does not, using only the accumulation of weak evidence.

The rule that links all three

Applied to the buyer above, a rule requiring agreement on surname plus mobile plus normalised employer is too strict, because she changed employer. The version that works is a disjunction. Link if surname agrees and mobile agrees. Link if surname agrees and employer agrees and forename agrees. Link if email agrees. Then take the transitive closure of everything that fired.

That cascade is deterministic, which makes it auditable and fast, and it has a specific failure point worth knowing before you build one, covered in deterministic matching rules. The scoring approach that replaces the cascade when the fields get weaker is in probabilistic record linkage.

The field ranking that falls out of this surprises people. For linking a person across years, I would rather have a mobile number than a work email address. The email tells you where somebody worked on the day they registered. The mobile follows them out of the building. Work email is better for one job, which is inferring the employer, and that job belongs to company matching rather than person matching.

What this does to your repeat rate

Take the 21,300 registrations from the opening. The email join found 6,400 prior registrants, a repeat rate of 30.0 per cent.

Add the mobile rule and 1,150 more rows link, taking the count to 7,550 and the rate to 35.4 per cent. Add surname plus employer plus forename and another 780 link, giving 8,330 and 39.1 per cent. Nine points of repeat rate, one file, no change in anyone's behaviour, and the third number is still a floor rather than the truth.

The bias in that gap is the part worth arguing about in a commercial meeting. The rows recovered by the second and third rules belong disproportionately to people who changed employer, and people who change employer are more senior on average than people who do not. Your exact match repeat rate understates repeat attendance among exactly the buyers your exhibitors pay to meet.

Why not just make people register with the same address every time?

This is the first suggestion in every meeting where the repeat rate comes up, and it is worth taking seriously for about five minutes.

The proposals are a mandatory account, a login before registration, or a returning visitor flow that recognises the person and prefills the form. All three reduce the rate at which new addresses enter the file. None of them touches the five editions you already have, which is where the analysis question lives. A portfolio with 40 event instances of history is asking about the past, and the past is not going to re-register.

They also carry a cost that audience acquisition teams feel immediately. Every field you make mandatory and every step you put before the form suppresses completions, and a login wall suppresses them most for the casual first time visitor you were trying to attract. Trading registration volume for cleaner keys is a real trade, and the identity work is cheaper than the volume you would lose.

The version I would actually run is softer. Ask for a mobile number and explain what it is for. Offer a one click recognition on the confirmation page when a returning person is detected, and let them correct it. Then accept that a proportion of your file will always be unlinkable by key alone, and resolve the rest after the fact.

Where this stops

Three limits, and the first is coverage. If 38 per cent of your rows have no mobile number, the mobile rule cannot fire on them, and their apparent repeat rate will be lower than the rest of the file. That difference is a property of your registration form, and reporting it without the completeness attached invites somebody to conclude that a channel brings worse attendees when the truth is you know less about them.

The second is the shared inbox. Any rule that treats an email address as identifying will merge everyone who used the assistant's inbox. Detect addresses that appear with more than a handful of distinct surnames and demote them to non identifying before the rules run.

The third is families and colleagues. Same surname, same employer, same postcode, two different people. Rules cannot separate them and neither can a score, because the evidence genuinely points one way. The only fix is a field that distinguishes them, usually forename plus a date of birth or a job title, and if you do not collect one you should say so rather than pretend the merge was clean.

The first step is a two line count on last year's file. Count rows where the email matches a prior edition. Then count rows where the mobile matches a prior edition and the email does not. The second number, divided by the first, is how much of your repeat audience the email join is currently throwing away, and it is the cheapest argument you will ever make for a unified data layer. The full six stage version of that work sits in duplicate attendee records across shows.