An in game purchase dashboard can look healthy while the underlying business is getting worse. Transaction count may rise because of a discount, yet net revenue can fall. Average revenue per paying user may climb while the payer base shrinks. Day-30 LTV may improve only because one acquisition channel delivered a small group of unusually valuable players.
The fix is not another top-line chart. Game teams need a measurement model that connects a completed purchase to net proceeds, payer behavior, retention, acquisition cost, and the product decision that should follow. This guide gives developers, product managers, and growth teams that model, including formulas, an event schema, and a practical review cadence.
What is an in game purchase?
An in game purchase is a real-money transaction made inside a game for digital content, currency, access, or an entitlement. It is a game-specific form of in-app purchase and can include consumables, permanent unlocks, subscriptions, battle passes, or ad removal.
The useful boundary is the movement of real money, not the later use of virtual currency. If a player buys 1,000 gems for $9.99, that is one purchase. Spending 300 of those gems on a cosmetic is an economy event, not another $3 revenue event. Mixing the two creates double counting.
Unity’s definition of an in-game purchase covers virtual goods, upgrades, levels, and features. Your taxonomy should go one level deeper by separating each product into a stable SKU type:
- Consumable: currency, energy, boosts, or other items that can be purchased repeatedly.
- Non-consumable: a permanent character, level pack, or ad-removal entitlement.
- Subscription: a recurring VIP membership or similar access product.
- Pass or non-renewing access: a season or event entitlement with a fixed term.
That classification matters because the same revenue total can represent very different behavior. A one-time unlock depends on new payer acquisition; a consumable economy depends on repeat purchases; and a subscription depends on renewal and churn.
Start every in game purchase report with the right revenue number
“Revenue” is ambiguous unless the dashboard names the layer being measured. Use at least three:
- Gross sales: the amount billed to players before store commissions, taxes, refunds, and adjustments.
- Net IAP revenue: gross sales minus refunds, chargebacks, taxes, store fees, and other transaction adjustments included in your accounting definition.
- Proceeds or cash received: the amount the platform reports as payable, reconciled to its settlement period and currency conversion.
Apple explicitly distinguishes sales from proceeds: sales are the amount billed to customers, while proceeds account for applicable taxes and Apple’s commission. Its analytics also exposes refunded sales, refunded proceeds, and refund rates, which is why gross sales should not be treated as cash available to spend on acquisition. See Apple’s App Store Connect sales definitions.
Google Analytics uses another defined layer: purchase revenue includes purchases, in-app purchases, and subscriptions, less refunds. That can be useful for product analytics, but it still needs to be reconciled with store financial reports before finance or UA teams call it net cash. The Google Analytics in-app purchases report documents the calculation.
Choose one revenue basis for each decision and label it in the metric name. Use gross revenue to evaluate price presentation, verified net revenue for unit economics, and store proceeds for cash forecasting. Never compare a gross-revenue LTV with a CAC target built around net margin.
The in game purchase metrics that explain revenue
No single KPI diagnoses monetization. A compact metric tree works better: revenue per active player is driven by how many players pay and how much each payer spends, while lifetime value also depends on how long players remain active.
| Metric | Formula | What it answers | Common misread |
|---|---|---|---|
| Purchase conversion rate | Unique payers ÷ eligible active players | How broadly does the game convert players? | Changing the eligible-player denominator between tests |
| Checkout conversion rate | Completed purchases ÷ checkout attempts | Does the payment flow complete? | Treating a canceled or pending transaction as a sale |
| Average order value (AOV) | Purchase revenue ÷ completed transactions | How large is the average basket? | Assuming a higher AOV means more players are paying |
| Purchase frequency | Completed transactions ÷ unique payers | How often does each payer buy? | Letting subscription renewals and consumables blur together |
| ARPPU | Purchase revenue ÷ unique payers | How much revenue comes from each payer? | Ignoring a shrinking payer base |
| ARPU | Total revenue ÷ active users | What is each active player worth in the period? | Comparing periods with different active-user definitions |
| ARPDAU | Daily revenue ÷ daily active users | How efficiently does a live game monetize each day? | Reacting to daily noise or a single large spender |
| Payer retention | Prior-period payers who pay again ÷ prior-period payers | Are paying relationships repeating? | Confusing another session with another purchase |
| LTV | Cumulative cohort net revenue ÷ acquired players | What has an acquired player generated so far? | Calling observed day-30 value a complete lifetime forecast |
| ROAS | Cohort-attributed net revenue ÷ matched cohort ad spend | Has acquisition spend paid back within the window? | Mixing a 30-day revenue window with a 7-day cost cohort |
Unity’s current IAP reporting reference separates checkout conversion, payment success, payer conversion, ARPPU, ARPDAU, and new spenders. Those distinctions are useful because they isolate merchandising, payment reliability, and payer breadth instead of collapsing all three into revenue. Review the Unity IAP Revenue Performance metric definitions.
Google Play presents the relationship as a hierarchy. Its 28-day metrics include revenue per monthly active user, monthly buyer ratio, average revenue per monthly buyer, first-time and returning buyer ratios, average revenue per purchase, and purchases per buyer. The Google Play monetization guidance is a useful cross-check for denominator and window definitions.
A simple decomposition that catches false wins
For a purchase-only model, period ARPU can be decomposed approximately as:
ARPU = payer conversion rate × ARPPU
Suppose 10,000 eligible players produce 400 payers and $8,000 in verified net purchase revenue. Conversion is 4%, ARPPU is $20, and ARPU is $0.80.
After a price increase, 300 payers generate $7,500. ARPPU rises to $25, but conversion falls to 3% and ARPU drops to $0.75. A dashboard that celebrates ARPPU alone would call the change a win even though revenue per eligible player declined.
Decompose ARPPU again when you need to identify the lever:
ARPPU = purchase frequency × average order value
Now the team can ask whether payer value changed because people bought more often or because the average transaction grew. Those demand different experiments.
Connect in game purchase revenue to retention and LTV
Retention creates future opportunities to buy, but a purchase can also change later engagement. The relationship must therefore be measured in cohorts rather than inferred from a correlation between two aggregate charts.
Start with install cohorts and report D1, D7, D14, D30, D60, and D90 cumulative net revenue per acquired player. Next, split the same cohorts by acquisition source, country, platform, first-purchase SKU, and time to first purchase. Keep a non-payer group for context, but do not claim that purchasing caused retention: players who already have stronger intent may be more likely both to stay and to pay.
Use three retention views:
- Player retention: the share of an install cohort that returns on a defined day or during a defined interval.
- Payer retention: the share of payers who make another purchase in a later period.
- Revenue retention: later-period revenue from an earlier payer cohort divided by its starting-period revenue.
GameAnalytics recommends a small reliable event foundation—session start, progression, tutorial completion, purchase, and ad view—then prioritizes retention and ARPDAU for live operations. That framing is valuable because revenue has little room to compound when players stop returning. See its post-launch mobile game analytics guide.
LTV should be labeled observed or predicted. Observed D30 LTV is simply cumulative verified net revenue through day 30 divided by the number of acquired players in the cohort. Predicted LTV extends beyond available data and must disclose the model, training window, revenue sources, and uncertainty range. Do not hide a forecast behind a label that looks like settled revenue.
Build an in game purchase measurement system you can trust
A useful dashboard begins with a trustworthy event, not a chart. Track the funnel as separate states so a payment failure cannot look like a merchandising failure:
store_viewed → product_selected → checkout_started → purchase_pending → purchase_verified → entitlement_granted
Only purchase_verified should feed recognized purchase revenue. Keep entitlement_granted separate so engineering can detect the serious case where a player pays but does not receive the item.
Use a durable event schema
At minimum, the verified event should include:
event_name: purchase_verified
transaction_id: store-issued unique transaction identifier
player_id: stable first-party player identifier
product_id: stable catalog SKU
product_type: consumable | non_consumable | subscription | pass
quantity: purchased units
gross_value: amount billed in transaction currency
currency: ISO 4217 currency code
net_value: verified net amount when available
platform: ios | android | web | other
store: app_store | google_play | direct | other
transaction_time: server-normalized UTC timestamp
install_cohort: first-install date
campaign_id: attributed campaign identifier when availableDo not use a device-generated transaction value as the source of truth. Apple says StoreKit transactions can be verified through StoreKit or on your server, and its server APIs provide signed transaction information. Google recommends sending the purchase token to a secure backend, checking that it has not already been used, and verifying it with the Google Play Developer API before granting entitlement. Follow the current Apple StoreKit in-app purchase guidance and Google Play Billing security guidance for the platform-specific flow.
Reconcile events, analytics, and finance
Run a daily reconciliation across three layers:
- Count and value of server-verified purchase events.
- Store-reported transactions, refunds, chargebacks, and proceeds.
- Product analytics and attribution events used by growth teams.
Join on transaction ID where the platform permits it, then report unmatched records and value. A revenue dashboard without a reconciliation rate should be considered directional, not finance-grade.
Preserve the acquisition context
Purchase metrics become more useful when the verified event is connected to the campaign that acquired the player. Keep acquisition cohort, source, campaign, creative, geography, and attribution method alongside revenue windows; then compare CAC with D7, D30, and mature LTV on the same cohort basis. Apple’s AdAttributionKit documentation also makes the privacy constraint explicit: campaign measurement has to work within privacy-preserving postbacks, so not every purchase will have a deterministic user-level campaign join.
If a game already uses Deeplinkly for deep links and install attribution, its campaign context can be carried into downstream purchase events and exported for cohort analysis. That gives product and growth teams one path from link click and install to verified payer behavior without treating aggregate store sales as attribution data.
For a deeper implementation walkthrough, use the existing in-game purchase attribution guide alongside this metric framework.
Diagnose changes before choosing an optimization
When revenue moves, find the component that moved before launching an experiment.
| Signal | Likely area to inspect first | Useful next cut |
|---|---|---|
| Store views rise, checkout starts do not | Offer relevance or presentation | SKU, placement, progression state |
| Checkout starts rise, completions do not | Payment errors, pending states, price surprise | Platform, app version, country, error code |
| Payer conversion falls, ARPPU rises | Offer became attractive to fewer, higher-value players | New vs returning payer, SKU, price variant |
| Purchase frequency falls | Content cadence or repeat value weakened | Days since first purchase, inventory balance |
| ARPDAU rises, retention falls | Monetization may be extracting short-term value | Experiment cohort, D7/D30 retention, refund rate |
| Gross revenue rises, net revenue does not | Refunds, fees, taxes, or mix changed | Store, country, refund reason, SKU |
| LTV rises, ROAS falls | Acquisition cost increased faster than value | Campaign, creative, bid strategy, payback window |
Treat each row as a hypothesis, not a verdict. Check sample size, seasonality, release changes, LiveOps events, and cohort mix before attributing a movement to the most recent product change.
Use guardrail metrics for every monetization test. A price or bundle experiment should track payer conversion, net ARPU, refunds, D7/D30 retention, progression, and support contacts—not only gross revenue. Predefine the evaluation window and minimum sample needed so the team does not stop a test on the first favorable daily swing.
A dashboard cadence for product, growth, and finance
Different decisions need different windows:
- Daily operations: verified revenue, payment success, entitlement failures, refunds, ARPDAU, and reconciliation rate.
- Weekly product review: payer conversion, AOV, purchase frequency, ARPPU, first-time versus returning payers, and experiment guardrails.
- Cohort review: D7/D30/D60 LTV, player and payer retention, SKU mix, and time to first purchase by acquisition source.
- Monthly business review: net revenue, mature LTV, CAC, ROAS, payback period, store proceeds, and forecast accuracy.
Give every dashboard a written metric contract: numerator, denominator, revenue basis, timezone, cohort rule, attribution window, refund treatment, and refresh delay. If two teams use different definitions, they should use different metric names. Consistent labels are less elegant than one universal “revenue” chart, but far more actionable.
Frequently asked questions
What are the most important in game purchase metrics?
Start with verified net revenue, payer conversion rate, ARPPU, ARPDAU, purchase frequency, payer retention, cohort LTV, and ROAS. Add checkout conversion, payment success, refund rate, and reconciliation rate so the team can tell whether a change came from merchandising, payment operations, player behavior, or data quality.
How do you calculate average revenue per paying user?
ARPPU equals purchase revenue during a defined period divided by the number of unique payers in that same period. Always state whether revenue is gross or net and whether a payer is counted once across the whole period or separately in shorter windows.
Does in game purchase revenue include refunds and app store fees?
It depends on the metric. Gross sales usually precede refunds and platform deductions, while net revenue or proceeds applies defined deductions; label the revenue basis explicitly and reconcile analytics events to store financial reports.
How does retention affect in game purchase LTV?
Retained players have more future opportunities to make a first or repeat purchase, so weaker retention usually limits cumulative LTV. Measure the relationship with install cohorts and compare payer, non-payer, and first-purchase segments without assuming that the purchase itself caused a player to return.
Should virtual currency spend count as purchase revenue?
No. Count real-money currency acquisition as purchase revenue, then track the later use of virtual currency as a separate economy event. Treating both as revenue double-counts the same money.
Conclusion
An in game purchase metric is useful only when it leads to a decision. Begin with verified net revenue, decompose it into payer conversion, purchase frequency, and order value, then connect those drivers to retention, cohort LTV, and acquisition cost. Keep gross sales, net revenue, and proceeds separate.
The fastest next step is a one-cohort audit: choose last month’s installs, reconcile every verified purchase to store reporting, calculate D7 and D30 net LTV by source, and document every denominator. That exercise will reveal whether the next priority is instrumentation, payment reliability, offer design, retention, or acquisition quality.