Hot take: CDP sales demos never show you the hard parts of data quality

Having recently concluded a rigorous, multi-vendor evaluation for a client's customer data platform (CDP) procurement, I feel compelled to articulate a critical, often glossed-over deficiency in the standard sales process. The theatrical demos, with their polished dashboards and instantaneous segment activations, systematically fail to operationalize the single most determinative factor in CDP success: the entropy of the source data and the platform's capacity to mitigate it.

The prevailing narrative focuses on activation channels, pre-built connectors, and UI simplicity. However, the true performance bottleneck—and the primary source of post-purchase disillusionment—is identity resolution under non-ideal conditions. Sales engineers will demonstrate stitching a perfectly formatted `user_id` from a mobile SDK with a pristine `email` from a transactional system. In practice, we are dealing with:
* Asynchronous, schema-less event streams with inconsistent key naming (e.g., `userId`, `user_id`, `uid`).
* Latent and conflicting profile updates from batch CRM imports.
* High cardinality of low-quality, unvalidated first-party data points (e.g., multiple `email` keys with values `"null"`, `"test@test.com"`, `"user@example.org"`).

To illustrate, consider the following trivial example of the data quality transformation that is almost never shown, yet must be configured and tuned for every source:

```json
// Raw Ingested Event (from Web SDK)
{
"timestamp": "2024-05-15T08:30:00Z",
"event_type": "pageView",
"user": {
"device_id": "a1b2c3d4",
"email": " john.doe@gmail.com ",
"customerId": null,
"first_name": "John"
},
"properties": {
"url": "https://example.com/product",
"last_purchase_id": "789"
}
}

// Simultaneous Batch Profile Update (from CRM)
{
"user_email": "JOHN.DOE@GMAIL.COM",
"loyalty_tier": "gold",
"customer_id": "cust_789",
"last_order_date": "2024-05-10"
}
```

The sales demo will show a unified profile for "John Doe" with `loyalty_tier: gold` appended to his `pageView` event. What it omits is the 6-8 weeks of configuration required to establish a deterministic match key that:
1. Strips whitespace and lowercases the `email` field from the event.
2. Resolves the conflict between `email` and `user_email` as aliases.
3. Handles the logical merge of `customerId` (null) and `customer_id` ("cust_789").
4. Decides on a source-of-truth priority when the batch update (CRM) and the real-time event (SDK) provide conflicting values for the same attribute.

My proposal for any serious evaluation is to insist on a **benchmarking sandbox** using your own anonymized, production-like data. The key performance indicators (KPIs) should shift from feature-checklist velocity to measurable data fidelity:
* **Identity Graph Build Latency:** Time from ingestion of a net-new identifier to its successful resolution and merge into an existing profile.
* **Match Rate Under Noise:** Percentage of ingested records that resolve to a profile when you introduce controlled, synthetic bad data (e.g., placeholder emails, null IDs) into the sample.
* **Configuration Complexity:** Number of distinct rules, data transformations, and manual overrides required to achieve a 95% reliable match on your dataset. This is a direct cost metric for your engineering team.

Without this empirical grounding, you are selecting a platform based on its best-case, curated narrative, not its mean-time-to-value on your messy reality. The hard parts of data quality—fuzzy matching, conflict resolution, and handling schema drift—are where these platforms truly differentiate, yet they remain conspicuously absent from the pre-sales discourse.

numbers don't lie