Inactive subscribers: exclude group or unsubscribe them?

Options
I'm curious to get people's thoughts about how to handle inactive subscribers in LO after sending them a re-engagement email: put them in an exclusion group, or unsubscribe them from all email?


It seems to me that the best way to go about it would be to send them a reengagement email, and then the ones who don't open or reply would be unsubscribed. However, from this thread, it sounds like LO recommends putting inactive subscribers into a group which are then excluded from most of your emails.


The exclusion group technique is the one that my org is currently using, but our deliverability has taken a huge hit since creating it, which I'm thinking is because it's not getting excluded from all lists. Now, the obvious answer to that is to exclude it from all lists, but we're dealing with a number of different people sending from LO, so sends are still creeping through.


Thoughts? Has anyone unsubscribed inactive users and either regretted it or realized it was the right decision?
Tagged:

Comments

  • I wouldn't unsubscribe them mostly because there really isn't a way to distinguish between those and real opt-outs done by constituents.  I'm not sure what your criteria is for "inactive subscribers" (haven't opened an email in a long time?) but, for example, what happens if an inactive subscriber donates and you want to add them back onto your email list?  How would you know if they were opted-out as an inactive subscriber or that they opted-out on their own?  If they opted-out on their own you shouldn't opt them back in when they donate.  If you use an exclusion group you could remove them from the group regardless of their "Accepts email" status.  

     
  • We exclude ours from almost all appeals, but include them on many stewardship emails and some strong engagement appeals - typically during the holidays or an emergency.  Attached is a simple query Convio did for us about a decade ago and still seems to work well.
  • Great question, Reid. This is something I've been thinking about too, and would love input from others who have or have not done this kind of email list "purge."

     
  • Great question, Reid. This is something I've been thinking about too, and would love input from others who have or have not done this kind of email list "purge."

    I recently just did the 'purge' earlier this month. Setting up the tasks and queries as per the instructions BlackBaud gives was quite easy to do. I'm glad that it continues to run each day so it's fairly seamless.


    We sent the group an email saying:

    We are doing a little bit of spring cleaning and we noticed some emails in our system that have been collecting dust!

    Since you have opened this letter, our system will keep your EMAIL_ADDRESS email in our list of subscribers.

    You can update your personal information and subscription settings by clicking here.

    If you no longer wish to receive emails from us, you may unsubscribe at any time.

    As always, if you have any questions, please do not hesitate to contact us.

    We had 8% of the people open it (cool!), 47 people updated their profiles (yay!), 323 opted out (bye!)


    The next week we sent an email, removing all of those who are in the 'disengaged group'. It cut our target audience in half -- however, our new approach prooved fruitful as we had 60% of the audience open the message! So yes, we lost a lot of people, but they werent opening our emails anyways so good ridance. :)


  • The next week we sent an email, removing all of those who are in the 'disengaged group'. It cut our target audience in half -- however, our new approach prooved fruitful as we had 60% of the audience open the message! So yes, we lost a lot of people, but they werent opening our emails anyways so good ridance. :)
    Thanks, Megan! Just to be clear, did you opt-out all of those users out of email or remove them entirely from your system? And did you notice a change in your deliverability?

  • My methodology is to opt them out for two reasons. First, many organizations don't need more groups that they need to remember to exclude. If someone accidentally includes them, the results are far too damaging to risk it. 


    Second, there is always the hope that in time these folks will come back by taking an action. If they continue to be suppressed b/c they don't open, they'll be in a loophole they can't get themselves out of. Take for example an animal welfare org...they get a lot of signups by people in the market to adopt a pet. After a constituent adopts a pet, they might not want any more updates until such time they are ready for another pet. They might not open and get themselves into a suppression list that they cannot escape. 


    Similar loophole could even plague you from a simple data hygiene perspective. Someone gets a new job and their old job doesn't deactivate their account so they keep getting sent messages that aren't opened. They end up on a suppression list. Then, they resubscribe with their new email address and the duplicate is resolved. But, they continue to be suppressed b/c they are still being pulled into a disengaged group. 


    Just a few thoughts I've been juggling. Good luck and great to see you, Reid!! ?
  • We use an exclusion group but it's dynamic, based on last action date. So if someone falls into it because they haven't taken an action in x amount of months, then they take an action alert or make a donation or something else, they automatically fall off the exclusion list.


    Kim
  • Kim Ethridge‍ , thanks so much! Would you please share a little more about how you set up that up? I'd like to check it out. Are you using a Website Engagement Segmentation task and then combining it with a query (or several queries)? 
  • Nice to see so many familiar faces on this string (Reid! Rachael!)


    We used a suppression group for YEARS and are now moving to opting them out of email, to avoid the potential of human error. We have too many suppression groups as it is with every email deployment.


    And, to make it easy to track when/why we forced the opt out, I'll be employing two database fields - a custom_date field to enter the date we opt them out and a custom_string to enter the reason. Unfortunately, I believe doing this requires a manual process - first to run the group who is eligible to be opted out and then second preparing/uploading the file to update these two fields.
  • One thing to consider is that you pay for LO partially by how many emailable constituents you have. If they are opted in, even though they are in a suppression group, they are still contributing to your Blackbaud fee.


    BPM
  • Brian, that is a good point. So is there a downside to removing the email completely? We are connected to Raisers Edge so we can retain the record (though removing a record from RE altogether is being considered because we're about to hit a list size threshold). We also use a suppression list but do occasionally send to this list if we have a high profile action and hope to re-engage some folks. I'm not crazy about the idea of opting someone out and not knowing if this was a real opt-out or not. 
  • There is a secondary email field in cons records that you can get activated, or you can turn it on yourself if you have Database Config access.


    This field really has no functionality as far as LO email is concerned, so you could move their email address from the primary to the secondary email field. That way you could keep your records, and your addresses and still have them not affect your billing.


    You'd have to do that manually, or with a custom cons import.


    EDIT: And regarding your RE limit... I'm not an RE guy, but I know we have a lot of records in RE that are not full-blown constituent records. Check out "non-constituents" (non-cons) - the application is called List Management, but most people say container.


    BPM
  • That's interesting! So the secondary email will not be used by Luminate if the primary email field is empty? We already have this field enabled but I was not entirely sure if Luminate would use it if the primary bounced or is empty. 
  • 'No functionality' isn't quite right, but it doesn't work like a fail-over as we're both hoping. But you can send to both the primary and secondary.

    https://kb.blackbaud.com/articles/Article/72417


    But that means you will be sending to both for your entire target list.


    BPM


     

Categories