​

Audience hub console map — contacts, segments, and every identity you send from

The Audience docs split coverage by feature — a deep guide for segments, one for identity resolution, one for the senders hub — because that is how the features shipped. Operators do not work that way. A tenant rolling out its customer-data layer asks one question: what do I know about a contact, and what can I send them from? This page answers it, collecting the consoles under the Audience hub in the dashboard into one map. Every console below is a tenant-owned control — you set it for your workspace, and no PII surface renders a row until you put data in. Each maps 1:1 to a route under /audience in the dashboard.

​

Why the hub is a map

The Audience hub groups every control for the surfaces that read or shape your contact base: the contacts themselves, the lists and segments that slice them, the identity machinery that keeps one person one profile, the consent and opt-out records that gate what you may send, the sender identities every outbound message signs from, and the scoring surfaces that rank contacts before you activate them. One question brings an operator here — what do I know about a contact? — and the hub answers it across contact, segment, list, identity, activation, and send surfaces. Use the map to pick the right console instead of opening the per-feature guide first; each row links its in-depth guide.

​

Tile map

Each row is a hub tile (or a route one hop deeper). The PII-marked rows render only for owner/admin/developer seats, mirroring the read gate over the PII-bearing customer-event stream (see Permission scopes). One tile breaks the namespace: Referrals cross-links to /marketing/referrals, because referral programs create contacts — the referred end-users become rows in this workspace. See the Marketing hub console map for that surface’s map. The hub also keeps a Go to Contacts shortcut at the bottom of the grid — the tile operators open most.

​

Permission scopes

The hub grants three bands, and the tile hide is presentation-only — the destination page re-checks the seat server-side:

• PII surfaces — the CDP family: Contacts (360/Journey views), Segments, Identity resolution, Merge, Computed traits, Linked audiences, Consent inspector, Accounts, Predictive models, Propensity segments, Churn risk, Decisioning, Recommendations, Activation. These render only to owner, admin, and developer seats, mirroring the read gate over the PII-bearing customer-event stream. A viewer or agent sees none of these tiles; the destination page 403s them regardless.
• Member-readable consoles — Lists, Contact fields, Opt-outs, Senders, and Imports render for every member including viewers, because their read routes are member-readable. Writes on senders (registration, domain verification) stay owner/admin/developer-gated at the API.
• API scopes through the console — API keys with contacts:read read contact rows, lists, and segments; contacts:write runs writes (imports, merges, list edits, sender registration). The CDP family additionally requires one of the three gated seats regardless of the key’s scopes.

Every console is tenant-owned: contacts, segments, consent ledgers, and sender identities live in your workspace only, nothing crosses tenant boundaries, and nothing renders until you put data in.

​

Suggested rollout order

Touch the consoles in this order when you stand the surfaces up for the first time. Each step builds on the one above it:

1. Imports then Contacts — land the first CSV or CRM export, then work the Contacts surface. Every downstream console reads this base. Skip when: you ingest contacts over the API or a source connector instead of CSV — start from the base however it lands.
2. Contact fields — define custom fields before the first import’s mapping step if your schema needs them. Skip when: built-in fields cover your schema.
3. Senders — register sender IDs and verify email domains while the import runs. It is the slowest lead-time dependency (carrier/domain verification), so start it early. Skip when: no outbound traffic yet — nothing sends until a campaign exists.
4. Opt-outs + Consent inspector — inherit suppression and consent records before you send anything. Legacy unsubscribe lists belong here, not in the campaign flight path. Skip when: truly greenfield with no legacy suppression list — the consoles then start empty and fill as events land.
5. Merge + Identity resolution — collapse deterministic duplicates and review the probabilistic band before segments read inflated counts. Skip when: the import’s merge strategy already resolved duplicates at ingest.
6. Segments (and Lists) — define dynamic slices once the base is clean. Skip when: a static list covers your only audience.
7. Computed traits — stamp deterministic derived tags segments can then predicate on, no LLM spend. Skip when: your segments read raw attributes only.
8. Linked audiences — add when you model warehouse entities (accounts, opportunities, products). Skip on B2C-simple workspaces.
9. Accounts — add B2B golden records when group ingest defines them. Skip on pure B2C.
10. Predictive models → Propensity segments / Churn risk — train the four built-in models, then rank and save the top tiers as segments. Skip when: no activation destination consumes scored audiences yet — the models still train, but nothing reads them.
11. Decisioning + Recommendations — per-profile testers once a campaign workflow calls them. Skip until a next-best-action or next-best-product flow exists.
12. Activation — sync saved segments to ad networks last. It consumes what steps 6–11 define.

Steps 1–5 unblock a working contact base. Steps 6–12 turn the base into audiences and activation.

​

Where the in-depth docs live

• Customer-360 workspace — per-contact profile, conversations, calls, journeys, and the snapshot endpoint behind the 360 tab.
• Import and reconcile contacts — CSV jobs, merge strategies, rollback; the end-to-end first-import tutorial is First contact import.
• Custom fields — the schema surface the Contact fields tile browses.
• CDP segments, computed traits, and activation — the segments guide that also introduces derived traits and ad-network activation.
• Computed traits — the deterministic rule DSL behind the Computed traits tile.
• Linked Audiences — data graphs and no-SQL relational audiences.
• Identity resolution — deterministic rules, probabilistic review, survivorship, consent-aware merges.
• Contact merge end-to-end and merge policy — the deterministic merge workflow and the survivorship rules behind it.
• Identity resolution model — how the engine bands candidates into auto-merge, review, and dismiss queues.
• Account relations — B2B account graphs, member contacts, parent/child hierarchies, and the read endpoints behind the Accounts tile.
• CDP predictive models — the four built-in models, training reports, CLV tiers, and re-activation schedules.
• Propensity segments and Churn-risk scoring — rank-by-score → save-as-segment on the trained scores.
• AI decisioning and Recommendations tester — the next-best-action and next-best-product testers.
• Opt-outs console — suppression provenance, STOP fences, and evidence export.
• Consent inspector — per-contact consent ledgers and live destination verdicts.
• Senders hub and sender-identity onboarding map — registration and verification for every outbound identity.
• Activation pipeline — register, run, and monitor segment pushes to ad networks and webhook sinks.
• Static contact lists — the Lists tile’s targeting model.
• Outbound audiences console — how lists, segments, suppression, and frequency caps compose into a campaign audience outside this hub.

​

See also

• Marketing hub console map — the same console-map treatment for Wallet Passes, Loyalty, and Referrals.
• Insights hub orientation — the map pattern applied to the analytics hub, with its RBAC visibility table.
• Consent and suppression model — the ledger the Opt-outs and Consent inspector surfaces read from.