Welcome to Luminate Ideas!

Would you want to surface a message to a donor that they can identify themselves as related to but not the donor on the form?
No, because adding complexity to the form may cause more abandonments, which means losing money.

Or if they change the name information would you want the result to create a whole new record for the spouse and then link them together relationally?
Yes, as long as we can catch it in the de-dupe report. Some records we will want to merge (e.g. spouses using the same email address and mailing address), and others we won’t. Although this may add more volume to our de-dupe process, it’s probably cheaper than adding complexity to our donation form.

Thanks,
Kerry

[Eagle302_874NoTag Small.jpg]

Kerry Meyers
Chief Development Officer
Direct Marketing, Development
T: 404-420-5190
kerry.meyers@cartercenter.org
www.cartercenter.org

[Subscribe][Twitter][Facebook][YouTube][Pinterest][Google+][Instagram]

Waging Peace. Fighting Disease. Building Hope.
A not-for-profit, nongovernmental organization, The Carter Center has helped to improve life for people in more than 80 countries by resolving conflicts; advancing democracy, human rights, and economic opportunity; preventing diseases; and improving mental health care. The Carter Center was founded in 1982 by former U.S. President Jimmy Carter and former First Lady Rosalynn Carter, in partnership with Emory University, to advance peace and health worldwide.

Ken, I appreciate the prompt feedback. The scenario that you put forward is not representative of how I experience this problem with LO though I do appreciate this challenge. My suggestion in this instance would be that only if e-mail + lastname+firstname is the same should we match to existing records otherwise a new record should be created.

The way that I am experiencing this is interfacing RE 7.96 with LO. When I try to synch new RE constituents with LO my developer tells me that e-mail address is the only matching field that the LO API uses. The result is that when a spouse, family member, work colleague.... of an existing supporter comes in to our RE database, matching on e-mail address only will result in the new name overwriting the existing. Again, to my mind, it would be best to use a combination of e-mail+ lastname + firstname to match.

Just to say too that we can't assume a spouse connection here. We just need to treat them as separate records.

Hope this is helpful.

No features on the roadmap as of yet but it continues to be discussed. 

Related I am talking about it internally this week at a high level with some folks as related to developing next gen donation forms. How would you expect this to work with autologins from emails? So if we had 1 of the two spouses in the database because they were the ones who have given before and we send an email to that person with a link to a donation form which is prepopulated with their information. Would you want to surface a message to a donor that they can identify themselves as related to but not the donor on the form? Or if they change the the name information would you want the result to create a whole new record for the spouse and then link them together relationally? 

I'll take your input directly to this meeting to represent directionally where you would like to see this go. It's not a roadmap planning meeting but it would inform how we think about and plan to solve this better in the future. 

Thanks,

Ken

This issue was identified in May of 2015 and in March of 2019 we seem to be no further ahead as we are fighting with the same issues today.

Has any change been made to address this issue?

yes, we have the exact same problem with a wife and husband making diff donations, using diff credit cards but the donation transaction gets recording to the husband's constituent record because they didn't bother to log out. We also had another problem before with multiple donations made by different individuals (all with different addresses and credit card info) all went into the same constituent record because he was not logged out. I'm wondering how to eliminate problems like this from happening? what's the best practice for the rest of the organizations that's facing this problem too? it's either having many duplicates or getting transaction records into the wrong constituent...

Thanks for everyones input here. I'll pass along to the PM who is working on this for next gen and they may follow up with additional questions!

Ken

I'm an experienced CLO client and this is the way I would handle this:

1. Make two records (one for the wife, one for the husband) in your CRM (in our case it's Raiser's Edge). Link the two records as a spouse relationship. Both records will have the same email.

2. In Convio, do the same thing. Enter those two records separately. One unique ID for the wife and another unique ID for the husband. Both records will have the same email though. Email duplication across separate records is possible in CLO.

Just remember CLO is not intended to be a full-fledged CRM solution and it'll save you frustration.

Good luck,

Kerry

Its my understanding there is a site option that can be updated to allow for different users to "share" an email address. Its not a site option a client can set.

Ask about this Site Option / SDP
USER_ENFORCE_UNIQUE_EMAIL

However, there is some risk associated with making this change. But we have seen this make Duplicate Management a challenge and I can't fully recommend it.

So those types of transactions don't go to Duplicate Management for the client?

Other related Site Options

CAL_ENFORCE_UNIQUE_EMAIL: FALSE (Calendar Event registrations, recommendation: FALSE)

ECARD_ENFORCE_UNIQUE_EMAIL: FALSE (E-Card registrations, recommendation: same as USER_ENFORCE_UNIQUE_EMAIL)

F2F_ENFORCE_UNIQUE_EMAIL: FALSE (TeamRaiser registrations, recommendation: keep FALSE)

TRIBUTES_ENFORCE_UNIQUE_EMAIL: FALSE (Personal Fundraising registrations, recommendation: FALSE)

Maybe it could be something along the lines of the household concept. Like there could be a shared household email option and at entry the system would evaluate on email and first name. If it was the same email but a different first name, it would create a separate contact on the household. If it was the same email and same first name, it would update the record. If it could be something a client could opt into or not - using a shared household email. If there was a household email in place it could be used to send a single email with multiple names. I'd be happy to connect you to the client that presented this challenge (UUSC) for any further discovery insights.

This is the default because Luminate is an email marketing system designed around the idea that 1 email = 1 person/target which is the most accurate and industry standard way of uniquely identifying users online. Optimally I think we want the system to continue to work this way because you can more accurately target end users with personalized messaging because your data on their interactions is tied to that one static value which is their email address. 

However, with that being said, I know it comes up that some constituents do share one email account so I am interested in hearing from our users how they might expect a system which allows end users to share email addresses would work. There may be ideas and ways of doing this we can incorporate which we haven't thought of.

Thanks for submitting your idea!

Ken