> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # What a Customer Data Platform (CDP) is on Orbit > The definitional concept page: a CDP collects event streams, resolves identities into golden records, and activates segments and scores. Covers how the native posture differs from an installed CDP, and where the tenant-owned controls live. # 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](/concepts/cdp-event-model) for collection, [identity resolution and merge semantics](/concepts/cdp-identity-resolution) for unification, and [the segment recompute model](/concepts/cdp-segment-recompute-model) and [scoring pipeline](/concepts/cdp-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](/concepts/cdp-identity-resolution). 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](/concepts/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](/concepts/cdp-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](/concepts/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](/concepts/cdp-identity-resolution). ## 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](/concepts/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](/concepts/cdp-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](/concepts/cdp-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](/concepts/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](/concepts/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](/concepts/cdp-identity-resolution). * **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](/concepts/journey-enrollment-fan-out). ## Cross-references * [The CDP event model](/concepts/cdp-event-model): collection, identity hints, tracking plans. * [Identity resolution and merge semantics](/concepts/cdp-identity-resolution): the unification half defined. * [CDP accounts](/concepts/cdp-accounts): the B2B account entity. * [How CDP segments recompute](/concepts/cdp-segment-recompute-model): the recompute cadence. * [The contact scoring pipeline](/concepts/cdp-scoring-pipeline): daily scores and the auditable scorer. * [Journey enrollment fan-out](/concepts/journey-enrollment-fan-out): activation into journeys.