A short answer first: Orbit's personalization engine is the native CDP's computed traits, decided against per visitor. The same profile the CDP resolves across SMS, voice, email, and WhatsApp carries maintained traits — engagement segment, churn risk, lifetime value, interest affinity — and the personalization surfaces read those traits to decide what a given visitor sees on your site or in your app. There is no second event pipeline to buy and no nightly export to keep alive, because the traits are computed where the interactions already happen.
This post covers what the engine actually does, where the boundary with a Segment-style collection CDP sits, who owns the consent posture that personalization runs under, and a checklist you can verify in your own account before you take our word for it.
What the personalization engine does
Everything below is shipped, and each surface is reachable from the dashboard today.
Computed traits as the input. Trait definitions come from the no-code rule builder or raw SQL, and they recompute in real time as events land. The segmentation vocabulary the surfaces speak is concrete — champion, engaged, new, passive, at-risk, dormant, lost — so "what should this visitor see" is decided against a maintained label, not against a snapshot from last night's batch.
On-site and in-app content slots. Personalization slots bind a named placement — a hero, a banner, a product rail — to a segment label, with content, a CTA room, per-variant priority, and an active switch. A visitor resolved to "at-risk" can see a retention offer while a "champion" sees the loyalty prompt, decided per visitor at render time. A/B variants and lift reporting are part of the same surface, so a slot experiment closes its own loop rather than exporting to a separate testing tool.
Next-best-product ranking. The recommendations surface ranks a candidate catalog for one profile by content affinity, with the per-factor breakdown — category, brand, tag, price fit, popularity — returned with the ranking. It ranks; it never sends anything on its own. An orchestrator wires the ranked result into a catalog send or an on-site rail.
Next-best-action decisioning. Given one profile and the rolled-up counts for candidate arms, the decisioning engine picks the best variant, channel, and send-time under a principled policy, and returns the full scored breakdown. The same rule holds: it decides, and the execution layer dispatches.
The common shape across all four: the decision is stateless and side-effect-free, computed on demand from the profile's current traits. No stored model drifts, and nothing fires a message as a byproduct of asking "what should this person see."
Where the Segment-style boundary sits
Event collection parity is real, and it is worth being exact about it. Orbit's CDP collects cross-channel interactions, resolves them against a golden record, computes traits, builds segments, and syncs the result out to a warehouse — the jobs a Segment-style pipeline also does. For collecting from dozens of unrelated tools far outside communications, a dedicated pipeline still earns its place, and the Orbit vs Segment page says so plainly.
The difference shows up one step later. A collection CDP routes clean data somewhere; acting on it still means buying a separate ESP, a separate personalization vendor, a separate loyalty platform, and keeping the trait payloads between them fresh. Orbit's execution surfaces — messaging, on-site personalization, loyalty — are in the same platform, reading the same traits. The personalization slot a visitor triggers is reading the engagement label the CDP maintains, not a trait exported to a third-party personalization tool over an API you have to babysit.
That is the inverse shape the Segment comparison documents from the other direction: parity on collection, divergence on what happens after collection. If your evaluation is "we need event routing to forty unrelated tools," Segment still wins that query. If it is "we need the profile to change what the customer actually sees," the pipeline adds a vendor without adding a capability.
Who owns the consent posture
Personalization reads resolved profile traits, which makes consent a first-order question rather than a compliance footnote. The honest answer is the same one the platform gives everywhere else: the posture is tenant-owned, and the platform enforces it.
Orbit exposes the controls — trait and segment definitions, consent verification before audience activation, retention and erasure behavior — and every one of them is set in your account, scoped to your organization. When a segment activates to a destination, consent is checked per profile before anything leaves, but the policy that check implements is yours. A tenant can also bind a personalization slot to no segment at all and serve it to everyone; the endorsement to personalize is tenant-configurable, not platform-mandated. Erasure cascades the same way the rest of the CDP does, so a withdrawn customer stops feeding traits, not just stops receiving messages.
Nothing in that list is a compliance decision the platform makes for you. You set your posture for your jurisdictions; Orbit enforces it at the decision point. Personalization inherits that posture — it does not route around it.
A buyer checklist you can run yourself
Each row maps to a shipped surface, so you can run the evaluation inside a trial account rather than in a deck.
- Trait freshness — define a computed trait over the rule builder or SQL and check whether it recomputes as new events land, or only on a nightly run.
- Segment vocabulary — confirm the decisioning input is a maintained engagement label (champion through lost), not an exported CSV of scores someone re-uploads.
- Content-slot targeting — create a slot bound to a segment label and verify the variant, priority, and active controls in the same surface that reports lift.
- Ranking transparency — ask the recommendations surface for a ranked catalog and check whether the per-factor breakdown (category, brand, tag, price fit, popularity) comes back with the result.
- Decision-policy choice — pick among the documented bandit policies instead of a black-box "AI" toggle, and read the scored breakdown the response carries.
- Consent at activation — activate a segment and confirm the consent check runs per profile before the audience leaves, under the policy you configured.
- Erasure reach — verify what an erasure request cascades through, including whether the personalization inputs stop deriving traits from the erased profile.
- Execution adjacency — count how many separate vendors the personalization decision has to cross before a customer sees it; on this platform the answer is zero.
Frequently asked questions
Is the personalization engine a separate product?
No. It is the native CDP's computed traits read by the personalization, recommendations, and decisioning surfaces in the same account — one platform and one pay-as-you-go bill.
Does deciding what a visitor sees send anything outbound?
No. The ranking and decisioning surfaces are side-effect-free — they return a ranking or a decision, and a separate execution layer does any dispatch. Asking "what should this person see" never sends a message by itself.
How is this different from adding a personalization vendor next to Segment?
Collection parity is genuine; the difference is execution. A Segment-plus-personalization-vendor stack exports traits across an API to decide what a visitor sees. Orbit's surfaces read the traits where they are computed, so there is one pipeline less to keep fresh.
Who sets the consent posture personalization runs under?
You do. Consent policy, retention, and erasure behavior are configured in your account; the platform enforces the configured policy at activation and decision time rather than mandating one.
Where do I verify the checklist claims?
The CDP feature page and the Orbit vs Segment comparison carry the capability statements, and every checklist row above maps to a surface reachable in a trial account.
The takeaway
Personalization on Orbit is the native CDP's computed traits, decided per visitor on your site and in your app — slots, next-best-product ranking, and next-best-action decisioning included. Collection parity with a Segment-style pipeline is real; the divergence is that the execution surfaces sit on the same platform as the profile, so acting on the data stops being a second vendor. The consent posture underneath is yours to set, and the checklist above is runnable in your own account before you trust this post.
Published 1 September 2026.