Hey folks. I've noticed a lot of the CDP comparison threads dive straight into vendor features, but I think a lot of the confusion starts one layer deeper: the data models. If you don't get how a CDP structures the world, you'll struggle to evaluate them.
At its core, most CDPs revolve around a few key entities. Think of these as your foundational tables:
* **Individual/Person:** The who. A single human, with identifiers (email, cookie ID, device ID).
* **Account/Household:** The grouping. B2B is obvious, but in B2C this might be a household for a brand.
* **Event:** The what and when. Page views, form fills, purchases. The raw behavioral stream.
* **Session:** A sequence of events from a single source in a given timeframe.
The magic (and where vendors differ wildly) is in the **identity resolution** layer. This is the logic that stitches your "Individual" from an anonymous browser cookie to a known email address from a form fill. Some CDPs force a strict hierarchy (one email to one person), while others allow a more flexible graph (one person can have multiple emails, phones, etc.).
For example, in a B2B context, you're often modeling the relationship between a **Person** (like a buying committee member) and an **Account** (their company). A good CDP will let you build segments based on account-level attributes (e.g., "all people at companies with >500 employees") combined with individual behavior ("who visited our pricing page").
Getting this model clear in your head first makes comparing activation capabilities, reporting depth, and pricing models so much easier. What are you trying to connect? Is it purely digital behavior, or are you blending in offline POS data? That changes everything.
Happy to dive deeper on any specific entity relationships that are tripping you up.
— revops_metrics_guy
This is a huge help, thank you. The distinction between a strict hierarchy and a flexible graph for identity resolution feels like the linchpin. When you say some allow a more flexible graph, is that something you can typically configure, or is it a core architectural choice you're stuck with? I'm worried about picking a vendor whose model can't handle messy, real-world data where people absolutely have multiple emails and old cookie IDs hanging around.
The grass is greener? We'll see.
Great question, and your worry is spot on. The graph vs. hierarchy approach is usually a core architectural choice, baked into how they store and resolve identities at the database level. You can't really configure a rigid system to be flexible.
When you evaluate, ask them directly about their "identity stitching" logic for edge cases. For example, can a work email, personal email, and an old anonymized mobile ID all belong to the same person profile without forcing a primary hierarchy? Some systems will treat one ID as primary and link others as attributes, which can break the timeline of events.
Your messy data scenario is the perfect test. Ask for a specific use case in a demo: "If a purchase comes in tied to an old cookie ID we haven't seen in a year, and later a newsletter sign-up uses a new email, how does your model connect or separate those?" Their answer will tell you everything.
audit often