Most app teams set their CAC payback window using a number that came from a Series A pitch deck three years ago. The actual install-to-first-revenue distribution looks very different, and disclosing it changes how marketing budget gets approved.

Across 145k+ non-reattribution installs processed on Linkrunner over the past month, the median time from install to first revenue event was 48 hours. The 90th percentile stretched to roughly 14 days. Those two numbers anchor a payback model more honestly than any blended LTV curve.

This post breaks the benchmark down by what it measures, why vertical changes the picture, and how to translate the numbers into a payback window your finance team can defend.

## What Install-to-First-Revenue Actually Measures

**Install-to-first-revenue timing is the elapsed time between an install event and the first revenue event credited to that install, measured at the user level and aggregated to a distribution at the project or portfolio level.**

What goes into the measurement:

- Install timestamp, captured at SDK first open or Install Referrer broadcast

- First revenue event timestamp, fired by the app or pushed to the MMP via server-side reconciliation

- A user-level join that links the two events through the same install id

What it is not:

- Time-to-first-session (which fires before any revenue event)

- Time-to-activation (a custom event that varies by product)

- D7 or D30 LTV (which measure cumulative revenue, not first-event timing)

This metric matters because it tells you when revenue starts, not when it ends. A blended LTV curve smooths over the early days where most teams feel the cash crunch. Our [true marketing ROI guide](https://linkrunner.io/blog/how-to-measure-true-marketing-roi-in-mobile-apps-complete-guide) covers how to layer this onto a full ROI calculation.

## The Benchmark: 145k+ Installs Across 24 Apps

Headline figures from the rolling month of April 2026:

Methodology note: non-reattribution installs only, joined to their first Revenue event within 720 hours of install. Project-level identifiers were stripped before aggregation. Apps span eCommerce, gaming, subscription, and fintech verticals.

What the long tail tells us:

- Roughly half of revenue-converting users do so within two days of install

- 90% convert within two weeks

- The 10% beyond two weeks are typically trial-to-paid transitions, multi-step KYC funnels, or user-driven research cycles

## How Vertical Changes the Picture

The blended median masks meaningful variation across app categories:

- **eCommerce and food delivery** cluster on the fast end. First purchase often happens in minutes to hours because the install was triggered by a specific intent (a sale, a craving, a referral code).

- **Subscription apps** cluster around the trial-to-paid transition. Median first revenue lines up with the day a 7-day or 14-day trial converts. Our [subscription app attribution guide](https://linkrunner.io/blog/attribution-for-subscription-apps-tracking-trials-conversions-and-churn) covers how trial-to-paid attribution interacts with this metric.

- **Gaming sits in between.** First in-app purchase follows a session-based curve. Casual games convert faster than mid-core titles because the monetisation surface area appears earlier in the session loop.

- **Fintech is bimodal.** Transactional apps (UPI, payments, remittance) convert in hours. KYC-heavy apps (lending, broking, insurance) often have multi-day onboarding before any revenue event fires.

If your distribution has two distinct peaks, you are probably looking at a hybrid revenue model and should split the analysis by event type before drawing payback conclusions.

## Translating Timing into a Payback Model

Install-to-first-revenue timing is the front end of a payback calculation, not the whole thing. The connection:

- Median tells you when revenue starts

- P90 tells you how patient your finance team needs to be before flagging a campaign as underperforming

- Cohort revenue curves (D7, D30, D90) tell you how revenue compounds after the first event

A simple structure:

1. Measure your median and P90 install-to-first-revenue

2. Pull D30 and D90 cohort revenue per channel

3. Compute payback period as CAC divided by cohort revenue at the cohort age that matches your finance committee's risk tolerance

For the formal P&L treatment, our [CFO's view of an MMP](https://linkrunner.io/blog/cfo-view-mmp-marketing-pnl-impact) covers how this connects to accrual revenue recognition and channel-level gross margin. For the mechanics of how an MMP compresses payback in practice, our [payback window impact post](https://linkrunner.io/blog/mmp-payback-window-impact-cac-recovery) walks through the three levers.

A scale anchor for what tracking this looks like in production: Jumbo Gaming has tracked Rs40+ crore in revenue across 250+ campaigns through Linkrunner, with first-revenue events flowing into the same attribution lineage as the install events. Operating at that volume requires the timing chain to be clean end-to-end.

## How to Pull This Number from Your Own MMP

The minimum-viable export from any MMP that supports raw data access:

1. Pull installs from the last 30 days with install timestamp, project id, and platform

2. Pull all revenue events within 720 hours of install with revenue timestamp, install id, and revenue amount

3. Compute revenue_time minus install_time in hours per row

4. Calculate median and P90 by vertical, channel, and acquisition source

5. Compare against the benchmark

How to handle edge cases:

- **Reattribution events:** exclude them from the install side. They distort the timing because the "install" already exists from a prior touch.

- **Refunds and cancellations:** decide upfront whether to count the gross revenue event or only the net. Most teams use gross for timing analysis and net for payback math.

- **Multiple revenue streams:** split by event type (subscription start, IAP, ad revenue) before aggregating.

For richer cohort segmentation that pairs well with this metric, see our [cohort analysis techniques guide](https://linkrunner.io/blog/best-6-mobile-app-cohort-analysis-techniques-for-growth-teams).

If your MMP exposes a per-project install-to-first-revenue distribution, you can skip the SQL. Linkrunner surfaces this distribution alongside the cross-customer benchmark in-product, so growth and finance teams can pull the comparison without engineering effort. Teams that have not yet wired in revenue events can start with the [revenue tracking API](https://docs.linkrunner.io/api-reference/revenue-tracking).

## What to Do When Your Number Sits Outside the Benchmark

A wide gap from the benchmark is a signal, not a verdict:

- **Median much faster than 48 hours.** Likely a checkout-focused vertical (food delivery, fast fashion, on-demand services). Validate with cohort revenue curves to confirm the early revenue compounds rather than churning.

- **Median much slower than 48 hours.** Investigate three things in order: event taxonomy (is your first revenue event firing when you think it is?), reattribution misclassification (are returning users being mixed into fresh-install timing?), and revenue-event lag (server-side reconciliation can delay events by hours or days, inflating the timing distribution).

- **P90 well above 14 days.** Long tails this far out usually indicate either a trial-driven business model or revenue events that fire late because of server-side reconciliation. Both are explainable, but neither is a true 14-day payback signal.

The revenue-event lag pattern is the single most common explanation we see for outlier P90s during attribution audits, and it is fixable without changing your underlying tracking.

## FAQ

**Is install-to-first-revenue the same as time to first purchase?**

Close but not identical. Time to first purchase usually refers to a specific event (a checkout). Install-to-first-revenue is broader and includes any monetised event such as a subscription start, an IAP, or an ad-revenue impression.

**How do I handle apps with multiple revenue streams (subscription plus IAP)?**

Split the analysis by event type. The first-event median for IAP often differs from subscription start by hours or days, and blending them hides the structural payback difference.

**Should I exclude trial conversions from this calculation?**

Depends on your model. If you treat a trial as activation rather than revenue, exclude it. If you treat trial-start as your first revenue signal because it correlates strongly with paid conversion, include it and document the choice in your methodology.

**How does install-to-first-revenue relate to CAC payback?**

It is the front edge. Median tells you when payback starts accruing; cohort curves tell you how fast it compounds; CAC divided by cumulative revenue at a chosen cohort age gives you the payback period.

**What does it mean if my distribution has a heavy long tail?**

Either you have a trial-led model (legitimate long tail), revenue events firing late (process issue), or reattribution events leaking into fresh-install data (measurement issue). Investigate in that order.

## What to Do Next

The single highest-value action this week: pull a 30-day install-to-first-revenue distribution from your MMP, compute the median and P90, and compare against the benchmark. If the median is more than 24 hours away from your existing payback assumption, your CAC model is using stale numbers and needs a refresh before the next budget review.

If you want to see your own install-to-first-revenue distribution alongside the cross-customer benchmark and pull a clean payback view without writing SQL, [request a demo from Linkrunner](https://www.linkrunner.io/) and we will walk you through the timing dashboard for your own project.