Skip to main content

User Tables

User tables store persistent customer information, enabling BPP to unify user data across multiple datasets. They contain the identifiers and stable attributes that enrich user profiles and feed AI models.

Grain: one row per person.

Mandatory requirements​

To be correctly processed by the platform, a user table must include:

  • At least one user identifier column (e.g. hashed_email, crm_id, cookie_id).
  • Consistent column meaning across datasets — if two tables refer to the same identifier, declare them with the same identifier type during mapping (column names can differ; see Identifiers & Hashing).

It may also include:

  • Optional attributes (e.g. birth date, country, job role) to enhance segmentation and predictions.

:::info Identifier as primary key At least one identifier must always be populated for every row, and rows should be unique at the person grain — no duplicate users. :::

Column nameTypeDescription
hemSTRINGHashed email
crm_idSTRINGCRM ID (optional)
countrySTRINGUser's country
created_atDATETIMEUser creation date (useful for event triggers)

Field names are flexible — these are examples. What matters is that identifier columns are declared consistently during mapping.

Example table​

CREATE TABLE my_dataset.users (
  hashed_email STRING,
  first_name   STRING,
  last_name    STRING,
  job_role     STRING,
  birth_date   DATE,
  country      STRING,
  created_at   DATETIME
);

Keep user and event grain separate​

A user table holds stable attributes, not event history. Don't put fields like last_pageview_url or last_order_date raw event data into a user table. If you need behavioural signals at user level, pre-aggregate them (e.g. total_orders, avg_basket_value, days_since_last_purchase) — the Fields Builder can compute these from your event tables. See Common Mistakes → Mixing user- and event-grain data.

By structuring user tables correctly, you enable effective identity resolution and improve AI model predictions.

Last updated on