Should Relational Database Support Be One of Your Criteria When Choosing an ESP?

If you’re doing an email service provider comparison, you might have noticed ESPs tend to fall into three categories: those for SMBs, the mid market, and the top-tier (or enterprise level) ESPs. Obviously, a Fortune 500 company doing enterprise email marketing wouldn’t use an ESP that exists to serve the corner espresso stand. Nor should that coffee place be investing top dollar in the powerful platform of a top-tier ESP.

Someone doing enterprise email marketing probably already knows they need a top-tier ESP. Someone running a tiny business with a tiny list probably already knows they don’t.

The biggest differentiator between enterprise-level ESP and mid-market

But there is a middle ground nowadays between mid market and top-tier, and that’s where things can get a little more interesting when in the market for a new ESP. Here’s why: If there’s one thing you can count on, it’s change, and it could be the ESP you choose today isn’t big enough for your email marketing needs tomorrow.

One of the biggest differentiators between an enterprise-level ESP and a smaller mid-market one is the ability to support relational databases. Depending on the current and future needs of your email marketing program, this could be a deal breaker for you when doing an email service provider comparison. So here’s what you need to know…

Flat file vs. relational: What’s the difference?

In order to understand the value of a relational database, you have to first understand how it differs from a flat file one.

A flat file database is, in a way, old-fashioned. Think Excel spreadsheets and linear ways of storing data. For example, I might have a database with four fields of information for each customer: name, age, address, ZIP code. This works just fine if those are the only pieces of information I need to have about my customers in order to email them successfully.

Adding more and more specific data fields

However, if I want to start tracking something specific like customer Sharon Smith’s sweater buying history so I can market sweaters to her next winter in a timely fashion, I would need to add fields in order to track that data. But then if I also want to track Bob Brown’s coat buying history, I would need to add fields to track that data.

Now, Sharon has yet to buy a coat from me but she still gets those fields added to her record. And Bob has yet to buy a sweater from me but he still has those fields added to his record. So for just two customers out of a database of let’s say 43,200 customers, I’m adding fields in a linear fashion and my list of fields just gets longer and longer and more clunky with lots of empty fields just taking up space and making my job harder.

Accessing data for email segmenting, selection and personalisation

Now let’s say I want to access that data to use it for segmenting. Can you say cumbersome? If I want to combine data, like segment everyone who bought a red sweater, I’m going to need to burn some serious midnight oil to extract that data. Or I could segment by making selections based on purchase behavior from another (integrated) database and then pushing that selection into the ESP, meaning I would have to make the selections outside of the ESP. That isn’t handy either, but many marketers still do it that way.

And you know what I’m going to do next? Decide that segmenting and targeting is just too hard to bother with. Instead, I’ll continue to do mass mailings with generic messages. As time goes by, I’ll watch both my email deliverability rate and my sales gradually decline as a result.

On the other hand, let’s say my competitor is using a relational database. She doesn’t have to add fields to track buying history. She can keep data in different tables rather than in fields in the same table. That means she can have a separate table for products, and each product and variation of that product (such as size and color) has a product number. Then she’d have another table for customers and another table for purchases that would tie together the products and the customers.

Armed with these tables that can be queried and integrated in your email marketing set-up, she can do a query for everyone who bought a red sweater and easily create a segmented list with that subset of data. Then she’s free to email them about the necklace that goes perfectly with red sweaters. Or she can segment the coat buyers and target them with messages about wool scarves that complement the coats. And how many late nights does she have to work to do this? Not a one.

That’s because a relational database doesn’t require a whole bunch of fields in one database. Instead, it “relates” pieces of information to each other. With a relational database, you can relate pieces of data to other pieces of data. Instead of making more fields, you simply make connections.

Reasons to want a relational database as part of your email marketing

Can you see the segmenting potential here? With a relational database structure, a marketer can segment to an extremely small micro niche if he wants to, say everyone who bought a red sweater on a Tuesday in January. With information that specific, a marketer can create extremely relevant and targeted offers.

Is this something you could use now, or in the future? Consider possible scenarios. For example, would you like to have all your customers’ buying history in your ESP, as well as your products and all past web behavior? Would you like to be able to integrate the data in your web analytics, CRM, financial or other systems to the data that’s in your ESP? Would you like to send event-triggered messages? Would you like to do better lead scoring? If you answered yes to any of these questions, you might want to give serious consideration to relational database support when doing an email service provider comparison.

If you’re still not sure if it’s something you need, here are some other reasons why you might want to use relational databases as part of your email marketing:

  • Flexibility: Flat file databases are set in stone, not literally, of course, but it restricts your ability to adapt when products, customers, targeting, or something else changes…and something will change, guaranteed. With a relational database, there’s no limit to the amount of data you can store, query, access, and ultimately use—and using data is why you have the data in the first place, right?
  • Speed: You can run your queries in virtually no time if everything is set up correctly from the get go. On the other hand, if you have more than a few records, a flat file quickly becomes cumbersome, time-consuming and even frustrating. (Remember the midnight oil mentioned above?)
  • Cost: Although it costs money to get up and running with a relational database, the speed and flexibility offered will save you time and money in the long run reducing the total costs of ownership. And trying to get a flat file database set up to do everything a relational database can would be too costly.

Hold on: A flat file database might serve you just fine

As great as I make it sound above, a relational database is not a necessity for every marketer, and signing on with an ESP that does support them is possibly going to mean investing more money. So if you don’t need that option, don’t pay for it.

You probably don’t–and won’t–need anything more than support for the old-fashioned flat file if:

  • Your email marketing program is fairly static and will stay that way
  • You only collect small amounts of information about customers
  • Email isn’t your primary workhorse but rather a backup to other forms of marketing, such as print or telemarketing
  • You have a limited product or service offering and no plans to grow it

If, on the other hand, your company is growing, your product offerings are escalating, and your competition is heating up in the inbox, demanding more targeted messaging from you, then having the support for a relational database is kind of a big deal if you are choosing a new ESP!

About Marco Marini

With 25 years in business, Marco is a walking encyclopedia of all things email: best practices, technologies, trends, and more. Marco is currently the COO of iPost, an email platform built for marketers by marketers. iPost an easy, flexible, dynamic marketing automation solution for email and mobile marketing. He has also held key marketing positions with CyberSource, ClickMail, eHealthInsurance, DoveBid and IBM Canada.

Enable registration in settings - general
Compare items
  • Total (0)