A customer data platform (CDP) is a system that collects every behavioral event and identifier a customer leaves across your channels, stitches them into one resolved profile, and keeps that profile current so other systems (segments, journeys, ad destinations, your CRM) read and act on it. Two jobs define the thing and cannot be skipped. The first is unification: the phone number from a WhatsApp conversation, the email from an onboarding form, and the device ID from your app must resolve to a single golden record rather than three partial ones. The second is activation: the resolved profile is only useful if segments, scores, and journeys can read it on a current cadence. A system that collects events but cannot resolve identity is a data lake; a system that resolves identity but keeps it in a nightly batch export is a warehouse with good intentions. This guide defines the category properly, walks the identity pipeline, contrasts a native CDP with an installed one, and maps the tenant-owned controls Devotel Orbit ships on top.
What a CDP holds: profile vs workflow
The cleanest way to separate a CDP from its neighbors is ownership. A CDP owns the customer profile: who this person is, what they did, and what you are allowed to do about it. A CRM owns the revenue workflow: deals, tickets, stages, and owners. A warehouse owns analytic queries over modeled data. The three systems answer different questions, and conflating them is how teams end up with a CRM that cannot explain why one customer appears twice and a warehouse full of unresolved fragments.
The profile a CDP maintains has three parts, all present on Orbit's native CDP:
- The golden record. One contact row per resolved person, assembled from conflicting partial records by identity resolution. Survivorship rules decide which value each field keeps, with a blank never overwriting a populated value, so the record is a synthesis with an audit trail, not the last import that happened to run.
- The event stream. Every
track,identify,page,group, andscreencall your SDKs send lands in one append-only event table per tenant, per the CDP event model concept. The stream is the raw material every segment, funnel, and score reads. - The derived layer. Computed traits (lifetime value, last-seen channel), predictive scores (churn risk, intent, propensity), and segment memberships. All are values recomputed from the event stream and stamped back onto the profile, per the scoring pipeline concept.
For B2B teams the profile extends one level up: Orbit models the organization contacts belong to as a first-class account entity with its own golden record and parent/child hierarchy, per the CDP accounts concept.
The identity-resolution pipeline: deterministic + probabilistic matching
Identity resolution is what turns "events arrive" into "events mean something about a specific person," and it runs in two deliberate layers. The mechanics are defined in the identity-resolution concept page; the shape of the two layers is what makes the system safe to automate:
Deterministic matching. When two records' normalized identifiers are equal on a declared key (the same lowercased email, the same E.164 phone, the same external id), they group transitively into one profile. Equality, not similarity, does the match, so this layer can auto-merge unattended once a group's confidence clears your tenant-set threshold. Before you run anything against live contacts, the same surface dry-runs the groups without writing, and a simulator runs a proposed rule set against your live data and flags an over-merge before the rule ever saves: a too-loose rule fails in preview, not in production.
Probabilistic matching. Everything below the deterministic bar (a fuzzy name, a phone-format respelling, a shared channel id) ranks into a review band with a confidence score instead of merging. A phone-only link between two people is a steward's call, never an automatic fold. That distinction is the load-bearing design decision of the category: auto-merge what is provably the same person, queue what is merely similar, and a duplicate-scan can run unattended without risking the shared-handset failure shape.
Three guards keep the fold auditable rather than mysterious. Every merge is reversible inside a bounded window. Every merge writes a durable audit row recording the verdict, the confidence, and the corroborating identifiers. And field-level survivorship is tenant-owned: a strict precedence runs from per-request pins through your survivorship policy to the blank-safe default, so the golden record reads as your policy, not as platform fiat.
Where a native CDP differs from an installed CDP
Most CDPs are installed: you run a communications platform over here, buy a CDP over there, and pipe events between them. Every channel interaction first lands in the platform, then waits for the export that makes it visible to the CDP; that integration tax is the price of pretending two systems are one. A native CDP ships inside the same platform that carries the calls and messages, which changes the timeline, not just the invoice.
On Orbit the difference is concrete. Channel-side events resolve against the golden record as they happen, because ingest and identity resolution live in the same system: there is no nightly import and no webhook plumbing to maintain before stitching can start. Orbit itself mints events when a customer action outside the browser belongs on the profile: a completed WhatsApp Flow becomes a whatsapp_flow_submitted event on the same stream through the same identity pipeline, per the CDP event model. And the two jobs a standalone CDP charges you to integrate ("collect from the channels" and "activate back into the channels") are the platform's existing surfaces: the segment builder filters over the live event stream, and journeys enroll from it directly.
When does an installed CDP still earn its place? When you genuinely collect from dozens of unrelated tools far outside communications, a standalone pipeline like Segment can still make sense, and the CDP vs CRM vs warehouse vs lake decision guide draws that boundary. When the customer data you care about is born on communications channels, the native posture removes the middle system instead of renting it.
Segments, scoring, and cohorts: the recompute model
A CDP profile is only as useful as its freshness. Orbit's recompute model is defined in the segment recompute concept and the scoring pipeline; the operating principle is that real-time is the fast path, and the scheduled pass is the guarantee.
Within about a second of an accepted event, the one contact the event binds to is re-evaluated against every auto-refresh segment in the tenant; nothing else moves. Backdated events still trigger the pass on arrival, and a degraded worker defers rather than blocks ingest. On top of that, a scheduled re-enrichment converges everything the fast path deliberately skips: page and screen events, trait re-derivation, and segment memberships that only need a daily cadence. Each downstream surface carries its own staleness guarantee: a dashboard badge, a journey trigger, and a destination sync converge on different clocks, and the concept page ends with a lookup table for exactly that "is my segment current?" question.
Scoring follows the same discipline at a daily rather than per-event cadence, and it is a deliberate choice: targeting decisions are slow, so a score that re-computes per event buys nothing but read amplification. Every contact gets a once-a-day pass that blends engagement signals into churn risk, intent, and propensity scores plus a lifetime-value estimate, with every input signal stamped into the row so "why is this contact at-risk?" has an auditable answer. The resulting profile (segments, scores, traits) is what segments-to-journey enrollment and the personalization engine activate against.
The complementary lens: CDP vs CRM
The wrong answer to "what is a CDP" is "a replacement for your CRM." The right answer is ownership: the CDP owns the resolved profile; the CRM owns the workflow; and the two stay in step through reverse-ETL, with enriched profiles and computed traits syncing into Salesforce or HubSpot on a schedule. The full comparison (where a CRM cannot resolve channel-side interactions, which system should own the record, and how the reverse-ETL sync works) lives in the CDP vs CRM comparative post, with the four-way expansion in the CDP vs CRM vs warehouse vs lake decision guide.
Tenant-owned controls: event model, identity rules, journey fan-out
Every control that decides how the CDP behaves belongs to the tenant, and the platform enforces no canonical posture beyond the contract of each surface. That maps onto three decision surfaces an operator configures directly:
The event model and its governance. You declare what the stream accepts: tracking plans catalog the allowed events and enforcement modes, event schemas pin a JSON Schema per event type, and event-property governance marks sensitivity and allowed uses per property; all of it lives on the tenant, per the event model concept. Undeclared events pass through; enforcement is a posture you choose, per-property and per-event.
Identity rules, thresholds, and survivorship. You author one identity rule per identifier type with a numeric priority, set the auto-merge threshold that divides deterministic auto-merge from review, and set the survivorship precedence, per the identity-resolution concept's tenant-owned decider section. Merges are reversible inside the window and audited permanently, so the posture can be tightened without fear.
Journey enrollment and its limits. Segments and events become action through three enrollment routers (inbound-reply keyword, segment entry/exit, and CDP-track events) that funnel through the same guarded entry chain with a tenant-set offboard precheck, re-entry policy, and per-hour entry rate limit, per the journey enrollment fan-out concept. The knobs are yours; the platform's job is executing your posture consistently. Turning those into behavior is the segments-to-journey handoff.
Frequently asked questions
What is a customer data platform, in one sentence?
A system that collects every customer event and identifier across channels, resolves them into one golden-record profile, and keeps that profile current so segments, scores, and journeys act on it.
How is a CDP different from a CRM?
A CDP owns the resolved customer profile; a CRM owns the sales and service workflow: deals, tickets, stages, owners. They complement rather than replace each other, and reverse-ETL keeps the two in step; the CDP vs CRM comparison is the frame.
What is identity resolution in a CDP?
Deterministic matching merges records whose normalized identifiers are provably equal on a declared key; probabilistic matching ranks merely-similar pairs into a review queue for a steward. Survivorship rules then pick the winning value per field on the merged record, all defined on the identity-resolution concept.
What is the difference between a native CDP and an installed CDP on Orbit?
A native CDP ships inside the same platform that carries SMS, voice, email, and messaging, so channel-side events resolve against the golden record as they happen and activation runs on the platform's existing segment and journey surfaces. An installed CDP collects from the same channels through an export-integration layer, which still makes sense when you genuinely collect from dozens of unrelated external tools.
How fresh are segments and scores?
Segments re-evaluate the affected contact within about a second of an event, with a scheduled re-enrichment that converges everything else; scores recompute on a daily pass, with every input signal stamped for audit. Both cadences are defined in the recompute and scoring concepts.
Published 21 September 2026.