Step 3 — User Model
Build Your Unified User Model
Your user tables each describe the same people from a different angle — the CRM knows their name, the shop knows what they spent, the loyalty scheme knows their tier. Step 3 is where you decide what the single, merged version of each attribute should be. The result is one logical user table, and it is what audiences and AI models read from — not the raw source tables.
What Copilot has already done
The step opens filled in, not empty. Every column of every table you marked User in Step 1 is already a field, and columns that share a name across tables have already been merged into a single field with each table listed as a source. Identifier fields are deliberately absent — they power identity resolution and get their own attributes automatically (see Derived identifier attributes).
Your job is to check that merge, not to build it.
Finding what needs attention
The toolbar filters the list:
| Chip | Meaning |
|---|---|
| All | Every field in the model |
| Aggregated | More than one source — these are the ones with a real decision to make |
| Single source | Exactly one source; nothing merges, so no rule applies |
| Unmapped | No sources at all — blocks activation |
Aggregated is the useful one. A single-source field has nothing to decide; a field fed by three tables does.
Each row shows the field name, its type, how many sources feed it, and the aggregation rule in force. Click anywhere on a row to open its editor.
The Type and Aggregation rule column headers also carry their own filter — click the icon to narrow the table to one or more specific types or rules, on top of whatever chip is selected.
Editing a field
The expanded row gives you:
- Name and description — both drafted by Copilot, both editable
- Sources · priority order — a numbered list. Rank 1 wins wherever the rule depends on priority. Reorder with the arrows, remove with
×, add more with＋ Add source field… - Aggregation rule — how the sources combine
Priority order matters more than it looks. Where a rule resolves by priority, rank 1 supplies the value whenever it has one, and the lower ranks only fill the gaps. Putting your most complete or most trusted source first is usually the right call.
Aggregation rules
| Rule | Allowed on |
|---|---|
| First non-empty by priority | any type |
| Keep all values | text only |
| Highest value | numbers |
| Lowest value | numbers |
| Sum of values | numbers |
| Average of values | numbers |
| Most recent | dates |
| Least recent | dates |
The rule select only offers what the field's type permits, and the same restriction is enforced on activation — so a rule that is wrong for the type cannot reach your data.
A field's type comes from its first source. Changing which source is first can therefore invalidate the rule you chose; when that happens the step tells you the rule was reset rather than silently changing your data.
Keep all values produces a list rather than a single value. Copilot never proposes it for your fields, and downstream features that expect one value per user cannot consume it — reach for it only when you genuinely want every variant kept.
What Copilot proposes
Every field opens on First non-empty by priority, with one exception: a merged date field whose name says which end of a range it means. last_purchase_at opens on Most recent, signup_date and created_at on Least recent.
Numeric fields are deliberately left on First non-empty, even when the name suggests otherwise. Whether a lifetime_value spread across a CRM and a shop should be summed depends on whether those sources cover the same transactions — and nothing in your schema says whether they do. Summing overlapping sources would double-count silently, so the choice is left to you.
Derived identifier attributes
For every identifier type in use, the platform automatically adds one user-model attribute holding its clear values — an email attribute, a phone attribute, and so on. These:
- use Keep all values: a person with two emails across your tables keeps both, as a list of text values
- list their sources with user tables first, then event tables
- still expand like any other row, but to a read-only panel — sources and rule are shown, not editable
- cannot be removed, and their field name is fixed; the label and description are editable
They exist so that destinations needing a clear reconciliation key have one. The values come from the _bpp copy in your own warehouse; ad platforms receive them hashed at send time.
Adding your own field
Add Field appends an empty field. Give it a name and at least one source. Until you do it counts as Unmapped and blocks activation — an unmapped field would otherwise materialise as an all-null column, which reads as missing data rather than missing configuration.
Gate
Every field needs a name and at least one source before you can continue.
After activation
This isn't your last chance to touch the model — see Editing the User Model After Activation for how to revisit fields, sources, and aggregation rules once your dataset is live.