NoSql Could be Digital Advertising's New Best Friend
NoSql databases could be that competitive advantage that advertising professionals need.
We as advertisers spend long hours slaving over ideas, creative and strategy. In digital advertising, much of that hard labor can get blown to bits by a few measly milliseconds of delay in page load time. It's the kind of thing that you don't see coming that jumps out at you seemingly out of nowhere and then bites you squarely in the rear. Companies like Google, Amazon, LinkedIn, Netflix and Foursquare are managing this unpleasant problem by using NoSql databases. In this post I'll do my best to explain these to you without boring you to tears.
What does a one second delay mean to you? If you're Amazon.com it could mean $1.6 billion/year in lost revenue. You can read more about that here.
Makes you sit up and take notice doesn't it? It's the kind of thing brands really should not ignore. I'll have to go into databases a little to explain how NoSql databases can help.
The most popular databases in use today are relational databases. You might vaguely remember long ago your teacher explaining relational algebra to you. If a = b and b = c then a = c. Most students sitting through these lessons probably roll their eyes and wonder how this could be relevant in the real world. Guess what? Relational databases are based on relational algebra and relational databases are playing a significant role in almost every significant website and software system in existence today.
Relational databases store data as relationships. If I am a site moderator and site moderators can ban comments, then I have the right to ban comments. This the kind of analysis you can expect coming out of a relational database.
At the time relational databases were designed, there were no mobile applications and no user generated content. Financial transactions were really important when it came to databases and no one cared at all about storing content. Storing data was expensive, so large amounts of data were rare, and since there was no internet, no one really cared about consumer drop off rates. In fact, no one really cared about consumers at all when it came to databases.
Times have changed. Move over bankers, we advertisers suddenly care a lot about data, too. We truly adore all these yummy consumer insights; user generated content and social networking data. If our consumers show us a lot of love via their snazzy smartphones, then we end up with tons and tons of data that we love with all our hearts.
It is really hard to store content and social data as relationships in a relational database. That's because this data is either hierarchical or a graph. For example, take your family tree and try to explain it as a = b and b = c, therefore a = c, and you'll quickly find out for yourself how ill-suited to hierarchies the relational model is. Next, compare that to explaining your family tree as a hierarchy. Life is so much easier and simpler when you use the appropriate model for the data that you have.
It is not impossible to translate hierarchies to the relational model, just hard. You'll end up with really convoluted data but you can stuff that round peg in a square hole. Once you're done with this really complicated task, you'll end up with a system that is really complex and so very, very slow. Since most people working with relational databases don't know anything besides relational databases you'll find a lot of this going on. In addition, if you're lucky enough to become very successful with your digital campaign, then, like Amazon and Google, you too will find that it is much harder to manage vast amounts of data with relational databases since they really were not designed for that.
To get around these problems, Google published a paper in 2006 famously called the Google Big Table paper on a new kind of database, which solved many of these issues for them. Then, in 2007, Amazon published a paper, which was famously called the Amazon Dynamo paper on a somewhat different way to solve the same type of problems. These papers have resulted in a slew of products, which are commonly referred to as "NoSql" databases. These databases are designed to handle large amounts of data. Some are particular to handling content and others to handling social data. Others store data in the most primitive of ways, just as simple pairs such as name and Sam, name and Jane, etc. These products focus on managing huge quantities of data, on retrieving data quickly and on always being available. They are cheaper to maintain than relational databases and could save brands millions of dollars in the long run. On the downside, they don't guarantee the correctness of data 100% of the time, and are newer, requiring more learning and have more quirks than older databases.
I've been a bit unfair to relational databases, making them sound outdated and irrelevant to marketers. I've got nothing but the utmost respect for relational databases. They are really quite entirely marvelous. They work really, really well, allow us to analyze data in microscopic detail with ease and win hands down when it comes to ensuring the correctness of data. For small to moderate amounts of data, even hierarchical and graphical data, the relational database is still the best choice. Relational databases are like the trusted friend that you know like the back of your hand that always gives you their very best.
The time has come though to take a look at adding some potential new friends to our arsenal. Ones we don't entirely trust yet, and ones whose company we aren't always in the mood for, but ones that we may end up loving in an hour of need. It's important that marketers keep NoSql databases in the back of their heads. Used in the right circumstances, it could end up being that competitive advantage that gets consumers to fall in love with your shiny new app.