Integrating New Email Addresses into Your Database
There may come a time in your career as an email marketer where you’ll be presented with a (legitimate) list that you need to integrate into your database; for example, your company could make an acquisition or you could be taking over marketing activities from another business unit. FierceMarkets has had a flurry of these kind of activities in the last 18 months, and we’ve developed a plan that has been successful so far. I’ll share the main points here to help with any integrations you may face.
Let me pause here and say that these integrations were not purchased emails from a list broker. In one scenario, FierceMarkets acquired a blog and took over publishing its newsletter. In another, we absorbed a newsletter from a different business unit in our parent company into our database. I am unequivocally against buying emails and adding them to your database. Buying a list and adding it to your database could have disastrous consequences that would outweigh any sort of decent response you might luck into.
The first step of a legitimate integration actually begins before moving any emails over. If there’s one thing I’ve learned through these integrations, it’s that you have to fight for a look at the data before you commit to the acquisition. A blog may have an email list of a certain number, but it could have a 15% bounce rate or a 2% open rate, or have full demographics or only emails – all good pieces of information to have before a sale is completed.
Your initial audit should also include analysis of any websites attached to the email list, but I’ll limit my discussion here to the email side.
Once you have access to the email list, give it a very thorough review. Not every blog or email list owner has grown his or her list responsibly, so it’s important to try to weed out as many of the questionable email addresses as possible before adding them to your own database. It’s also a good idea to check the original IP address for any presence on blacklists. Many smaller email lists are on shared IPs, so any blacklists may or may not have been the result of bad emails on your new list, but it at least gives you another data point on list quality.
You should also check the list for any data relating to time period of activity. Email addresses that have opened or clicked recently are presumably more engaged with the brand and are less likely to be spam traps or invalid emails.
We use the classifications from a list hygiene vendor called ImpressionWise as another data point for quality of the lists and throw out any email addresses that ImpressionWise identifies as dead or invalid.
Using the activity time period data and the ImpressionWise classifications, we separate the email list into two sections: those that we are fairly confident we can add without detriment to the existing database and those slightly more questionable email addresses, like those that haven’t interacted with the emails in a year or more, etc. We contact the more questionable email addresses separately and ask if they still want to receive the newsletter rather than uploading them directly into our database.
Before we add the first section of emails to our database, we also analyze the demographics of the list. If we have incomplete demographics, we generally try to infer information off of existing demographics to complete the record as best we can. For example, you can infer company name from email domain if folks originally signed up for the newsletter with their company email address. From that you can infer industry. If there is any IP address information in the record, you can also use that to infer country and other geographic information.
At this point, we’re just about ready to actually upload the email list. Before we move the new emails into our database, we usually send a message to the list from the existing ESP letting the subscribers know about any changes they may see as a result of the integration, even if we’re just picking up the publication where the old blog left off. You may be sending from the same “from” name and email address after the integration, but the IP address will almost certainly change, so a message like this is a perfect time to give information about whitelisting the new parameters. We also usually send a welcome email from our own system once the subscribers have been moved over onto our database.
Depending on your current send volume and the number of emails you’re adding to your database, you may want to gradually move the new email addresses onto your database so you don’t run into throttling issues. Your ESP can help you make that determination. You also may want to gradually add the new email addresses so you can monitor deliverability implications and easily roll back the additions should any problems arise. If you send a large enough volume on your current IP address(es) and the new list is relatively small, it may be fine to add all of the new email addresses to your database at one time.
If you do decide to gradually cycle the emails onto your database, there will probably be a period of time when you’re sending the newsletters from two different ESPs. This is fairly annoying but definitely doable and worth the extra work to ensure the any issues with the new email addresses don’t undo the deliverability success you’ve built up with your current database. It’s important to make sure you’re sending the correct opt-out information to each respective ESP’s list so folks can still successfully unsubscribe from whichever system is sending them the newsletter.
The last thing to do before adding the new emails to your database is to mark them with a source code so you can tie these particular email addresses back to the integration. Chances are you’ll want to be able to see how many of these folks stay on the list and how active they are to measure the ROI on the acquisition.
The work doesn’t stop once you add these email addresses to your database, however. You’ll want to monitor the emails closely on a variety of metrics to make sure everything is working as you expect. ESPs have different bounce thresholds, so check bounce rates to see who you’re losing because of bounces. Monitor blacklists to make sure you didn’t unwittingly add bad email addresses. Keep tabs on response rates to get a sense of activity level of the new email addresses. Calculate the unsubscribe rate to see how many of the new email addresses are voluntarily removing themselves. Run segments on the new email addresses to see how they compare to your existing database.
What are other best practices that others employ for migrating a list into your database? Let me know in the comments.