pcLTV (Subscription) — Reference

The Subscription pcLTV model estimates the future economic value a subscriber will generate over a defined forecast window (e.g. 3, 6, or 12 months). It relies on past transactions (renewals), behavioural patterns, and customer-level attributes. It is a predictive model.

Input data: see AI Model Data Requirements → pcLTV. The requirements below are the subscription-specific view.

---

Data model overview

To activate a Subscription pcLTV model, BPP requires:

• A transactional event table — one row per transaction (renewal).
• A user table — one row per user with optional demographic and behavioural features.

Field names are examples, not mandatory — identity resolution stitches users across tables.

---

1. Event tables

A. Transactional event table (required)

One row per transaction. This is the core input.

Column name	Type	Description
event_date	DATETIME	When the transaction occurred (UTC, mandatory)
user_id	STRING	User identifier (mandatory)
monetary	FLOAT	Total value of the transaction (mandatory)
transaction_id	STRING	Unique transaction identifier (mandatory)
subscription_type	STRING	Subscription tier (recommended)

The table may contain other numerical and categorical features at transaction level.

B. Interaction event table (optional, highly recommended)

One row per interaction event; improves accuracy.

Column name	Type	Description
event_date	DATETIME	When the event occurred (UTC, mandatory)
user_id	STRING	User identifier (mandatory)
event_type	STRING	Type of action performed (recommended)
payment_methods	STRING	Payment method used (recommended)

C. Behavioural event table (optional, recommended)

One row per behavioural event on your site/app.

Column name	Type	Description
event_date	DATETIME	When the event occurred (UTC, mandatory)
user_id	STRING	User identifier (mandatory)
event_type	STRING	e.g. page_view, form_submitted
OS	STRING	Operating system
Browser	STRING	Browser used

---

2. User table (optional, recommended)

One row per user with enrichment features.

Example field	Type	Description
gender	STRING	User's gender
age	INTEGER	User's age
country	STRING	Country of residence
client_type	STRING	e.g. new vs returning
industrial_sector	STRING	Company's sector
job_role	STRING	e.g. Marketing Director, HR Manager
num_employees	INTEGER	Company's employee count

---

Best practices

• Forecast horizon vs history depth — historical data must be at least double the horizon (e.g. one year of history to estimate 6 months).
• Renewal interval — a model estimates one renewal cadence at a time; you can't mix monthly and six-monthly renewals in one model.
• User coverage — at least 20% of users should have 2+ renewals in the observation window.
• Minimum volume — at least 2,000 users with transactions.
• Data consistency — UTC timestamps, no duplicate transaction IDs, cleaned/standardised monetary values.
• Feature quality — more descriptive, consistent, predictive features → better output.