AARRR Metrics: A Practical Guide for Founders

Listen to the podcast

AARRR Metrics: Which Number Should a Founder Fix Next?

An 8-minute conversation between an AI host and Heemang Parmar, covering the five metrics, the BriefBoard example, and what founders should measure next.

8 min 16 sec · In-page audio playback is temporarily unavailable. The full transcript is available below.

AI audio disclosure: This is a scripted, AI-generated interview adapted from this article, using Heemang Parmar’s authorised voice clone and a synthetic host. It is not a recording of a live interview. BriefBoard and all case-study numbers are hypothetical.

Read the podcast transcript

Host: More traffic. More signups. More activity. Those sound like good things. So why can a product still struggle to grow?

Today, we're discussing AARRR, or pirate metrics, with Heemang Parmar, founder of ProductOS. This is an AI-generated conversation adapted from Heemang's article, using his authorised voice clone.

Heemang, where would you start when a founder says, “Our numbers are going up, but the business isn't getting healthier”?

Heemang: I would ask which numbers are going up, and what they tell us about the customer.

A signup tells you someone was interested enough to try. It doesn't tell you whether the product helped them. And a login doesn't necessarily mean they came back for something useful.

The question I want the team to answer is: where are we failing to turn interest into repeat value? Then, what should we change?

Host: Give us the framework before we get into the numbers.

Heemang: AARRR stands for Acquisition, Activation, Retention, Referral and Revenue. Dave McClure introduced it as Startup Metrics for Pirates.

Acquisition asks whether the right people are arriving. Activation asks whether they get value for the first time. Retention asks whether that value repeats. Referral asks whether they bring new customers. Revenue asks whether the economics support the business.

But don't treat it as five mandatory steps in order. Someone can pay before using a product. A referral can happen before payment. It's a way to organise questions, not force every customer into the same journey.

Host: Which of those do teams misunderstand most easily?

Heemang: Activation is easy to make look better than it is.

You can call email verification activation. Or profile completion. Those may be necessary, but what did the customer actually achieve?

For a reporting tool, it could be getting a useful report from real data. For a scheduling product, the first real booking. For a workflow product, a handoff that removes the need to chase someone.

Start with the outcome. Then decide which event gives you credible evidence of it.

Host: Let's make this concrete. Your article uses a fictional agency tool called BriefBoard.

Heemang: Yes. These are teaching numbers, not ProductOS results or industry benchmarks.

Imagine one thousand new customer accounts. We're counting accounts, not individual employees. Three hundred create a useful work plan from a real client brief and assign a real task within seven days. That gives us thirty percent activation.

Then one hundred and twenty accounts complete a real task during days twenty-two through twenty-eight. That's our fourth-week return event.

Host: So retention is twelve percent?

Heemang: Twelve percent of all one thousand new accounts. But in this example, those one hundred and twenty also belong to the three hundred accounts that activated early. So retention among activated accounts is forty percent.

Same retained customers. Two different denominators.

Both numbers are correct. If I only show you forty percent, though, I'm hiding the customers who never reached first value. I want both views clearly labelled.

Host: That sounds like a small reporting detail with a fairly big consequence.

Heemang: Exactly. You could spend the whole meeting debating whether retention is good while people are looking at different definitions.

Write down the cohort, the event, the window and the denominator. And wait until the observation window is complete. An account created yesterday cannot tell you anything about fourth-week retention yet.

Host: What does the revenue picture look like for BriefBoard?

Heemang: Let's assume sixty accounts have paid and are still on an active forty-nine-dollar monthly subscription at day thirty-five. In this simplified example, that's two thousand nine hundred and forty dollars in monthly recurring revenue.

Now model a different activation outcome. Keep the same one thousand new accounts, but suppose four hundred and fifty activate instead of three hundred.

If forty percent of those activated accounts still return in week four, we get one hundred and eighty retained accounts. If half of those are paying at day thirty-five, we get ninety paying accounts.

At the same price, that's four thousand four hundred and ten dollars in monthly recurring revenue.

