Step 5 — Review & Activate
Review & Activate
Everything you configured, in one place. Nothing is written until you activate — up to this point the whole wizard is a draft, and closing the browser loses nothing.
What is each identifier?
The step opens with the role of every identifier type: Email, Device / anonymous ID, Person ID or Object ID. BPP suggests a role from the type and column names; change it where it is wrong, because profiles are linked safely only when each role is right. Roles are saved with the activation and stay editable afterwards; see Identifier roles.
What you are reviewing
Four summary cards:
| Card | Shows |
|---|---|
| Tables Classified | Each table with its Event / User classification, and the totals |
| User Identifiers | Every ID type in use, its role, and how many fields and tables carry it (Show fields lists the table.field pairs) |
| Unified User Model | The final field count and the user tables they are built from. One clear attribute per ID type is added automatically on activation |
| Event Mapping | Each event table, its user ID fields, and how many of its fields are visible |
Read the User Identifiers card carefully. It is the last place to catch an identifier declared with the wrong type — the mistake with the widest blast radius, because a wrong type either fails to merge two profiles that are the same person, or merges two that are not.
Activating
Activate Configuration asks for a last confirmation, then writes the configuration, creates the unified user model table and starts the first reconciliation, which assigns every person their BPP identity and builds the enriched tables.
You can start using the platform while the first reconciliation runs; see While the first reconciliation runs.
After activation
The schema becomes add-only. You can:
- edit labels, descriptions, visibility and identifier roles in Tables Configuration
- edit the user model; see Editing the User Model After Activation
- add new tables, or new columns of tables you already use, with Add Tables
You cannot rename, retype or remove an existing field. Those are changes that would silently break audiences, signals and calculated fields built on them, so they are refused rather than allowed to fail downstream.
Plan accordingly: it is worth spending the time on Steps 2 and 3 now rather than discovering a wrong identifier type after your audiences are live.