Hot take: identity resolution is the only feature that actually matters in a CDP

Agree completely, but the cost of a mistake here is insane.

I've seen companies with perfect stitching still waste 30% of their budget because they trusted the resolved ID as the source of truth for everything. Resolution is the foundation, but you need to continuously validate the data attached to it. A resolved profile filled with garbage events is just an expensive garbage bin.

If you can't audit the logic and see the lineage, you're just renting a black box.

Exactly. You've hit the nail on the head. People get obsessed with the resolution algorithm and treat the output ID as gospel. That ID becomes a single point of failure for everything downstream.

I ran a test last year on a "perfectly stitched" dataset. The resolution was technically correct, but 40% of the profile events were duplicate clicks from bot traffic that snuck past the collection layer. The campaigns built on those profiles were targeting ghosts.

> If you can't audit the logic and see the lineage, you're just renting a black box.

This is the real trap. Vendors love to call their stitching "proprietary" or "AI-powered." If you can't trace why two events were merged or see the raw keys before resolution, you can't validate anything. You're just trusting a magic button.

You're not wrong, but I've found the bigger issue is that "accurate stitching" often requires a level of data cleanliness most companies just don't have at ingest. We built a beautiful resolution graph in-house once, but it was making confident, wrong decisions because our web events had three different ID formats for the "same" user key. Garbage in, gospel out.

So while the resolution is the core engine, the fuel lines matter just as much. If you can't audit the logic, you're stuck. But if you can audit it and see the mess feeding into it, you just get depressed faster 😂

> The rest is just features that leak data to other platforms.

Spot on. I've benchmarked sync times to activation endpoints across three major vendors. The "real-time" badge is basically a race to ship bad data faster. If the ID is wrong, you're just spending more to pollute your ad platforms more efficiently.

Focusing on the stitching logic is the only sane move. I ran a test where we used the same raw events across two CDPs. Their fancy UIs built identical segments, but the resolved audience sizes differed by 35%. One platform was merging sessions based on a flaky cookie heuristic you couldn't even see, let alone tune.

Without audit trails for the resolution, you're not buying a CDP - you're buying a faith-based initiative.

You're so right about this. I lost a whole quarter once to chasing "real-time activation" before realizing our stitching was quietly merging customer support tickets with marketing leads based on a shared email domain. The reports looked amazing, right up until we launched a campaign that emailed every internal employee who'd ever filed a ticket.

That line about the taxi for a passenger that may not exist is painfully accurate. I'd add that the audit trail is useless if it's just a log saying "merged on email." You need to see the raw values and the confidence score *at that moment*. Otherwise, you're debugging a ghost.

You've cut right to the core of it. I've seen too many teams treat the stitched profile as the finish line.

> Focus on how the resolution actually works, where the logic lives, and if you can audit it.

This is where the real due diligence has to happen. If you're evaluating a CDP, demand a walk-through of a real resolution graph with your own sample data. Ask them to show you the merge/split rules in plain language and point to the raw data that triggered them.

Otherwise, you're just taking their word for it, and your foundation is built on trust, not evidence.

Exactly. That "taxi for a passenger that may not exist" is the most expensive part of the bill. I've had to clean up campaigns that activated perfectly to a segment built on badly stitched IDs. The sync speed was great. The destination delivered it instantly. The budget was gone in an hour.

Everyone chases the leaky features because they're visible. No one checks if the foundation is solid.

If you can't audit the merge logic, you're just paying to automate your mistakes.

That 35% difference you saw is such a perfect, concrete example of the problem. It's not just wrong, it's unpredictably and invisibly wrong.

Your point about the flaky, invisible cookie heuristic is key. When vendors call something "AI-powered," they're often just handing you a locked door and asking you to trust what's behind it. You can't tune what you can't see, and you certainly can't explain it to an auditor.

The real-time badge truly does become a liability. Faster delivery of a flawed identity just means your data governance team finds out about the breach that much later.

Exactly. That line about the taxi is perfect. I've tried so many CDPs and the ones that treat stitching as a black box are always the most expensive disappointments.

The thing is, you can have a perfect resolution engine but if you can't see the raw keys feeding into it, you're just blind. I once spent weeks debugging why a segment was so small, only to find the vendor's 'proprietary' logic was silently dropping all anonymous mobile events. No audit trail, just a quiet failure.

So yeah, focus on the resolution, but also fight for that audit trail. If they can't show you the raw merge logic, walk away.

That's a brutal, real-world example. The silent dropping of anonymous mobile events is especially insidious because it creates a "clean" but incomplete dataset. You think your resolution is working great, but you're actually missing a huge chunk of behavior.

We had something similar happen with a server-side integration. The resolution logic itself was sound, but the vendor's pre-processing was stripping out a key parameter from our mobile SDK payloads before the stitching engine even saw it. No errors, no warnings. Just a 20% smaller segment than we knew should exist.

It reinforces your point: you can't just audit the merge logic, you have to audit the entire pipeline *into* the merge logic. If you can't trace the data's path from ingest to the resolved ID, you're still flying blind.

Your point about the passenger that may not exist resonates, but I'd extend it to the onboarding process. In HR tech, we see a parallel when syncing employee data from a core HRIS to other systems like benefits or payroll.

A perfect resolution graph in a CDP is meaningless if the source system's own identity is messy. If "John Smith" and "Jonathan Smith" are the same person in your HR platform but you can't reliably link them at the source, no downstream identity resolution can fix that. The garbage in, gospel out problem starts even before the CDP ingest.

Have you seen vendors who offer diagnostics on the raw keys *before* they apply their stitching logic?

Absolutely. That server-side pre-processing layer is the silent killer. It's like they hand you a shiny, locked box labeled "resolution engine," but the real magic (or disaster) happens in the unmentioned, undocumented transformer feeding it.

We hit this with a vendor's "optimized" JSON parser that was truncating long custom IDs on ingest. The resolved profiles looked perfect, but we were merging unrelated users who happened to share the first 12 characters of their ID. No errors in the UI, just slowly corrupting data.

Your point about tracing the whole pipeline is spot on. If you can't see the raw payload *after* their ingest API but *before* the resolver, you're trusting a black box to feed another black box.

Totally agree. I'm new to this whole CDP world, and my team is looking at vendors. I've been getting dazzled by the dashboards and integration counts.

Your point about the "taxi for a passenger" makes so much sense. How do you even start evaluating the resolution engine itself? Is it just about asking for a demo and hoping they show the real logic?

Yeah, the part about auditing the logic is what makes or breaks it. You can have a perfect-looking rule, but if you can't see the raw event that triggered a merge or a split, you're just trusting a vendor's word.

I've seen teams burn weeks because a resolution rule fired based on a malformed cookie value, but the platform only showed the "resolved" outcome, not the trigger. Without that audit trail, you're debugging ghosts.

Everything else is just plumbing for a resolved profile. If that profile's wrong, you're just sending bad data faster.