How event and purchased lists create CRM duplicates

The event is over, and you have a spreadsheet of badge scans. Marketing bought a list of prospects in a new region. A sponsor sent its attendee export.

Everyone wants these people in the CRM by Monday, and lists like these are an easy way to bring duplicates in. Many of the people are already in your CRM, the files overlap, and the formats rarely match yours.

In this post, you'll see why these lists create duplicates and what to decide before you import one. You'll also see when to check them, before and after import.

Why event and purchased lists bring duplicates

The same people are already in your CRM

Your best prospects tend to show up everywhere. The person who visits your booth may have downloaded a guide last month and talked to a rep last year.

A purchased list for your market will also include companies and people you already know. Import it as is, and each of them can arrive as a second record.

Lists from several sources overlap

One event can produce several files: registrations, badge scans, session check-ins and a sponsor's export. A purchased list can overlap with the one you bought last year.

The same person appears in two or three of these files, often with slight differences. Import them one after another, and each file can add its own record.

The formats don't match yours

Every source has its own layout. Full names sit in one column, and phone numbers come with or without country codes. Some rows have a personal email, or none at all.

Each of these can stop an import from recognizing a record that already exists.

Lists often go in without a review

Lists usually arrive with a deadline. Reps want to follow up while the event is fresh, so the file often goes straight in. Without a review, every problem above can turn into duplicates.

Some event data never becomes a file

Event apps and badge scanners can sync leads straight into the CRM. There's no spreadsheet to clean first, so each scan creates or updates a record as it arrives.

If a scanned person has a different email from the one in your CRM, the sync can create a second record. For these sources, the check happens in the CRM, soon after the event.

Decide what counts as a duplicate for this list

Before cleaning, agree on what makes two rows, or a row and a record, the same person. That's case by case. What one team considers a duplicate, another may not.

A few examples come up with lists:

• Work and personal email: the same name and company with a gmail.com address may be one person, or a namesake.
• Colleagues at one company: two people at the same company are different people, even with the same domain.
• Shared registrations: an assistant who registers several people from info@ creates rows that share an email but belong to different people.

Start with the obvious duplicates, usually exact matches on email. Then look at name with company for the rows without one.

Clean the list against itself before import

Cleaning a file before import is easier than cleaning a CRM. Nothing depends on the rows yet, and no workflows, owners or sequences run on them.

Find the duplicates inside the file first. If you combined several files, like registrations and badge scans, this is where much of the overlap shows up.

Keep one row per person, and decide which row wins for each field. A badge scan may have the better phone number, and the registration the better job title. Fix the formats too, so names, phones and countries look like the rest of your data.

Decide which values the list may change

A list shouldn't overwrite what your team knows. Owner, lifecycle stage and email opt-out deserve the most care. Purchased data can also be older than what's in your CRM.

A common choice is to let the list fill empty fields but not replace existing values. Your team may choose differently for fields like job title, where the event data is newer.

Import on the field that identifies each record

Many CRMs use a field like email to decide whether an imported row updates an existing record or creates a new one. Rows without that field often become new records.

HubSpot, for example, matches imported contacts by email and companies by domain. Contacts without an email or another identifying value are imported as new records.

As of October 2026, from HubSpot's knowledge base: Deduplication of records.

That's why rows with no email are where list duplicates tend to come from. Decide before import what happens to them, or send them for review before they go in.

Check against your CRM after the import

Once the list is in, your CRM is where it meets the records you already have. Search the records from the new list against existing contacts and companies, by email first, then name with company.

Do it soon after import, before reps start calling and owners get assigned. Merging a duplicate is easier while nobody has worked the new record yet.

If you import lists often, duplicates from each one add to the next. A quick check after every import keeps them small. For duplicates from sources that run all the time, see how to manage recurring duplicates from CRM integrations.

What to decide for every list

Treat every list as a cleanup job

Event and purchased lists bring people you already know, files that overlap and formats that don't match yours. Imported without a review, each of those can become a duplicate in your CRM.

Cleaning the list against itself, with clear choices about which values it may change, keeps many of them out. A search in your CRM soon after import catches the rest, before anyone works the new records.

Frequently asked questions