About This Workbook
Every packaged CDP resolves identity, so the real question is never whether it can — it’s at what latency, across which sources, and at what cost when you already resolve identity in your own warehouse. The gap doesn’t show up in the demo. It surfaces months later, when the CDP’s scheduled resolution lags the moment you actually use the profile, when it only sees the anonymous clickstream its SDK captures, or when adopting it means running a second, partial identity graph alongside the one you already trust.
This workbook evaluates cross-session and cross-device identity resolution for a packaged CDP against a composable, warehouse-native stack — scored on four things the sales deck avoids: latency at the point of use, breadth across all your sources, duplication of resolution you already run, and control of the match. It turns those into requirements you configure and weight, then produces a binary, weighted scorecard you can defend in an architecture decision.
How the Toolkit Works
Four steps, mapped to the workbook’s eight sections:
- Understand the capability — what identity resolution really tests once you accept every CDP does it, and what pass and fail look like (Sections 1–3).
- Configure your requirements — six parameters that turn the capability into your specific requirement, including whether the CDP must defer to a graph you already run (Section 4).
- Weight your requirements — importance weighting so the score reflects your priorities, not a generic template (Section 5).
- Run due diligence and score — six paired packaged-vs-composable questions, then binary weighted scoring to a verdict (Sections 6–7).
Benefits & Outcomes
- Decide on evidence, not vendor framing — every score ties to something you confirmed in writing or tested in your own environment.
- Expose the hidden costs before they’re contractual: batch-resolution lag, sources the graph never sees, and the standing tax of reconciling two identity graphs.
- Answer the question the demo avoids — will this CDP consume the canonical ID you already resolve, or rebuild it on a subset of your data?
- De-risk the packaged-vs-composable call with a scorecard weighted to your business.
- Reuse the requirement definitions downstream in your RFP and vendor trials.
Who This Is For
- Founders and CTOs owning the data-architecture decision.
- MarOps and data leaders weighing a packaged CDP against a warehouse-native stack.
- Teams who already resolve identity in the warehouse and are deciding whether a CDP should too.
- Consultants and agencies running the selection for a client.
FAQ
Doesn't every CDP already do identity resolution?
Yes — and that's the point. Segment, mParticle and BlueConic all resolve identity out of the box. This workbook doesn't test whether a CDP can resolve identity; it tests how well: at what latency, across which sources, and whether it forces you to run a second identity graph alongside one you may already have.
What actually breaks identity resolution in practice?
Three things the sales deck skips. Resolution that runs on a schedule, so the profile lags the moment you use it. A graph that only covers the anonymous clickstream the SDK captures — missing offline, subscriptions and support. And matching thresholds you can't see or tune, so a shared household device quietly merges two customers into one.
We already resolve identity in our warehouse. Do we still need a CDP to do it?
That's the decisive question this workbook is built around. If you already mint a canonical customer ID, a packaged CDP that insists on resolving its own way hands you a second, partial graph to reconcile — a standing cost for a copy you didn't need. The scorecard weighs whether the CDP can defer to your graph or duplicates it.
How does the workbook actually score a vendor?
Six requirements you configure — freshness, source breadth, match basis, reuse of existing resolution, effort, and control — each weighted by importance, then scored binary: 1 only with hard evidence from your own environment, 0 otherwise. The final score is the sum of (result × weight), read against 80% pass / 50% caution bands.
Does the packaged-vs-composable choice really change the outcome?
Entirely, depending on your configuration — which is the point. In the worked example a warehouse-native stack scores 100% while two packaged CDPs land at 30%, because that buyer already resolves in Snowflake. A pre-warehouse brand with no existing graph would score the packaged options far higher. The framework gives a fit-for-purpose answer, not a universal verdict.
Who is this for?
Founders, CTOs, and MarOps or data leaders choosing between a packaged CDP and a warehouse-native stack — especially teams who already resolve identity somewhere and need to decide whether the CDP should too. Consultants running the selection for a client use it as the evidence framework.