Host: Fifty percent more recurring revenue, without increasing acquisition. That's a tempting headline.

Heemang: It is. And that's where we need to be careful.

It's a scenario, not an experiment result. We held downstream retention, payment conversion and price constant. In reality, the additional accounts we activate might retain less well. The new experience might also cost more to support.

The model says, “This hypothesis could be worth testing.” It doesn't say, “Ship this feature and revenue will rise by fifty percent.”

Host: So what would you actually test?

Heemang: First, understand why customers aren't reaching value. Look at the onboarding journey and speak to customers. Suppose the empty workspace is the problem. A guided brief-to-plan flow could be a focused intervention.

Then verify the tracking. For a collaborative product, consider assigning the experiment by account, so teammates don't get conflicting experiences.

Set the success measure and stopping rule in advance. Also watch quality, errors, support demand and cost. More completed plans aren't helpful if the plans are unusable.

And give retention and payment enough time to mature. Don't stop the test just because an early number looks exciting.

Host: We haven't talked much about referral. Is a high recommendation score enough?

Heemang: No. A survey asking whether someone would recommend you is different from someone actually bringing a new customer.

Track invitations, new referred accounts and whether those accounts activate. Also separate a colleague joining an existing workspace from a new customer account being created.

In our fictional example, referred accounts go into their own signup cohorts. They don't get added backwards into the original group just to make its numbers look better.

Host: One last distinction: monthly recurring revenue versus cash in the bank.

Heemang: They are not the same thing. Monthly recurring revenue normalises subscription amounts. If a customer pays annually, you don't count the entire annual payment as one month's recurring revenue.

Revenue is not the same as profit. Customer acquisition payback needs to consider the cost of delivering the service. That's especially important for AI products, where more usage can mean higher inference costs, more retries or more human correction.

I would want to know whether customers are completing useful work, and whether we can keep delivering that outcome economically.

Host: If a founder takes one action after listening, what should it be?

Heemang: Pick one important customer outcome. Write down exactly how you'll recognise it, who you're counting and over what period.

Then review mature cohorts and choose one problem to investigate. Give that investigation an owner. Decide what evidence would make you keep, change or stop the proposed intervention.

You don't need five impressive dashboard tiles. You need a clear reason for what the team should work on next.

Host: The full article is AARRR Metrics: A Practical Guide for Founders, on ProductOS dot dev. It includes the hypothetical case, visual explanations and linked research sources. You'll find the article link in the episode notes.

Thanks for listening.

A product can have more traffic, more signups and more activity, yet still struggle to grow into a healthy business. The numbers are moving. The customer outcome may not be.

My starting question is simple: where are we failing to turn customer interest into repeat value, and what should the team do about it?

AARRR gives founders and product teams a useful structure for answering that question. But the framework becomes useful only when we define the events, the people or accounts being counted, and the time windows behind each number. Five dashboard tiles without those definitions can create more confidence than understanding.

This guide explains the framework, the metrics I would put behind it, and a small hypothetical SaaS example. The example is deliberately fictional. It is not ProductOS performance data, a customer success story, or an industry benchmark.

What are AARRR metrics?

AARRR stands for Acquisition, Activation, Retention, Referral and Revenue. Dave McClure introduced the framework in 2007 as “Startup Metrics for Pirates.” His original presentation breaks the customer lifecycle into these five categories and encourages teams to measure deeper conversion, rather than stopping at visits. [1]

• Acquisition: how the right potential customers find and enter your product.
• Activation: whether they experience meaningful value for the first time.
• Retention: whether they return and continue receiving value.
• Referral: whether existing users bring new potential customers.
• Revenue: whether the value delivered supports a viable business.

A paid product may generate revenue before the customer activates. An enterprise buyer may sign a contract before employees begin using the product. A referral can happen before payment. Returning customers can introduce more customers, creating a loop back to acquisition.

I would use AARRR as a diagnostic framework, not a rigid sequence or a rule that monetisation must wait until the end.

Before choosing metrics, write a measurement contract

“Activation is 40%” is an incomplete statement. Forty percent of whom? Completing which action? Within how long? Are internal accounts included?

