How do you deduplicate event customers with different emails?

Someone buys your April workshop with a work email, then books June using a personal address. Your customer list treats them as two people. Meanwhile, two friends book through a shared inbox and look like one. If you merge everything that seems similar, you can make both mistakes harder to spot.

To deduplicate event customer data, confirm which records belong to the same customer before combining their history. Keep the original customer references, orders and contact preferences, and leave uncertain matches for review. A name that looks familiar is a reason to investigate, not enough evidence to merge.

The first thing you want to decide is what you're trying to improve. You might need an accurate repeat-buyer report, fewer duplicate promotional emails or a clearer view of a customer's purchases. Those jobs overlap, but they don't all require a permanent change to the customer database.

This guide walks through the matching decisions, including changed email addresses, shared inboxes, group purchases and conflicting opt-outs. We'll use fictional records to show what should change and what must stay intact. You'll also get a review record your team can reuse, so the next person understands why a match was accepted.

Decide whether you're matching buyers or attendees

Start with one sentence describing the person your report counts. For example, you want to identify customers who bought tickets to more than one edition of your paid workshop. That is a buyer question. It doesn't establish whether those customers entered the room, brought guests or transferred their tickets before the event.

Imagine Maya buys four tickets and gives three to colleagues. The order belongs to Maya as purchaser. Each ticket provides an admission, but the buyer's email on all four tickets doesn't make all four attendees Maya. Combining customer records should preserve that distinction. It mustn't attach every guest's attendance to the person who paid.

A company booking introduces another relationship. The business might pay, an assistant might handle the correspondence, and several employees might attend. Decide whether you need a company purchasing history, an individual buyer history or an attendee history. You can retain these relationships without forcing everyone into the same personal customer record.

If the source records identify only purchasers, call the result repeat purchasing. If you have reliable individual attendance records, you can investigate repeat attendance separately. Our guide to measuring repeat attendance across an event series explains the observation period and attendance evidence that calculation needs. Matching email addresses alone doesn't supply either.

Write the boundary beside your working report. For this project, you might include paid workshop purchasers across the current season and exclude newsletter subscribers who haven't bought. That keeps the review useful and manageable. You can widen it later when another decision requires more history, rather than collecting every contact your business has ever encountered.

Separate a repeated row from a repeated customer

A duplicate row can appear because someone combined the same download twice. A repeated customer can appear because one person has two separate contact records. These need different fixes. Remove a verified repeated copy from the working data; investigate whether separate customer records describe the same person before linking them.

Two orders with the same buyer name aren't duplicate orders. They may be two legitimate purchases, even on the same day. Equally, one order can generate several rows because it contains several tickets. If you delete those rows while trying to tidy customer data, you can lose valid sales or admissions.

Check the source references first. Keep the system name with each customer, order and ticket reference, because separate systems can issue identical-looking numbers. A customer reference identifies whatever that particular system calls a customer. Confirm whether it represents an individual, a shared account or a company before treating it as proof of a person's identity.

An existing link maintained by the source can save you work. If two purchases already belong to the same verified individual account, start with that relationship. Don't rebuild it from name similarity. Investigate contradictions, such as evidence that the account is shared, instead of assuming every system reference describes one natural person forever.

Our guide to cleaning ticket sales and attendance data covers repeated rows, refunds and the relationships between orders, tickets and admissions. Finish those basic checks before customer matching. Otherwise you may congratulate yourself for finding returning buyers when you've really found the same export twice.

A useful first review ends with separate lists of verified repeated copies, existing customer relationships and possible customer matches. You don't need elaborate software to understand the distinction. You do need to avoid applying one delete-duplicates command to all three, because it cannot decide what the repeated information means.

Preserve the original records before changing the view

Keep the source customer references and original values available in your authorized system. Prepare proposed matches separately from the live customer records. That gives the reviewer something concrete to approve and lets you compare the result with what existed before. Don't start by overwriting one email address with another.

