Skip to main content

​
Audience hub

The Audience hub is the landing grid at /audience that groups every operator surface of the customer data platform into one tile set — the answer to “where do I go to work on who I can reach?” when you open the sidebar’s Audience entry. One page holds the whole picture the individual consoles typically get described through: import identifies the person behind each row, identity resolution and merge collapse the duplicates, lists and linked audiences define a membership, activation pushes that membership out, and consent with opt-outs govern whether the push is allowed. Read top to bottom, the hub is the lifecycle.

​
What the hub surfaces

Four families of consoles share the grid, in the order a contact record usually walks them:
  1. Bring data in. Import, Imports (the migration and job history), Identity resolution, and Merge turn raw rows into one clean golden profile per person. Run them first: every tile downstream reads the profile they leave behind.
  2. Define who. Lists, Linked audiences, Computed traits, Decisioning, and Contact fields build and describe the membership — static hand-picked groups, relational audiences over warehouse entities, deterministic derived tags, and the next-best-action scorer.
  3. Push it out. Activation syncs first-party segments to the paid-media ad networks for acquisition or suppression.
  4. Govern it. Consent, Opt-outs, and Churn risk keep the membership lawful and worth keeping — a per-contact consent ledger with live delivery verdicts, the suppression and evidence surface, and the retention-risk ranking.
Supporting consoles sit beside the four families: Accounts (the B2B golden-record view), Contacts (the per-person record browser), and Fields (the schema explorer segments read from).

​
The tile map

Every tile on the grid is one console. The table is the map of the hub — the route each tile opens and the one-line job it performs:

​
When to open which

Four tasks cover most visits. Walk the decision tree from the top and open only the tile the branch names:
  • Bring data in. Fresh rows arriving today — open Import for one CSV-through-wizard job, or Imports for the platform-migration connectors and the job history. Duplicates piling up — open Identity resolution for the probabilistic review queue when a fuzzy match needs a human call, or Merge for the deterministic collapse you already decided. New identifiers still fragmented — open Identity resolution and check the rule simulator before you merge by hand.
  • Define who. A fixed hand-picked group — open Lists. A rule over contact facts that re-evaluates itself — open Computed traits for the deterministic predicate, or Linked audiences when the predicate traverses your warehouse entities. A per-profile choice among message variants — open Decisioning. Before any of these, Contact fields (and Fields on the schema side) tells you which attributes exist to build on.
  • Push it out. Any audience readied above — open Activation, choose the ad-network destination, and confirm the segment syncs as acquisition or suppression.
  • Govern it. Before you queue a send for one contact — open Consent and run the verdict check. Evidence for a carrier, DPA, or audit — open Opt-outs and export. A membership worth defending — open Churn risk and save the high-tier scorers as a retention segment before they lapse.

​
RBAC — which tiles render for which role

The hub itself renders every tile to every member role; the gating lives on the destination surface, not on the grid:
  • Read access. Every tile’s underlying read endpoint gates to the owner, admin, or developer role plus the contacts:read scope — the same gate that protects every CDP surface exposing PII-bearing traits. A viewer seat sees the tiles in the grid, but the destination page refuses the read with a 403. Restricting the grid was rejected on purpose: the tile hide is presentation-only, never an authorisation boundary, and the same guard fires either way.
  • Write access. Identity-resolution merges, consent grants, opt-out edits, and activation syncs each carry the owner/admin/developer gate plus their own scope (contacts:write, or the destination-specific credential). Viewer seats can run none of the writes even when the read side of a surface is open to their role (the consent ledger read is the one open case).
  • Developer seats equal owner/admin on every tile here — the split that actually changes the grid is viewer versus the rest, because writes and PII-bearing reads close at the same boundary.
Each tile has one long-form guide; open the hub tile for the console and the guide for the workflow:

​
Concepts behind the consoles

Four concept pages explain the models every tile above leans on:

​
Troubleshooting

Two failure modes recur across the hub:
  • A tile is visible but the page refuses to load. The role gate fires server-side even when the grid rendered the tile — the hub does not pre-filter by role, so a viewer seat sees the full grid and hits the 403 at the destination. Grant the seat the owner, admin, or developer role plus contacts:read (and the write scope where it applies) rather than hunting the grid for a missing tile.
  • The grid shows a tile whose console is empty. An empty Identity resolution queue with known duplicates usually means the deterministic rules already merged the easy pairs and the scan has not re-run; an empty Activation list means no segment has been synced yet. Start at the family entry — Import first, then Identity resolution, then the membership tiles — and the downstream consoles fill in order.