“Data-Driven Thinking” is written by members of the media community and contains fresh ideas on the digital revolution in media.
Today’s column is written by Tasso Argyros, CEO and founder of ActionIQ.
Recently, martech influencer Scott Brinker posted the results of a survey that claims 67% of respondents plan to build their own “custom” customer data platform (CDP) rather than buying one off the shelf. It generated a lively conversation on LinkedIn.
I have been in the software business for 15 years now, and the “build vs. buy” debate has been going on for even longer. However, these days only a very small percentage of companies actually decide to build off-the-shelf SaaS themselves.
This is because companies have come to understand that success derives from focusing on core product and services competencies, not by running “pet” engineering projects. Developing these core competencies requires more bandwidth than many companies have available today, illustrating why they often choose to buy solutions rather than build them.
Building technology outside your core competency in-house tends to fail for a number of reasons:
- Time and resources are consistently underestimated. Even a workable V1 needs careful budgeting and executive patience.
- Engineers love to build but not to maintain. That means after V1 is rolled out, the pace slows and, with it, the enthusiasm for perfecting a complete solution. For complex problems, like those a CDP aims to solve, V1 will prove inefficient, yet few teams will be up for the multiyear effort that is required to develop the V2 and V3 iterations that can finally deliver value.
- Engineers also love to build products that only an engineer can use. They often end up developing so-called solutions that have too much complexity for the nontechnical business user.
- Internal projects are more vulnerable to shifts in company priorities. It’s much easier to pull funding from internal projects rather than from a vendor under contract.
Why, then, did two-thirds of the survey’s respondents say they’re building a “custom CDP?”
My educated guess is that they do not have a proper definition in mind of what a CDP really is. Despite its popularity, the term “customer data platform” is unfortunate because it gives the impression that we’re referring to a data lake or warehouse for customer data. This is not the case.
A CDP is not just a data warehouse. Rather, it typically sits on top of data warehouses and integrates with other IT systems and customer data streams. After unifying customer data (and only to the extent needed), the purpose of a CDP is to provide a wide array of functionality within an intuitive business interface, such as identity resolution, audience creation, customer intelligence, machine-learning customer modeling and omnichannel journey orchestration.
CDPs provide business users direct access to the raw customer data stored within a data warehouse for the purpose of activating more intelligent customer experiences.
This is a topic that is very personal to me because my last company, Aster Data, was a customer database technology that was deployed at dozens of Fortune 500 customers. At the time, in the mid-2000s, our technology was best used for building a customer data lake, similar to what many IT departments do today with cloud databases, such as Google’s BigQuery, Amazon’s Redshift, Snowflake and Databricks.
I witnessed firsthand the limitations of that pure data management approach. The data was unified but not formatted for easy analysis. There was no interface for the business to extract intelligence; all audience creation was done through SQL code. This meant that activating data on any channel required fragile custom integrations or a data engineer moving customer files around.
Creating a nontrivial customer journey was impossible, and forget any notion of agility in designing new CX campaigns.
So, the next time you hear someone say they intend to build a CDP in-house, I’d advise you to have them ask their team these five questions:
1. What is your definition of a CDP and does it include more than centralizing your data?
2. Will your CDP have an easy-to-use self-service business interface to remove dependency on analysts and data engineers?
3. Do you have $10 million or more in funding and at least a three-year buffer so you have time to get to value?
4. Are you prepared to implement and maintain dozens of data and channel integrations with vendors whose APIs constantly change or break?
5. Have you evaluated a purpose-built enterprise CDP in order to make an honest comparison of trade-offs?
(I’d argue that what the big marketing clouds are selling under the guise of a CDP is not a real customer data platform at all. They are random products whose only purpose is to obscure the fact that they have no solution in the space.)
To be clear: we do need properly managed customer data warehouses, data lakes and data streams, and IT needs to own and build those out because they are fundamental to all your data initiatives. If that is done well, a CDP can be deployed on top to realize the value of that work by activating that data in customer experiences.
By the same token, though, organizations that don’t plan beyond data consolidation are setting themselves up to miss out on 95% of the value that a CDP can provide.
Follow ActionIQ (@ActionIQinc) and AdExchanger (@adexchanger) on Twitter.
