Email List Management in Raiser's Edge

Danielle Allen 2

Hello,



We are about to migrate to Online Express and have been using a 3rd party app (Constant Contact) for emails. We are starting to import everything in to RE from Constant Contact but I can't find any best practices or information about the best way to manage email lists in RE. 



We have dozens of segmented lists in Constant Contact and I think the best way to capture them in RE is to use Attributes. A constituent will have an Email List Attribute for each list we have them on in Constant Contact. Then we can query which lists we want to email to. Does this make sense? Should we be using something else for email list management?



Thanks!

Carolyn Moatz

Unless there's something else about each person on their record that will allow you to pull the lists separately, an attribute is probably your best bet. We use Constant Contact, and do not use attributes to track email lists, but our email lists are based on their relationship with our school (alumni, parent, grandparent, etc., and tracked in constituent code), where they live (which we track in region), and giving, so we can pull lists easily through that. Sometimes things get more specific, but it's still something we can pull out of RE easily.



Depending on what your email lists are, it might be good to track them as interests rather than just email lists, if you want to be able to do something broader with them later, and include people you don't email in the same group.

Jen Claudy

We moved from Constant Contact to Online Express back in September.  However, most of our CC lists were created by exports from RE and had the RE Constituent ID as a CC Custom Field.  That helped tremendously.



OLX lists are created from RE Queries, and you can include multiple queries in one OLX list.  OLX will automatically dedupe for you, just like CC does (so if one email address appears in 4 of 5 queries that make up one OLX list, that address will only receive the message once).  One really great feature is that after you've sent the message, you can push the data from OLX to RE and all of those records will then have an Appeal tag showing what address the message was sent to as well as the furthest action (Received, Opened, Bounced, Opted-Out, Clicked, Donated) that was taken.



I suggest that you use Attributes only for situations where either the data won't be changing or there is no other way to pull that group of records together.  So if it's a query of recent donors, do that in its own query using Gift data, rather than assigning an Attribute that then must be updated periodically.  A query based on Gift data, if done correctly, can update itself every time you send a message.  If it makes sense to use a Constituent Code for something (i.e. Employee or Board Member) then use that instead of an Attribute and build that query on the Const Code rather than the Attribute.  Don't duplicate with Attributes data that is already available in your database via something else...but beyond that, Attribute probably is your best route when there is no other obvious place.



Also, when you are moving data from CC to OLX/RE, be sure to also move Unsubscribed email addresses!  We created a new Email/Phone Type for those, so that they are never included in OLX email lists.  Don't want to start sending to someone who has an email already existing in RE but unsubscribed in CC at some point in the past!  (Aggravating, plus, I think, illegal.)  This also provides an easy way to unsubscribe someone on your end.  I did that this morning.  Someone replied to an eNewsletter asking to be unsubscribed (rather than clicking the Unsubscribe link at the bottom of the email message), and I left the email in RE but changed the Phone Type from "eHome" to "XeHome" to prevent OLX from pulling that address in the future...and also to prevent well-meaning staff from adding his email address back onto his record without realizing it had been deleted for a reason.  (My basic rule is to never delete data from the database...at least not addresses and email addresses.)

Paul Morriss

We use a single email attribute "email subscription" to feed almost all of our email lists. Obviously a person can have more than one of these attributes.

Sevana Keshishian

Jennifer Claudy:

We moved from Constant Contact to Online Express back in September.  However, most of our CC lists were created by exports from RE and had the RE Constituent ID as a CC Custom Field.  That helped tremendously.


OLX lists are created from RE Queries, and you can include multiple queries in one OLX list.  OLX will automatically dedupe for you, just like CC does (so if one email address appears in 4 of 5 queries that make up one OLX list, that address will only receive the message once).  One really great feature is that after you've sent the message, you can push the data from OLX to RE and all of those records will then have an Appeal tag showing what address the message was sent to as well as the furthest action (Received, Opened, Bounced, Opted-Out, Clicked, Donated) that was taken.