Where your reporting tool supports it, you can group two source customer records under one reference for reporting without merging their accounts. That may be enough for a repeat-purchase calculation. Check the tool's documented behavior and access rules. A reporting association should not silently change ticket ownership, account access or where receipts are delivered.

A permanent merge is a bigger change. Find out which record survives, which fields are overwritten, whether orders move and whether the operation can be reversed. Ask what happens to notes, permissions, subscriptions and connected tools. If the documentation doesn't answer those questions, test the supported process with approved test records or ask the provider before using real customers.

Keep a record of the proposed changes and the version of the source you reviewed. A customer can update their address while you're investigating. Before applying the approved match, check the current record again. If the evidence has changed, reconsider the decision rather than applying yesterday's approval to today's different information.

The UK's Information Commissioner's Office explains in its accuracy guidance that records should make their source and status clear, and that historical information can remain accurate when labelled as historical. That supports preserving an old purchase address as history while maintaining a separately verified current contact address. The guidance addresses UK data protection law and is under review following legislative changes.

Clean formatting without inventing a match

Formatting differences can hide useful evidence. An accidental space at the edge of an imported address might stop a comparison from finding it. Preserve the original value and use a separate comparison value where your tools support that. Record the changes applied so another person can reproduce the comparison.

Email handling needs more care than a universal cleanup rule. Follow the source system's documented treatment of case and whitespace. Don't remove punctuation or rewrite the part before the @ sign across every provider. A change that works for one email service may point to a different mailbox elsewhere.

Google's explanation of dots in Gmail addresses says dotted versions of a personal gmail.com address reach the same inbox. It also says dots change addresses used through work, school or other organizations. That is a provider-specific delivery rule. It doesn't establish that the person named on every purchase using that inbox is the same customer.

Treat other email variations the same way. If you want to compare an alias with its underlying address, verify that provider's rules first and preserve the actual address the customer supplied. Don't remove everything after a plus sign simply because you've seen that technique described online. Your matching process should work for the addresses you actually hold.

Names deserve similar restraint. You can identify potential matches despite extra spaces or different capitalization, but changing a name's spelling to make it agree is a different act. Keep the supplied name. A nickname, transliteration or changed surname can explain a difference without proving that explanation applies to these records.

At this stage, you should have possible matches to review. If the only evidence is that two strings become similar after several transformations, keep the records separate. You haven't learned more about the customers by making their details less distinctive.

Use matching clues to choose a review, not to declare certainty

A customer can change email, phone, name and address over time. Different people can share each of those details. So a rule such as same surname plus same postcode needs a clear purpose and an understanding of its weaknesses. It should identify records for review rather than automatically combine everyone in a household.

The Office for National Statistics distinguishes incorrect links from missed links in its data linkage and matching policy. It also explains that making more matches doesn't establish better matching quality. The policy governs statistical work at the ONS, not event databases, but the distinction is useful when judging your own process.

For an event business, a missed match might understate repeat purchasing or produce an unnecessary duplicate message. An incorrect match can expose someone else's order history, attach a refund to the wrong customer or combine conflicting preferences. Consider those consequences before deciding how much evidence a proposed change needs.

I'd use a cautious rule for permanent customer merges. A verified change of contact details through the source's supported account process, or an authenticated support request linking the relevant records, is much stronger than a similar name. Check that the evidence identifies the same buyer and that no contradictory information remains unexplained.

A matching phone number can support a review, but it isn't universal proof. A family can share a number, an assistant can book for several people, and old details can stop belonging to the same person. Use information you already hold for an appropriate purpose. Don't start collecting extra personal identifiers merely to strengthen a marketing report.

Give reviewers explicit outcomes. They can accept the match, reject it or leave it unresolved. Unresolved is useful when the available evidence doesn't support a decision. It prevents a guess from turning into a fact that every future report and campaign then repeats.

Work through the cases that look deceptively easy

Suppose two records both say Alex Kim and contain different email addresses. They bought the same kind of ticket in the same city. That is plausible returning-customer behavior, but it's also plausible behavior for two people with a common name. Keep them separate until stronger evidence connects them.

