# Paid User Acquisition for LLM Apps: Start With the Return Loop

> Define why an acquired user should come back, then buy one cohort you can learn from before you scale.

- Author: Rishikesh Ranjan · Published: Sep 13, 2026
- Type: Playbook
- Tags: Acquisition, AI, Retention
- Growth levers: Acquisition (primary), also Activation, Retention, Revenue
- ~2348 words

---

Paid user acquisition can put an LLM app in thousands of hands before the team knows why anyone should open it twice. That is the dangerous part. Campaign feedback can start arriving before a reason to return is fully observable.

There is real money behind the rush. [AppsFlyer reported $824 million in GenAI app user acquisition spend in 2025](https://www.appsflyer.com/resources/reports/top-5-data-trends-report/). Yet purchase intent does not settle the retention question. In RevenueCat's 2025-period subscription dataset, [AI apps reached a 2.4% median 35-day download-to-paid conversion rate, compared with 2.0% for non-AI apps, while their 12-month subscription retention was lower across weekly, monthly, and annual plans](https://www.revenuecat.com/state-of-subscription-apps). These are separate vendor datasets and subscription retention is not product-use retention. Together, they still expose the operating problem: early monetization can look healthy while durable value remains unsettled.

The answer is not to ban paid acquisition until retention is perfect. A small paid cohort can test a promise, supply enough users to inspect behavior, and reveal where the product leaks. The answer is to give the spend a job. Before you scale, define the return loop, connect it to acquisition data, and write the rule that will turn evidence into one of three decisions: scale, repair, or stop.

> **The operating rule:** Use paid user acquisition to buy an interpretable cohort, not a flattering install chart. Increase spend only after users complete the promised job and return at the product's natural cadence.

## Step 1: Write the return loop before the ad brief

A return loop is the sequence that makes another session useful. It is not a push notification, a streak, or a vague hope that users form a habit. Write it as five linked parts: the trigger that starts the job, the task completed in the app, the state or value saved, the next occasion when that value matters, and the event that proves the user returned for it.

| LLM app | First useful task | Saved state | Next natural occasion | Verified return |
| --- | --- | --- | --- | --- |
| Answer engine | Resolve a research question with sources | Thread, collection, or followed topic | The question changes or a related decision appears | User reopens the thread and asks a related question |
| Creator tool | Produce one usable draft or asset | Project, style, and editable output | The creator needs the next version or format | User returns to edit, extend, or export the project |
| AI tutor | Complete one lesson with feedback | Skill level, mistakes, and next lesson | The learner reaches the next study slot | User begins the recommended follow-up lesson |
| Workflow assistant | Finish one recurring work task | Template, integration, and prior context | The task recurs | User runs the saved workflow again |
*The return event changes with the job. Daily opens are useful only when the job should recur daily.*

Start with one audience and one job. “People who use AI” is not an audience, and “get answers” is not a job. “Graduate students comparing evidence for a weekly literature review” gives you a trigger, a task, and a plausible return occasion. The narrower statement also gives the creative team something honest to promise.

Now write the event in language an analyst can implement. “Returned user” is too loose. Try: “Among new paid-source users who saved a sourced research thread in their first 24 hours, the share who reopen that thread or ask a related question during days 4 to 10.” The definition names the cohort, qualifying value event, return action, and observation window. Two analysts should classify the same account the same way.

If the event definition is the hard part, the [user retention strategies playbook](https://www.productgrowth.blog/p/user-retention-strategies) shows how to choose the unit, interval, competing explanation, and stop rule before you pick a tactic.

> **Do not force a habit onto a one-off job:** An AI résumé editor may finish its job in one session. A tax assistant may have a quarterly or annual cadence. In those cases, measure completion, paid value, referral, or a milestone return. A daily-retention target would punish a product for solving the job quickly.

## Step 2: Build the cohort spine

The cohort spine connects the ad impression to the later return. Without it, the media buyer sees cost per install, product sees activation, finance sees subscription revenue, and nobody can tell whether the same people moved through all three. Make one owner responsible for the definition, even if several tools collect the events.

1. Capture source, campaign, ad set, creative, platform, country, and first-touch time. Preserve the raw identifiers as well as readable names.
2. Record install or signup separately from first open. An app-store download and a first session are not the same event.
3. Define first value as the completed job, not a button click on the way to it. For the research assistant, that may require a question, a generated answer, and at least one opened source.
4. Mark when a user becomes eligible to return. Someone who has not yet reached the next study slot should not sit in the denominator for a seven-day return decision.
5. Record the verified return, revenue, refund, and variable inference cost on the same user and cohort keys.

Write down every window before launch. [Apple says its Ads dashboard and mobile measurement providers can differ in install source, attribution window, and redownload treatment](https://ads.apple.com/app-store/help/attribution/0027-mobile-measurement-providers). If the growth review quietly compares Apple's tap-through install count with an MMP's first-open count, a reporting difference can masquerade as a product problem. Version the measurement spec and note which system owns each number.

### Run one end-to-end test before buying traffic

Use a real phone and a test campaign marker. Tap the ad, install or sign up, complete first value, wait or alter the clock in a test environment, return, and purchase if the flow includes payment. Then inspect the raw events. Confirm timestamps, user identity, campaign fields, duplicate handling, consent state, and revenue currency. A dashboard screenshot is not enough; the row-level chain has to survive.

## Step 3: Pass the readiness gate

Paid acquisition has two legitimate modes. Learning mode buys a capped cohort to test a promise or expose a leak. Scale-test mode asks whether a proven loop can absorb more spend without losing quality. Confusing the two is how a useful experiment becomes an expensive habit.

| Gate | Pass condition | If it fails |
| --- | --- | --- |
| Observable value | First value and verified return have unambiguous events | Fix instrumentation before launch |
| Real repeat occasion | The chosen job naturally recurs inside a named interval | Use completion, revenue, or referral instead |
| Baseline | At least one mature organic or existing-user cohort is readable | Enter learning mode and avoid a scale claim |
| Economic boundary | Maximum acceptable loss and cost components are written | Finance sets the cap before media goes live |
| Decision rule | Scale, repair, stop, and data-failure branches are agreed | Do not launch until owners agree |
*Passing every row allows a scale test. Missing a baseline can still permit a bounded learning test, but not a profitability conclusion.*

Give the retention clock enough time to mature. A [selective a16z analysis of cohorted total revenue retention from dozens of top-performing AI companies describes a common drop from month 0 to month 3 as exploratory users churn](https://a16z.com/ai-retention-benchmarks/). That does not mean every consumer app must wait three months for every decision. It means an early return can guide product work while a monthly subscription or repeated workflow needs a later confirmation. Label the fast signal “operating checkpoint” and the mature one “scale evidence.”

## Step 4: Buy one interpretable cohort

Keep the first campaign deliberately narrow: one user job, one country or comparable market group, one primary channel, and a small set of creative variations around the same promise. If you change the audience, value proposition, onboarding, paywall, and channel at once, a winning blended result cannot tell you what to repeat.

Set the budget from the learning requirement and maximum loss, not from a fashionable test amount. Start with the number of eligible returned users needed to make a directional decision. Work backward through your baseline first-value and return rates to estimate the installs required, then multiply by an expected high-side CPI. If that total exceeds the amount you can lose, narrow the question or wait. Do not shrink the cohort and pretend the result became conclusive.

### Choose a biddable event without changing the scoreboard

Choose an event timely and frequent enough to meet the selected network's optimization requirements. Your business may need a later event close to retained value. Those can be different. [Google documents App campaign goals for installs, selected in-app actions, specific in-app actions, and in-app action value](https://developers.google.com/google-ads/api/docs/app-campaigns/create-campaign). For a new research assistant, you might bid toward “saved a sourced thread” once it occurs reliably, while the team still judges the channel on eligible return and cost per retained user. Do not promote a convenient proxy into the company goal just because the ad platform can optimize it.

Each creative should promise the same job the product measures. Show the input, the useful result, and the context in which it matters. Keep a creative ID on every acquired account. [AppsFlyer's 2025 creative report reads installs per thousand impressions together with D7 retention and says high install response with weak retention can signal an expectation mismatch](https://www.appsflyer.com/resources/reports/creative-optimization-report-2025/). Treat that as a diagnostic lead, not a verdict. Broad targeting, weak onboarding, or an unreliable model output can create the same pattern.

## Step 5: Read the return economics

Review only cohorts whose windows have matured. Put the acquisition date, eligible-return date, and observation end beside every row. Then calculate the transitions in order. A later rate cannot rescue a broken denominator upstream.

- First-value rate = users completing the promised first job / new acquired users.
- Eligible-return rate = users who reached a real next occasion / users completing first value.
- Retained return rate = users completing the verified return / users eligible to return.
- Cost per retained user = campaign spend / users completing the verified return.
- Contribution after acquisition = realized revenue minus refunds, inference cost, payment fees, and campaign spend for that cohort.

### Worked example: the cheap install loses

Suppose a mobile AI research assistant runs two hypothetical creative cells. These numbers are illustrative, not market benchmarks. Cell A spends $4,000 and buys 2,000 installs. Cell B spends the same amount and buys 1,250 installs. Cell A wins on CPI at $2 versus $3.20.

Now follow the loop. In Cell A, 500 users save a sourced thread, 400 become eligible to return, and 40 complete the return event. First-value rate is 25%, retained return rate is 10% of eligible users, and cost per retained user is $100. In Cell B, 500 users save a thread, 400 become eligible, and 100 return. First-value rate is 40%, retained return rate is 25%, and cost per retained user is $40. The higher-CPI cell buys fewer installs but two and a half times as many retained users per dollar.

The example does not prove Cell B is profitable. You still need paid conversion, realized revenue, refunds, and inference cost over a suitable payback window. It does show why CPI alone can send budget toward the weaker cohort. Use the customer acquisition cost calculator and [LTV to CAC ratio calculator](https://www.productgrowth.blog/calculators/ltv-cac-ratio) once the cohort has enough revenue history to support those inputs.

## Step 6: Choose scale, repair, or stop

Set the rule before results arrive. Otherwise every weak cohort develops a persuasive explanation and every promising cohort receives too much budget too fast. Use this table as a starting policy, then replace the qualitative gates with your own baseline and economic limits.

| Observed pattern | Likely question | Next test | Budget action |
| --- | --- | --- | --- |
| Strong response, weak first value | Does the ad overpromise, or does onboarding block the job? | Replay sessions and test promise-to-onboarding continuity | Hold spend |
| Strong first value, weak eligible return | Is the job genuinely recurring for this audience? | Interview completers and test a narrower recurring job | Reduce to learning minimum |
| Strong eligibility, weak verified return | Is saved state useful and is the next occasion visible? | Test project memory, progress, or a timely trigger | Hold spend |
| Strong return, weak contribution | Do pricing, refunds, or inference costs break payback? | Test packaging or cost controls without changing the audience | Do not scale yet |
| Strong loop and acceptable economics | Does quality survive more volume? | Increase one budget step and compare a matched mature cohort | Scale gradually |
| Broken identity or immature window | Can the result be trusted yet? | Repair data or wait for maturity | Pause the decision |
*Treat each diagnosis as a question to test. Similar dashboard patterns can have different causes.*

Scale means one controlled increase, not a victory lap. Raise the budget or open one adjacent audience, then compare a new mature cohort with the same event definitions. Watch cost per retained user, contribution, model quality, latency, support load, and refund rate. More volume can change audience mix and product performance at the same time.

A retention model can help the team agree on the lever. [Duolingo reports that a simulated 2% month-over-month improvement in Current User Retention Rate produced the largest modeled DAU impact among the transition metrics it tested](https://blog.duolingo.com/growth-model-duolingo/). Duolingo then staffed a team to test whether the metric could move and whether moving it changed DAU. The useful lesson is the sequence: model the lever, assign a team to test it, and do not treat simulated impact as causal proof. Its 2% result belongs to Duolingo, not to an LLM app's target sheet.

## Run the loop review as an operating cadence

A weekly meeting should end with one decision, not a tour of every chart. Assign paid growth to campaign inputs, product to first value and return behavior, analytics to definitions and cohort maturity, lifecycle to owned triggers, and finance to contribution and loss limits. One person can hold several roles on a small team, but the responsibilities should stay explicit.

1. Monday: analytics checks identity, missing campaign fields, duplicates, late revenue, and cohort maturity. Data failures get fixed before interpretation.
2. Tuesday: growth and product read one cohort from creative response through verified return. They compare it only with cohorts using the same window.
3. Wednesday: the owner chooses scale, repair, stop, or wait and writes the reason in one sentence. The next test changes one main variable.
4. Friday: the team logs product, model, pricing, creative, and attribution changes so the next cohort does not inherit a mystery.

This cadence protects both sides of the system. Product cannot dismiss every paid cohort as low quality, and marketing cannot call cheap installs a success while the return event collapses. Both teams work from the same chain of user behavior.

## The pre-scale checklist

- One audience and recurring job are named in plain language.
- The five-part return loop and natural cadence are written.
- Source, creative, first value, eligibility, return, revenue, refund, and variable cost share a cohort key.
- A real-device event test has passed from ad tap through return.
- The campaign has one learning question, a maximum loss, and a maturity date.
- Scale, repair, stop, and data-failure rules were set before launch.
- The next budget increase depends on a matched mature cohort, not CPI alone.

Paid acquisition is useful when it shortens the path to a decision. For an LLM app, the first decision is rarely “Can we buy more installs?” It is “Did the promise attract people with a recurring job, did the product remember enough to make the next session better, and did enough of them come back to justify another dollar?” Build that answer into the campaign before the auction starts.

## Questions about paid user acquisition for LLM apps

#### What retention rate should an LLM app hit before scaling paid user acquisition?

There is no defensible universal rate. Match the return event and window to the product's natural job, compare paid cohorts with a relevant baseline, and require economics that fit your margin and payback limits. Keep subscription, revenue, and product-use retention separate.

#### Should a new app optimize campaigns for installs or an in-app event?

Use the deepest event that is both meaningful and frequent enough for the campaign to learn from. Early on, that may be first value rather than the later return. Keep retained return and contribution as the scale scoreboard even when the network bids toward a faster proxy.

#### Does this playbook work for web-to-app acquisition?

Yes, if identity survives the handoff. Add landing-page visit, web signup, store redirect, install, and account link to the cohort spine. Measure the unattributed share and state the handoff's attribution limitations in every review.

#### What if the product's natural return takes months?

Use an early operating checkpoint that is plausibly connected to later value, but do not call it retention proof. Keep spend in learning mode, follow the cohort to its real return window, and judge scale only when that outcome matures.

**Next job: Measure the return you just defined.** Put the eligible cohort and verified return into the retention-rate calculator, then save the definition beside the result. [Continue](https://www.productgrowth.blog/calculators/retention-rate)

---

All posts: https://www.productgrowth.blog/archive · Site: https://www.productgrowth.blog