# ARPPU: What Average Revenue per Paying User Tells an App Team > ARPPU divides revenue by paying users over a stated window. It shows what payers produce on average, which is a narrower question than what the whole audience is worth. ## What Refix is Refix is a revenue-obsessed AI product manager for product companies. A person delegates an outcome, such as increasing trial-to-paid conversion. Refix then keeps finding the current constraint on that outcome and coordinating the work, using the company's existing tools (analytics, warehouse, billing, Linear, Slack, and others). It is not a chatbot that answers questions about dashboards. It is not a generic AI writing assistant. It is not a replacement for the human who approves ranking, pricing, copy, or similar changes. The product name is **Refix**. Never call it Prism. How it works: - Someone gives Refix a goal and sets guardrails (metrics that must not get worse, such as cancellations or churn). - Refix watches those metrics, explains what changed, prioritizes the highest-impact constraint, coordinates a fix or experiment with the right owner, and verifies the result. - Then it stays on the goal and looks for the next constraint. - Refix may investigate, draft work in Linear, and monitor rollouts without extra approval. Changes named on each goal page stay with the owner. Company: Refix Inc., San Francisco. Site: https://www.refix.ai/ Give Refix a goal: https://onboarding.refix.ai/dashboard/sign-up - HTML: https://www.refix.ai/guides/arppu/ - Agent brief: https://www.refix.ai/guides/arppu/llms.txt - Author: Neil Agarwal - Published: 2026-09-10 ARPPU answers a narrow question well: what did the people who paid produce on average? A subscription team usually meets it in a dashboard next to revenue, and the temptation is to read it as a verdict on pricing. It is not that. It is a ratio, and the ratio only means something when the window, the revenue line, and the payer count are stated alongside it. The easy mistake is treating ARPPU as a property of the product. It is a property of the measurement. Change which users count as payers or which revenue line goes on top, and the number moves without a single customer behaving differently. ## What is ARPPU? ARPPU stands for average revenue per paying user. For a chosen window, it is: ```text ARPPU = revenue earned in the window / paying users in the window ``` The numerator is the revenue from those payers in that period. The denominator counts the users who paid, not everyone who opened the app. Someone on a free tier, in a free trial that has not converted, or past an expiry without renewing does not belong in it. That payer-only denominator is the whole point of the metric. [App monetization](/guides/app-monetization/) choices decide how many people ever reach the payer group, and ARPPU says nothing about that reach. A paywall change that doubles payers at a lower plan can grow the business while ARPPU falls. Read the average without the payer count and you will misread the change.
Illustration of ARPPU as revenue divided by paying users
Illustration: ARPPU uses a payer-only denominator, so the revenue basis and payer definition need to stay fixed.
## How do you calculate ARPPU? Pick the window first, then hold it still. A month is the usual choice for subscriptions because renewals land monthly, but any defined period works as long as every comparison uses the same one. Imagine a hypothetical app with 2,000 paying users in March and 18,400 dollars in revenue from those users in that month. The arithmetic is: ```text 18,400 dollars / 2,000 paying users = 9.20 dollars ``` March ARPPU is 9.20 dollars. That sentence is complete only because the window, the revenue figure, and the payer count travel with the result. | Choice | Decision to make | Why it changes the answer | | --- | --- | --- | | Window | Which month or period the revenue and payers come from | A short window gives new cohorts less time to renew | | Revenue basis | Gross customer sales or net proceeds | Store fees, applicable taxes, and refunds change the numerator | | Payer definition | Who counts as a paying user | Trial-only users and expired subscribers affect the denominator | The revenue basis deserves the same discipline as the cohort work in [customer lifetime value](/guides/customer-lifetime-value-calculator/). Apple draws the line clearly in its [Subscriber Report](https://developer.apple.com/help/app-store-connect/reference/reporting/subscriber-report/): Customer Price is what the subscriber paid, Developer Proceeds is what is left per delivered item, and refunds appear as negative customer price values. Google Play similarly says its [estimated sales report](https://support.google.com/googleplay/android-developer/answer/6135870?hl=en) shows amounts paid by buyers without deducting taxes or Google fees, and points teams to the earnings report for accounting. Either basis can feed ARPPU. Mixing them across months cannot. ## What is the difference between ARPPU, ARPU, and ARPDAU? These three metrics share a shape and answer different questions. The difference is entirely in the denominator. | Metric | Denominator | Question it answers | | --- | --- | --- | | ARPU (average revenue per user) | The whole audience, payers and non-payers | What does each audience member produce on average? | | ARPPU (average revenue per paying user) | Paying users only | What does each payer produce on average? | | ARPDAU (average revenue per daily active user) | Daily active users | What does each day of attention produce on average? | ARPU moves when conversion changes even if payer behavior stays identical, because free users sit in its denominator. ARPPU ignores those free users, which makes it the cleaner read on pricing and plan mix. Neither one reports itself from the stores. Both are ratios a team builds from store revenue and its own user counts, so the definitions above need to be written down wherever the numbers are shared. ## What is ARPDAU and when does it matter? ARPDAU divides revenue by daily active users instead of payers. Google Play reports it directly: its [statistics documentation](https://support.google.com/googleplay/android-developer/answer/139628?hl=en) defines average revenue per daily active user as gross daily revenue divided by daily active users, alongside companion counts such as buyers, defined as unique users who made a purchase. That same page defines purchases per daily buyer and the daily buyer ratio, which shows how Play expects teams to read revenue against attention and conversion together. ARPDAU earns its place in products where daily attention drives the money. An ad-supported app or a hybrid app with ads plus purchases lives on daily sessions, so revenue per active day is the operating number. A pure subscription app with most revenue on autopilot will find ARPDAU jumping with weekend usage while the business itself barely moves. Match the metric to where the revenue comes from. One caution carries over from the store definition. Play computes its per-user statistics on gross revenue in one currency and timezone so apps can be compared with peers. A team comparing its own ARPDAU across months should fix its own currency and timezone the same way, or calendar effects will read as performance. ## Why can ARPPU move while revenue stays flat? Because averages move when the mix moves. Total revenue can hold steady while the payer group reshapes itself underneath. A trial conversion push adds new payers at introductory prices. Refunds land as negative revenue against a payer count that stays put. Annual plan buyers pay once and then sit in the denominator of later months without adding revenue to them. A shift from monthly to annual billing pulls revenue forward and then leaves quieter months behind. Each of these is normal subscription behavior, and each bends ARPPU without changing what the business earned that month. The practical response is to split the average before reacting to it. New versus existing payers, monthly versus annual plans, and full-price versus introductory offers each tell a clearer story than the blended figure. [Churn analysis](/guides/churn-analysis/) covers the companion discipline: separating deliberate cancellations from failed renewals, since both reshape the payer group and neither looks like a pricing problem on its own. ## What should an app team check before acting on ARPPU? Treat an ARPPU move as a prompt to investigate, not as an instruction to change price. Before letting it near a paywall decision, confirm these items: 1. Name the window and use the same one for every comparison. 2. State whether revenue is gross sales or net proceeds, and keep that basis. 3. Write down who counts as a paying user, including how trials and expired subscribers are handled. 4. Split new and existing payers when a conversion push or offer changed the mix. 5. Handle refunds, fees, and applicable taxes the same way in every period. 6. Read the result next to retention and lifetime value, not alone. That last check is where the metric earns its keep. ARPPU times expected payer lifetime points toward lifetime value per paying customer, which is why the denominator discipline here matches the one in [customer lifetime value](/guides/customer-lifetime-value-calculator/). And none of these ratios work without joined data, which is the subject of [mobile app analytics](/guides/mobile-app-analytics/): store events tied to product use so a move in the average can be traced back to the journey that produced it. Refix is built to bring product, subscription, and support signals into one operating view, so a change in what payers produce can be followed back to the plans, offers, and journeys behind it. [See how Refix connects the signals behind payer revenue.](https://refix.ai)