A propensity model assigns every customer a score predicting the likelihood of a specific outcome — responding to an offer, churning, upgrading, making a purchase in the next 30 days — based on patterns learned from historical data. Instead of targeting an entire segment uniformly, a campaign can target only the top-scoring decile, or weight creative and offer intensity by score band. The value proposition is concentrating limited marketing spend and contact budget on the customers statistically most likely to convert, rather than spreading it evenly across a broad segment.

Variable selection: the step that determines model quality

Model quality is driven far more by which variables go in than by which algorithm is chosen. Useful predictor categories for marketing propensity models typically include recency/frequency/monetary history, engagement signals (email opens, site visits, app sessions), product/category affinity, tenure, and — where available — support interaction history. A critical discipline is excluding variables that leak the outcome itself (including a "purchased in last 7 days" flag when predicting "will purchase in next 7 days" trained on overlapping windows) or that aren't available at actual scoring time in production, even if they exist in the historical training data.

Good vs. leaky predictor variables

Variable	Issue	Fix
Order placed this week (predicting this week's purchase)	Direct outcome leakage	Use only data available before the prediction window starts
Customer service ticket opened today	May not be available at scoring time in production	Confirm the field is populated in the live pipeline before training on it
Days since last purchase	None — safe, standard RFM input	Keep
Email click rate last 90 days	None — safe, standard engagement input	Keep

Building the training set

A propensity model is trained on historical examples where the outcome is already known: take a past point in time, gather the predictor variables as they existed *then*, and label each record with whether the outcome actually happened in the window that followed. This time-boxing discipline (sometimes called a "snapshot and label" approach) is what prevents leakage — every predictor must be computed strictly before the outcome window it's predicting.

training_set_construction.txt

text

Snapshot date: Jan 1
  Predictors computed using data up to Dec 31 (prior year)
    - recency_days, frequency_12mo, monetary_12mo
    - email_open_rate_90d, site_visits_30d
    - product_category_affinity

Outcome window: Jan 1 - Jan 31
  Label = 1 if customer made a purchase in this window, else 0

Repeat snapshot at multiple historical dates to build a large,
time-varied training set (not just one snapshot — avoids overfitting
to one calendar moment's idiosyncrasies).

Scoring and deploying the model

Once trained, the model runs in a batch scoring job (typically nightly, as part of the ETL pipeline that refreshes the marketing mart) producing a propensity score per customer that gets written back as a column on the customer dimension — exactly the "pre-aggregation" pattern used for RFM tiers. Campaign targeting queries then filter on propensity_score >= threshold the same way they'd filter on any other dimension attribute, which is why model scores belong in the warehouse as first-class columns rather than living in a separate data science tool that marketing can't query directly.

Model decay signals and refresh triggers

Decay signal	What it indicates	Typical response
Score distribution drifts over time	Underlying customer base or behavior has shifted	Retrain on more recent data
Actual response rate in top decile drops	Model's predictive power is degrading	Retrain; investigate feature staleness
New product line or market segment launched	Training data doesn't represent new population	Retrain including new segment's data, or build a separate model
Calibration drifts (predicted vs actual rates diverge)	Model is no longer well-calibrated even if rank-ordering holds	Recalibrate or retrain

Models decay silently unless someone checks

A propensity model doesn't throw an error when it goes stale — it just quietly gets worse at ranking customers, and campaigns targeting the "top decile" slowly start targeting a less and less predictive group with no visible signal unless someone is actively comparing predicted scores against actual outcomes on a schedule. Build the monitoring (a simple actual-vs-predicted response rate report by score band, refreshed monthly) before the model ships, not after someone notices performance has quietly degraded.

A refresh cycle should be scheduled, not reactive

Rather than waiting for visible decay, most mature teams schedule model retraining on a fixed cadence (quarterly is common for propensity models) regardless of whether decay has been detected yet — treating refresh like a maintenance task rather than an incident response, since the cost of a scheduled retrain is far lower than the cost of weeks of campaigns running on a degraded model.

What's next

A propensity score tells you who to prioritize contacting. The next module covers the practical discipline of deciding how often and through which channel to actually reach them.

Next: Optimizing Contact Strategy & Frequency →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →