Constituents with no name information
In my 4 years at my organization I have been staunch in not allowing unusable data to be added to the database - if we didn't have at least a first initial and last name we were not adding random email addresses to Raiser's Edge. However we've now grown to the point where we would like to get as many individuals signed up for our email newsletters as possible, and this may include people who only provide their email and not a first or last name. I'm looking for advice on best practices for capturing email addresses when the constituent doesn't provide their name. For background, we capture email signups via a survey in Luminate Online and are transitioning from RELO to ImportOmatic for our connection to Raiser's Edge 7/NXT. We also have a large number of users already in LO that have emails but no names (long story, we recently went through a merger and what we did was definitely not a best practice ?).
Is it standard practice to have these emails in LO but not as constituents in RE? Under that scenario we would still run the emails against the database to match up any possible duplicates as they come in, and if the email address includes an obvious name (ie john.smith@company.com) we would add that information in manually. Appreciate any insight!
Is it standard practice to have these emails in LO but not as constituents in RE? Under that scenario we would still run the emails against the database to match up any possible duplicates as they come in, and if the email address includes an obvious name (ie john.smith@company.com) we would add that information in manually. Appreciate any insight!
Tagged:
2
Comments
-
I am of the belief that data shouldn't be entered into the database unless it is both complete and actionable. While I would argue that initials and emails might fall under the banner of actionable, I don't think many people would believe them to be complete. Your foresight is quite keen, as I believe this practice would be almost impossible to manage when it comes to duplicate records. Simply put, you'd have one verified unique trait on the record, and that trait isn't even an one-to-one trait. If a person has a duplicate record and uses another email address you'll never be able to accurately know if they can be merged.
I'd also question if the email address you're getting is a main address, or if it is a secondary or a trash account. Especially if they are not entering a name.8 -
Hi Kevin Schaeffer - I second what Dariel has said. Additionally, I would be very weary of a stance that promotes quantity over quality - "We would like to get as many individuals signed up for our email newsletters as possible." What happens when all those extra emails do not engage with your newsletters? Check out this article from sgEngage for more information on the impact this could potentially have on your Org's email deliverability. If your Org chooses to move forward with the plan to boost their recipient list numbers, make sure you have recurring process in place to remove constituents from your recipient list that are not engaging with your Org's emails.
5 -
I agree with what seems to be the general consensus here. I would definitely not advocate putting these emails into RE. Largely for the reasons Dariel outlined - duplicate management will be impossible, and they'll just become junk in a couple of years. If those emails do correlate to an actual record in your database, and that person is relatively engaged with the newsletter, you'd never know it was one of your existing constituents. It sounds like you already know all this, though, so I'm just throwing another vote out there. I would use an external service to manage those orphan email addresses, and maybe compare them to your RE database periodically to see if there are matches with existing constituent records, and whether any of them can be merged into the main system.
I'm curious how you're handling communication preferences/opt-outs for these? I am not familiar with LO, so maybe that's the answer, but do you cross-check the external email list from LO against communication preferences in RE in the event that that email address does exist there on a legitimate constit record and contains a "Do Not Contact" or something to that effect? Does LO have its own preferences/opt out management?
This sounds like a bit of a headache to manage...you have my sympathy. ?0 -
Discussion moved to Raiser's Edge Community forums. Thanks!0
-
Running into a similar situation here. I created a record "Newsletter Emails" and load all the emails into that record. It is exportable and I can manage opt-out's as well.0
Categories
- All Categories
- 6 Blackbaud Community Help
- 206 bbcon®
- 1.4K Blackbaud Altru®
- 394 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 1.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- 15 donorCentrics®
- 358 Blackbaud eTapestry®
- 2.5K Blackbaud Financial Edge NXT®
- 646 Blackbaud Grantmaking™
- 562 Blackbaud Education Management Solutions for Higher Education
- 3.2K Blackbaud Education Management Solutions for K-12 Schools
- 934 Blackbaud Luminate Online® and Blackbaud TeamRaiser®
- 84 JustGiving® from Blackbaud®
- 6.4K Blackbaud Raiser's Edge NXT®
- 3.6K SKY Developer
- 242 ResearchPoint™
- 118 Blackbaud Tuition Management™
- 165 Organizational Best Practices
- 238 The Tap (Just for Fun)
- 33 Blackbaud Community Challenges
- 28 PowerUp Challenges
- 3 (Open) Raiser's Edge NXT PowerUp Challenge: Product Update Briefing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports+
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Email Marketing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Gift Management
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Event Management
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Home Page
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Query
- 779 Community News
- 2.9K Jobs Board
- 53 Blackbaud SKY® Reporting Announcements
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)





