Every campaign you send is only as good as the profile it reads. If the same customer lives in your account as three contacts — an email from a form, a phone number from WhatsApp, an anonymous session from your app — then "top 20% by propensity" is three partial guesses, and the message you meant for one person can reach them twice or not at all. That is why identity resolution sits underneath every other CDP mechanic, and why this post walks the exact surfaces Devotel Orbit ships for it: Audience → Identity resolution, Audience → Computed traits, Audience → Propensity segments, Audience → Churn risk, Audience → Merge, and Audience → Consent. If the acronyms blur together, the CDP vs CRM decision post is the framing piece; here it is the mechanics piece, screen by screen.
1. Why identity resolution underpins every campaign CDP
A customer data platform earns its keep on one operation: deciding that these identifiers belong to the same person. Everything downstream — segment membership, funnel math, predictive routing, propensity scoring — reads the contact row that operation produced. When it goes wrong, the failure shape is not subtle: membership counts inflate, a churn score splits across two halves of one person, and the conversation timeline opens parallel threads for a single customer. The Identity resolution concept doc names it precisely: every segment membership, funnel, attribution model, and routing decision is only as correct as the contact row it reads.
Orbit resolves identity on four normalized keys — your external id, email, phone in E.164, and the SDK-minted anonymous id — with a precedence order you set yourself. Deterministic matching (equal on a declared key) groups profiles that provably share an identifier; probabilistic matching (a fuzzy name, a respelled phone, a shared handset) ranks pairs into a review band for a human instead of merging them unattended. The distinction matters for operations: the deterministic layer can run safely on a schedule, while the probabilistic layer produces a queue for a steward. Set it too loose and you over-merge — the simulator catches that in preview before the rule goes live, not afterward on production contacts.
So before you trust any segment, the question is which version of the customer the segment counted. Identity resolution is what makes "one customer, one profile" an actual property of the data rather than a hope.
2. What Orbit's Audience hub actually ships
The CDP functions live in one place: the Audience section of the dashboard. These are the exact screens, and each one is shipped, not roadmap.
Audience → Identity resolution. The operator console for duplicates: run a deterministic preview without writing anything, auto-merge the groups that clear your confidence threshold, and work the probabilistic review queue. When you change a rule, a simulator previews the blast radius — a rule that would collapse dozens of contacts into one profile gets flagged as an over-merge before you save it. The API equivalents are POST /api/v1/cdp/identity-resolution/preview, /run, and /simulate.
Audience → Merge. Detect and merge duplicate contacts in one pass. Every merge returns a merge id, and the undo window stays open for 30 minutes — an incorrect fold is recoverable, not silent. Survivorship is decided by per-request pins first, then your tenant policy (prefer source, prefer target, most recently updated, prefer the record a named system like your CRM produced), then a safe default: blanks never overwrite a populated value. The full audit list lives on the merge history feed, and the deeper walkthrough of survivorship rules is the merge-rate operator guide.
Audience → Computed traits. Define a trait once — lifetime value, last-seen channel, days since last inbound — as a no-code rule or raw SQL, and it becomes a maintained field on every profile. Segments recompute as events land, so the trait your journey branches on is current rather than a nightly batch export.
Audience → Propensity segments. Rank contacts by likelihood of a defined outcome — purchase, reply, renewal — and let the ranking feed a segment whose membership recomputes as events land. Audience → Churn risk. Score each profile's drift so retention plays run before the exit instead of after it. Because both scores compute over the unified event stream, they reflect the whole relationship — purchases, inbound messages, missed deliveries — not one channel's slice.
Audience → Consent. The consent inspector: one contact's complete grant and revocation ledger by channel (SMS, voice, email, WhatsApp, push, MMS, fax), plus a verdict simulator that returns the exact allow or block decision the dispatch path would compute if you tried to send today. It is the screen you open before you queue a send, and the screen you open when a send was suppressed and you need to know why.
Audience → Imports. Bring CRM and legacy CSVs in through the same identity index, with external id first so re-imports converge instead of duplicating. Audience → Activation. Publish a saved segment to a paid-media destination or your own webhook sink on a schedule you control — consent-checked per member before anything leaves.
3. A worked example: high-propensity minus churn-risk into WhatsApp
Say you run the quarterly re-engagement play: reach the customers most likely to buy in the next cycle, excluding the ones drifting toward exit, over WhatsApp. On Orbit that is a data exercise you run once, not a vendor integration.
First, make the profiles trustworthy. In Audience → Identity resolution, run the preview, let auto-merge take the high-confidence groups, and clear the review band — the play is worthless if 15% of the target population is one person counted twice. Second, define the two traits that carry the decision: a propensity score on the purchase outcome from Audience → Propensity segments, and the churn-risk score from Audience → Churn risk. Third, build the segment — propensity in the top band, churn risk below your cutoff — and watch its membership settle as profiles finish merging; auto-refresh segments re-evaluate on their cadence, so the count you activate is the count as of now. Fourth, gate it on consent: open Audience → Consent on a sample of members, confirm the WhatsApp line shows an active grant, and rely on the per-profile consent check at activation time as the backstop for the rest — opted-out members never leave, by construction. Finally, wire the segment into the WhatsApp journey: the journey branches on the same traits the segment used, so a member whose churn risk spikes mid-flight falls out of the persuasion branch into the retention branch without a rebuild.
Compare the same play on a split stack: export from a CRM, resolve identities in a standalone CDP, push to a journey tool, and re-verify consent at the destination. Three systems, four sync delays, and the segment is stale before the first message. The mechanics above are one account.
4. When you don't need a full CDP vendor
The boundary is worth stating honestly, because an external CDP is sometimes the right answer and sometimes overhead. If your customer data collection spans dozens of unrelated tools — a retail POS, a data warehouse, three SaaS products, an ad platform — a standalone CDP that specializes in breadth of connectors earns its price, and Orbit's reverse-ETL feeds that stack profiles and traits on a schedule rather than pretending to replace it. The CDP vs CRM vs warehouse decision post lays that matrix out.
If, on the other hand, your segmentation problem is the communications problem — "reach the right people on SMS, WhatsApp, voice, and email, with consent honored, and stop paying an integration tax to keep the profile current" — then the segment you needed is downstream of exactly the interactions Orbit already carries. Buying an external CDP for that case buys you a pipeline back to your own channels. The deciding question is not "do we need a CDP's features" — it is "where do our customer events already live." If the answer includes your messaging and voice traffic, the native copy of that event stream is the one your segments should read.
5. Privacy and consent mechanics — tenant-owned, enforced at send time
Consent is the one CDP mechanic that cannot be an afterthought, because it gates the last step: delivery. Orbit keeps the consent ledger per contact and per channel — grants, revocations, the policy template and lawful basis they were captured under — and enforces it at activation and dispatch, per profile, before anything leaves. A keyword STOP on a phone number fences every channel that address can reach in one ledger write; the consent-proof-first post is the operating manual for running the ledger as an asset.
Two properties matter for a communications leader vetting this machinery. First, everything above is tenant-owned: the identity rules and their precedence, the auto-merge threshold, the survivorship policy, the consent posture, and the activation cadence are controls in your account, scoped to your organization — the platform supplies the enforcement, you set the policy it enforces. Second, the identity machinery is reversible and audited: merges undo inside their window, and every fold writes a durable audit row with the confidence and the corroborating identifiers, which is the answer to the GDPR erasure and profiling questions before counsel asks them.
Frequently asked questions
Where do I start if our contact database has years of duplicates?
Run Audience → Identity resolution: a deterministic preview first, then the auto-merge on high-confidence groups, then the review queue. Nothing merges without either clearing your threshold or a steward's accept, and every merge is reversible inside the undo window.
Do propensity and churn scores update as new events land?
Yes. Scores and computed traits recompute over the unified event stream, and auto-refresh segments re-evaluate on their cadence — the segment you activate reflects now, not last night's batch.
Is consent really checked before a segment activates?
Per profile, at activation time. Opted-out members never leave for any destination, and the Consent inspector shows the exact verdict the dispatch path would compute before you run it.
Do we still need Segment or another standalone CDP?
Only when collection breadth across unrelated tools is the requirement. For communications-driven segmentation, the native CDP removes the pipeline; the decision post CDP vs CRM + native CDP and the warehouse decision draw the line both ways.
The takeaway
Identity resolution decides whether your segment counts people or duplicates; propensity and churn scores decide who the segment should hold; consent decides who is allowed to receive anything; and activation decides where the audience keeps landing. All four mechanics ship in one Audience hub — verify on the CDP feature page, then open Audience → Identity resolution and run a preview before the next campaign sizes itself on profiles you have not resolved.
Published 25 September 2026.