> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Audience hub: the operator surface set for the customer data platform

> Navigate the /audience hub as one customer-data lifecycle — bring data in, define who, push it out, govern it — with a per-tile map, role visibility, and a deep link into each console's guide.

# 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:

| Tile | Route | What it is |
| - | - | - |
| Contacts | `/audience/contacts` | Search, import, and manage every contact record with channel consent and lifecycle |
| Lists | `/audience/lists` | Static hand-curated lists for one-off sends and re-engagement waves |
| Computed traits | `/audience/computed-traits` | Deterministic predicates stamped onto matching contacts as first-class tags — no model spend |
| Linked audiences | `/audience/linked-audiences` | Relational audience builder over warehouse entities — target profiles by the accounts, opportunities, and products they link to, without SQL |
| Contact fields | `/audience/fields` | The schema explorer — every contact field, trait, and custom property your segments and personalization tokens read from |
| Identity resolution | `/audience/identity-resolution` | Probabilistic merge review with confidence bands and a side-by-side diff of each candidate pair |
| Merge | `/audience/merge` | Deterministic duplicate-collapse screen — preview the dry-run, pick the survivor, carry consent forward |
| Decisioning | `/audience/decisioning` | Per-profile next-best variant, channel, and send-time from a conversion bandit, with the full scored breakdown |
| Churn risk | `/audience/churn-risk` | Rank the at-risk population with the trained churn-propensity model and save the top scorers as a retention segment |
| Accounts | `/audience/accounts` | Every organization in your audience as a golden record — member contacts plus parent/child hierarchy, for account-based audience building |
| Activation | `/audience/activation` | Sync first-party segments to paid-media ad networks (Meta Custom Audiences, Google Customer Match, TikTok, LinkedIn) for acquisition or suppression |
| Consent | `/audience/consent` | The Consent inspector — one contact's consent ledger plus a live allow/block verdict simulation per channel |
| Opt-outs | `/audience/opt-outs` | The per-channel suppression list plus consent receipts, exportable as GDPR / CCPA / TCPA evidence |
| Import | `/audience/import` | The CSV import wizard entry point — shape the file, dry-run, map consent, dedupe |
| Imports | `/audience/imports` | Migration jobs and import history — the platform-migration connectors plus the queued → running → partial-success/failed job lifecycle |

## 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.

## Deep-link list — a guide per console

Each tile has one long-form guide; open the hub tile for the console and the guide for the workflow:

| Tile | One line | Guide |
| - | - | - |
| Identity resolution | Reviews the probabilistic merge queue with confidence bands | [Identity resolution](/guides/identity-resolution) |
| Linked audiences | Builds relational audiences over warehouse entities, no SQL | [Linked Audiences](/guides/linked-audiences) |
| Computed traits | Authors deterministic trait rules stamped as tags | [Computed traits](/guides/computed-traits) |
| Churn risk | Tiers the trained churn model into a retention segment | [Churn-risk scoring](/guides/churn-risk-scoring) |
| Decisioning | Scores the next-best variant, channel, and send hour per profile | [AI decisioning](/guides/ai-decisioning) |
| Imports | Operates migration jobs end to end with pause/resume and rollback | [Migrations console](/guides/audience-migrations-console) |
| Import | Picks the right surface (CSV wizard, async jobs, CDP ingest, migration connectors) and runs it | [Import or migrate contacts](/guides/import-and-migrate-contacts) |
| Consent | Shows one contact's consent ledger plus a live destination verdict | [Consent inspector](/guides/audience-consent-inspector) |
| Opt-outs | Reads and exports the suppression list and consent receipts | [Opt-outs console](/guides/audience-opt-outs-console) |
| Merge | Preview, pick the survivor, carry consent forward | [Merge duplicate contacts](/guides/contact-merge) |
| Contact fields | Model metadata reused across segments and personalization | [Custom fields](/guides/custom-fields) |

## Concepts behind the consoles

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

* [CDP identity resolution](/concepts/cdp-identity-resolution) — how deterministic rules and the probabilistic scan fold into one golden profile.
* [Decisioning](/concepts/decisioning) — how the bandit ranks arms under consent and timing eligibility.
* [Consent and suppression model](/concepts/consent-and-suppression-model) — how the ledger, the verdict, and the suppression list decide each send.
* [Contact merge policy](/concepts/contact-merge-policy) — which values survive a collapse and how consent follows the survivor.

## 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.