Now suppose the records share a household address as well. You have another clue, but still need to consider a family member with the same name. If the same address was copied from a company booking, it may identify a workplace rather than a household. Read what the field actually represents before using it as supporting evidence.

For a changed work email, ask whether there is a verified account update or an existing support record confirming the change. A message from the new address saying it belongs to the old customer isn't enough to reveal the old customer's purchases. Use the normal verification process and avoid disclosing the information you're trying to protect during that check.

For a shared inbox, preserve the distinction between reaching the mailbox and identifying the buyer. Two partners may use one address to book different events. A team inbox may receive tickets for several employees. You might send one eligible campaign message to that destination without concluding that every associated purchase belongs to one person.

An obvious-looking typo also needs a real correction route. If a buyer entered an address one character away from an existing customer's, don't silently redirect the ticket. Verify the order through the supported support process. A plausible correction could otherwise deliver purchase details to an unrelated person whose address happens to look right.

Finally, separate a transferred ticket from a changed customer. If Maya buys for Jordan and later transfers the admission, Maya remains the original purchaser. Jordan can become the holder where the source records that change. Combining their profiles would erase a useful commercial relationship and could make both purchase and attendance reports misleading.

Confirm changed addresses without making customers repeat themselves

The best opportunity to resolve a changed email is often an ordinary customer service interaction. Someone contacts you because they can't find their ticket or wants future correspondence sent elsewhere. Solve that task through your established process, and record the verified relationship when the system permits it. Don't create a separate identity investigation for every reporting ambiguity.

Your team should know which checks the provider supports and what information staff may disclose. Use a secure account process when one exists. Where support handles the change, verify the request proportionately to its consequences. Changing an account login or revealing historical orders needs more care than noting that an address bounced.

A simple reply can explain the next step without revealing another record. For example: "We can help update the email for your booking. Please use the booking support form so we can verify the request before making the change. Don't send payment card details in your reply." Adapt that wording to a real, supported route your business actually provides.

Once the request is verified, confirm what changed. If you updated only the current booking's delivery email, say that. If the source also updated an individual account's contact address, explain that separately. Don't promise that every historic order or external mailing list changed unless you've checked the supported process and its result.

A customer may deliberately keep work purchases and personal purchases separate. Ask what they want changed when their request is ambiguous. You can correct a booking without assuming permission to display their entire purchase history under one shared login. A convenient internal reporting association shouldn't create an unexpected customer-facing disclosure.

Record the verification outcome and its reference, with access limited to staff who need it. Avoid copying the whole conversation into a general spreadsheet. For an unresolved historical report, it may be better to leave the match open than contact every possible pair solely to improve your count of returning buyers.

Review a small fictional batch before changing the whole list

Let's work through a deliberately small example. River Workshops has eight customer profiles in a review batch. Each profile has one separate completed order for one $50 ticket. There are eight orders, eight tickets and $400 in ticket charges, with no refunds, fees or taxes included in this simplified calculation. These are invented records, not a customer result.

Profiles A and B belong to Maya Reed. One contains a work address, the other a personal address. An authenticated support request confirms both purchases belong to her and records her current contact choice. The reviewer approves linking those source profiles to one reporting customer. The two orders and their original delivery addresses remain traceable.

Profiles C and D belong to Jordan Ellis. The source's verified individual-account change history connects the old and new address, with no evidence of a shared account. This match is also accepted. Again, the orders remain separate. Two purchases by Jordan should become easier to see, not become one purchase.

Profiles E and F both say Alex Kim. Their similar names caused them to appear in the review batch, but the support investigation establishes that they are different buyers. The match is rejected. The reviewer records enough of the decision to stop the same pair being suggested again without a new reason.

Profiles G and H both say Riley Morgan and use different addresses. Nothing currently verifies whether they are one customer or two. Those records stay separate and the pair remains unresolved. Nobody marks them as the same buyer merely because leaving the question open makes the report less tidy.

After the two accepted matches, the report has six customer groups under the current rules. One possible pair remains unresolved. In this closed example, assuming every other identity is settled and that pair is the only uncertainty, the records represent either five or six people. Report that uncertainty rather than claiming six confirmed unique buyers.

