Step 2 — User Identifiers
Select User Identifiers
An identifier is any column that can point at a person — an email address, a CRM number, a cookie ID, a loyalty card. Step 2 is where you mark them and say what each one is.
This is what lets BPP recognise the same person across tables. It is also what connects an event to whoever performed it, which is why you mark identifiers in event tables too, not just user tables.
The layout
The step is organized by ID type, not by table: one card per ID type, each listing every field across every table that carries that type. Copilot's analysis proposes an initial set of fields and types, so most cards are already populated when the step opens.
Each field appears as a chip showing its name, data type, source table and — if Copilot proposed it — an AI detected badge.
Use the search box (next to Start over, at the top of the wizard) to filter chips across every card by field or table name.
Moving a field between ID types
Drag a chip from one card to another to reassign its ID type. BPP matches people by type and value, so moving a field into a card changes who it will be matched against — not just where it is displayed.
To remove a field as an identifier entirely, use the × on its chip.
Adding a field
Every card has an Add field button that opens a picker: choose a table from the left rail (or search across all of them), pick a column, and confirm. Adding a field this way assigns it directly to that card's ID type.
To create a brand-new ID type, use the New ID type card at the end of the list. Click it, type a name, and press Enter (or Create). It is saved to your account's catalogue immediately, so it is offered again the next time you onboard a table — not just for this field.
Identifier types belong to you, not to a fixed platform list. If your business runs on a loyalty card number or a franchise account code, declare it. Your account starts with Email, Personal Phone, Internal ID and Cookie ID.
Each card header has two actions: untick every field in the group, and — for an ID type you created — delete the ID type from your catalogue (its fields are unticked first). The four built-in types cannot be deleted.
:::tip Use the built-in Email and Personal Phone types Values declared Email or Personal Phone are cleaned before matching: emails are trimmed and lowercased (Gmail dots removed), phone numbers are brought to international format, using your account's default country (set by Bytek, Italy unless changed) for numbers written without a prefix. A value that is already a SHA-256 hash is kept as it is, so a column of hashed emails and a column of clear emails do not match each other. A type you create matches values exactly as written (only surrounding spaces are removed), so declare email and phone columns with the built-in types. :::
:::info Matching is by type and value
BPP matches people by identifier type and value — never by column name. crm.email_address and shop.user_email resolve to the same person because both are declared Email and hold the same value, regardless of what the columns are called.
The corollary matters just as much: two columns given the same type will be matched against each other, so do not reuse one type for two unrelated numbering schemes. :::
Personal data
There is no personal-data setting in this step. Identity resolution runs inside your own BigQuery project, so declaring a column as an identifier does not copy its values into BPP. Email and phone identifiers are also kept out of external enrichment providers by default; see Tables Configuration.
Tables without an ID yet
A banner lists any table that has no identifier marked at all, with an Add field shortcut scoped to that table. A table with no identifier has no way to connect to a person, and blocks the gate below.
Needs attention
A field can be ticked as an identifier but not fit cleanly into a card — because its data type cannot be matched on (only text and whole-number columns qualify), or because it has no ID type yet. These land in a Needs attention panel instead of a card: drag them into a card to give them a type, or untick them if they were marked by mistake.
Identity Resolution Preview
The grouping you build here — which ID types join multiple user tables, which only link events to users, and which resolve nothing because they appear in a single table — is summarized in the User Identifiers card on Step 5 — Review & Activate, not on this step. Check it there before activating.
Gate
Select at least one ID in every table before you can continue. A table with no identifier has no way to connect to a person, and nothing downstream could use it.