Why Static LTV Estimates Failed Us β And How Dynamic AI Saved Our Q2
Why Static LTV Estimates Failed Us β And How Dynamic AI Saved Our Q2 π
By Dr. Julie Jones, PhD in Artificial Intelligence
Every growth team has lived this story. You build a customer lifetime value model, back it with 18 months of cohort data, calibrate the assumptions, and present a confident number to leadership. Six months later, the number was wrong. Not a little wrong β structurally wrong.
That was us. And the fix turned out to be less about a better spreadsheet and more about a fundamentally different way of thinking about prediction.
The Illusion of a Stable Customer
Our LTV model was, by 2023 standards, respectable. We used a cohort-based approach:
$$\ text{LTV}c = \sum{t=0}^{T} \frac{ARPU_c \cdot R_t^c}{(1+r)^t}$$
where $R_t^c$ is the retention rate at month $t$ for cohort $c$, $ARPU_c$ is average revenue per user, and $r$ is our discount rate. Clean. Auditable. The kind of model a CFO would nod at.
The problem: it assumed the future looked like the past. That cohort $c+1$ would behave like cohort $c$. That the customer who signed up in March 2024 would churn at the same rate as the customer who signed up in March 2023.
In a stable market, that's a reasonable approximation. In the market we were operating in β one where our pricing page changed in April, a competitor launched a feature in May, and our onboarding flow got A/B tested in June β it was an approximation that quietly went stale.
The Q2 Blowup
By mid-April, our static LTV estimate for new signups was $412. Our finance team was building Q2 forecasts on that number. Marketing was allocating budget on that number. Engineering was prioritizing features on that number.
Then May happened.
A new self-serve tier launched. Our onboarding dropped a friction point. A key enterprise segment shifted their procurement cycle. The customer mix in our funnel changed in ways our 18-month historical window hadn't captured.
By June, actuals were tracking 22% below our LTV-based projections. Not because customers were churning faster β they weren't. It's because who was signing up had changed, and their behavior profiles were different. Our static model couldn't see that. It was a photo of a moving car.
We spent two weeks reconciling. Two weeks of "why is the number wrong" meetings that should have been "the number updated itself" meetings.
The Core Problem: LTV as a Snapshot vs. LTV as a Stream
Here's the conceptual shift that mattered most:
Static LTV treats lifetime value as a property of a cohort. You measure it once, backfill it, and carry the number forward. It's a scalar. A single point estimate.
Dynamic LTV treats lifetime value as a property of a specific customer at a specific time, conditioned on everything that has happened so far and everything the model predicts will happen next. It's a function:
$$\ text{LTV}_i(t) = f\big(x_i(t), \mathcal{H}_i(t), \theta_t\big)$$
where $x_i(t)$ is the feature vector for customer $i$ at time $t$, $\mathcal{H}_i(t)$ is their behavioral history, and $\theta_t$ represents the current market/state parameters that the model learns continuously.
That last term, $\theta_t$, is the one that separates the two approaches. In a dynamic model, the "state of the market" is not a fixed assumption. It's a learned parameter that updates as new data arrives. When your funnel changes, when your pricing shifts, when a competitor moves β $\theta_t$ adjusts. The LTV estimate adjusts with it. No one has to notice. No one has to run a reconciliation.
What We Actually Built
We didn't replace our cohort model. We layered a dynamic model on top of it.
Layer 1: Real-time behavioral features. For each active customer, we maintain a rolling feature vector updated daily. Engagement depth, feature adoption, support ticket frequency, payment behavior, session patterns. These are the $x_i(t)$ terms.
Layer 2: A sequence model for behavioral trajectory. A small transformer-based model that ingests each customer's interaction sequence and outputs a predicted retention probability curve β not a single retention number, but a distribution over the next 12 months. This gives us the $\mathcal{H}_i(t)$ term.
Layer 3: Market-state embedding. A lightweight model that ingests funnel-level metrics (sign-up rate, tier mix, CAC by channel, competitor activity signals) and outputs a state vector $\theta_t$. This is the piece our old model was missing. It captures "the market shifted" without anyone having to manually update assumptions.
Layer 4: LTV synthesis. The final LTV estimate for any customer $i$ at time $t$ is computed by combining the retention distribution from Layer 2 with the revenue model and the market state from Layer 3:
$$\ widehat{\text{LTV}}i(t) = \sum{t'=t}^{t+T} \mathbb{E}\big[\text{Revenue}_{i,t'} \mid x_i, \mathcal{H}i, \theta_t\big] \cdot \prod{s=t}^{t'} P(\text{retained}_s)$$
This is not a single number. It's a live estimate that shifts as each of its inputs shifts.
The Numbers That Changed the Conversation
Here's what the dynamic model did versus our static model during the Q2 period:
Metric | Static LTV | Dynamic LTV | Actual |
|---|---|---|---|
Avg. LTV estimate (new signups) | $412 | $358 | $351 |
Forecast error (Q2 revenue) | +22% | +3.1% | β |
Time to detect market shift | ~6 weeks (manual) | ~5 days (automatic) | β |
Budget reallocation speed | 2-week cycle | Same-day | β |
The forecast error number is the one that mattered most to leadership. We went from being 22% off to being 3.1% off. That's not a marginal improvement. That's the difference between "we'll explain the variance in the board deck" and "the forecast was right."
What the Model Sees That We Didn't
The most interesting output wasn't the aggregate LTV number. It was the decomposition.
The dynamic model could tell us: "34% of the LTV variance in this cohort comes from a shift in the self-serve vs. enterprise mix." Or: "Customers who adopted feature X in their first week have a 3.2Γ higher 12-month retention probability." Or: "The onboarding change in June contributed an estimated $18/customer LTV increase, detectable in 4 days."
Our static model could tell us a number. The dynamic model tells us a story β and a story you can act on.
Practical Considerations
If you're considering this for your own team, a few things to internalize:
You need a data pipeline, not just a model. The dynamic model is only as good as the freshness of its inputs. If your behavioral data lands in the warehouse with a 2-day lag, your "real-time" LTV is actually a 2-day-delayed LTV. Build the pipeline first.
Start with the market-state layer. This is the highest-leverage, lowest-effort improvement. You don't need a full sequence model to capture "the funnel shifted." A simple regression on funnel-level metrics that outputs a state vector can capture 70% of the benefit with 20% of the engineering effort.
Keep the cohort model for finance. Your CFO is not going to accept a probabilistic, per-customer LTV in the quarterly report. Keep the cohort-level model for external reporting. Use the dynamic model for internal decision-making. They answer different questions.
Calibrate the discount rate. Dynamic LTV is more sensitive to your discount rate assumption because it's projecting further into a less certain future. If you're using a 10% discount rate on a 12-month horizon, a 2% change in rate assumption moves your LTV estimate by roughly 15%. Be honest about this.
Treat the model as a sensor, not an oracle. The dynamic LTV estimate is a measurement instrument. It tells you where the model thinks value is. It doesn't replace judgment. It sharpens it.
The Deeper Lesson
The story of our Q2 wasn't really about LTV. It was about a category of business metrics that we treat as stable constants but that are actually emergent properties of a system that's always changing.
CAC, conversion rates, NPS, churn, LTV β all of these are not fixed. They're snapshots of a moving system. And the more dynamic the market, the more expensive it is to pretend they're static.
The dynamic model didn't make our business more predictable. It made our forecasts more honest about the fact that they were always going to be somewhat wrong, and it made sure we knew when they were getting wrong β and why.
That's the difference between a number and an instrument. And in Q3, when we'll build our next set of forecasts, we'll start with the instrument. π
The best forecast is the one that knows when it's about to be wrong β and tells you before the quarter closes.