Skip to content

Revenue dashboard

Analytics → Revenue (/analytics/revenue) is the money dashboard. All numbers come from rollup_revenue_daily, which is fed by the coin ledger (Purchase + Subscription + CoinLedger), not raw client analytics events. This means numbers here match the finance ledger by construction.

MetricDefinition
Gross revenueSum of purchase.amount_cents where status='completed', in USD (converted).
Net revenueGross − refunds − fees (fee % per rail from a config table).
RefundsSum of refund_requests.amount_cents where status='executed'.
ARPUNet revenue / DAU (period-scoped).
ARPPUNet revenue / paying-users-in-period.
LTV (30d)Cohort LTV: installs from N days ago, cumulative revenue over 30 days.
  • Revenue by rail (stacked area). See the mix shift over time: as payment rails come online, this stack diversifies.
  • Revenue by country (top 10). Where the money is coming from.
  • Revenue by day (line). Daily gross + net + refund overlays.
  • Refund rate (line, %). Refunds ÷ gross per day. Anything above 3% is a fraud or product-quality signal.
  • Date range (UTC)
  • Rail (multi-select)
  • Country (multi-select)
  • Kind (coin_pack, subscription)

Every filter is URL-state: shareable views.

Healthy rail mix at scale (rough targets):

RailTarget share
Store IAP (Apple + Google)30–40% (high fees, but frictionless)
Cards (web)20–30% (lowest fees)
dLocal + pawaPay20–30% (local wallets, mid-fee)
VAS10–20% (variable: market-specific)

Store dominance early = launch pattern (IAP frictionless). As you enable card + local wallets, the store share should decline.

  • ARPU: total revenue / total active users. Ties revenue growth to audience growth.
  • ARPPU: revenue / paying users only. Measures the willingness-to-pay of buyers.

ARPU rising with ARPPU flat = you’re converting more users to paying. Healthy. ARPPU rising with ARPU flat = existing whales are spending more. Also healthy but riskier.

  • FX conversion is daily. Numbers in the past use the rate from that day, not today’s rate. This can cause 1–2% drift vs bank reports.
  • Fees are estimated by rail, not per-transaction. Reconcile with the actual provider statements (Reconciliation).
  • VAS revenue lags: carrier settlements are monthly. VAS numbers stabilize about 45 days after the transaction.
ActionEndpoint
Revenue dashboard dataGET /v1/admin/analytics/revenue (query: dateFrom, dateTo, rails, countries, kind)

Full details in API: Analytics.