Identifiers & Hashing
Identifiers are the foundation of BPP. They let the platform resolve user identities across multiple data sources and unify events and attributes into a single customer profile — the Bytek ID.
This page is the practical reference for which identifiers to provide, how BPP normalizes and hashes PII, and how identifiers are mapped. For the conceptual walkthrough of how matching and stitching work, see User Reconciliation.
How identifiers map to the Bytek ID
When you map your dataset in the Data Source Manager, each column that represents an identifier is declared with:
- Identifier type — a canonical name (e.g.
email,cookie_id,crm_contact_id). - External sharing — whether the column's values may leave the platform (to an enrichment provider or a language model). Email and phone identifiers are not shared by default; Bytek staff change the setting on request. Each destination hashes what it requires at send time.
BPP matches identifiers by their type and value, not by column name. If the same identifier type appears in multiple tables, all of them are linked to the same Bytek ID — even when the underlying columns are named differently.
Example: a column named
hashed_emailinusers_mainand a column namedheminevents_webcan both be declared as identifier type
| table_name | field_name | identifier_type |
|---|---|---|
| users_main | hashed_email | email |
| events_web | hem | email |
| events_web | fp_cookie_id | cookie_id |
If a single event row contains both hem and fp_cookie_id, both are linked to the same Bytek ID.
:::warning User-level identifiers only
Map only user-level identifiers (email, phone, cookie, CRM contact ID). Entity-level IDs — subscription_id, account_id, order_id, crm_account_id — must not be declared as user identifiers.
:::
Automatic PII normalization and hashing
Since DSM v2, BPP's _bpp copy inside your dataset is a faithful, clear copy of your source data — hashing no longer happens in your warehouse. Identity resolution also runs inside your own BigQuery project: BPP does not copy your identifiers into its own database. Hashing happens only when data leaves your perimeter, at send time, in the format each destination requires.
For matching (identity resolution)
Before two values are compared, BPP cleans them according to the identifier type:
| Identifier type | Cleaning before matching |
|---|---|
Trim and lowercase. For @gmail.com / @googlemail.com, dots in the local part are removed. | |
| Personal Phone | Spaces, brackets and dashes removed, brought to international format (+39…). A number without a prefix takes your account's default country (set by Bytek, Italy unless changed). Values outside 8–15 digits are ignored. |
| Any other type | Surrounding spaces removed; the value is matched exactly as written. |
A value that is already a SHA-256 hash (64 hex characters) is kept as it is, lowercased. A hashed column and a clear column of the same type therefore do not match each other — declare them under the same type only if they are both clear or both hashed.
For ad platforms (at send time)
Google Ads, Meta Ads, Microsoft Ads and OpenAI Ads receive emails and phone numbers normalized and hashed with SHA-256 (hex, lowercase), each platform with its own rules:
- Trim, lowercase.
- Google Ads and Microsoft Ads: for
@gmail.com/@googlemail.com, dots are removed from the local part. - You may provide pre-hashed emails (SHA-256) or raw emails — BPP hashes raw values and sends hashed values as they are.
Phone number
- Converted to E.164 format (e.g.
+14155552671) using your account's default country for numbers without a prefix; Meta and OpenAI receive it without the leading+. - Invalid numbers are dropped.
Names, city, zip, date of birth (Meta, OpenAI) — lowercased and cleaned per the platform's specification, then hashed.
Device identifiers (non-PII) — GA Client ID, GA4 user pseudo-ID, first-party cookie, mobile advertising ID (IDFA, GAID)
- Already anonymized; sent as they are.
Destinations inside your perimeter (BigQuery, API) and Google Analytics 4 receive values as they are.
Common identifier types
Identifier types are your account's own catalogue, not a fixed platform list — see Step 2 — User Identifiers. Every account starts with four: Email, Personal Phone, Internal ID, and Cookie ID. Add your own from the ID type select during onboarding (a loyalty card number, a franchise account code, anything that points at a person) and it is saved to your catalogue for future tables.
Whether a field pre-hashed at source, a raw value, or a device identifier — BPP declares them all under the same identifier type by what they represent, not by whether the source column already hashed them:
| Identifier type | Example field names | Description | Typically PII |
|---|---|---|---|
email, user_email, hem, hashed_email | Email address, raw or pre-hashed at source | Yes | |
| Personal Phone | phone, mobile_number, hphone | Phone number, raw or pre-hashed at source | Yes |
| Internal ID | crm_contact_id, hubspot_vid, domain_id | Account/CRM-issued identifier | No |
| Cookie ID | fp_cookie_id, ga_client_id, idfa, gaid | First-party cookie / device identifier | No |
Every identifier is cleaned per the matching rules above and resolved inside your own BigQuery project. Use the built-in Email and Personal Phone types for emails and phones: types you create are matched exactly as written.
The Bytek ID
The Bytek ID is the system-generated, anonymized user key created during identity resolution.
- Each unique person receives one Bytek ID.
- All their sub-identifiers (email, phone, cookie, CRM contact ID, …) link to it.
- When new identifiers appear, the identity graph is updated and merged on the next daily run.
- BPP writes the resolved key back to your warehouse as a
bpp_user_idcolumn on the enriched copy of each table.
This unified key enables consistent joins, aggregations, and model training across time, channels, and systems. See User Reconciliation for merge rules and coverage metrics.
Best practices
- Include at least one stable user identifier in every user and event table.
- Use consistent identifier types across datasets — the same concept must share the same identifier type everywhere.
- Ensure user identifiers form the primary key of the user table: at least one always populated, no duplicates.
- Provide multiple identifiers where possible to maximize match rates.
- Never tag entity-level IDs (
subscription_id,order_id,account_id) as user identifiers. - Hash PII consistently (correct casing, whitespace, Gmail normalization, E.164 phones) so hashes match Google and Meta. There is no per-column hashing toggle: each destination hashes what it requires at send time.
Summary
- BPP performs identity resolution to unify users across sources.
- Each user receives a unique Bytek ID, surfaced as a
bpp_user_idcolumn. - Normalization keeps matching deterministic; hashing happens at send time, per destination.
- Identifiers are mapped in the Data Source Manager UI — by identifier type — not by column name.