For every primary metric, write down:

1. Unit: a person, account, workspace, company or transaction. In B2B SaaS, ten employees from one customer are not ten customers.
2. Cohort: the group entering through the same defined event and period, such as new eligible accounts created during one week.
3. Qualifying event: the observable action that counts, including any quality requirements.
4. Window: when the action must happen, measured from a clear starting timestamp.
5. Denominator: everyone eligible for the question being asked, not only the users who made it far enough to look successful.
6. Exclusions and ownership: bots, test accounts, duplicate workspaces, refunds where relevant, and the person responsible for the definition.

Keep the definition versioned. If you change the activation event or attribution model, annotate the change. A definition change is not a product improvement.

1. Acquisition: are we attracting people with the right problem?

Acquisition starts with discovery, but traffic alone does not tell us whether a channel is working. Someone searching for a solution to an urgent problem and someone casually clicking an interesting post can both become visitors. Their downstream behaviour may be very different.

I would review each meaningful channel against new eligible accounts, activation, retained accounts and paying customers. McClure’s original slides make a similar point: evaluate channels deeper down the conversion path, ideally through monetisation. [1]

Useful measures include:

• Visitor-to-signup conversion: attributable new signups divided by eligible unique visitors, using a documented attribution window.
• Cost per activated account: channel spend divided by the attributable accounts that meet the activation definition.
• Customer acquisition cost, or CAC: the acquisition costs included in your policy divided by the new paying customers attributable to those costs.

Cost per signup is not CAC. If the denominator is free signups, label it that way. Also distinguish paid-channel media costs from a fully loaded CAC that includes relevant sales and marketing costs. Sales cycles can stretch across months, so dividing this month’s spending by this month’s customers may misrepresent the underlying acquisition economics. [2]

Decision: if a channel delivers cheap signups but weak activation and retention, investigate targeting and promise-to-product fit before increasing its budget.

2. Activation: did the customer actually get value?

Creating an account, verifying an email or completing a profile can be necessary steps. They are not automatically evidence that the product helped.

For a reporting product, first value might be a useful report delivered from real customer data. For a scheduling product, it might be the first real booking. For a workflow product, it might be a completed handoff that saves someone from chasing an update.

Activation rate = eligible new accounts reaching the defined value event within the activation window ÷ eligible new accounts with a fully observed activation window × 100.

Alongside the rate, measure time to first value. Report the median and a slower-tail percentile among accounts that activate, but keep the non-activating share visible. “Our activated customers get value quickly” can hide the fact that most customers never activate.

My practical approach is to identify candidate value events from customer conversations, then test whether accounts completing those events tend to retain better. That relationship is a useful signal, not proof of causality. More motivated customers may both complete onboarding and retain, even if the onboarding step itself causes neither.

Mixpanel’s product analytics guidance makes the underlying distinction clearly: meaningful active usage should reflect customers finding value, rather than merely accessing the product. [3]

Decision: remove unnecessary work before first value, improve empty states, or offer a relevant starting template. Do not improve the activation rate by redefining success as an easier but less meaningful click.

3. Retention: does that value repeat?

Activation answers whether the customer found value once. Retention asks whether there is a reason to come back.

Choose a return event and a cadence that match the job. A weekly agency workflow does not need daily usage to be valuable. An annual tax product should not be judged like a daily messaging app.

There are several valid retention definitions, and they answer different questions:

• Exact-day retention: did the user return on a specified day after entry?
• Window retention: did the user return at least once during a defined interval, such as days 22–28?
• On-or-after retention: did the user return on the specified day or later within the observed period?

Amplitude documents the difference between “Return On” and “Return On or After,” including how incomplete observation windows affect the calculation. These numbers are not interchangeable. [4]

Week-four account retention = accounts in the original eligible cohort completing the return event during the defined fourth-week window ÷ accounts in that cohort with a complete fourth-week observation window × 100.

In a B2B product, measure account-level value separately from individual employee activity. Deduplicate on the correct account identifier or configure the appropriate group analytics. A busy employee does not necessarily mean the whole customer account is healthy.

