ARPDAU is the revenue your app earns in one day divided by the number of unique users who were active that day. For an AI app that single division is useful and easy to misread, because the numerator mixes subscriptions, credits, affiliate income and ads, and the cost of serving each user varies far more than it does in a casual game.
This guide covers the formula, a hypothetical calculation, the scoping mistakes that quietly distort the number, and what ARPDAU can and cannot tell you before you consider sponsored placements. Every figure below is invented for illustration. None are benchmarks and none are Jolts results.
What average revenue per daily active user means (ARPDAU formula)
Average revenue per daily active user is total revenue for a single day divided by that day's daily active users (DAU). The formula is ARPDAU = daily revenue ÷ DAU. A result of $0.10 means each active user generated ten cents of revenue that day, on average.
It is a daily metric by design. Unity's glossary lists the same ARPDAU formula. Ad platforms such as Google AdMob and Google Play Console report revenue-per-user style metrics built on the same logic, though each defines its own scope. Check which revenue and which users a dashboard includes before you compare its figure with yours.
There are two inputs, and both need a written definition: what counts as revenue, and what counts as an active user.
A hypothetical AI-app calculation, step by step
To calculate revenue per daily active user, sum one day's revenue, count that day's active users, and divide. Here is a made-up writing assistant on one made-up day.
Subscription revenue recognized that day: $1,800
Credit pack purchases: $700
Affiliate commissions: $250
Total revenue: $2,750
Daily active users: 25,000
Total ARPDAU = $2,750 ÷ 25,000 = $0.11.
Now split the same day by source: subscriptions $0.072, credits $0.028, affiliate $0.010. They add back to $0.11. If this app later adds ads, that stream gets its own line instead of being folded into one blended number.
A single day is noisy. Weekends, product launches and outages all move it. Report a trailing seven-day average next to the daily figure so a quiet Tuesday doesn't read as a trend.
Keep scope and dates consistent: which revenue, which users, which days
The most common ARPDAU error is mismatched scope, and it can swing the number more than any monetization change you make. Fix three things in writing.
Which revenue. Decide whether you use gross or net of app-store fees and refunds, and whether an annual subscription is recognized daily or counted on the day it was bought. Pick one rule and keep it. A $120 annual plan booked on one day makes that day look spectacular and the next 364 look weak.
Which users. Define "active". Opened the app? Sent a prompt? Received a model response? A user who opens the app and bounces counts under the first definition and not the second. Include free-tier users, since they are the ones costing you inference. Decide how you treat logged-out sessions and bots.
Which days. Use one time zone for both numerator and denominator. Revenue cut at midnight UTC divided by users cut at midnight local time produces a number that belongs to no real day.
Write the definition once, version it, and note the date you changed it. Otherwise a before-and-after comparison measures your accounting, not your product.
Total ARPDAU vs ad ARPDAU: splitting subscriptions, credits, affiliate and ads
Total ARPDAU answers "what does an active user bring in?" Ad ARPDAU answers "what does this one stream bring in?" Track both, because blending them hides which lever moved.
The split is simple: take each revenue source's daily amount and divide it by the same DAU.
For an AI app, the useful lines are:
Subscription ARPDAU
Credit or usage-pack ARPDAU
Affiliate ARPDAU
Ad ARPDAU, if you run ads
Watch the denominator trap. If ads appear only to free users, ad revenue divided by all DAU understates what a free user earns. Ad revenue divided by free DAU only is a different metric. Both are legitimate. Label which one you report. If you are weighing how ads sit next to paid plans, what should pay for your AI app's free tier covers that trade-off.
ARPDAU vs ARPU and ARPPU: which metric answers which question
ARPDAU differs from ARPU in the time window and the user base. ARPDAU is per daily active user per day, while ARPU is revenue per user over a longer period, usually a month, across all users in that period. ARPPU (average revenue per paying user) divides by paying users only.
| Metric | Divides revenue by | Window | Best for |
|---|---|---|---|
| ARPDAU | Daily active users | One day | Fast reads on pricing, paywall and placement tests |
| ARPU | All users (or active users) | Month or lifetime | Plan-level and cohort comparisons |
| ARPPU | Paying users only | Any | Pricing power among payers |
Use ARPDAU for short experiments, ARPU for planning, and ARPPU to see whether payers would tolerate a price change. If only 4% of users pay, ARPPU can look large while ARPDAU stays small. Neither is wrong. They answer different questions, so quote the metric name every time you quote a figure.
Why revenue per user is not margin when inference costs vary
ARPDAU measures revenue, not profit, and in an AI app the gap between the two is wide and uneven. Every prompt costs inference money, and heavy users cost far more than light ones.
Take a hypothetical: an app with ARPDAU of $0.11 and an average inference cost of $0.06 per active user per day looks fine at 45% contribution. But the average hides the spread. If a coding user who runs long agent sessions costs $0.40 a day and brings in $0.11, that segment loses money while the blended number looks healthy.
So pair ARPDAU with cost per DAU, and cut both by segment: free versus paid, light versus heavy, by feature. The figure to watch is contribution per active user (revenue minus inference and other variable cost), not revenue alone. A rising ARPDAU driven by a power-user segment can shrink your margin.
How to use ARPDAU before an ad pilot, and what Jolts has not confirmed
Before you add sponsored placements, calculate your baseline ARPDAU and cost per DAU with fixed definitions, then decide what an ad stream would need to add to matter. If subscriptions and credits cover a paid user's inference but free users cost more than they earn, the gap per free DAU is the number an ad stream has to close.
A sensible sequence:
Fix your definitions and compute total and per-source ARPDAU for at least four weeks.
Compute cost per DAU for free and paid segments.
Write down the shortfall you want ads to cover, as a per-DAU figure.
Agree pilot terms, including revenue share, event counting and payout timing, before going live. See AI ad pilot terms: publisher revenue share and payouts.
Decide what context you would share for matching. See AI ad request data: what publishers should share.
Jolts connects advertisers with AI publishers through clearly labelled sponsored placements in AI conversations, kept separate from the organic answer. If no suitable match exists, no ad is shown. Publishers agree categories, frequency, excluded topics, shared data, revenue share, counting and fees before launch, and the first step is a call to confirm audience fit and scope. Jolts has not established an ARPDAU figure or revenue projection for any publisher, so your own baseline is the right starting point. For publisher-side groundwork, read Before the SDK: the publisher conversation worth having.
Fix your ARPDAU definition first, then book the pilot call
ARPDAU is only as honest as the scope behind it: one revenue rule, one definition of active, one time zone, and a cost-per-DAU line beside it so revenue never passes for margin. Once you have four weeks of clean numbers, bring them to a call with Jolts at contact@jolts.xyz and use them to scope categories, frequency, exclusions and terms for an early-partner pilot.