A practical guide for selecting a Customer Data Platform

Some analyses of Customer Data Platforms take this general form: they list all the functions that CDPs have, or are expected to have, and then rank various CDPs on how well they do those functions in general.

I suppose that’s as good as you can do for that sort of analysis, but I don’t think that information is very helpful for any particular company.

If you’re evaluating Customer Data Platform options, you don’t care what they’re supposed to do in the abstract, or what they do for other people. You care if they solve your problems — that is, if they address your use cases.

For example, it doesn’t matter how well a CDP generates reports, in some broad sense. What matters is if you can get the reports you need with the data you can collect.

But that raises a big problem for the company that’s considering a CDP. How do you whittle down the list? There’re a lot of CDPs out there, and you can’t afford to investigate each of them with the diligence required.

Here’s a practical path forward.

1. Start with a very detailed list of use cases. Explain exactly what you want to be able to do, what data sources will be required, how that data will have to be processed, what other services will be involved, what activations will occur, what reports need to be generated, etc. The more time you spend on your use cases, the better.

2. Explain your niche. I work with publishers, and the bare fact that a CDP has worked with “publishers” is not enough. There are all different sorts of publishers out there, and they have different business models with different needs. Ask if a prospective CDP has any clients like you.

3. Set reasonable budget goals. I know everybody likes to play games with prices, but I believe transparency is the best strategy. You can negotiate later.

4. Put these three things in a relatively short Request for Information and send it out to all 743 CDPs.

I’m kidding about that 743 number. You can’t send your request to everybody, so whittle the list down. 20 might be manageable at this first stage. To the extent that you can, sort them by geography, general ratings, and whether they work in your industry. You’ll have to spend a little time on their websites and YouTube videos to figure this out. Or you can ask me to do it.

While you’re waiting on the responses, come up with a grading system, giving the use cases the biggest portion of the score.

Then the fun starts. You’re going to have to evaluate all the responses! It’s wearisome, but you’ll learn a lot in the process about what can and can’t be done. You might modify some of your use cases as a result of what you learn, and you might come up with new ones.

As you read through the responses and learn new things, you’ll want to change your evaluation criteria. That’s good. Realize that because you’re learning along the way, you’ll evaluate your tenth RFI response differently than you evaluated your first.

One way to handle this mound of documents is to divide up the responses among a few different people. Let everyone have a go at scoring ten of them, then re-convene and re-evaluate your grading system. Have one person (that should be me — I’m independent!) read all the responses.

Take your revised scoring system, redistribute more of the RFI responses, and do it again.

By the time you get through the stack, you should be able to decide which companies make it to the RFP stage.

It’s not an easy process, but if you remain focused on your own business requirements, and not on generic rankings, you should make a good decision.

Resources
-----------
The Krehbiel Letter
https://krehbielgroup.com/the-krehbiel-letter/