I also want both retention among all new accounts and retention among activated accounts. The first exposes the complete onboarding problem. The second helps investigate what happens after first value. Do not silently replace one with the other.

Decision: compare mature cohorts by customer segment, use case and acquisition source. If activation rises but repeat value does not, talk to customers about what was missing after that first successful session.

4. Referral: are customers bringing new customers?

A share button click is not a referred customer. An invitation sent is not an accepted invitation. A colleague joining an existing workspace may improve collaboration without creating a new customer account.

Track the path explicitly: eligible referring accounts, accounts sending referrals, unique invitations or links, attributable new accounts, then activation and retention of those new accounts.

• Referral participation rate: eligible accounts making at least one qualifying referral divided by eligible accounts, in a stated period.
• Invitation-to-signup conversion: attributable new accounts divided by unique eligible invitations, under a stated conversion window and deduplication policy.
• Activated referrals per eligible account: new referred accounts reaching activation divided by the original eligible referring accounts.

The familiar viral-coefficient formula, average invitations per user multiplied by invitation conversion, can be useful. But it is a simplified model. The eligibility base, cycle time, duplicates, recipient saturation and referred-user quality all matter. A short-window coefficient is not a guarantee of self-sustaining growth.

NPS is a different measure. Bain defines it from answers to a recommendation-likelihood survey, using the percentage of promoters minus detractors. That is not an observed referral-conversion rate. Use survey answers to learn why people might recommend you, and referral events to measure what actually happened. [5]

Decision: place a useful invitation or sharing opportunity after a genuine value moment, then assess the quality of the accounts it brings.

5. Revenue: is the product building a viable business?

Revenue measurement should connect willingness to pay with retention and cost to serve. A conversion improvement that attracts heavily discounted customers, increases refunds or requires expensive manual support may not improve the business.

For a subscription product, I would begin with paid conversion, monthly recurring revenue, customer retention and gross margin.

Paid conversion by day X = cohort accounts that satisfy the documented paid-conversion definition by day X ÷ eligible cohort accounts with a fully observed X-day window × 100. Define whether this means first successful payment or an active paying subscription at the observation date. They are different measures.

MRR = the sum of monthly-normalised recurring subscription amounts under your documented billing policy. It is not the sum of cash paid into your bank account this month. Stripe explicitly distinguishes MRR from GAAP revenue and immediate cash flow. An annual subscription is normalised to a monthly amount rather than counted entirely in the payment month. Document how your system handles discounts, delinquency and usage-based charges. [6]

For existing subscription customers, track net revenue retention, or NRR:

NRR = (starting recurring revenue + expansion − contraction − churn from that same starting customer cohort) ÷ starting recurring revenue × 100.

Do not add revenue from newly acquired customers to NRR. Expansion can offset losses and take NRR above 100%, so also inspect customer counts and gross revenue retention. A few large expansions can hide a broad customer-retention problem. [7]

Finally, assess CAC payback using gross profit rather than revenue alone. A simplified estimate is CAC payback in months = CAC ÷ (monthly recurring revenue per customer × gross-margin fraction). Treat that as a model with explicit assumptions about stable pricing, margin and retention, not a promise of cash recovery. [2]

Decision: investigate why customers pay, downgrade or leave. Avoid projecting lifetime value from a tiny, immature cohort and then using the optimistic result to justify more spending.

A small hypothetical case: BriefBoard

Imagine BriefBoard, a fictional SaaS tool that helps small agencies turn a client brief into a work plan. All numbers below are invented for teaching. They are not targets or benchmarks.

The unit is a customer account, not an employee. We start with a fully observed cohort of 1,000 new eligible accounts. All day windows are elapsed time from account creation, consistently using UTC timestamps. Day 1 is the first 24 hours, activation is measured through the first seven days, and week four is days 22–28.

First value means an account creates a work plan from a real brief and assigns at least one real task. Repeat value means a team member completes a real task in the product during week four. Internal accounts and sample-data-only activity are excluded.

The baseline cohort

