Action Prediction — User & Event Table Requirements
The Action Prediction model assigns each user a probability score representing the likelihood of a specific action occurring. Typical use cases:
- Signing a contract
- Requesting an appointment
- Requesting a quote
- Subscribing to a newsletter
Data structure overview
Action Prediction can be powered by:
- One or more User tables containing user attributes and (optionally) a
target_variable. - Optionally, an Event table representing occurrences of the action you want to predict.
BPP applies identity resolution across all data sources. Field names are not mandatory, but tables must follow the structural requirements.
Structural requirements
User table
- One row per unique user.
- Must include at least one user identifier.
- May include a
target_variable(INT:1,0, or-1) and one or more independent variables.
Event table (optional)
- One row per discrete event.
- Must include one user identifier, one UTC timestamp, and the fields needed to infer the target (e.g.
deal_status,order_status).
Target variable: direct or derived
Option 1 — Direct in the user table
| user_id | target_variable |
|---|---|
| U123 | 1 |
| U456 | 0 |
| U789 | -1 |
1= action occurred (positive)0= action did not occur (negative)-1= ignored or unknown
Option 2 — Derived from events
If the target isn't stored on the user table, derive it from an event table.
Deal status table
| user_id | event_timestamp | deal_status |
|---|---|---|
| U123 | 2024-06-01 12:00:00 | open |
| U123 | 2024-06-15 17:45:00 | closed_won |
| U456 | 2024-06-20 08:30:00 | closed_lost |
Order table
| user_id | event_timestamp | order_id | order_status |
|---|---|---|---|
| U789 | 2024-05-10 14:22:00 | O123 | completed |
Newsletter subscription table
| user_id | event_timestamp | action |
|---|---|---|
| U456 | 2024-07-01 09:00:00 | newsletter_subscribe |
Independent variables
Provide at least one independent variable. They must:
- Be available for both success and failure cases.
- Be usable in past and future data.
- Can live in one or more user tables.
Examples
- Demographic — age, gender, location, sector, job role.
- Company (B2B) — revenue, number of employees, industry, year of incorporation.
- Engagement — webinar attendance, event participation, email opens.
- Interaction history — days since first contact, number of follow-ups, time since last interaction.
Best practices
- Field names are flexible (
user_id,target_variable, etc. are examples). - Follow BPP table rules: User table = 1 row per user with ≥1 identifier; Event table = 1 row per event with one user ID and one timestamp.
- Clean categorical variables (e.g. normalize job roles).
- Review and update variables regularly.
Minimum data volume
| Success rate (p) | Minimum rows required |
|---|---|
| 50% | 1,000 |
| 10% | 3,000 |
| 1% | 10,000 |
Summary
| Area | Must-have |
|---|---|
| User table | One row per user, with user ID and independent vars |
| Target variable | Direct or derived (binary: 1 / 0 / -1) |
| Event table (optional) | One row per event with timestamp + fields for target |
| Independent variables | At least one, present historically and prospectively |
| Identity resolution | Automatically applied across tables |
| Data volume | 1K–10K users depending on class imbalance |