AARRR
Review acquisition, activation, retention, revenue, and referral with explicit events, cohorts, observation windows, and denominators.
Use AARRR to decide which part of a customer journey deserves investigation. Define acquisition, activation, retention, revenue, and referral separately; revenue and referral need not follow one another. The cards organize questions rather than measured counts or conversion rates.
Counts or observations for a defined cohort, the events behind each measure, the relevant time windows, and known gaps in the data.
A shared record of five diagnostic areas and the evidence needed for the next investigation or experiment.
How to use it
- Define the cohort and observation windows before entering stage counts.
- Specify acquisition and activation events in terms of meaningful customer behavior.
- Define repeat-use or return events and ensure the intended retention window is complete.
- Record payment and referral separately, including their own windows and attribution rules.
- Select a question to investigate; check logs or speak with customers before proposing a causal explanation.
Keep its limits in mind
A lower count does not identify a cause. Revenue and referral can occur independently. Compare rates only when cohort membership, event definitions, and observation windows support the denominator; do not infer a conversion rate from adjacent cards.
Choose an investigation after a first collaboration
Fictional software example. Teams from one signup week are tracked through first use and later collaboration. Payment and referral are recorded separately.
On a small screen, scroll across the diagram to read it.
Supported comparison: 24 of 60 activated teams is 40%, provided the following-month window is complete. The remaining teams have no recorded return in that window; this does not prove permanent churn.
Unknown relationship: The counts of 12 payers and 6 referrers do not establish a 50% payer-to-referrer conversion rate.
Next step: Investigate continued collaboration after activation. Confirm event tracking and observation completeness, then discuss obstacles with teams that did not return.
Three reasons to pause before dividing adjacent counts
Use AARRR to choose a customer question, with a defined event and eligible population for each metric. Teams, people, visits and purchases are different units. The visual order of the cards does not establish that each event is a prerequisite for the next.
Pause when cohorts or observation windows do not match. Pause when a team with an unfinished follow-up window is being marked as a nonreturner. Pause when payment and referral counts are divided as if one group were known to contain the other. First inspect membership and eligibility, then calculate the rate that answers your question.
The original 24/60 retention comparison is conditional on a complete following-month window. “Following month” also needs precise dates in actual tracking. Twelve payers and six referrers alone cannot establish their overlap, net revenue or why teams did not return.
Choose the investigation rather than a favorite funnel
A lifecycle summary can locate a question. Understanding the task, defining a metric or comparing purchase histories requires different inputs. Keep behavioral absence within a window separate from permanent churn.
| Method | Input | Output |
|---|---|---|
| AARRR | Cohort membership, event definitions and mature windows | Lifecycle questions and supported rates |
| KPI tree | Compatible counts, amounts and denominators | A reproducible metric breakdown |
| Customer journey map | Attributed task and touchpoint records | Experience gaps to investigate |
| RFM | Eligible purchase histories under common rules | Purchase-behavior groups to validate |
Worked case: preserve every team and its eligibility
This is an independent fictional six-team cohort, not a subset or estimate of the 200 teams above. T1–T6 signed up August 3–9, 2026. Activation means a first real collaboration within seven elapsed days after signup. Retention means collaboration in September 1–30 among activated teams. All those windows are complete in this teaching set.
Payment means at least one recorded payment during September; amounts and refund status are not supplied. Referral means at least one attributed new team during September. We count referrer teams, not the number of new teams; those new teams do not enter this signup cohort. Neither event requires a prior event in the other column.
The complete ledger below leaves retention ineligible for T5 and T6 because they did not activate. That does not claim they can never collaborate later. It preserves the denominator of the specific retention definition instead of silently counting every signup as eligible.
| Team | Activated | Retained if eligible | Payment record | Referrer |
|---|---|---|---|---|
| T1 | Yes | Yes | Yes | Yes |
| T2 | Yes | Yes | No | Yes |
| T3 | Yes | No | Yes | No |
| T4 | Yes | No | No | No |
| T5 | No | Not eligible | No | No |
| T6 | No | Not eligible | No | No |
Calculate the sets, then investigate without inventing a cause
Four of six activated: 66.7% when rounded to one decimal. Two of those four returned: 50% retention under this definition. Two of all six reached both activation and retention:33.3%, a different question. T3 and T4 have no recorded qualifying return in September, not proven permanent churn.
There are two payment-record teams and two referrers, but their intersection contains only T1. The share of payment-record teams that referred is therefore 1/2 = 50%, not 2/2 = 100%. Equal totals do not imply identical membership. T2 referred without a payment record, while T3 has a payment record without a qualifying retained event. None of these counts provides a revenue amount or margin.
The conclusion is a continued-collaboration investigation with a denominator and membership check. For the original 200-team case, retrieve the actual authorized ledger rather than substituting this teaching set. Confirm event capture, identity rules, complete windows and overlap before accepting rates. Ask eligible nonreturning teams about recent tasks and obstacles without presuming disinterest. Keep tracking gaps separate from a confirmed absence of an event.
If a change is proposed, agree eligibility, scope, outcome window and review before execution. Retain the original cohort and definitions, append outcomes and explain any rule change. Review continued collaboration alongside relevant quality and payment information; an increase in one count does not establish causation or business profitability. The cards identify where to look, not an automatic intervention.
Check your work
- Each count has a defined event and population.
- Activation and retention windows are explicit and sufficiently observed.
- The payment and referral groups are not assumed to be nested.
- Unknown stages stay unknown rather than receiving invented zeros or rates.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.
Read a practical guide →Practice with an example
Switch denominators for the same cohort counts, distinguish the first task from later use, and leave with a bounded problem statement and evidence plan.
New users aren’t coming back. What should you check first? →