I suggest that you use Attributes only for situations where either the data won't be changing or there is no other way to pull that group of records together.  So if it's a query of recent donors, do that in its own query using Gift data, rather than assigning an Attribute that then must be updated periodically.  A query based on Gift data, if done correctly, can update itself every time you send a message.  If it makes sense to use a Constituent Code for something (i.e. Employee or Board Member) then use that instead of an Attribute and build that query on the Const Code rather than the Attribute.  Don't duplicate with Attributes data that is already available in your database via something else...but beyond that, Attribute probably is your best route when there is no other obvious place.


Also, when you are moving data from CC to OLX/RE, be sure to also move Unsubscribed email addresses!  We created a new Email/Phone Type for those, so that they are never included in OLX email lists.  Don't want to start sending to someone who has an email already existing in RE but unsubscribed in CC at some point in the past!  (Aggravating, plus, I think, illegal.)  This also provides an easy way to unsubscribe someone on your end.  I did that this morning.  Someone replied to an eNewsletter asking to be unsubscribed (rather than clicking the Unsubscribe link at the bottom of the email message), and I left the email in RE but changed the Phone Type from "eHome" to "XeHome" to prevent OLX from pulling that address in the future...and also to prevent well-meaning staff from adding his email address back onto his record without realizing it had been deleted for a reason.  (My basic rule is to never delete data from the database...at least not addresses and email addresses.)

Jennifer,


Thank you so much for your comprehensive response. We are thinkig of migrating from CC to OLX. I was wondering what is the best way of bringing CC contacts into RE as constituents. While we also have used the custome field for the Cn ID in CC, (not for all imports though!) I have a lot of non-constituent contacts in Online express that have signed up or have been imprted from a different source. I uderstand that I will end up creating constituent record with just first, last and email address for them. But what do you suggest to avoid creating duplicates in RE, and still capturing everyone in OLX?

Thank you,

Sevana

Jen Claudy

Sevana,


If you know how to use MS Access or maybe Excel VLOOKUP (I'm not as familiar with that function), you can probably find most of the possible duplicates.  You'll probably still end up with some of them.  I know we did.  Especially if it's a common name and the record in RE does not have an email address...no way to know for sure.  However, if they make a donation, we'll get the street address, and will then look up the name and address in RE to see if there's a dupe.


Another thing I've done (because we have a lot of duplicates from another problem, not related to OLX), is to create a Relationship Type of "POSSIBLE DUPLICATE" and when I think I might have duplicate records but can't be certain, I link them with that Relationship/Reciprical Type.  That way, if I come across other information for one, I can immediately notice a possible duplicate and see if this new info resolves that issue one way or the other.


This is the biggest reason that I would really love to see a Zip Code Field available in the OLX Email Sign Up Form.  It would help in preventing duplicates with new sign-ups.


We do have a subscription to LexisNexis (it's pricey, though) and that helps because I can look up the person with the address, and then see possible email addresses.  But it's all manual.


Hope this helps...let me know if you want more information/specifics.

Sevana Keshishian

Thank you , this is very helpful! I am familiar with Vlookup function. So correct me if I'm wrong, I would dedupe the CC list with the RE list in excfel, and then import the non-duplicates in RE? I imagine, the RE list should incluede all non-constituent relatioships. Correct?


I didn't even think about managing the new sign ups after migratign to OLX! I was only worrying about correctly adding new non-duplicate constituents in RE before starting to use OLX. I'm not quite sure how the new sign ups will work, probably cause I have not worked with OLX. Can you just give me an idea about how they work? 


My follow up question would be, do you think OLX has added more value to your email campaigns? What woudl you say is (are) the biggest value in using OLX vs. staying with CC. I have some people that I will need to sell the idea to. Eventhough we are using RE NXT for 9 months now, we haven't utilized OLX becasue of the resistance to change, and honestly people are happy with CC.


Thank you!