The budget allocation model
Cohort pLTV
- Weekly
- Per cohort
- Graded on the total
Cohort pLTV vs user-level pLTV
Two jobs. Two models. Never one.
Cohort pLTV allocates budget. You build it. User-level pLTV picks who to buy. Churney runs it.
AcmeBuilt in-house by your data team
InsideA regression, once a week
To Acme finance
Built and run for Acme
InsideCausal ML, in a loop with the auction
The one-model claim, examined
It fails on the math first.
Some vendors say one pLTV model handles budget allocation and bidding. It cannot, for five reasons. Each one is checkable on your own data.
01 · The best cohort forecast can’t bid
Same average. Different customers.
Ten new customers worth $60 on average. The perfect cohort forecast sends every one of them $60. It is exactly right about the total and tells the platform nothing about who to buy.
Cohort pLTV sendsOne value for the whole cohort
Average $60Ten equal customers.
User-level pLTV sendsA value for each customer
Average $60Who to buy more of.
02 · Different units
The bidding value isn’t even in dollars.
Meta lets you index or normalize pLTV values as long as the ranking holds (Meta’s guide). The platform bids the same on all three. Sum them for a budget and you get three different answers.
03 · Different clocks
One answers in hours. One waits for data.
Platforms learn from the first days after a click, so the bidding value has to land within hours. A cohort forecast is worth little before day 7, and gets better as the cohort matures.
04 · Different data
The bidding model moves its own data.
A cohort model observes who you acquired. A bidding model changes who you acquire, so its next training set depends on its last prediction. That loop needs testing and guardrails a forecast never does.
05 · Different grading
Graded on the total, or on telling people apart.
Minimize error on a cohort’s total and the winning model shrinks every customer toward the average. Optimize ranking and the winning model stretches them apart. These are opposite pressures on the same numbers.
Any model that claims to win both has picked one and stayed quiet about the other.
Ask anyone who sells one model for both.
If the answers are the same for both jobs, one of the jobs is being done badly.
- What does it minimize: error on the cohort total, or ranking of customers?
- In what units does it send values to Meta, and do they still add up to your revenue?
- When does it answer: within hours of the first event, or after day 7?
- How is it tested: a backtest on matured cohorts, or a split test in the account?
Side by side
Two models. Two owners.
Cohort pLTVThe budget allocation model
User-level pLTVThe bidding signal
Its job
Cohort pLTV: Budget allocation and financial forecasting
User-level pLTV: Telling Meta, Google and TikTok which customer to buy
Built by
Cohort pLTV: Your data team
User-level pLTV: Churney
Grain
Cohort pLTV: A cohort: a week, a channel, a campaign
User-level pLTV: Each new customer
Graded on
Cohort pLTV: Error on the cohort total
User-level pLTV: Ranking customers, then a split test
Answers
Cohort pLTV: Weekly, once day-7 data is in
User-level pLTV: Within hours of the first event
Units
Cohort pLTV: Dollars that add up to revenue
User-level pLTV: Whatever the platform bids best on; Meta accepts indexed values
Its data
Cohort pLTV: Observes customers
User-level pLTV: Changes which customers you acquire
Checked by
Cohort pLTV: Backtests on cohorts that have matured
User-level pLTV: Split test against your current setup, criteria in writing
Built by you
Build the first one yourself.
Cohort pLTV is your budget allocation and financial forecasting model. Your team should own it and be able to explain it. It is also the tractable part, and we would rather help you build it than sell it to you.
Open the free choosercohorts.churney.io
A few questions, then the model to build.
- Tell it how customers pay you and how you buy media
- Get the model to build, what not to use, and how you will know it works
- Hand the build to Claude: the chooser ends with a skill that builds it with you
When you come to feed the ad platforms, that is a second model.
Built by Churney
We run the second one.
The user-level model is the smaller part of the job. The work is in getting a value the platform can learn from, proving it against your current setup, and keeping it steady while the platform learns.
Before launch
Checked for every client, every test.
- Opportunity sizing on your data, against your current event
- A written test protocol: metric, success bar, cells, your attribution
- Every customer who fires the anchor event gets a value
- At least five distinct values, and no zeros
- The same dataset and population as your current signal
- Match quality on par with your current event
- Enough volume: 100 conversions a week on Meta
- Platform sign-off before launch
- About two weeks of signal before anything bids on it
The model is frozen until the readout.
After launch
Watched for every signal, every day.
Live predictions vs trainingWithin band
Checked Monday and ThursdayEvery drift alert gets a named cause before anything changes.
Retrain vs the model it replaces0.998
Ranking stable · shippedIf a retrain reshuffles who ranks high, it waits, so the platform does not relearn.
Values landing on the right customer91% matched
Match quality per signal, with an alert when an upstream change drops it.
Freshnessnext in 4h 46m
Warehouse syncs up to six times a day where a platform needs it.
The bidding signal, beyond ads
What the auction taught us.
Meta, Google and TikTok are the largest learning systems in production. Every problem of training them on a per-person prediction has a twin when you train your own models on one.
In ad bidding
In your models
The auction finds a proxy: device, hour, region
Reward hacking: the model learns what scores, not what pays
Bidding changes who you acquire, so the model drifts
Your model changes the conversations it sees, so the reward drifts
The model is frozen until the readout
The reward stays fixed for a training run
A retrain that reshuffles the ranking is held back
A new reward model is checked before a run uses it
Split test against business as usual, criteria in writing
Held-out gate, then a live A/B against the current model
Day-90 value predicted within hours
A score on every interaction now, for outcomes that land months later
The value must land on the right customer
The outcome must join the right conversation trace
Built by Churney, with you
Harness first. Then RFT.
The per-person predicted outcome scores every reply, offer or action your models take. We build it with you, on your data and the platform you already use. Your cohort model is not involved.
Step 1 · Harness
Change what surrounds the model.
Prompts, tool choice, routing and context, scored on the predicted outcome. The best variant ships. No training run.
- Weeks, not quarters
- Proves the reward on your own traffic
Step 2 · RFT
Then change the model itself.
Reinforcement fine-tuning on the same reward, released only after it passes a held-out gate and a live A/B against your current model.
- Vertex AI, Together, Fireworks, Tinker or SageMaker
- Production stays on your cloud
2x move accuracy in our chess study, about 1,500 Elo from near zeroA fifth of the cost of the frontier model it beatThe reward layer →
FAQ
Questions we get.
Can one pLTV model do both budget allocation and bidding?
No. A budget forecast is graded on the error of the cohort total, so the best one averages customers out. A bidding signal is graded on how well it ranks customers, within hours, on values the platform may not even read as dollars. A model tuned for one is doing the other badly, whatever the slide says.
Can I use my cohort LTV model for bidding?
No. It gives every customer in a cohort the same value, so the platform cannot tell the customer worth $200 from the one worth $5. Keep it for budget allocation and forecasting.
Can I sum user-level predictions to forecast a cohort?
Not reliably. The values are built to rank customers inside the platform’s window, can be indexed rather than in dollars, and the mix they score shifts as bidding follows them. Forecast with your cohort model.
Why should our own team build cohort pLTV?
It is your budget allocation and financial forecasting model, so your team should own it and be able to explain it. It is also the tractable part: start with one regression on your warehouse. Our free chooser at cohorts.churney.io tells you which model to build and ends with a Claude skill that builds it with you.
Why not build user-level pLTV the same way?
Because the model is the smaller part. The rest is sending a value the platform can learn from, proving it against your current setup, and keeping it steady while the platform learns. That is the work Churney runs every day.
What does Churney check before a test goes live?
Opportunity sizing on your data against your current event, a written test protocol, and a checklist per client: every customer who fires the anchor event gets a value, at least five distinct values, the same dataset and population as your current signal, match quality on par, enough weekly volume, and the platform’s sign-off. The signal then runs for about two weeks before anything bids on it, and the model is frozen until the readout.
What happens after the signal is live?
Live predictions are compared with training twice a week, and every drift alert gets a named cause. A retrain that reshuffles the ranking is held back so the platform does not relearn. Match quality and freshness are watched per signal.
Can the user-level signal train our own models?
Yes. The per-person predicted outcome that tells Meta which customer to buy can also score every reply, offer or action your own models take. That makes it a reward. Your cohort model stays where it is.
What is a harness, and why start there before RFT?
The harness is everything around your model: prompts, tool choice, routing and context. We score harness variants on the predicted outcome and keep the best, with no training run. Reinforcement fine-tuning comes next, on the platform you already use.
Build the first. We run the second.
A 30-minute call. We look at your data and tell you plainly whether user-level pLTV would pay.
Book a call