• 300 accounts activate by day 7: 300 ÷ 1,000 = 30%.
• 120 accounts complete the week-four return event: 120 ÷ 1,000 = 12% of all new accounts.
• In this example, all 120 retained accounts came from the 300 early-activated accounts. Retention among that activated subset is 120 ÷ 300 = 40%.
• 60 accounts have successfully paid and remain on an active $49/month subscription at day 35: 60 ÷ 1,000 = 6% paid conversion under this example’s definition.
• With no discounts, refunds, taxes included in price, or usage charges in this simplified model, their cohort MRR at day 35 is 60 × $49 = $2,940.

The paid accounts are assumed to be a subset of the 120 retained accounts for this teaching example. That is a modelling choice, not a universal customer journey.

Referral is a separate branch. Suppose 24 of the 120 retained accounts send 60 unique external invitations during days 29–35. Those invitations produce 12 new customer accounts within a seven-day invitation-conversion window. Participation is 24 ÷ 120 = 20%, invitation conversion is 12 ÷ 60 = 20%, and new referred accounts per retained account are 12 ÷ 120 = 0.10.

Those 12 new accounts belong to their own signup cohorts. They are not added retrospectively to the original 1,000-account cohort, and we wait until all invitation windows mature before reporting conversion.

What if activation improved?

Suppose interviews suggest that new customers struggle to turn an empty workspace into a useful first plan. The team considers a guided brief-to-plan flow.

Before building it, model a scenario with the same 1,000 new accounts and activation rising from 30% to 45%. Hold retention among activated accounts at 40%, and the share of retained accounts paying at day 35 at 50%.

• Activated: 1,000 × 45% = 450 accounts.
• Week-four retained: 450 × 40% = 180 accounts, or 18% of the original cohort.
• Paying at day 35: 180 × 50% = 90 accounts, or 9% of the original cohort.
• Cohort MRR: 90 × $49 = $4,410.

The model produces $1,470 more cohort MRR, a 50% relative increase, without assuming additional acquisition. Activation increased by 15 percentage points, not 15%. Retention among all new accounts increased from 12% to 18%, even though retention among activated accounts stayed at 40%.

This does not prove the guided flow will work. Newly activated customers may be less motivated and retain at a lower rate. Support or AI-processing costs may rise. The calculation identifies a worthwhile hypothesis and makes its assumptions visible.

Turn the hypothesis into a product decision

My next step would not be to present the modelled revenue as a forecast. It would be to inspect failed onboarding sessions where permitted, speak with customers, verify event quality, and test a focused intervention.

For a collaborative SaaS product, randomising at account level can help prevent teammates receiving conflicting experiences. Define the primary outcome, minimum detectable effect, sample-size method and stopping rule before reading the result. Give downstream retention and payment windows time to mature.

Use guardrails such as errors, abandoned plans, task quality, support demand and cost per activated account. Check that the experiment’s allocation and instrumentation work as intended. Microsoft researchers’ A Dirty Dozen paper documents how sample-ratio problems, denominator changes, novelty and repeated significance checking can distort experiment interpretation. [8]

If traffic is too low for a useful controlled test, combine qualitative evidence with carefully labelled cohort observations. Do not describe a before-and-after change as causal proof.

A lightweight tracking plan the team can actually maintain

You do not need hundreds of events to begin. For BriefBoard, I would start with a small, explicit event contract:

• account_created: establishes the cohort and a stable account identifier.
• work_plan_created and task_assigned: together establish the proposed first-value condition, excluding samples.
• task_completed: records the defined repeat-value event.
• external_referral_sent and referred_account_created: connect the referring account, unique invitation and new account.
• subscription_started, invoice_paid, subscription_changed and subscription_ended: reconcile payment and subscription state with the billing system.

Include an event ID for deduplication, account ID, actor ID where needed, event timestamp, source, environment, schema version and experiment assignment. Use the same attribution rules across reports. Prefer authoritative server-side confirmation for successful payments and completed actions, rather than counting a button click as success.

