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. However, the organization could eliminate the duplication of printing and mailing costs if it could act on the fact that we are members of the same household and read the same mail, especially when it’s addressed to both of us. Most fundraising databases can manage the process of “householding” records – if the members of the same household are properly linked. Unfortunately, there are plenty of ways that members of the same household can be added to a constituent database without that crucial linkage.
Even the most careful data entry process can sometimes allow mistakes like the following: misspelled names, duplicated records with variations on the name or different addresses, and just plain bad addresses. When an organization supports multiple databases with constituent information, the problem can escalate. 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 that have multiple inputs for constituent data
Do any of these scenarios sound familiar? If so, utilizing a unique identifier is the perfect solution to help you organize any database –or databases – with multi-faceted inputs.
How does it work? An individual “key” can be assigned to all name and address combinations that pertain to a specific person. A unique identifier will link members of the same household with the same household key, even in instances where the organization is unaware that the relationship exists.
Unique identification needs to go beyond name and address for constituent matching. It needs to work across databases of all types and be scalable to fit any organization’s needs. Further, it must be set up as an on-going process to manage past, current and future records.
Below are some examples of how records for the same person and household might multiply in a database over time as new gifts or interactions are entered without knowing that the person already has a record:
| 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 if you have a process to catch duplicate records during data entry, the system will usually not prevent you from adding a new record if the entered name is different enough. If the incoming record has a different address – because the household has moved without notifying the organization – it looks to the database like a new record, even though it is for the same person or household.
After the unique identifiers have been applied, you get an output like this:
| ID | Name | Individual ID | Household ID |
| RE1243 | Jon Smith | 145789367 | 978317445 |
| RE2354 | Jane Smith | 298378119 | 978317445 |
| RE3465 | Jon Smith | 145789367 | 978317445 |
| RE3465 | Jane Smith | 298378119 | 978317445 |
| RE4576 | Kohn Smith | 145789367 | 978317445 |
| RE5687 | Jonathan Smith | 145789367 | 978317445 |
| RE6798 | J Smith | 145789367 | 978317445 |
Note that the original IDs are still part of the record, but all records for Jon and Jane Smith now share a single household key and the duplicate individual records are identified with a common key. Instead of seven different individuals, we now see that there are two individuals in one household. The retention of the original ID is important for mapping the individual and household keys back to the original records, and for any deduplication that might follow.
What happens next depends on the needs of the organization. If your organization supports two or more databases and needs to be able to know which records in one are the same as the records in the other, you can upload the individual and household IDs to the records in both systems. If, on the other hand, you intend to use this as a method of deduplication within a single database, or to migrate more than one database into a unified database, some added steps are necessary. Coding records with a unique ID will not deduplicate a database on its own, but it lays the foundation for the most thorough deduplication possible. Best practice is for an organization to use an automated duplicate pairing service that matches on the unique ID so that records can be identified for merging. In fact, we’ve seen that using this combined process can find as many as 43% more duplicates than a simple name and address deduplication process.
Lastly, to set yourself up for success, this is not a once-and-done process. Rather, files should be uniquely identified on an incremental basis as your database grows. I typically recommend This is the only way to assure that you can control the duplication of records as early as possible, especially during times of heavy donor acquisition or increased donation activity such as the holiday season.
The benefits of controlling duplication of constituent records include, at the very least, a cost savings for solicitations and avoiding giving an impression of incompetence to the recipients of your mailings.
from npENGAGE https://ift.tt/2EUt2cX
0 comments:
Post a Comment