Skip to main content

​
CDP data catalog and identity rules

Two tabs on Integrations → CDP own the governance side of your customer data: Data catalog aggregates every declared event and property into one data dictionary with its sensitivity classification, and Identity resolution holds the operator-authored rules that decide how an inbound event’s userId merges onto a contact. This guide covers reading the catalog, classifying fields, authoring match rules safely, and setting the survivorship policy that decides which value wins a merge. The concept — how an incoming identifier becomes one contact, and what merges write downstream — is Identity resolution and merge semantics. This guide teaches the in-app surfaces that let you author and audit that policy.

​
1. Data catalog: audit where personal data lives

The Data catalog tab is a per-tenant data dictionary. It reads your tracking plan and renders one row per declared event plus one row per declared property, each carrying the governance metadata you attach to it:
  • Sensitivity — none, pii, phi, financial, or sensitive. Unclassified entries report none.
  • Owner — the team accountable for the field (free text, e.g. data-platform).
  • Allowed use — the purposes the field may be used for (e.g. analytics, support).
  • Policy — a reference to the governing policy (retention, masking, lawful basis).
The rollup at the top counts classified versus total entries and breaks the total down per sensitivity class, so a governance owner can see at a glance how much of the plan is still unmapped. Filter the table by sensitivity class, owner, or classified-only to build a review list — the filters are applied server-side, so an empty result means nothing matched, not that the dictionary is thin.

​
Classify a field

The catalog is read-only. Classification is authored on the tracking plan, stored alongside each event’s property rules, and the catalog tab aggregates it. Add a classification block to a property rule — or at the top level of the schema for the event as a whole — when you upsert the plan row:
Classification never affects ingest. The tracking-plan validator reads only type and enum; sensitivity, owner, allowed use, and policy are stored verbatim and surfaced purely for audit. Classifying a field cannot reject events, break a producer, or change what a destination receives — it answers “where does personal data live?” before that data fans out to destinations and exports. To mark progress, filter the catalog to Classified only off and work the none rows down to zero. A common cadence: classify on the day you declare the event, then re-review the catalog when a destination or export is added.

​
2. Identity rules: author how inbound identifiers merge

The Identity resolution tab on Integrations → CDP holds the merge rules that resolve an inbound event’s userId to an existing contact. Each rule has three fields:
  • Match shape — one of External ID, Phone, Email, or Anonymous ID. The shape is the natural key: one row per shape per tenant, so adding a shape that already exists updates that row rather than duplicating it.
  • Priority (1–1000) — the order the resolver tries shapes in. Lower runs first; the seeded default is 100.
  • Enabled — a disabled rule stays in your list but is skipped at resolve time, which is how you stage a removal without deleting the audit history.
Every tenant starts with a seeded default: External ID enabled at priority 100. That default resolves a userId against the contact’s external identifier and nothing else. The two opt-in shapes change what an inbound userId is allowed to match:
  • Phone — treat userId as an E.164 phone number and match the contact’s phone. Only enable this when you control the SDK and deliberately ship phone numbers as userId. A phone-shaped userId that was never meant to be an identity key will stitch the wrong people together, so the tab labels this opt-in.
  • Email — same trade-off for email-shaped userId values.
  • Anonymous ID — matches the platform-assigned anonymous identifier stored on the contact. Safe to enable; it carries no attribution risk because the identifier is platform-owned.
Priorities matter when more than one shape could match. Put the most trustworthy identifier lowest (first) so it wins, and leave slack between values — inserting a rule between 100 and 200 later beats renumbering.

​
Simulate before you save

Changes to the three shapes the deterministic resolver actually matches on — external ID, email, and phone — are gated: the dashboard refuses to save until you have run a simulation for that shape in the current browser session. A save attempt without one shows a toast naming the simulation to run.
  1. Open Audience → Identity resolution and run the simulation panel against the rule set you intend to apply. The simulation is read-only: it estimates how many clusters the proposed rules would form, how many profiles would merge, and flags rules that over-merge.
  2. If the estimate looks right, return to Integrations → CDP → Identity resolution and save the same change.
  3. If it flags an over-merge (one rule stitching far more profiles than expected), narrow the proposal — disable the aggressive shape or raise its priority so a stronger identifier resolves first — and re-run the simulation.
The gate is session-scoped and ignores priority-only edits: re-ordering rules carries no new merge risk, so it never forces a re-simulation. Deleting a rule is never gated; the resolver falls back to the seeded default for that shape.

​
Author the survivorship policy

Match rules decide which contacts merge. The survivorship policy decides which value wins when the merge folds two rows into one — per field, for every merge from then on: newest value wins, oldest wins, a named source system wins, or a non-empty value always beats an empty one. That rule builder lives on Audience → Identity resolution, directly beneath the merge review console, because it governs the merges you review there. Draft the policy, preview it in the same simulation run you use for match rules, then save. Clearing the policy reverts every field to the legacy fallback; the policy itself is validated when it is applied, so an invalid draft fails on save rather than silently half-applying.

​
Policy vs. review queue

The two surfaces split authoring from adjudication:
  • Integrations → CDP → Identity resolution is where you author the policy — the match shapes, their priority and enabled state. Nothing here approves or rejects an individual merge.
  • Audience → Identity resolution is where the policy meets data — the auto-applied merges, the lower-confidence review queue you approve or dismiss one by one, the simulation panel, the survivorship builder, and the stitching timeline that records what merged and why.
Author the policy on the CDP page, then spend your day-to-day in the review queue. The Identity resolution guide walks the review workflow end to end; the merge semantics concept defines what a fold-in writes onto the surviving record.

​
3. End to end: declare, observe, tighten

The two tabs form one loop with the tracking plan:
  1. Declare the event. Add the event to the tracking plan in soft mode with its property rules, and tag each property’s classification as you go.
  2. Verify in the catalog. Open the Data catalog tab and confirm the event and its properties appear with the sensitivity and owner you set. Anything showing none is a gap in your governance map.
  3. Run traffic. Ship the producer. Watch the tracking plan’s violations feed until the payload and the plan agree.
  4. Watch identity. If the new event carries an email- or phone-shaped userId, the identities will not stitch until you enable that match shape. Simulate the enable first, then flip the rule on the Identity resolution tab.
  5. Tighten. Once producers are clean, flip enforcement to strict; once merge behaviour is proven, reorder rule priorities so the strongest identifier resolves first. Re-run the catalog rollup after any of this to keep the classified share from drifting back down.

​
4. Permissions and audit

  • Data catalog — visible to the owner, admin, and developer roles. It enumerates where personal data lives, so it is not exposed to marketer or analyst roles, and analyst API keys cannot read it.
  • Identity rules and the survivorship policy — readable and writable by owner, admin, and developer. Merge semantics are a tenant-wide attribution decision; the dashboard also hides the write controls for roles that lack them, and the API enforces the same restriction regardless of the UI.
Every write is recorded in the audit log: tracking-plan upserts and deletes (which carry classification changes), identity-rule upserts and deletes, and survivorship-policy updates and clears each appear with the acting user, timestamp, and the values written. Filter the audit log by resource to review who changed a rule and when — that trail is your first stop when a merge pattern shifts unexpectedly.

​
See also