While there are myriad ways to divide up people, I think it’s fair to say that at least one dividing line is between puzzle people and non-puzzle people.
You know which one you are: You either love to do jigsaw puzzles — the more pieces the better — or you’d be happy to do basically anything else to pass time.
If you have an opinion one way or the other, which is to say, you’ve done a jigsaw puzzle, you’ll indulge me on an analogy that customer data platforms (CDPs) are like jigsaw puzzles.
Specifically, the database architecture underlying CDPs can be compared directly with how one would solve a puzzle.
The 3 types of CDP databases
Before I explain the comparison between CDPs and jigsaw puzzles, let’s review the three kinds of databases, which determine possible CDP database architectures.
These databases are used by what Gartner calls “pure–play” CDPs. (The consulting firm goes into far greater detail about this in its Market Guide for Customer Data Platforms.)
1. Relational Databases
A CDP that uses a relational database is by far the most inflexible when it comes to enabling a marketer to define her own taxonomy.
Relational databases are highly structured architectures whereby the database enforces the relationship(s) between objects. Once that data schema is implemented, you must work within its structure.
An example: A relational database CDP would need to pre-define a relationship between unidentified visitors to a website and a campaign in order to store that anonymous information.
The campaign is the organizing principle — which makes sense, as most CDPs with a relational database foundation are actually more like campaign management tools than built-for-purpose CDPs.
2. Event-Stream Databases
A CDP that uses an event-stream database is the most likely to explode in size and cost to scale.
These databases are at the other end of the spectrum from relational databases because they collect massive amounts of raw data into a big data structure. But it’s only after the fact that it’s up to the marketer to sort through the raw data and determine what data should be mapped to the profile graph or be stuck with the event-to-graph schema the CDP ships with.
In this context, the profile graph is a set of attributes associated with an ID, but not consolidated into a separate entity — a la a unified profile.
These CDPs lean heavily into web and mobile since these channels deal primarily in events (clicks, swipes, page views, etc.) and, because of the volume of raw data they collect (and optionally store), may be preferred by analytics types who care more about the breadth of data than the marketing segmentation and integration use cases supported by a built-for-purpose CDP.
3. Profile Databases
A CDP that uses a key value profile database sits somewhere between the other two by offering a balance of flexibility and intention when it comes to data collection and consolidation.
That’s because there aren’t related tables or stores, which means values can be added easily and scale without limit.
These CDPs create and store true unified profiles at the individual level, as opposed to just creating a chaotic graph and its deconstructed events or enforcing an arbitrary data schema on the data set.
Since, by definition, CDPs must provide a “persistent” profile, a profile database provides both high volume storage and fast read and write speeds so that data is unified and actionable in marketer-specific ways, such as for segmentation, personalization, and analytics.
(Fun fact: BlueConic is built on top of the same database technology that both Netflix and Rackspace use, and we’ll discuss that more in a separate post).
Why choosing the right CDP matters
Here’s where the puzzle comes in.
You are given a 100-piece puzzle. You solve it readily. Then you’re told that it’s actually only one part of a much bigger puzzle and you’re given another 500 pieces to add. Upon completion, again, you are given another 1,000 pieces to expand the puzzle with.
Imagine that each puzzle piece is a data point about an individual person — prospect or customer — and your “image” of that person keeps expanding with every new piece.
The complete puzzle represents a unified profile for that person. The surface on which you are constructing the puzzle represents the CDP database.
Now, let’s look at how much more difficult or easy it would be to keep adding new pieces — data points — depending on what type of database your CDP is using:
- If you started with a relational database, the surface for your puzzle would have come with a space carved out for each of the first 100 puzzle pieces in advance. But as soon as you needed to expand to an additional 500 pieces, you’d have to take the whole thing apart and build a new surface from scratch with an additional 500 spaces carved out for what you need, which takes a lot of time, resources, and money. In the off chance you know exactly what you need ahead of time, this might not be a problem. But I’ve yet to find a company who can say that was the case.
- If you started with an event-stream database, those first 100 pieces were manageable. But to add 500 more pieces actually means finding those 500 in a bucket of puzzle pieces with 10x more than you need. And then 20x. And 50x. Suddenly, in order to complete the puzzle, you have to weed through thousands and thousands of pieces for every one piece you need to find. Eventually, you’re running out of table space to account for all of these pieces. So you have to either 1) buy a much bigger table or 2) choose which puzzle pieces to throw away because there just isn’t room for all of it.
- If you started with a profile database, you’d have an unblemished table that comes with some guidelines about where to start building and where to place puzzle pieces in anticipation of what’s to come. This table has an endless number of extending leaves within it. So when you need more room to account for the additional pieces, you can expand adjacently – and only as much as you need in that moment – as opposed to buying a bigger table. When you get a critical piece that changes the whole complexion of the puzzle, you can shift the entire work-in-progress to keep building in a new direction.
To be clear: Different database architectures underlying CDPs bring different strengths to bear. But for organizations that want to make the customer the central object of their entire tech stack, taking into account what the long-term implications and as yet-unforeseen consequences could be is an exercise well worth undertaking before you buy a CDP.
Otherwise, you might end up like me and avoid puzzles altogether.