1. Poor Data Quality
In a fast-changing API-driven world, a lot can go wrong. Fast.
Take for example the third-party data feeds you may use for firmographic, technographic, or news feeds. The structure and/or schema can change overnight, the API itself may be updated, and all sorts of strange nuances (like API call throttling and pagination) can change without notice. These challenges can be mitigated with a rock-solid data engineering team, but the reality is, there will always be quirks with third-party data.
Beyond basic data presence is the question of reliability. Should you trust Olwer’s revenue estimates for a privately-held company? How about LinkedIn’s employee count estimate? Are Crunchbase funding rounds comprehensive?
Data quality is a balance act. In some situations, perhaps such as personalizing a website experience, a “close guess” may be good enough. On the other hand – reconciling financial transactions requires keen precision.
When building a customer data platform, use discretion with respect to data quality and the downstream impact it may have.
2. Data Licensing Constraints
Data enrichment tools, data feeds, and data platforms often have licensing fine print which prevents extracting fields for copy to downstream systems.
Ensure someone in the organization reads (and fully understands) applicable restrictions before building relevant data flows. Failure to do so may nullify contracts and/or create costly license breaches.
3. GDPR & Privacy Compliance
Wouldn’t it be great if we blend clickstream data, advertising DMP data, and existing account data? From a marketing perspective, that would be awesome. But from a privacy perspective, it would be a complete disaster.
Some systems, such as AdTech data management platforms (DMPs) are not allowed to store PII. Blending data from systems with different privacy profiles is an experiment in data alchemy which will lead to privacy officer heartburn at best, and sky-high fines at worst.
4. Basic Data Governance
Let’s assume we can mitigate the aforementioned pitfalls above. Our data is trustworthy, licensed properly, and compliant with all applicable laws and regulations. This begs the question: do all internal parties agree on how to measure the data?
For example:
- Do sales and finance agree on how to measure revenue?
- Do the product management and customer success teams measure churn consistently?
- Will the sales forecast and finance record-to-report output even be in the same ballpark?
After the technical infrastructure is sound, getting business teams to agree on what the important metrics are, how to measure them, and who owns the measurement algorithm is harder than it sounds.
In less mature organizations, each team has their “view” or “opinion” of a metric. Unfortunately, these metrics don’t live in a vacuum. And when executives cross-examine these metrics, they get double-vision; or incapacitating confusion which is never resolved.
Having a skeletal framework for metric definition and governance is crucial to a successful CDP / Account 360 platform.
5. Determining Data Presentation Targets
When data is trustworthy, compliant, and generally agreed-upon in terms of measurement, the next step is to decide where the data should be analyzed.
Sales reps, marketing managers, and customer support staff prefer to remain within native tooling. For example, a customer success rep or BDR will prefer to remain inside Salesforce as this is where tasks, opportunities, and all the other day-to-day functionality lives. Similarly, a marketing manager will want to create A/B campaigns in Optimizly, create advertising segments in Salesforce Marketing Cloud, and drive ad campaigns in Google AdWords.
Other teams, such as revenue analytics, will need an inherently custom solution which allows blending of multiple data sources which may then be sliced-and-diced using graphical visualization tools (such as Tableau) or crunched using a raw data query language like SQL/HQL.
As a “single pane of glass” for visualization and data utilization is unrealistic, a more practical model may look something like the figure below:
For the operational users of the CDP, data is back propagated from either the ODS or EDW tier, directly into the source system itself. (See the pink lines.) For example: Marketo may feed a web visit from IP address 17.253.144.10 into the CDP ecosystem. The enrichment layer will return firmographics data for that IP, such as: “this IP is Apple Computer Inc, headquartered in California, with revenue of $265 billion USD”. Marketo may then use that information to customize a web chat window: “We ❤️ Apple products! What can we do for you today?”
The more analytical users will likely hit a data visualization tool (Tableau, Power BI, etc) and possibly require raw SQL access to build analytical AI/ML models. The data access goal here is not one-stop-shopping; it’s creating multiple avenues of governed, secured access to the customer 360 data model.
6. Scope Creep
Ask five people leaders in the organization what a CDP / customer 360 solution will provide, and you’ll likely get five different answers:
- It’s an account scoring tool
- It’s a churn prevention tool
- It’s a website personalization engine
- It’s a GDPR source of truth
- It’s the single pane of glass for customer data (my personal favorite)
All of these answers may be right… over time. But for an MVP, pick one or two use cases, and stay the course until each scenario is fulfilled. Scope creep will create a swiss army knife which attempts to do too many things; none of which very well.
