Skip to main content

​
What a Customer Data Platform (CDP) is on Orbit

A customer data platform (CDP) collects every behavioral event and identifier a customer leaves, stitches them into one resolved profile, and keeps that profile current so segments, scores, and journeys act on it. Two jobs define the category: unification (one golden record per person, not a pile of partial records) and activation (the profile is readable and current for segments, journeys, and destinations). This page defines the term and points at the shipped concepts that make both jobs real on Orbit: the CDP event model for collection, identity resolution and merge semantics for unification, and the segment recompute model and scoring pipeline for activation.
Every control named on this page is tenant-owned. Orbit supplies the match contract, the event pipeline, and the audit trail; you set the identity rules, thresholds, tracking plans, and journey policies. None of this is legal advice.

​
The three parts of the profile

  1. The golden record. One contact row per resolved person, assembled by identity resolution from conflicting partial records. Survivorship rules decide which value each field keeps, with a blank never overwriting a populated value, per identity resolution and merge semantics.
  2. The event stream. Every track, identify, page, group, and screen call your SDKs send lands in one append-only event table per tenant, bound to the resolved contact after ingest, per the CDP event model.
  3. The derived layer. Computed traits, predictive scores (churn risk, intent, propensity, lifetime value), and segment memberships. All are recomputed from the stream and stamped back onto the profile, per the scoring pipeline.
For B2B teams the profile extends one level up: the organization contacts belong to is modeled as a first-class account entity with its own golden record and parent/child hierarchy, per CDP accounts.

​
Identity resolution: the unification half

Two deliberate layers turn “events arrive” into “events describe a specific person,” and the split is what makes the pipeline safe to automate:
  • Deterministic. Records whose normalized identifiers are equal on a declared key (the same lowercased email, the same E.164 phone, the same external id) group transitively into one profile and auto-merge once confidence clears your tenant-set threshold.
  • Probabilistic. Everything below that bar (a fuzzy name, a respelled phone, a shared channel id) ranks into a review queue for a steward, never an automatic fold.
Merges are reversible inside a bounded window, every merge writes a durable audit row, and the survivorship precedence (per-request pins → your policy → the blank-safe default) is tenant-owned. The full semantics live on identity resolution and merge semantics.

​
Native versus installed

An installed CDP pipes events out of your communications platform into a separate system before the profile can form; a native CDP ships inside the same platform that carries the channels. On Orbit the difference is concrete: channel-side events resolve against the golden record as they happen, platform-minted events like whatsapp_flow_submitted enter the same stream through the same identity pipeline, and activation (segments, journeys) reads the live stream without an export round trip. When a standalone CDP still earns its place (collecting from many unrelated tools outside communications) is a comparison the native-vs-installed framing answers case-by-case, per the CDP event model.

​
Activation: segments, scores, journeys

  • Segments re-evaluate the one contact an event binds to within about a second, with a scheduled re-enrichment converging the rest. The per-surface staleness guarantees are tabulated on the segment recompute model.
  • Scores recompute once per day per contact (churn risk, intent, propensity, and a lifetime-value estimate), with every input signal stamped into the row for audit, per the scoring pipeline.
  • Journeys enroll from the same stream through three routers (inbound-reply keyword, segment entry/exit, and CDP-track events), funneled through a guarded entry chain with a tenant-set re-entry policy and entry rate limit, per journey enrollment fan-out.

​
Tenant-owned controls

Three decision surfaces carry the behavior you set:
  • Event governance. Tracking plans catalog the allowed events, event schemas pin a JSON Schema per event type and enforcement mode, and event-property governance marks sensitivity and allowed uses. Undeclared events pass through; enforcement is a posture you choose, per the CDP event model.
  • Identity rules. One rule per identifier type with a numeric priority, an auto-merge threshold dividing the deterministic layer from the review queue, and a survivorship policy per governed field, per identity resolution and merge semantics.
  • Journey enrollment. Re-entry policy, the per-hour entry rate limit, and the offboard precheck on the contact’s own block/opt-out fields, per journey enrollment fan-out.

​
Cross-references