Keep analytics privacy-conscious. Do not send raw client briefs, payment-card details or unnecessary personal data just because the tracking tool accepts arbitrary properties. Apply consent, access and retention controls appropriate to your product.

How I would run the weekly AARRR review

Keep the review focused on decisions:

1. Confirm data health. Did an event break, an identifier change or a billing integration fall behind?
2. Review mature cohorts. Keep newly acquired accounts separate from groups with complete retention windows.
3. Find the meaningful constraint. Consider customer impact, expected business value, confidence and effort. The largest percentage drop is not automatically the best opportunity.
4. Choose one intervention. Record the hypothesis, owner, primary outcome, guardrails and review date.
5. Close the loop. Decide whether to keep, change or stop the intervention, and document what was learned.

Give every stage an owner, but avoid five isolated teams optimising five isolated targets. Acquisition should care about retained customers. Product should care about whether value can be delivered economically. Revenue should not grow by creating customer frustration that appears in next month’s churn.

Where AARRR needs another layer

AARRR does not explain every mechanism of growth. Reforge’s growth-loops framework asks how the output of one cycle becomes input for the next. That is useful for collaboration, sharing, marketplaces and other products where growth is not a one-way journey. [9]

It also does not replace customer research, product-market-fit judgement, unit economics or cash-flow planning. For AI products, I would add outcome quality, human correction, latency, inference costs and successful-task economics. More generations or messages can mean more confusion rather than more value.

When applying this to a product like ProductOS, I would look for evidence that someone moved a real product task forward, then returned to do meaningful work again. That is a proposed measurement principle, not a claim about our current analytics or results.

A complete SaaS journey connects building, launch, acquisition and repeat value. AARRR gives us a manageable set of questions inside that journey. The team’s job is to connect the answers to the next product decision.

Common questions about AARRR

What is a good activation or retention rate?

There is no useful universal number without a matching product category, customer segment, event definition, denominator and observation window. Begin with consistently defined internal cohorts. Use external benchmarks only when you can explain what is genuinely comparable.

Should an early-stage startup focus on retention before acquisition?

You need enough relevant customers to learn. Beyond that, scaling acquisition into a product that does not deliver repeat value can amplify waste. The practical choice depends on whether the current constraint is insufficient qualified demand, failure to reach value, weak repeat use or poor economics.

Is AARRR the same as a North Star metric?

No. AARRR organises several lifecycle questions. A North Star metric aims to summarise a central form of customer value. They can coexist: use the North Star for direction, AARRR to diagnose where the journey is breaking, and guardrails to prevent harmful optimisation.

Does every business need all five stages?

All five questions are worth considering, but their importance varies. Referral may be a small channel for an enterprise product. Revenue may come before product use. Adapt the definitions to the business rather than forcing the business into the acronym.

Sources and further reading

The definitions above draw on the sources below. Recommendations framed as “I would” are my practical interpretation. The BriefBoard case and its charts are hypothetical, calculated examples, not research findings. The featured image is an original AI-generated conceptual illustration, not a ProductOS interface.

1. Dave McClure: Startup Metrics for Pirates. Original five-stage framework and channel/conversion analysis.
2. Stripe: What is the CAC payback period? Acquisition costs and profit-based payback.
3. Mixpanel: Get to know your users. Active usage grounded in value rather than simple access.
4. Amplitude: How the Retention Analysis chart calculates retention. Return definitions and incomplete observation windows.
5. Bain: Measuring your Net Promoter Score. Survey question and score calculation.
6. Stripe: Understanding MRR and ARR. Subscription normalisation and distinction from accounting revenue and cash flow.
7. Stripe: Net revenue retention. Existing-customer revenue, expansion, contraction and churn.
8. Dmitriev, Gupta, Kim and Vaz: A Dirty Dozen, KDD 2017. Common metric-interpretation pitfalls in controlled experiments.
9. Reforge: Growth Loops are the New Funnels. A complementary way to understand how growth compounds.

The takeaway: write down what value means, measure whether the right customers reach it and return, then make one better decision. AARRR is useful when it changes what the team builds or tests next.