Monetization Analysis

LT Prediction (User Lifetime Prediction)

Estimate the average number of days a user stays active and the area under the retention curve, supplying the core decay parameter for LTV calculation. If LT is off, LTV will be too.

IndustriesGamesEntertainmentSubscriptionE-commerce

Agent · Skills Live

skill · loadedindustry+100

Run this Skill on my data

Fitted forecast curve

by cohort

Analysis readyevidence attached

LT Prediction is a user-lifetime estimation capability in ThinkingAI's industry Skill library. It helps growth and operations teams predict the average number of active days per user (LT) from retention data. This is the core decay parameter for LTV calculation, and if LT is off, LTV will be too. This is ThinkingAI's decade of industry experience, packaged into ready-to-use Skills.

Live walkthrough

AgentSave as AgentExport session

lt-prediction

Calculate the LT for all the new users who registered in January. We've been assuming 55 days to compute LTV, but the UA team's payback numbers haven't lined up lately and I suspect that figure is inflated. Registration spans 31 days, and the cohorts from different days have retention of different lengths. I spent an afternoon trying to weight it by hand and couldn't get it to add up.

Confirm data mapping: active event login, registration property #reg_time

Matches the tracking plan

Call ae-analysis to pull daily retention for the 31 January registration cohorts

43,617 January new users in the sample

Count the valid cohorts at each retention-day point and flag confidence

D15 has 17 valid cohorts, D25 has 7, D31 only 1 (dropped)

Fit power, logarithmic, and exponential functions, auto-select the highest R²

Power function wins, R²=0.91

Integrate the area under the retention curve with scipy, generate the LT and forecast table

Done. The bottom line first: the old 55-day assumption overestimates by 30%; the fitted LT is 42.3 days. At an ARPU of $0.6/day, LTV should be $25.4 rather than the old $33, and that gap is exactly why your UA payback wasn't lining up.

1. Valid cohorts and confidence

January registration spans 31 days, and cohorts from different registration days have retention series of different lengths, so a naive average gets polluted by the short cohorts. First, segment by the number of valid cohorts:

Retention-day point	Valid cohorts	Confidence	Handling
D15	17	High	Fully included in the fit
D25	7	Acceptable	Included in the fit
D31	1	Low (<5)	Flagged and dropped, excluded from the fit

← Scroll to see more

2. Fitted curve and extrapolation

January new-user weighted retention curve: fit and extrapolation　Unit: %

Weighted actual retentionPower-function fitForecast segment

The decay shape is a power function (the decay rate is slowing), which is a healthy form. If it had fit an exponential decay (accelerating churn), the problem would be more than just a definition issue. Your LT problem is in the starting-point estimate, not in the curve itself.

3. Parameters and forecast

Item	Value	Notes
LT (truncated at 365 days)	42.3 days	Area under the fitted curve
Fitted function	r(n) = 0.46·n^(-0.295)	Power function, highest R² of the three
R²	0.91	Log 0.87 / exponential 0.79
Safe forecast window	D90	Valid data reaches D25; beyond the window, roll and recalibrate
Forecast retention	D30 16.9% / D60 13.7% / D90 12.2%	Matches the chart's forecast segment

Conclusion

Recommend switching the LTV definition immediately: 42.3 days × $0.6/day ≈ $25.4, versus $33 under the old 55-day assumption, a 30% overestimate. If your UA bid break-even line was set on $33, lower it accordingly. Disclaimer: the D31 point has only 1 valid cohort, so this LT is fit and extrapolated from data within D25; once mid-February data fills in, rerun a calibration.

The fitting script and weighted-retention SQL are saved to the project query library; the February batch can rerun with adjusted parameters.

On your data

That was a simulated run

Leave your work email and we will run a live walkthrough on your real business data.

The problem

LTV is calculated as LT × ARPU, where LT (user lifetime in days) is the area under the retention curve. Most teams estimate LT with a multiplier method (for example, D7 retention times a multiplier), but that essentially means guessing the decay rate, and the error is large. One team estimated LT at 21 days with a 3x method, but the actual fitted value was only 14 days, overstating LTV by 50% and making the payback judgment completely wrong. A more precise approach is to fit a function to the retention curve and integrate for the area, but that takes math skill and over 30 minutes per manual run. Time-window aggregation (for example, "all new users in January") is more complex still. Cohorts from different registration dates produce retention data of different lengths, weighted calculation is error-prone, and a manual pass averages 1 to 2 hours.

What it does

Supports three curve fits (power, logarithmic, exponential), automatically outputs the one with the highest R², and integrates for the area to derive LT

For time-window aggregation, automatically computes the effective cohort count, and flags data points with fewer than 5 effective cohorts as "low confidence" and excludes them from the fit

When data is insufficient, borrows the decay rate from a mature batch to aid prediction, with the borrowed source and version consistency clearly noted

Output includes the LT estimate, fitted function parameters, R² score, safe prediction window, and disclaimer

Provides a weighted-retention SQL fallback so it can still run when no MCP interface is available

When to use it

After acquiring a new batch of users, you need to estimate average user lifetime to feed the LTV calculation

Weighted LT estimation for a full month or quarter of new users, where registration cohorts have inconsistent retention lengths

Judging the retention curve decay shape: power-law decay (healthy) versus exponential decay (accelerating churn)

Comparing LT differences across channels or versions to inform acquisition and product decisions

You already have LTV forecasts but the LT parameter is uncertain and needs independent calibration

In the field

Case

An SLG game · LT estimation for January new users

January registrations spanned 31 days, and retention data from different registration dates varied in length. The LT Prediction Skill automatically computed effective cohort counts: D15 had 17 effective cohorts (high confidence), D25 had 7 (acceptable), and D31 had only 1 (excluded as low confidence). A power-law fit gave R²=0.91, and integrating for the area produced LT=42.3 days. Combined with ARPU=$0.6/day, LTV was estimated at about $25.4.

FAQ

What is the difference between LT and LTV?

LT is user lifetime in days (the area under the retention curve), and LTV is user lifetime value (LT × ARPU). LT is the core input to LTV, so if LT is off, LTV will be too.

Can you predict LT with only 7 days of data?

Yes, but with significant error. The safe prediction window is only 7 to 10 days. We recommend borrowing the decay rate from a mature batch or calibrating on a rolling basis.

How does time-window aggregation handle different cohort lengths?

The Skill automatically computes the effective cohort count for each retention day, flags data points with fewer than 5 effective cohorts as low confidence, and excludes them from the fit, keeping the weighted calculation reliable.

Precise LTV through curve fitting

LTV Payback Period Prediction

Predict whether spend will pay back

LTV Analysis and Monitoring

Diagnose the root cause of LTV drops

LTV Metric Calculation and Monitoring Dashboard Setup

Build an LTV monitoring system