…and what’s this? Relational database support, that’s what.

With all of the technological developments in our industry, developments that enable personalization, automated campaigns, cart abandonment follow up, and so on, it’s surprising how many marketers are still relying on flat file databases—although sometimes that’s because they have no choice. Sometimes, that’s all their ESP offers.

And sometimes that’s not enough.  

What is a flat file database?

Although email experts have been explaining the benefits of relational databases for quite a while, not many email service providers (ESPs) support them, meaning most ESPs still rely on a flat file format. That simplistic data structure used to be enough, before Big Data, personalization and cross-channel marketing came on the scene. It’s not enough any more.

In many cases, however, marketers aren’t even sure what a flat file database is, how it differs, or why they need it. So here’s a quick explanation, starting with this definition from Techopedia:

A flat file database is a type of database that stores data in a single table. This is unlike a relational database, which makes use of multiple tables and relations. Flat file databases are generally in plain-text form, where each line holds only one record. The fields in the record are separated using delimiters such as tabs and commas.

Why does this file format matter? 

A flat file database structure works just fine for the email marketer who is doing only the most basic segmentation, because the data being collected and used is either minimal or in common for most of the names on the list. If a marketer is using only gender, age group, ZIP code and marital status information, for example, then most (if not all) names in the database will have those attributes and can be segmented accordingly.

However, as soon as a marketer wants to move towards using data that will vary between customers, it gets a little complicated.

When flat file falls flat

Let’s say customer A is a much more engaged customer with an extensive history of buying seasonal women’s clothing in size small. And customer B is a much less engaged customer who has only purchased one paisley tie and a pair of brown slacks, size 36/36. In order to track all of customer A’s behavior kept it in the flat file database, the marketer will have to add a field for each new attribute to not only customer A’s record, but to customer B’s record as well. So now all of a sudden we’re adding all of these empty fields—because customer B is not only rarely active but also buying something very different from customer A.

But wait, it gets worse: Let’s say we also have customer C who has purchased only children’s clothing, but a lot of it, and what they’re buying keeps changing as their children grow. For every record generated by customer C’s behavior, the same fields have to get added to customers A and B. That’s a lot of useless fields! Now, times this by a thousand or ten thousand or even more and you’ll see how quickly this can get out of hand—and how hard it can be to access and use this valuable data for targeted marketing!

Then there’s the possibility that you’ll have to “overwrite” existing data to make a flat file format work. That means giving up existing data (that still has value, mind you) in order to make room for the new data—and that means less data for targeted marketing to that particular customer or subscriber.

Finally, there’s a chance you’d have to rely on your internal IT team to make your data more usable. Need I say more on that point?

Relational vs. flat file systems

So how does a relational database compare? To use a visual analogy, picture a flat file database as two dimensional compared to a three dimensional relational database.

Unlike the flat file counterpart, a relational database lets you keep all kinds of data and then “relate” one piece of data to another—no new fields required. The data can exist in different places and the relational database structure lets you connect one piece of data to another. You can have one table with only one record per customer, for example, like the customer ID. Then you can “relate” the data to another table that contains actions such as buying behavior, or even multiple tables.

To go back to our example, you don’t have to add empty fields for customers B and C because A’s buying activity can be tracked elsewhere. Ditto for the buying (or even browsing) activity of customers B and C. Store it elsewhere and grab it when you need it by “relating” it to that particular customer.

And this is how you do personalized email marketing: by unlocking and putting to use data collected about individual customers.

(See another explanation about the differences between flat file and relational databases here.)

Why you need an ESP that supports relational databases

So what makes relational databases so special? The marketing you can do.

Email experts in the know have been promoting the benefits of relational databases for several years now, yet few email service providers (ESPs) support them. (Note: The Salesforce Marketing Cloud does offer support for relational databases.)

Should relational database support be on your list of criteria when choosing an ESP? Probably, if you want to true one-to-one email marketing.

Using relational data, you can use data from several different sources, including web analytics, ecommerce, your CRM system, point-of-sale data, social media and more. This data all exists independent of your email data, but you can draw on it and relate what you need to that email data when crafting campaigns and messages.

A relational database gives email marketers limitless possibilities for segmenting and targeting, to the point where it is literally one-to-one marketing.

By now, your email marketing program should be geared towards evolving into something uber-personalized, a kind of one-to-one marketing we marketers used to only dream about. But you won’t get there with a flat file data structure. You can only achieve one-to-one email marketing of this kind (without a lot of hassle and harassing of the IT department, I mean) by using relational data.

Do they or don’t they…?

Many ESPs will tell you that they do support relational data because they use a relational database in their architecture to run their application. However, there are only a handful of ESPs that allow you as the client to leverage this structure within the account to build your own data structure. This is a critical distinction if you’re going to do more advanced segmentation and targeted email marketing in the future.

If you’re striving for true one-to-one email marketing, then it’s time to have a heart-to-heart with your ESP—because you have to have this: relational database support.

About the Author

Marco Marini has been at the forefront of email marketing since its inception as a channel. Prior to co-founding ClickMail, Marco developed pioneering email campaigns for CyberSource, eHealthInsurance, DoveBid and IBM Canada while holding key marketing roles in those organizations. Clickmail is a part of the Salesforce Marketing Cloud Partner Community in both the Channel and HubExchange programs.