A year ago this week we published the launch post for the native CDP — the customer data platform inside Devotel Orbit, not bolted on next to it. The claim at launch was specific: the same platform that runs SMS, voice, email, and WhatsApp also resolves identities, computes traits, builds segments, and activates audiences, with no external pipeline in between. Twelve months of customers launching on it, and twelve months of supporting those launches, is enough time to say honestly what held, what broke, and what buyers actually verify before they trust it.
This is the anniversary note: a recap of the lane's shipped work, the operator posture that mattered, the case the launch post made (launch + support) reported against what actually happened, and a current snapshot of the capability.
If the launch claim was a bet, this is what it bought
The launch framing was that a native CDP changes two jobs: launch engineering stops being pipeline engineering, and support stops being a lookup across three systems. A year in, both halves of that bet are measurable rather than rhetorical.
"Tenant-owned" turned out to be the operative phrase. The profiles, the identity rules, the consent decisions, the exports — all of it lives in the customer's own account and is scoped to their organization, not pooled or governed by us. In practice that meant two things: a customer's segment logic is theirs to inspect and change, and their compliance posture (retention, erasure, activation consent) is configured by them against controls the platform exposes — a posture, not a platform-mandated setting. That distinction shaped almost everything that followed.
Twelve months in one lane
The public changelog route (orbit.devotel.io/changelog) carries the full record; the lane's arc compressed into the milestones that mattered:
- Event history became a first-class export. The CDP events export API landed, streaming a contact's full cross-channel event history — messages, calls, agent interactions, flow events — as JSON or CSV, which is also how GDPR export requests and warehouse feeds get built without a side pipeline.
- Computed traits matured from rules into a language. The computed-traits DSL shipped and then got a real front end: no-code rules for the common cases, SQL for the rest, with real-time recompute so a trait reflects current behavior rather than last night's snapshot.
- Segments got honest. Group events per contact, deduplicated segment counts, and explicit subscription scopes closed the gap between "the count says 4,102" and "there are actually 4,102 people."
- Activation and consent hardening. Audience activation checks consent per profile before a segment leaves for an ad destination or a messaging channel, and the erasure path (Article 17-style soft-delete cascading into CDP events) became a shipped guarantee rather than a runbook.
- Reverse-ETL both ways. Enriched profiles and traits sync out to HubSpot, Salesforce, Snowflake, and BigQuery on a schedule; the CRM integrations added a contact-context overlay in the conversation view, so the CDP's resolved record shows up where agents work.
- Engagement-derived channel intelligence. Per-recipient channel recommendations — derived from the same event history — started feeding flows, so first-touch channel choice is a per-contact decision rather than a campaign-level guess.
That is the honest version of "the lane is alive": roughly a dozen shipped, customer-facing increments in a year, not a launch post and silence.
What an operator actually configures
The question buyers ask second (after "does it exist") is "what do I have to own." The operator surface is deliberately a posture to set, not a pile of mandated controls:
- Identity rules and survivorship. Which identifiers stitch, and which source wins when two records disagree about a field.
- Trait and segment definitions. The rule builder or SQL, plus recompute behavior — yours to define, version, and retire.
- Consent and activation policy. Where segments may be sent, and under what consent conditions. The platform enforces the check on every profile at activation time; the policy that check implements is the tenant's.
- Retention and erasure behavior. How long raw events stay, and what an erasure request cascades through.
Nothing in that list is a compliance decision the platform makes for you. Orbit exposes the controls; the tenant sets its own posture for its jurisdictions, exactly as the rest of the platform treats quiet-hours, consent, and retention.
The launch-and-support case study, one year later
The original post argued the native CDP changes launch and support concretely. Here is what the first six weeks actually looked like, and what the year did with it:
What broke first. Identity stitching edge cases — the same person arriving with a phone number in one channel and an email in another — surfaced merge questions the rule defaults handled conservatively but not always the way an operator wanted (the identify-race and wildcard-subscription fixes in the first month came straight from these). Segment counts that disagreed with operator intuition turned out to be real deduplication and group-event gaps, and customers said so loudly enough that the fixes shipped with their names on the changelog. And the GDPR path — export and erasure — was where "tenant-owned" got stress-tested first; the events-cascade work closed what the runbook used to cover.
What tenants asked for. Two requests repeated until they became features: "give me SQL when the rule builder runs out" (the computed-traits DSL), and "show me the CDP where I already work" (the CRM context overlay and the contact events export feeding external warehouses). Neither was on the launch roadmap; both are now the parts of the lane that get cited in evaluations.
What documentation closed. The support pattern was consistent: the questions stopped being "does the CDP do X" and became "which knob controls X." The documentation investment followed the questions — the CDP feature surface and the operator-facing controls are documented where tenants actually land, and the comparison rows (the contact-center native CDP row, Orbit vs. Segment) answer the "is this real" question before a demo ever happens.
Where the capability stands today
A snapshot, in the vocabulary the comparison matrices use, since that is what buyers check:
- Identity resolution and golden records — deterministic plus probabilistic matching across channels, survivorship rules per field.
- Computed traits and segments — no-code rules plus SQL, real-time recompute, honest counts.
- Audience activation — segments to Meta, TikTok, and messaging channels, consent enforced per profile before anything leaves.
- Reverse-ETL — profiles and traits out to HubSpot, Salesforce, Snowflake, BigQuery on a schedule; the customer's warehouse stays a source of events too.
- The native row on comparisons — on the contact-center comparison, the "Native customer data platform (identity resolution, golden records, audiences)" row is the one the enterprise CCaaS suites (Five9, Genesys, NICE, Talkdesk) answer no to, because they integrate an external CDP to approximate the same view.
What's next for the lane
Framed realistically: the work ahead is depth, not new promises. Tighter trait tooling (better debugging when a definition surprises you), more activation destinations where tenants are actually asking, and continued hardening of the identity and consent paths that production keeps teaching us about. Nothing here is vaporware — every item is an extension of a shipped surface, and the changelog is where each one will land when it is real.
Frequently asked questions
Is the native CDP a separate product I have to buy?
No. It is part of the same account as the messaging, voice, and contact-center surfaces — one platform and one pay-as-you-go bill — which is the entire point of "native."
What did "tenant-owned" mean a year in?
Your profiles, identity rules, segments, and consent posture live in your account and are yours to configure and inspect. Orbit exposes the controls (and enforces consent at activation time); the policy those controls implement is yours, not the platform's.
Does a native CDP replace an external one like Segment?
Not for collecting data from dozens of unrelated tools — a dedicated pipeline still has a role there. It removes the need to buy that pipeline just to make communications and customer profiles work together, which is the integration tax the launch post quantified.
How do I verify claims like "consent checked at activation"?
They are stated on the CDP feature page and the contact-center comparison, and they are testable in your own account: the activation path checks every profile's consent before a segment leaves.
Where do I see what shipped in this lane this year?
The public changelog at orbit.devotel.io/changelog — filtered by the contacts, messaging, and voice surfaces — is the running record; this post is the summary.
The takeaway
A year ago the native CDP was a claim; a year on it is a track record. The lane shipped roughly monthly, the first customers' breakage turned into identity, count, and erasure fixes that are now guarantees, and the "tenant-owned posture, platform-enforced checks" split held up as the right operator model. If you are evaluating, the verification path is short: the CDP feature page, the contact-center comparison, and the Orbit vs. Segment page tell you what exists — and the changelog tells you the lane is alive.
Published 27 August 2026.