CDP Connector Count Is a Vanity Metric. Here's What Isn't

Your CDP vendor’s sales deck probably leads with a number. 500 connectors. 200 native integrations. An API for everything. What it rarely leads with is what happens to your data once it arrives.

Tealium’s Nick Albertini put it plainly in a recent post: flexibility isn’t something you accumulate, and the platform with the longest integration list doesn’t win. I’d go further. In six years of stitching together customer profiles across retail, fintech, and e-commerce in Southeast Asia, I’ve watched brands mistake connectivity for capability — and pay for it in stale audiences, misfired campaigns, and identity graphs that quietly lie to everyone downstream.

The connector count is a proxy for potential. What you actually need is a framework for trust.

The Integration Illusion and Why It’s Expensive

Here’s what a long connector list actually tells you: the vendor has built a lot of pipes. It tells you nothing about what flows through them, how clean it is when it arrives, or whether it means the same thing across sources. A Shopee order event and a Lazada order event both say “purchase” — but their schemas, timestamps, and customer identifiers are structured differently enough that naive unification creates phantom profiles and duplicate suppression failures.

Brands running omnichannel operations across Southeast Asia face this acutely. A single customer might touch a LINE OA chatbot, a Shopee storefront, a brand’s own app, and a physical POS in the same week. Each touchpoint speaks a different data dialect. The question isn’t whether your CDP can connect to all four — most can. The question is whether it can resolve those four interactions into a single, trusted profile without your data engineering team writing bespoke transformation logic for every new source.

When that logic lives outside the platform, in dbt models or custom ETL scripts, you’ve bought a connector hub, not a customer data platform.

Quality Is Engineered In, Not Inspected Out

Monte Carlo’s Barr Moses drew on a compelling manufacturing analogy recently: American industry spent three decades learning that you can catch defects at the end of the line, but you cannot inspect your way to quality. Quality has to be engineered into the process itself.

The same principle applies to customer data. Evaluation layers — whether for AI agents or identity resolution — are the last gate, not the only gate. If your CDP is ingesting malformed consent flags, inconsistent email formats, or session IDs that reset on every app update, running a final deduplication pass before audience export doesn’t fix the underlying problem. It just makes the damage less visible.

The CDPs that earn their licence fee are the ones that enforce schema validation at ingestion, flag identity conflicts before they compound, and give your team observability into data lineage — not just a dashboard showing events received. Implementation-wise, this means auditing your CDP’s data quality controls before you evaluate its connector library. Specifically: does it support configurable validation rules at the source level? Can it quarantine bad records rather than silently drop or merge them? Can your team trace a profile’s identity stitching decisions back to the raw events that drove them?

---

When You Can’t Trust the Data in the Room

There’s a concept in distributed systems called Byzantine fault tolerance — the problem of reaching a reliable consensus when some nodes in your network are sending incorrect or conflicting signals, not because they’re broken, but because their information is genuinely inconsistent. Maria Mouschoutzi’s recent piece on the topic at Towards Data Science framed it as: how do you make decisions when you can’t trust everyone in the room?

This is, functionally, the identity resolution problem. Your CDP receives signals from a dozen sources. Some are timestamped correctly. Some carry authenticated IDs. Some carry probabilistic device fingerprints. Some are consent-gated and some aren’t. The platform has to reach a confident conclusion about who this customer is, despite the fact that some of those signals are wrong, stale, or deliberately ambiguous.

Byzantine fault tolerance in distributed systems solves this through redundancy and voting mechanisms — no single node’s signal is trusted unconditionally. Good CDP architecture does the same thing: it weights identity signals by reliability, maintains probabilistic confidence scores on profile merges, and degrades gracefully when signals conflict rather than forcing a false resolution. If your CDP can’t show you a confidence score on a merged profile, you’re flying blind on your highest-value audiences.

For Southeast Asian deployments specifically, this matters because the identifier landscape is fragmented. Phone numbers are more reliable than email addresses in markets like Thailand and Indonesia, where users frequently rotate free email accounts. LINE UIDs and GrabPay customer IDs are often more persistent than browser cookies. A CDP that was architected for a Western identifier hierarchy — email first, cookie second — will underperform in a market where neither is the most trusted signal.

What to Actually Evaluate in a CDP

Connectors are table stakes. Here’s what differentiates platforms that actually unify customer data from those that accumulate it:

Identity resolution transparency. Can you inspect the logic that merged two profiles? Can you audit merge decisions and reverse them? Opaque resolution engines create technical debt that compounds with every new data source you add.

Data quality controls at ingestion. Validation rules, schema enforcement, and anomaly detection should sit at the point of entry, not the point of activation. Ask vendors to show you what happens when a malformed event hits the pipeline — does it fail loudly, or fail quietly?

Consent and compliance architecture. In Southeast Asia, PDPA in Thailand, PDPC in Singapore, and Indonesia’s PDP Law have different consent requirements. Your CDP’s consent management layer needs to be granular enough to honour per-regulation opt-outs without blowing up your audience segments. This is a non-negotiable architectural requirement, not a feature to configure later.

Activation fidelity. The gap between a unified profile and an activated audience is where most value leaks. Evaluate how your CDP handles real-time segment updates, how it manages audience suppression across channels, and whether its export logic respects the identity resolution it just performed — or flattens it back into a list of email addresses.

The right CDP isn’t the one with the most doors. It’s the one that can tell you exactly who’s on the other side of each one — and why it’s confident.

Key Takeaways

• Connector count is a measure of potential connectivity, not data quality or profile accuracy — evaluate on identity resolution transparency instead.
• Engineering data quality into ingestion pipelines is fundamentally more effective than running deduplication at the activation stage.
• In Southeast Asia, CDP identity resolution must weight phone numbers, LINE UIDs, and platform-native IDs above email and cookies to perform accurately.

The real question for 2026 isn’t which CDP connects to the most sources — it’s which one you’d trust to make an autonomous decision about your highest-value customer. If you’re not certain of the answer, that uncertainty is the brief.

---

At grzzly, we work with growth teams across Southeast Asia to audit, architect, and activate customer data platforms that actually justify the investment — from identity resolution design to consent-compliant audience activation across Shopee, LINE, and owned channels. If your CDP is accumulating connectors faster than it’s building confidence in your data, that’s a conversation worth having. Let’s talk