Constituents with multiple active emails (2016 Email best practices?)
P
Patrick Edwards
started a topic
about 7 years ago
Still new-ish to this (first post!), and still not able to identify a good solution. We are hosted RE 7.95, using IOM to maintain our MailChimp users (I'm not looking for info about the connector, yet). Complicated by the fact that we're planning for a move to BBNC (where the key limitation is: for any BBNC emails, only 1 RE email type for any constituent; only first instance of that type on the record will "send").
How are folks using Email types, DNC/Inactive, Constituent Attributes, Solicit Code and the various features of the IOM import profile to accomplish a sustainable maintenance of MailChimp Active, Unsubscribed, and Cleaned users and their email addresses (values)?
In particular, how do folks deal with the following challenges:
An Active MC user's email may change (import provides a new value, same MC ID), but a Constituent (if you've done the work to established a match) may also have a second Active MC email that cannot (because it needs to be considered one of the "Active" emails, and that constituent needs to be considered one of the "Active" constituents) be overwritten, dumped to Address attribute, etc. It just isn't always so simple as: "email value 1 is active, then gets unsubscribed" or "email value 1 is active, gets unsubscribed and replaced with email value 2". I get so far as "Active import profile backs up existing value, Unsub/Clean profile backs up new value" but I don't get past that for manual review concerns noted below.
Stacking email types (MCemail becomes MCemail1, MCemail2, etc) in the case of disagreeing values answers the "where does the email go when values disagree?" question, but it doesn't help if you need to arrive at one email type for every MC / BBNC email value. I see how a constituent record with something like "email1 (active), email 2 (inactive), email 3 (active)" [it seems a given these will be sequentially mixed up based on timing of subscribes, unsubscribes, and imports] isn't a huge problem when you look only at maintaining email list in MC. But at bare minimum I need to differentiate between emails that may be backed up to Add Attribute simply because they have a value that disagrees with the value for that email type, from those that are backed up because they are unsubscribed/clean. So how can I perform an import of Active MC users and know that the address attribute emails (or email2, email3, email4's etc...) that I need to manually review are 100% secondary active emails, not a mix of secondary active emails and unsubscribed emails or changes to active email value. Or, how can I make that review less painful? I'm aware this method of backing up disagreeing values also should also help with the huge challenge of ensuring matches (during import) of identical email values across multiple types, though I've found some Excel analysis to accomplish this isn't the end of the world.
Convinced there must be a solution. Convinced someone out there is doing something on a daily/weekly basis that isn't a maintenance nightmare. Welcome your input!!
Patrick Edwards
Still new-ish to this (first post!), and still not able to identify a good solution. We are hosted RE 7.95, using IOM to maintain our MailChimp users (I'm not looking for info about the connector, yet). Complicated by the fact that we're planning for a move to BBNC (where the key limitation is: for any BBNC emails, only 1 RE email type for any constituent; only first instance of that type on the record will "send").
How are folks using Email types, DNC/Inactive, Constituent Attributes, Solicit Code and the various features of the IOM import profile to accomplish a sustainable maintenance of MailChimp Active, Unsubscribed, and Cleaned users and their email addresses (values)?
In particular, how do folks deal with the following challenges:
An Active MC user's email may change (import provides a new value, same MC ID), but a Constituent (if you've done the work to established a match) may also have a second Active MC email that cannot (because it needs to be considered one of the "Active" emails, and that constituent needs to be considered one of the "Active" constituents) be overwritten, dumped to Address attribute, etc. It just isn't always so simple as: "email value 1 is active, then gets unsubscribed" or "email value 1 is active, gets unsubscribed and replaced with email value 2". I get so far as "Active import profile backs up existing value, Unsub/Clean profile backs up new value" but I don't get past that for manual review concerns noted below.
Stacking email types (MCemail becomes MCemail1, MCemail2, etc) in the case of disagreeing values answers the "where does the email go when values disagree?" question, but it doesn't help if you need to arrive at one email type for every MC / BBNC email value. I see how a constituent record with something like "email1 (active), email 2 (inactive), email 3 (active)" [it seems a given these will be sequentially mixed up based on timing of subscribes, unsubscribes, and imports] isn't a huge problem when you look only at maintaining email list in MC. But at bare minimum I need to differentiate between emails that may be backed up to Add Attribute simply because they have a value that disagrees with the value for that email type, from those that are backed up because they are unsubscribed/clean. So how can I perform an import of Active MC users and know that the address attribute emails (or email2, email3, email4's etc...) that I need to manually review are 100% secondary active emails, not a mix of secondary active emails and unsubscribed emails or changes to active email value. Or, how can I make that review less painful? I'm aware this method of backing up disagreeing values also should also help with the huge challenge of ensuring matches (during import) of identical email values across multiple types, though I've found some Excel analysis to accomplish this isn't the end of the world.
Convinced there must be a solution. Convinced someone out there is doing something on a daily/weekly basis that isn't a maintenance nightmare. Welcome your input!!
Patrick