The money hasn't changed. You still have eight orders, eight tickets and $400 in charges. If any of those totals changed solely because you associated customer profiles, stop and investigate. Matching should change which purchases you recognize as belonging to one customer; it should not remove a valid transaction.

Choose current details field by field

Once you've confirmed a match, you still have to decide what the combined view shows. Choosing the newest record wholesale can replace good information with an empty field or a temporary booking address. Prefer a field-by-field rule that follows what the information is for and where the verified update came from.

For Maya, the verified support request establishes her current contact choice. Keep that separately from the work address used for the earlier order. If finance needs the original invoice information, it should remain attached to that transaction. A current personal email doesn't rewrite what was supplied when the work purchase occurred.

Names can have different legitimate uses too. The name on an invoice, the name a person wants in an email and the named ticket holder may differ. Avoid squeezing them into one field without checking what the source supports. A merge that makes the display name consistent can still make a receipt or admission record wrong.

Missing information should not automatically erase known information. Equally, an old value should not become current merely because the newer record is blank. Keep an unknown current value where you can't establish it, while retaining necessary historical information with its date and source. That is more honest than silently choosing the most convenient version.

Define who can approve changes that affect customers directly. A reporting analyst may be able to approve a private reporting association, while account access or ticket delivery changes require the authorized support process. If the same person performs both jobs in a small business, the distinction still helps them check the consequences before clicking save.

For every accepted match, inspect the result from the customer's point of view as well as the report's. Which email receives the next booking update? What can the account holder see? Which name appears at the door? If the merge process changes any of these unexpectedly, stop using it until you understand why.

Keep marketing preferences separate from the identity decision

Confirming that two records belong to one person doesn't create permission to send marketing to both addresses. One address might have a valid subscription while the other was supplied only for booking delivery. Keep the source, purpose, channel and timing of each preference available. Don't replace them with a single yes copied from whichever profile looks more useful.

The ICO's UK guidance on planning direct marketing says to record the source of contact information, marketing consent, objections and suppression details accurately. A suppression record identifies a contact or person who should not receive specified marketing. Applying those rules requires understanding the preference's scope, rather than treating a profile merge as a new subscription.

Suppose Maya opted into workshop promotions at her work address, then later asked you to stop sending her marketing. Don't use the personal address to continue the same promotion simply because its imported field is blank. Review what she requested and preserve the objection. If the request clearly concerned all your marketing to her, changing addresses doesn't defeat it.

A narrower address-specific delivery problem is different from a person-wide objection. So is a confirmed new subscription given after a previous withdrawal. Keep the evidence and apply your provider's supported preference process. If the records conflict and you can't establish the current position, hold the promotional send for review instead of choosing yes to increase the audience.

Our guide to event email marketing consent explains the distinction between information needed for a booking and promotional choices. An operational message about an existing ticket has a different purpose from an offer for the next event. Check the content and destination even when both messages concern the same customer.

Loopyah's attendee email tools keep purchase contacts and audience selection connected, and handle opt-outs when preparing promotional sends. Use the supported audience and preference controls rather than rebuilding their work in a separate send list. That capability does not establish that two different addresses belong to the same person or that a cross-address merge is supported.

Give every proposed match a reusable review record

Your review record needs enough information to explain the decision without exposing unnecessary personal details. Use source references to retrieve restricted records when needed, rather than pasting whole booking histories into the review queue. One clear decision per proposed pair is easier to check than a note saying the customer database was cleaned.

The following is an example structure you can adapt to an authorized tool. It is a suggested working record, not a claim about fields available in any particular product. Keep the entries brief, and link to the original evidence through your normal access controls.

• Purpose: repeat-purchaser reporting for the current paid workshop season.

• Source records: system name and customer references A and B.

• Proposed relationship: both records represent Maya as the individual purchaser.

• Supporting evidence: authenticated support case confirming the two orders and address change.

