Skip to main content

Event Tables

Event tables store user interactions or transactions over time, allowing BPP to analyse customer behaviour, train AI models, and trigger marketing actions.

Grain: one row per event (immutable — 1 row = 1 thing that happened).

Mandatory requirements​

Each event table must include:

  • A timestamp column marking when the event occurred (store it in UTC).
  • At least one user identifier column, never all null on the same row. For example, if you use both hem and crm_id as identifiers, every event row must have at least one of them populated.

It should also include:

  • Descriptive attributes (e.g. order value, page URL, event type) to provide context for modelling and activation.
Column nameTypeDescription
event_idSTRINGUnique event identifier (optional)
event_timestampDATETIMEWhen the event occurred — mandatory, UTC
user_idSTRINGA user identifier — can be hem, CRM ID, cookie, etc. — mandatory
event_typeSTRINGType of event (e.g. purchase, click, signup) (optional)
event_valueFLOAT64Value associated with the event (e.g. order total) (optional)
additional_infoSTRINGAdditional context (optional)

Field names are flexible — these are examples.

Example table​

CREATE TABLE my_dataset.events (
  event_id        STRING,
  event_timestamp DATETIME,
  hashed_email    STRING,
  event_type      STRING,
  event_value     FLOAT64,
  additional_info STRING
);

Best practices​

  • Maintain consistent user IDs across all event tables, so identity resolution can stitch behaviour together.
  • Use clear, controlled event types to differentiate actions.
  • Store timestamps in UTC for consistency with ad platforms and ETL.
  • Never overwrite events. Track state changes as new rows (e.g. an order_status_history table), not by mutating a single row. See Common Mistakes → Overwriting event states.
  • Keep absolute URLs and attribution parameters (utm_*, gclid, gbraid, wbraid) on web events — they power interest classification and ad matching.

:::tip Enriched tables After event reconciliation, BPP writes an enriched copy of each event table alongside the original (suffixed _bpp, e.g. events → events_bpp) containing all your columns plus a bpp_user_id. You don't create or manage these — BPP does. :::

Properly structured event tables enable BPP to generate insights, build user profiles, and power AI-driven marketing strategies.

Last updated on