About Analytics

This page covers cross-cutting principles that apply to every Apphud analytics surface — the rules behind how data is counted, why some numbers don't match across surfaces, and which surface to use for which question.

If you're new to Apphud analytics, read this first.

What's inside Analytics

Apphud Analytics has three reporting surfaces that aggregate data into metrics — plus a source-data layer of granular per-user records that those metrics are built from.

Reporting surfaces

Paywall analytics is a Reports view scoped to paywall-and-placement performance — same chart-style report layout with the controls pre-restricted to the paywall-analysis use case.

Source data — Users & Events

The raw per-user records that all reporting surfaces are built from:

📘

Source data includes sandbox; reports don't

The Users & Events layer shows both production and sandbox records (toggleable filters). The three reporting surfaces above (Business Overview / Dashboard / Reports) display production-only data. See Production data only for why.

When the answers don't match across reporting surfaces, the explanation is usually one of the cross-cutting rules below.

Production data only

Apphud Analytics displays only production data. Sandbox / TestFlight / staging purchases do not appear in any chart, widget, or report. This applies to every analytics surface.

You can configure an A/B test or audience that targets sandbox users — the test will execute, but none of the results will show in analytics. Use sandbox for behavioral verification, not for analytics validation.

Near-real-time, with one exception

Most analytics data updates near real-time — within 15 minutes to 1 hour depending on the surface. Per-surface freshness rules:

• Revenue charts (MRR, Sales, Proceeds, Refunds, Refund rate), MRR/ARR Movement, Active Paid Subscriptions, Active Trials, Cohort Revenue → under 15 minutes from the renewal event.
• Other charts (ARPU, Conversions, Events Chart, etc.) → within 1 hour.
• Predictions → refreshed daily at 00:00 UTC.

Between 00:00 and 06:00 UTC you may experience temporary data delays due to processing schedules — keep that in mind when analyzing early-day metrics.

❗️

Don't analyze same-day cohort data

Cohort-based metrics (Cohort Revenue, Cumulative LTV / CLV, Subscribers / Revenue retention) require consistency between user and revenue data. User and receipt data can be ingested with different delays — minutes up to 2 hours. This can cause purchases reflected before users appear in the cohort.

For reliable cohort results, exclude users whose First Seen Date is today. Example: today is June 17 — set the cohort range to June 1–16.

User's First Seen Date

The User's First Seen Date is the earliest recorded activity date for a user — determined as the earliest among:

• First Installation Date
• First app Launch Date
• First Purchase Date

The User's First Seen Date serves as the baseline cohort anchor for most cohort-based metrics in Apphud — ARPU, ARPPU, ARPAS, Cumulative LTV / CLV, Cohort Revenue, Subscribers Retention, Revenue Retention, Conversions Charts, etc.

In receipt-based charts (Gross revenue, Sales, Proceeds, Refunds), you can also segment by First Seen Week or First Seen Month to analyze how acquisition cohorts contribute to revenue over time.

VAT and store commission

VAT is deducted from the Proceeds metric for both iOS and Android apps. The deduction impacts analytics, integrations, server-to-server webhooks, and other services using Proceeds.

Example: For a sale priced at GBP 3.99 with a store commission of 15%, the proceeds amount to GBP 2.82.

The chain of reductions:

Gross revenue (billed amount) → minus refunds → Sales → minus store commission (15% or 30%) → minus VAT → Proceeds

For metric definitions, see Gross revenue, Sales, and Proceeds.

About Currencies

US Dollar is the base currency in Apphud. All transactions are automatically converted to USD using the exchange rate at the time of the event, sourced from OpenExchangeRates. All analytics surfaces show metric values in USD.

Original-currency values are still visible on individual events — on the User Page timeline you'll see entries like +1090.00 HUF (~$3.53): the store-currency amount with the USD equivalent at the time of the event.

The historical USD value is frozen at event time — it does not re-compute when exchange rates change later. This keeps revenue numbers stable across reports.

Charge date

iTunes and Google Play accounts are charged for subscription renewals within 24 hours prior to the end of the current subscription period. Apphud's revenue charts (Sales, Proceeds, Gross revenue, Refunds) display revenue based on the transaction charge date, not the subscription renewal date.

Example: A subscription period ends on July 7; the renewal transaction may be charged on July 6. The Sales chart shows this revenue on July 6, not July 7.

