Why it matters
Cohort LTV charts and segment averages answer a reporting question: "How did March buyers perform by month four?" They do not answer the bidding question: "Should we pay more for this user right now?"
Ad platforms optimize in real time on the events and values they receive per conversion. If you only send gross first-purchase revenue, everyone who checks out looks equally valuable until refunds and repeat orders arrive weeks later. If you send one blended value for a whole audience, the platform cannot rank users within the traffic you are buying today.
User-level pLTV closes that gap. Each eligible user gets an early score trained on first-party data from your data warehouse, then that score travels with the conversion event through paths like Meta Conversions API or Google Ads Conversion API. The platform learns a value gradient across users while acquisition is still active.
User-level pLTV
User-level pLTV is the activation unit in a signal orchestration stack:
- Inputs: Event, revenue, and identity history in your data warehouse (plus MMP data for apps where needed).
- Modeling: Per-user prediction at a defined prediction horizon (for example D7 or D90 value), trained on delayed outcomes.
- Anchor timing: Score fires on or after an anchor event so the platform receives value when the user is still in-market.
- Signal design: Magnitude, calibration, freshness, and volume so learning is stable.
- Activation: Churney sends user-level values directly to the ad network; the data warehouse remains the modeling input, not the delivery pipe.
Segment models and cohort-based LTV models can inform strategy, but they are not substitutes for per-user scores at bid time. See cohort-based LTV model for the distinction.
Category variants
| Vertical | Anchor event | Typical horizon | Notes |
|---|---|---|---|
| Ecommerce | First purchase | D30–D90 margin or net revenue | Refunds and repeat rate drive spread between users |
| Subscription | Trial start or first paid bill | Renewal and expansion | Trial-to-paid alone is a weak per-user value proxy |
| Mobile app | Install or registration | D7–D90 IAP / ad revenue | ATT and match rate affect how much of the score the platform can use |
Common mistakes
- Sending cohort averages as "pLTV." A single value for all purchasers removes the ranking signal platforms need.
- Scoring too late. Late scores may miss influencing the original impression's bid, but timely delivery still matters for how quickly the ad set learns which user profiles correlate with higher value.
- Unstable user IDs. Fragmented identity breaks training and event matching.
- Ignoring calibration. Uncalibrated scores inflate or deflate values; platforms learn the wrong gradient.
- Confusing reporting LTV with activation. Finance cohort views and per-user bid signals are different products.
Advertiser lens
| Role | Cares about |
|---|---|
| UA / performance | Can I bid differently on high vs low predicted value users today? |
| Growth analytics | Is the score stable, calibrated, and explainable vs holdout? |
| Finance | Does predicted value align with realized margin over time? |
| Data / engineering | Identity graph, feature pipeline, and event delivery to Meta CAPI or Google Ads Conversion API |
FAQ
What is user-level pLTV?
An early predicted value assigned to one customer, used to weight or rank that user's conversion events in ad platform learning.
How is it different from cohort LTV?
Cohort LTV looks backward at groups acquired in a period. User-level pLTV looks forward per person and is sent at acquisition time for bidding.
When should the score be calculated?
Soon after the anchor event, while the conversion can still be attributed and fed into ad set learning (often same session or within hours, depending on channel and upload path).
Do all platforms accept custom per-event values?
Major networks support value parameters on conversion uploads when campaign types allow value or ROAS optimization. Setup and volume requirements vary.
What data do you need?
Stable user IDs, revenue and behavioral history in a data warehouse, and a server-side or partner path to send values with conversions.
Can you use user-level pLTV without a holdout test?
You can launch, but holdout tests or incrementality readouts are how you prove the scores improve outcomes vs business as usual (BAU) bidding.
Not the same as
| Term | Difference |
|---|---|
| Customer lifetime value (LTV) | Historical realized value, not an early prediction for bidding |
| Cohort-based LTV model | Segment or cohort grain; not one score per user at event time |
| Average order value (AOV) | Single-transaction proxy, not full predicted relationship value |
