The CDP that adapts to your business, not the other way around.
Point CDPx at your warehouse. Your model walks in as-is.
Your warehouse
- users
- policies
- claims
- agents
4 tables · 3 relationships
- users→policies1:∞
- policies→claims1:∞
- policies→agents∞:1
- ●user_id
- ○first_name
- ○city
- ●policy_id
- →user_id
- →agent_id
- ○renewal_date
- ●agent_id
- ○name
- ○tier
- ●claim_id
- →policy_id
- ○status
- ●occurred_at
- →user_id
- →policy_id
- →claim_id
Five capabilities, one thread. Pick your industry below and follow it end-to-end.
Open a profile. Your entities have their own tab.
Policies don’t hide inside Attributes. They sit right next to Basic Info and Events as a first-class tab, with every field and relationship intact.
Build the audience a flat CDP can’t even describe.
“New York customers with a Health policy renewing in 30 days and a pending payment”, an audience most CDPs can’t build without a data analyst, because those filters live on the policy and the payment, not the user. CDPx builds it in the UI, live.
Journeys that run per policy, not per person.
One customer, three policies, three renewal dates. A per-person journey fires them all at once, three reminders in a day. CDPx runs a separate trip per policy, so each renewal is timed to that policy alone: the right nudge, on its own schedule, never a pile-up.
Merge tags from your schema.
“Your policy is expiring” is the best a user-only CDP can do. CDPx turns any entity field into a merge tag: {{policy.renewal_date}}, the details, even the agent’s name. So every message carries the real record, not a generic nudge
Open a profile. Your entities have their own tab.
Accounts don’t hide inside Attributes. They sit right next to Basic Info and Events, as a first-class tab, with every field and relationship intact.
Build the audience a flat CDP can’t even describe.
“New York customers with a credit card and a transaction above $5K last month”, an audience most CDPs can’t build without a data analyst, because those filters live on the account and the transaction, not the user. CDPx builds it in the UI, live.
Journeys that run per loan, not per person.
One customer, three loans, three EMI dates. A per-person journey fires them all at once, three reminders in a day. CDPx runs a separate trip per loan, so each EMI is timed to that loan alone, the right nudge, on its own schedule, never a pile-up.
Merge tags from your schema.
“Your loan is expiring” is the best a user-only CDP can do. CDPx turns any entity field into a merge tag, {{loan.emi_due_date}}, the details, even the manager’s name, so every message carries the real record, not a generic nudge.
Open a profile. Your entities have their own tab.
Prescriptions don’t hide inside Attributes. They sit right next to Basic Info and Events, as a first-class tab, with every field and relationship intact.
Build the audience a flat CDP can’t even describe.
“New York patients on a chronic prescription with an abnormal lab in 30 days”, an audience most CDPs can’t build without a data analyst, because those filters live on the prescription and the lab report, not the user. CDPx builds it in the UI, live.
Journeys that run per prescription, not per person.
One patient, three prescriptions, three refill dates. A per-person journey fires them all at once, three reminders in a day. CDPx runs a separate trip per prescription, so each refill is timed to that prescription alone, the right nudge, on its own schedule, never a pile-up.
Merge tags from your schema.
“Your prescription is expiring” is the best a user-only CDP can do. CDPx turns any entity field into a merge tag, {{prescription.next_refill_date}}, the details, even the doctor’s name, so every message carries the real record, not a generic nudge.
Open a profile. Your entities have their own tab.
Vehicles don’t hide inside Attributes. They sit right next to Basic Info and Events, as a first-class tab, with every field and relationship intact.
Combine entities. Find segments no flat CDP can see.
“New York owners with an out-of-warranty vehicle and a service due in 15 days”, an audience most CDPs can’t build without a data analyst, because those filters live on the vehicle and the service order, not the user. CDPx builds it in the UI, live.
Journeys that run per vehicle, not per person.
One owner, three vehicles, three service dates. A per-person journey fires them all at once, three reminders in a day. CDPx runs a separate trip per vehicle, so each service is timed to that vehicle alone, the right nudge, on its own schedule, never a pile-up.
Merge tags from your schema.
“Your vehicle is expiring” is the best a user-only CDP can do. CDPx turns any entity field into a merge tag, {{vehicle.next_service_date}}, the details, even the advisor’s name, so every message carries the real record, not a generic nudge.
We didn't build four versions of CDPx. Those are four different warehouses , read by the same product.
Your warehouse stays the source of truth
Every team, same data, same way.
Marketing sees exactly what analytics, support and data science see.
No drift.
When the lake updates, CDPx is updated - segments, journeys and profiles included.
Your governance travels with it.
Access and definitions live where your data lives.
Keep your customer data to yourself. Say hello to ZeroPII.
Everything you just saw needs your customers’ real details. Who to message, and what to say to them. Normally a vendor gets those details. With ZeroPII, a first for customer engagement platforms, you keep them. We build a small agent, you run it inside your own network, and it handles both of those jobs (segmentation and personalization) there. We only ever see scrambled IDs.
