How BPP Connects Events to Customer Profiles
What event reconciliation does
Your business events — purchases, page views, form submissions, CRM stage changes — arrive in your data warehouse as rows in event tables. Each row records what happened and when, but events from different sources often identify users differently (cookie here, email there, CRM ID somewhere else).
Event reconciliation is BPP's process of linking every event row to the correct customer profile — the Bytek ID. Once events are linked to profiles, BPP can:
- Send the right conversion data to Google Ads and Meta Ads, attributed to the correct user.
- Build audience segments based on what users have or haven't done.
- Use Fields Builder to compute per-user behavioural metrics from event history.
How it works
Event reconciliation runs as part of the same automatic daily process as user reconciliation. BPP reads your event tables, looks up the identifiers on each row (email, cookie, user ID, etc.), and stamps each row with the Bytek ID of the person who performed that event.
The result is an enriched copy of each event table, containing all your original columns plus a bpp_user_id field.
BPP handles each event table you have connected. The process is:
- First pass — BPP adds Bytek IDs to every event row it can match immediately, based on already-known profiles.
- Resolution — For event rows with unrecognised identifiers, BPP creates or updates customer profiles.
- Final pass — BPP re-processes the event table with the newly expanded profile data, filling in any remaining gaps.
At the end, nearly every event row has a Bytek ID. The only rows that remain unresolved are those with genuinely unrecognisable identifiers (for example, a completely anonymous event with no identifier at all).
What this means for your exports
When you create a Signal in BPP to send conversion data to Google Ads or Meta Ads, BPP reads from the reconciled event tables. This ensures:
- Each conversion event is attributed to the right person.
- BPP sends the correct hashed email, phone, or click ID to the ad platform for matching.
- Duplicate events are not sent twice (BPP tracks which events have already been pushed).
Naming convention
For each event table you connect, BPP creates an enriched version alongside the original. For example:
| Your original table | BPP enriched table |
|---|---|
event_pageview | event_pageview_bpp |
event_orders | event_orders_bpp |
user_crm | user_crm_bpp |
You don't need to manage these tables — BPP creates and maintains them automatically.
Incremental updates
BPP processes only new or unresolved data on each daily run — it doesn't reprocess the entire table from scratch every time. This keeps processing fast even as your data grows.
When your source table has new rows, BPP detects this automatically and processes them on the next run.
Event coverage metrics
After each run, BPP calculates how many events were successfully linked to a Bytek ID. You can view this in the Data Diagnosis section of the platform:
- Total events in each table.
- Percentage linked to a customer profile.
- Number of unique customers represented in each event table.
Low coverage on an event table often means that table has few usable identifiers. Improving coverage typically involves ensuring the event table includes at least one identifier field (email, user ID, or cookie) that overlaps with your other data sources.
Troubleshooting
| Symptom | What to check |
|---|---|
| Conversion signal sends fewer events than expected | The event table may have low identity coverage. Check Data Diagnosis to see how many event rows have a Bytek ID. |
| Events attributed to the wrong user | Check that the identifier columns in your event table are correctly declared in the data source configuration. |
| Enriched table seems outdated | The daily reconciliation process may have encountered an issue. Check Data Diagnosis for any data quality warnings. |