Stop Paying to Mail Yourself Twice: Why Unique Identifiers Matter for Your Constituent Data
A few times a year, my wife and I receive separate but identical mailings from the same nonprofit. The organization gets points for thoroughly reaching out to all constituents. But it could cut printing and mailing costs if it recognized that we’re members of the same household who read the same mail, especially when it’s addressed to both of us.
Most fundraising databases can handle this kind of “householding,” but only if the members of the same household are properly linked in the first place. Unfortunately, there are plenty of ways members of the same household end up in a constituent database without that crucial link.
Where Duplicate and Disconnected Records Come From
Even the most careful data entry process allows mistakes like misspelled names, duplicated records with slight variations, and outdated or incorrect addresses. The problem multiples when an organization supports more than one database with constituent information. Organizations most at risk for data health issues include:
- Organizations that keep separate alumni and donor databases
- Healthcare organizations with separate patient and donor databases
- Religious denominations with national offices and regional synods
- Dioceses and congregations
- Operating foundations with regional offices
- Multi-channel fundraising programs with multiple inputs for constituent data
If these scenarios sound familiar, a unique identifier is one of the most effective tools for organizing a database—or multiple databases—with data coming in from several directions.
What Is a Unique Identifier, and How Does It Work?
A unique identifier is a code, or “key,” assigned to all name and address combinations that belong to a specific person. It links members of the same household under a shared household key, even when the organization has no idea the relationship exists.
To be useful, unique identification needs to go beyond simple name-and-address matching. It needs to work across databases of every type, scale to fit your organization’s size, and run as an ongoing process that manages past, current, and future records—not a one-time cleanup.
An Example: How One Household Becomes Six Records
Here’s how records for the same person and household can multiply over time as new gifts or interactions come in without anyone realizing the person already has a record on file:
| ID | Name | Address |
|---|---|---|
| RE1243 | Jon Smith | 908 High Top Lane, Mt. Pleasant SC 29464 |
| RE2354 | Jane Smith | 77 Secret Garden Lane, Mt. Pleasant SC 29466 |
| RE3465 | Jon and Jane Smith | 1234 Bridge Street, Charleston SC 29492 |
| RE4576 | Kohn Smith | 908 High Top Lane, Mt. Pleasant SC 29464 |
| RE5687 | Jonathan Smith | 77 Secret Garden Lane, Mt. Pleasant SC 29466 |
| RE6798 | J Smith | 77 Secret Garden Lane, Mt. Pleasant SC 29466 |
Even with a process to catch duplicates at entry, most systems won’t block a new record if the name is different enough. And if the incoming record has a different address, say, the household moved without telling the organization, it looks like a brand-new record, even though it’s the same person or household.
After unique identifiers are applied, the same data looks like this:
| ID | Name | Individual ID | Household ID |
|---|---|---|---|
| RE1243 | Jon Smith | 1457893679 | 78317445 |
| RE2354 | Jane Smith | 2983781199 | 78317445 |
| RE3465 | Jon Smith | 1457893679 | 78317445 |
| RE3465 | Jane Smith | 2983781199 | 78317445 |
| RE4576 | Kohn Smith | 1457893679 | 78317445 |
| RE5687 | Jonathan Smith | 1457893679 | 78317445 |
| RE6798 | J Smith | 1457893679 | 78317445 |
The original IDs stay on the record, but every record for Jon and Jane Smith now shares one household key, and the duplicate individual records share one individual key. Instead of seven different people, you can now see there are really just two people in one household. The original ID is what lets you map the individual and household keys back to the source records for any deduplication work that follows.
From Unique IDs to a Clean Database: Deduplication
What happens next depends on what your organization needs:
- If you support two or more databases and need to know which records in one match records in the other, you can upload the individual and household IDs into both systems.
- If you’re deduplicating a single database, or migrating multiple databases into one, a few more steps are involved.
Coding records with a unique ID won’t deduplicate a database on its own, but it lays the foundation for the most thorough deduplication possible. Best practice is to run an automated duplicate-pairing service that matches on the unique ID, so records can be flagged for merging. In our experience, this combined approach finds as many as 43% more duplicates than a simple name-and-address deduplication process alone.
Make It an Ongoing Process, Not a One-Time Fix
This isn’t a once-and-done project. Files should be uniquely identified on an incremental basis as your database grows. Many organizations run this process quarterly, and more often during periods of heavy donor acquisition or high donation activity, like the year-end giving season. Running it on a regular cadence is the only way to keep record duplication under control before it snowballs.
The Payoff
Controlling duplication in your constituent records saves money on solicitations and print costs. Just as important, it keeps you from looking out of touch with the very supporters you’re trying to build a relationship with.