If you cross-reference Apphud revenue against other sources that anchor on the renewal date, expect a 1-day shift.

FAQ

My Apple Small Business app shows ~30% reduction from Gross revenue, but the SBP commission is only 15%. What's happening?

You're forgetting VAT. Proceeds deduct both commission and VAT — in a typical European country with ~15% VAT plus the 15% SBP commission, you'd see roughly a 30% total reduction from gross billings. This is correct accounting, not a bug.

To verify: pick a single transaction and compute manually — Sales (billed amount minus any refund) − 15% commission − local VAT rate. The result should match Proceeds for that transaction.

Why does the Users page show data that isn't in any chart?

The Users (Audiences) page and the Events page are source data, not reporting surfaces. They include sandbox records; the three reporting surfaces don't. They also update slightly differently from aggregated charts because chart pipelines apply additional roll-ups and timing rules. For day-to-day spotting of "did this user do X", trust the source data; for cross-cohort aggregates, trust the reporting surfaces.

Why don't the same metrics match across Business Overview, Dashboard, and Reports?

Common causes:

• Different periods. Reports default to a chart-specific date; widgets in Business Overview use their own period setting (often longer).
• Different anchor dates. Reports may use First Seen Date for cohort metrics; same metric in a different surface might use transaction date.
• Pending data. Recent periods (last 24-48h) shift as more receipts arrive.
• Refunds processed retroactively. Historical proceeds change when refund requests get approved.

When in doubt, compare the metric definitions and date ranges side-by-side.

Can I run an A/B test on a Sandbox audience and see results in charts?

You can configure the A/B test — the experiment will run for sandbox users on TestFlight / staging. But chart and report data are production-only, so the sandbox-side results won't appear in any analytics surface.

Use sandbox testing for behavioral verification (does the right paywall show?). For analytics validation, switch to a production audience.

Why do historical Proceeds keep changing for past months?

Because refunds can be processed retroactively. A user requesting refunds for the last 3 months' renewals will reduce Proceeds in each of those historical months when Apple approves. See Proceeds → Why might historical proceeds change? for the full breakdown.

Why can historical data in my charts change over time?

Apphud analytics are built from receipts, subscription events, server notifications, user records, and store / app settings. When any of these inputs is updated later, the related charts update too. Common causes:

• Late or missing store server notifications. Renewals, refunds, cancellations, and other events can arrive late if App Store Server Notifications or Google Play RTDN are not configured correctly. Once notifications start flowing, historical data may shift.
• Receipt / subscription-state refreshes. Some metrics (MRR, ARR, active-subscription counts) depend on Apphud being able to validate receipts and refresh subscription status. If validation was blocked earlier — e.g., an invalid App Store In-App Purchase API key — values can diverge until the next refresh aligns them.
• Refunds. When a refund is reported after the fact, the revenue-related charts (Proceeds, Sales, Gross revenue, Refunds) update for the original transaction's period. See Why do historical Proceeds keep changing for past months?
• Late SDK integration on an existing app. If you integrate the SDK into a live app with existing customers and skip historical data migration, purchases arrive only as users open the app or as server notifications come in. Cohort-based reports (Cohort Revenue, Cumulative LTV / CLV, retention) can shift upward as those historical transactions land.
• Different chart logic, same input data. Two charts can answer different questions even when they use the same revenue source. Example: Proceeds shows revenue by transaction date; Cohort Revenue shows the same money grouped by the user's install date. The totals won't match — that's by design.
• Store-setting changes. Some configuration changes (for example, the Apple Small Business Program entry date) apply only from the moment they're set and don't recalculate prior periods.

If you see unexpected differences or shifts that do not match any of the above, contact Apphud Support with:

• The app and report name.
• The date range affected.
• Screenshots or exported values showing the discrepancy.
• Confirmation there were no recent changes to store settings.

Support uses this to determine whether it's expected chart logic, late store data, a configuration issue, or a case that needs deeper investigation.

Can Apphud recalculate historical data for me?

It depends on the cause.

• Yes, automatically: if the missing source data eventually arrives — server notifications get configured, an API key is fixed, subscription states are refreshed — Apphud reprocesses the affected events and the historical charts update on their own.
• No, not retroactively: some store-setting changes (e.g., adding Apple Small Business Program after the fact) are forward-only.

Where should I look for which question?