When we decided to build a churn prediction layer into Onboardvue, the first question we faced was: what are we actually predicting? "Will this user churn" is not a modeling target. It's a vague wish. Before we wrote a line of model code, we spent a week on definitions.
Churn in a self-serve PLG context means different things depending on the product's billing model and user lifecycle. For subscription SaaS, churn is a billing event: the user doesn't renew. But a user can stop using the product weeks before they cancel. That behavioral churn, the point at which engagement effectively drops to zero, is what we actually want to predict. By the time a user clicks "cancel," the churn has already happened. The prediction has to lead the billing event, not track it.
Defining the prediction target precisely
We settled on this definition: a user is "about to churn" if they will have zero meaningful product activity in the 14 days following the prediction date, and the subscription will lapse within 30 days of that zero-activity period beginning.
That's two conditions: behavioral inactivity and subscription lapse within a bounded window. We require both because users who go inactive and then come back are not churned, and users who cancel but remain active until the end of their billing period present a different intervention opportunity than users who've already gone dark.
The "meaningful activity" qualifier is important. We don't count session starts or marketing email opens. Meaningful activity means product events: creating, viewing, or editing core objects; running reports; firing a nudge; anything that requires intentional product use. A user who logs in and immediately logs out is not meaningfully active.
Feature engineering: what signals we use
We use three categories of behavioral signals, all derived from product event streams.
Recency signals
Days since last meaningful activity is the single strongest predictor in our model. A user who was active 2 days ago has a very different churn probability than one who was last active 11 days ago, even holding all other factors constant. We compute this as a continuous variable rather than bucketing it, because the churn probability curve is non-linear and bucketing loses information.
We also track "recency of specific feature use" separately from overall recency. A user might have logged in recently to check account settings but not have used the core product feature in 18 days. These two recency signals tell different stories.
Frequency and depth signals
Session frequency over the trailing 28 days, normalized against the user's own historical average rather than against a population benchmark. A user whose frequency has dropped 60% from their own baseline is more concerning than a user who was always a low-frequency user. Absolute frequency penalizes casual users unfairly.
Feature depth: the number of distinct product capabilities used in the trailing 14 days. Users who only use one feature are more fragile than users who've embedded across multiple capabilities. A user who uses the activation funnel, the nudge editor, and the churn dashboard daily has much higher switching costs than one who only looks at the funnel. Depth correlates strongly with retention.
Trajectory signals
This is the category we spent the most time on. Trajectory captures whether engagement is increasing, stable, or declining. We compute 7-day rolling session frequency and compare it to the prior 7-day period for the same user. A declining trajectory is a leading indicator of the inactivity we're trying to predict.
Trajectory signals are noisy because users legitimately have busy weeks and slow weeks. We smooth with a 3-period exponentially weighted moving average rather than a simple comparison, which reduces false positives from single-week anomalies.
Model architecture
We evaluated three model families for this: logistic regression, gradient boosting (XGBoost), and a lightweight LSTM for sequence modeling. Logistics was the baseline; XGBoost outperformed it materially on held-out data; LSTM showed a small additional lift but required substantially more infrastructure and training time.
We shipped with XGBoost and a prediction window of 8 days. Why 8? It's a pragmatic calibration. A 3-day window gives more accurate predictions but leaves almost no time to intervene before behavioral churn is complete. A 14-day window gives more lead time but accuracy degrades enough that false-positive rates become a user experience problem (you're sending churn-risk nudges to users who were never actually at risk).
Eight days was the point on the precision-recall curve where we felt confident enough in the prediction to fire an automated intervention without a human reviewing each case. Below 8 days, the confidence is high but the intervention window is too narrow. Above 10 days, you have enough time to intervene but the signal-to-noise ratio means too many false positives.
The cold-start problem
The hardest part of building a churn model for PLG products is the cold-start window. New users have no history. You can't compute recency trends on a user who signed up 3 days ago. And yet, early-stage churn prediction for new users is arguably the most valuable use case, because the intervention window is widest and the user's future habits haven't yet crystallized.
We solved this with a two-phase approach. For users in their first 14 days, we run a separate "new user risk model" that uses activation progress as its primary signal instead of historical behavioral trends. A new user who hasn't completed activation step 3 by day 7 is flagged as at risk not because of engagement decay, but because their activation trajectory suggests they'll hit the typical abandonment pattern we see in the population.
After 14 days, users transition to the main behavioral churn model, which now has enough history to compute recency, frequency, depth, and trajectory signals reliably.
What we got wrong the first time
Our first model used population-normalized frequency (comparing each user's session count to the average across all users). This worked poorly because it penalized products with a low-frequency use case. A user who uses a weekly reporting tool once a week is not low-frequency; that's the natural cadence of the product. By comparing to a cross-product average, we were systematically mislabeling healthy users on low-cadence tools as at-risk.
The fix was to normalize within a user's own cohort (users at a similar subscription age with similar product type) rather than against the total population. This required more data pipeline work but substantially improved precision on the products where the original model was performing worst.
How confidence scores surface in the product
Onboardvue surfaces churn risk as a score between 0 and 100 for each user in your product, updated daily. The score is not a probability (we found PMs found percentage probabilities harder to act on than a relative risk score), but it's derived from model confidence.
Customers can set threshold rules: "when a user's churn score exceeds 72, fire the re-engagement nudge." Or they can use Onboardvue's suggested threshold, which is calibrated based on the intervention rate that produces the best conversion without excessive nudge fatigue. We generally recommend starting at the suggested threshold and adjusting based on observed conversion rates over the first 30 days.
We're not claiming this model is perfect. For products with very sparse event data (fewer than 50 active users), the model has limited signal to work with and should be treated as directional rather than authoritative. For products with rich event streams and 200+ active users, the prediction window and precision hold up well across most PLG product types we've tested on.
The underlying insight isn't proprietary: behavioral decay predicts churn. The implementation detail, arriving at a reliable 8-day prediction window with manageable false-positive rates, is where the work actually is.