data-driven email

If you’re reading this post, I’m pretty sure I don’t need to explain to you why email is an ideal channel for conducting commerce, marketing products and ideas, and more. In fact, I’m willing to bet that email is a fundamental part of how you do business. So, go ahead—send some of that mission-critical, data-driven email. I’ll just wait for you here.

Oh, wait. You mean, it’s more than simply pressing that big green “send” button? Syncing business data up with your ESP is, let’s say, complicated? Yeah, I hear you. You’ve kludged in some mechanisms to generate data files for account and CRM data, transaction data, shipment data, abandoned cart data, product data, loyalty data, and more. And as for getting that data into your ESP? Well, the integration between an ESP and your own internal systems typically involves tedious, brittle mechanisms such as FTP to upload all of that information.

On top of that, core email functions like message injection, reporting, unsubscribing, and templates aren’t programmatically accessible in real-time at most ESPs. That means manual updates and still more data duplication: sends, bounces, clicks, and more. So round-tripping data? Fuhgeddaboudit.

And, as for security around all that data, well… all we have to do is look at the news and see who’s been hacked this week. After working in the security business for 10 years, I’m enough of a realist to know that putting duplicate copies of your core customer data up on someone else’s servers doesn’t make the problem better.

Now, none of this is to say ESPs don’t care about your business or the integrity of your data. Of course they do, but their systems weren’t built for how we use data-driven email today. They were architected for delivering relatively static marketing messages, not for real-time transactions such as password resets, login notifications, triggered commerce flows, guided user onboarding, and more.

What if you took an API-centric approach to generating and delivering email, instead? Your business systems already are the system of record, so let them, not a redundant workflow at an ESP, handle the business logic. Your systems can identify which customer has triggered what action, and simply call a service (via a straightforward REST API, natch) to generate that specific email message right when it’s needed, not in a batched queue for offline processing.

By taking this direct send approach, no business logic needs to be built within the confines of your ESP, nor does the data need to be synced beforehand. That adds up to real-time delivery with a lot less hassle. And, by the way, since your email delivery service is now a triggered service, they no longer need access to all that sensitive business data or retain your customer’s personally identifying information (PII). That might lessen your security concerns, too.

None of this is automagical—you would need to build the right event- or state-based triggers into your business systems. But isn’t it better to have them in your own systems (where they can be reused for multiple purposes) then to build them out-of-phase at an ESP? These sorts of triggers are core to your business process flow. Treat them as such.

Today’s personalized, data-driven email is frankly far more complex than most ESPs were designed to handle. The hassles of synchronizing business logic and data for triggered sends at an ESP make that challenge clear.

So, maybe it’s time to take a step back and see if relying on your strategic business systems to handle the logic, and using API-driven approaches for personalized, triggered, and transactional email delivery is a better choice. Sure, for old school email marketing or soup-to-nuts campaign management, ESPs can give a lot of value. But for data-driven email, there’s a better way. Don’t let your ESP hold you back.


If you like this post, be sure to check out Getting to a Segment of One (Data-Driven Marketing Series, Part 1)

9 Things ISPs Really Want Email Marketers to Know