The customer data layer, built in.

The difference

Included, not integrated.

A customer data platform you buy separately spends its life syncing: the profile is over here, the send is over there, and the gap between them is where the mistakes live. Here the record and the action are one system. The profile a segment reads is the profile a send checks.

• One customer record per brand, held by the platform that acts on it.
• No sync window between a data layer and the tools that send.
• A first-party warehouse on every plan – not a second vendor and a second contract.

Ingestion

Six doors into one first-party warehouse.

Getting the data in is usually the part that kills the project, so there are six ways in and none of them need an integration team standing by. Most tenants sit on Postgres; larger volumes run on ClickHouse. Re-sent data replaces itself, so nothing double-counts.

• An SDK for events on your site or app.
• Webhook push – one endpoint, your own keys, on your schedule.
• Self-serve pull from your own Postgres or MySQL: point it at the table and it runs on a rhythm.
• File feeds, CSV upload and Shopify, for the data that arrives another way.

Identity

One person, resolved deterministically.

Identity resolution here is a ladder of hard identifiers, in order, with no probabilistic guessing. E-mail first, then your own external id, then the customer id, then the visitor id that carried someone before they were known.

• E-mail, then external id, then customer id, then visitor id – in that order.
• Hard identifiers stay unique within a brand; the record that holds one absorbs the other on a merge.
• Merged keys forward, so nothing that pointed at the old record breaks.
• Nothing merges on the evidence of a shared device – a family laptop stays two people.

Segmentation

Segments that rebuild themselves.

Segmentation is not a saved filter someone remembers to re-run. Every segment re-materializes on a 10-minute cycle and swaps atomically, so a journey reading it never sees a half-built list. RFM sorts your buyers into eight lifecycle stages, with churn risk and health scores per person.

• A 10-minute refresh with an atomic swap – readers never catch a list mid-write.
• RFM into eight lifecycle stages, plus churn risk and health scores.
• Honest ceilings: one audience holds up to 500,000 members, a saved RFM audience up to 250,000, and we raise them for a named account. Bigger than that belongs in your own warehouse, and we will say so.

Activation

From segment to send, without an export.

A segment is worth what it can act on. These go straight into journeys, campaigns and ad audiences inside the platform, and every one of those paths runs through the same suppression gate.

• Email, SMS, push and on-site messages all read the same segment.
• Marketing and transactional streams are kept apart at the send path.
• Ad audiences push to Meta and Google through the suppression gate, never around it.
• Anyone suppressed after a push is removed from those audiences nightly.

Governance

Consent, erasure, and a way to read it back.

Governance is enforced in the path, not written on a checklist. Consent and suppression are checked when data is written and again when a message is sent. An erasure writes a tombstone, so a nightly connector cannot resurrect someone you deleted.

• Consent and suppression enforced at the write and at the send.
• Erasure leaves a tombstone – the person stays deleted through the next sync.
• A subject access export per person, in JSON, across every rail we hold.
• A read API under a data:read scope: profiles, one person by identifier, the members of a saved segment, or everything changed since a timestamp – JSON or CSV.