​

What a Customer Data Platform (CDP) is on Orbit

​

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.

​

Identity resolution: the unification half

• 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.

​

The pipeline end to end

{
  "event": "Order Completed",
  "userId": "user_42f8",
  "properties": { "order_id": "ord_99171", "total": 129.0 },
  "messageId": "2b1c9d2e-…"
}

​

Worked example: what folds and what queues

​

Native versus installed

​

Activation: segment, score, and journey cadences in numbers

• Segments — re-evaluate in about one second. A track or identify event re-evaluates only the one contact it binds to against the tenant’s auto-refresh segments, and a scheduled batch catch-up converges everything the fast path skips; the per-surface staleness table (dashboard badge ~1 s, enrichments up to ~24 h, ad audiences in hours) lives on the segment recompute model.
• Scores — recompute once per day per contact. Churn risk, intent, propensity, and a lifetime-value estimate are a fixed-weight blend, every input signal stamped into the row for audit; an on-demand pass closes the first-touch gap for freshly imported contacts, per the scoring pipeline.
• Profile traits — re-enrich once per day. The enriched attributes a segment filter references (industry, country, lifecycle stage) refresh on the daily re-enrichment sweep named in the staleness table on the segment recompute model.
• Journeys — enroll from the same stream. Three routers feed enrollment (inbound-reply keyword, segment entry/exit, CDP-track events) through a guarded entry chain with a tenant-set re-entry policy and hourly entry rate limit, per journey enrollment fan-out.

​

Tenant-owned controls

• 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

• The CDP event model: collection, identity hints, tracking plans.
• Identity resolution and merge semantics: the unification half defined.
• CDP accounts: the B2B account entity.
• How CDP segments recompute: the recompute cadence.
• The contact scoring pipeline: daily scores and the auditable scorer.
• Journey enrollment fan-out: activation into journeys.