• Contradictions checked: shared account, different purchaser or unexplained conflicting details.

• Decision: accepted for the stated reporting purpose, with reviewer and review date.

• Change authorized: associate both source references with one reporting customer reference.

• Protected information: order totals, ticket ownership, original transaction details and preference evidence.

• Follow-up: confirm current contact destination through the supported process if separately requested.

• Reversal: remove the reporting association using the decision reference, then regenerate affected reports.

For a rejected match, replace the change instructions with the reason the profiles stay separate. For an unresolved pair, record what evidence is missing and whether there is a practical reason to investigate now. Don't add a deadline that will automatically turn an unanswered question into an accepted match.

Record rejected pairs carefully enough that a later import doesn't keep suggesting the same mistaken relationship. New evidence can justify another review, but a different file order isn't new evidence. Where a tool allows reviewers to dismiss a suggestion, find out whether that decision survives future imports and rule changes.

If an accepted profile already contains several linked source records, review the whole group before adding another. A weak link through a shared phone number can otherwise join several different people indirectly. Every member must fit the intended customer relationship. Agreement with one part of the group doesn't settle contradictions elsewhere.

Test the consequences before applying more matches

Choose test cases that reflect the mistakes your business could make. Include a verified changed address, two different people with the same name, a shared inbox, a group booking, conflicting marketing preferences and an uncertain pair. Use approved test records where the process changes live accounts, with test messaging contained so no real customer receives an experiment.

Check both accepted and rejected outcomes. A system that catches the changed address but merges the two Alex records still fails the practical test. A system that keeps everyone separate may avoid incorrect merges while leaving your original reporting problem unsolved. Decide whether the supported process provides useful, explainable results before expanding it.

For accepted matches, compare the relevant totals before and after. Orders, tickets, charges and refunds should retain their meaning. Check that each source transaction appears once, and that an order with several tickets hasn't multiplied the customer's spend. Compare a known customer's history directly with the source rather than trusting a dashboard total alone.

Then check the destinations and permissions affected by the process. Preview a promotional audience without sending it. Confirm that an opt-out remains excluded and that a customer with no valid promotional basis hasn't become eligible. Inspect an operational booking separately so a new reporting association hasn't redirected somebody else's ticket update.

Connected systems need attention too. A correct association in one report may have no effect in another tool, or a later sync may recreate a profile you thought had disappeared. Document where the approved relationship is maintained and how other authorized systems receive it. Don't repeatedly merge live accounts to compensate for an integration you haven't understood.

Test reversal while the batch is still small. If you cannot restore the separate relationships or identify which reports need regenerating, a permanent merge may be the wrong tool for this job. A limited reporting association can be sufficient while you investigate a safer operational process with the provider.

Show what unresolved matches could change in the report

A report can be useful without pretending every identity is settled. State the rules used, the period covered and how many possible matches remain unresolved. Explain which result they affect. An uncertainty about repeat purchasing does not necessarily stop finance from reporting verified ticket charges for those orders.

Consider a separate fictional example. You have an original group of 100 verified, distinct buyers. Twenty are confirmed to have bought again during the agreed later period. Four additional later buyer records may correspond to four other, distinct people in that original group, but those links aren't verified. The original group itself has no unresolved identity issue in this example.

Your confirmed repeat-purchase rate is 20 divided by 100, or 20%. If all four pending links are confirmed, it becomes 24 divided by 100, or 24%. That possible range reflects only those four identity decisions. It does not forecast future purchases or prove that every other part of the data is complete.

Don't present the upper result as the corrected figure before reviewing the evidence. Equally, don't describe the four uncertain cases as definitely new customers. Keep them unresolved and ask whether the difference would change the decision you're making. If both outcomes support the same next step, you may be able to act while the record review continues.

If the decision depends on whether repeat purchasing reaches the higher figure, finish the relevant reviews before making that claim. You might also decide the evidence isn't recoverable and publish only confirmed repeat purchases with the limitation stated. That's preferable to using a plausible identity guess to justify a larger marketing commitment.

