What's New in DSM v2

The Data Source Manager (DSM) is where a customer connects their data to BPP. Version 2 changes three things: how the setup is done, how BPP builds a single profile of each person from the customer's different systems, and where personal data lives.

This page lists every new feature in plain words. For the screens themselves, see the Data Source Manager pages.

At a glance

Area	Before	With DSM v2
Setup	Every table, field and identifier configured by hand	AI drafts everything; you review it in 5 guided steps
A person's profile	Fixed logic decided how sources were merged	You decide which source wins for each attribute
Personal data	Hashed inside the customer's own warehouse, so it was readable nowhere	Kept in clear, only in the customer's warehouse; hashed only when sent to an ad platform
Kinds of ID	A fixed platform list	The customer's own list, extendable
"When did it happen?"	Every table needed a column called `event_date`	Any date column, chosen where it is used
After go-live	Changes needed Bytek's help	The profile model and new columns can be managed by the customer

1. A guided setup, drafted by AI

Setup is now a 5-step wizard. BPP's AI reads the customer's dataset first and fills in every step; the user reviews and corrects instead of starting from a blank page.

Classify tables — is each table about people (a customer list) or about what they did (orders, visits)? Tables that are about neither, like a product catalogue, can be marked unused and are ignored.
User identifiers — which columns point at a person (email, phone, customer code, cookie…), grouped by kind of ID. Fields are moved between groups by drag and drop.
User model — what a single, merged profile of each person looks like (see section 2).
Event mapping — readable names and descriptions for the fields of the activity tables, and which ones to show.
Review & activate — one summary of everything, then go live.

Also new:

Nothing is lost. Progress saves automatically; the user can close the browser and continue later.
AI suggestions are marked. A badge shows what is still the AI's proposal, so the user knows what they have not checked yet.
Start over at any time, with a typed confirmation so it cannot happen by accident.
No customer data is sent to the AI model. It only sees table and column names, statistics and the masked shape of values.

2. One profile per person, built your way

Customers often hold the same people in several systems: the CRM knows the name, the shop knows the spending, the loyalty scheme knows the tier. DSM v2 adds the unified user model: one merged profile per person, and the customer decides how each attribute is merged.

Source priority. For each attribute, the user ranks the sources. The first one wins; the others only fill gaps.
Eight merge rules, offered only where they make sense: first available value, keep all values, highest, lowest, sum, average, most recent date, oldest date.
Safe suggestions. The AI proposes a rule for each attribute but never sums numbers on its own, because summing two systems that record the same purchases would double-count.
Every known email, phone and ID of a person is collected automatically into the profile, ready for destinations that need it.

Audiences and AI models read this merged profile.

3. Personal data stays with the customer

This is the biggest change in DSM v2. The principle: the data belongs to the customer and stays in their perimeter.

A faithful copy. The working copy BPP keeps in the customer's own BigQuery is identical to the source, plus three BPP columns. Nothing is scrambled or transformed.
Matching happens at the customer's. Recognising the same person across tables runs inside the customer's own BigQuery project. BPP does not keep a copy of the customer's emails or phone numbers in its own database.
Hashed only on the way out. When data is sent to Google Ads, Meta, Microsoft Ads or OpenAI Ads, emails and phone numbers are converted into the anonymous code (a "hash") each platform requires, in that platform's exact format. A value that is already hashed is never hashed twice.
New destinations unlocked. Because the clear value exists, BPP can now send profiles to destinations that need a readable key, such as the customer's own BigQuery or an API.
Phone numbers match better. Numbers written without a country code are completed with the customer's default country (Italy unless changed), so 333 1234567 and +39 333 1234567 are recognised as the same number.
Closed by default for AI and enrichment. Email and phone columns cannot be sent to AI Fields or to external enrichment providers unless Bytek opens them on request.
No more "requires hashing" checkbox and no more personal-data consent step. The protection is built into where data lives, so there is nothing for the user to tick.

4. The customer's own kinds of ID

Every business has its own codes: a loyalty card, a franchise number, a booking reference.

Create new kinds of ID in the setup, by typing a name. They are saved for the customer and offered again next time.
Delete kinds of ID the customer created and no longer needs.
Matching is by kind and value, never by column name. A mail column in one table and a customer_email column in another are recognised as the same person when both are declared Email and hold the same address.
Every customer starts with four kinds: Email, Personal Phone, Internal ID and Cookie ID.

5. "When did it happen?" — chosen where it matters

Before, every activity table needed a column literally named event_date, and data teams had to rename columns to fit BPP.

Any date column works, whatever its name. Nothing needs renaming in the warehouse.
The date is chosen where it is used: each signal picks its own date column, and so do the First and Last aggregated fields. Two signals on the same table can use different dates (for example order created and order shipped).
Copilot and the BPP MCP tools ask for the date column too, so signals they create work the same way.

6. Keeps working after go-live

Before, any change after go-live needed Bytek's help. Now:

Edit the profile model at any time from the Datasource Manager page: sources, priority and merge rules. Saving rebuilds the profiles straight away, without waiting for the nightly update.
New columns are spotted automatically. When the data team adds a column to a table BPP already uses, it appears in Discover New Tables and can be added with one click.
Clearer warnings. BPP tells the user when a table or column was removed from the source, and when the profile rebuild is running or has failed.
One page. Setup and table settings are merged into a single Datasource Manager page, which now also holds the profile model.

What does not change

The structure of the data is still add-only after go-live: names, descriptions and visibility can be edited, and tables and columns can be added, but existing fields cannot be renamed, retyped or removed. This protects the audiences, signals and fields already built on them.
Audiences, signals, AI models and exports work as before, on top of the new setup.

At a glance​

1. A guided setup, drafted by AI​

2. One profile per person, built your way​

3. Personal data stays with the customer​

4. The customer's own kinds of ID​

5. "When did it happen?" — chosen where it matters​

6. Keeps working after go-live​

What does not change​