The same caution applies to customer spend. Once Maya's two purchases are confirmed as hers, you can associate both order amounts with her buyer history. That doesn't establish personal attendance, willingness to pay more or a reason she bought again. Use the matched history for the question it can answer and investigate the rest separately.

There is a commercial choice here as well. If you plan to offer a returning-buyer benefit, decide what evidence qualifies someone before launching it. Let customers ask you to check an earlier purchase when a changed email hides it. Don't make them create another account or buy again while you investigate a history you already hold.

For the fictional workshop, you could have support check the earlier order through its normal verification route before confirming eligibility. Record that decision against the actual offer rules. Matching alone doesn't decide whether an old refunded order, a purchase for someone else or an event outside the offer period qualifies. Those are conditions your business must set clearly.

Avoid putting an unreviewed possible match straight into a customer-facing label such as loyal regular. An incorrect label can affect a discount, access to a presale or how staff handle the customer. Check the relationship before using it for those decisions, and keep the offer conditions separate from the identity evidence.

Undo a mistaken match and correct what used it

If a customer or colleague identifies an incorrect merge, stop the affected automated actions while you investigate. Find the original source references and the decision that linked them. Don't attempt a second guess at the correct identity inside the combined profile. Establish which records belong to each person through the supported process.

A reporting association can often be corrected by separating the source references and regenerating the affected outputs, depending on your tool. A permanent operational merge may require provider assistance. Follow the documented recovery route and check the current records before each change, especially if either customer has placed new orders since the merge.

Review more than the visible name and email. Inspect order ownership, contact destinations, account access, preferences, notes and any connected records that received the mistaken relationship. Preserve valid transactions while correcting who they relate to. If information reached the wrong person, involve the responsible privacy or security colleague and follow the applicable incident process.

Then identify the reports and audiences built from the mistaken match. Recalculate the relevant buyer counts and spend, replace affected working audiences, and explain material changes to the colleagues who used the earlier result. A corrected source record won't automatically retract a report that someone already downloaded or a message already sent.

Update the matching rule or reviewer guidance if the error reveals a recurring weakness. Perhaps shared inboxes were being treated as individual accounts, or a blank field was allowed to overwrite a verified preference. Record the specific correction. Telling staff to be more careful doesn't help them recognize the same case next month.

Avoid measuring success by how many profiles disappeared. Review incorrect matches, missed confirmed relationships and unresolved work that could affect decisions. A smaller database can still be less accurate. Your aim is a customer history the team can explain, with enough recorded evidence for another colleague to check the original decision.

Reduce future duplication without asking for unnecessary data

Look at where new profiles come from before adding more matching work. A customer may be unable to update an address through the current booking route, staff may import the same list repeatedly, or a connection may ignore an existing source reference. Fix the supported process that creates the problem rather than reviewing its output indefinitely.

Tell import owners what identifies an existing record in their particular tool. Check the documented behavior for updates and new records, and inspect the result of a small approved import before applying a larger one. Keep customer matching separate from importing ticket admissions. A contact correction should never create extra tickets or send unexpected booking messages.

Don't respond by demanding dates of birth, identity documents or full postal addresses from every workshop buyer. The ICO's UK data minimisation guidance says personal data should be sufficient, relevant and limited to the purpose. It is also under review following legislative changes. Improving a marketing report alone is a poor reason to collect a much more intrusive identity record.

Limit who can inspect matching evidence and approve operational changes. Reviewers need enough information to make the decision, while most colleagues need only the resulting totals or approved customer view. Keep temporary working material only as long as its purpose requires. Our guide to attendee data retention explains how to assign those decisions rather than keeping every export forever.

Set the next review around a real reporting or operational need. After your next workshop, check whether verified address changes remain connected, rejected pairs remain separate and unresolved cases still have a clear status. If a new import changes those outcomes, investigate the import before widening the matching rules.

Start with one small batch and one purpose. Confirm the relationships you can support, preserve the purchases and preferences underneath them, and leave the rest open. You can then use the buyer history for a decision without making customers live with an identity guess your team can no longer explain.