How to Unify App Store and Google Play Revenue in BigQuery

Why Unify Apple App Store & Google Play Revenue Data into One View?

To make app revenue consolidated reporting a daily automated workflow, not a month-end ceremony. Finance wants a single daily truth, analytics wants stable dashboards, and the CEO wants one number to watch that doesn’t change its meaning every time someone exports a different report.

• Daily awareness: You're always up-to-date with your App Store + Google Play revenue dashboard without manual merges.
• Clear definitions: You stop mixing “gross,” “net,” “proceeds,” and “earnings” casually.

Why Apple vs Google Play Revenue Never Matches Out of the Box

• Different definitions: Apple “Proceeds” ≠ Google Play “Estimated sales” ≠ “Earnings”.
• Different cadence: Some data is daily (estimated), some is monthly (earnings / payout context).

The goal isn’t “force everything to match.” The goal is: one daily table that's explainable in one minute.

Revenue Terminology Map (Apple vs Google Play) — The Part That Prevents Bad Dashboards

Apple (App Store Connect)

• Customer Price: what the customer paid (gross context).
• Proceeds: what you receive (Customer Price minus applicable taxes and Apple’s commission); Sales and Trends proceeds aren’t final.
• Sales: billed-to-customer totals; not the same as proceeds.

Source: Apple App Store Connect Help (Proceeds definition; Sales & Trends not final): Apple docs

Google Play (Play Console)

• Estimated sales: buyer-paid lens; revenue data is based on estimated sales (amounts paid by buyers, including tax).
• Earnings reports: a separate report family from estimated sales; treat it as a different lens (often tied to payout/reconciliation workflows).
• Sales channel: values like IN_APP, PLAY_STORE, OUTSIDE_PLAY_STORE (when available).

Source: Google Play Console Help: Revenue data based on estimated sales • Estimated sales vs Earnings reports download

Get Your Unified Google + Apple Revenue Table to BigQuery

Netice’s Unified Revenue Schema is a good target contract because it bakes in the definitions, audit fields, and currency conversion.

Minimum Columns (Sales-Only Focus)

This is the smallest “app revenue single table BigQuery” schema that stays explainable:

• revenue_date, source, source_kind, platform, app_id, country
• sales_channel (when available), units, product_id, product_name
• original_currency, report_currency, fx_rate_to_report
• revenue_net_original, revenue_net_report (+ optional revenue_gross_original, store_fee_original)
• is_final, source_report, transaction_type, meta_json

Options: DIY Exports vs ELT + Modeling vs Netice

Option A — DIY Exports + Manual Merge

Works for small volume and low stakes. Breaks when daily finance confidence becomes a requirement. Huge work when you need to convert currencies from multiple markets. Manual exports scale poorly as business develops, but a starting publisher can live with just Excels.

Option B — General ETL + Your Own Model Layer

Common approach: ingest raw reports, then build a unified model for reporting. This can work well, but you still own the hard parts: terminology, currency conversion consistency, audit flags, and “why did it change?” explainability. This takes days to build and validate even for a more experienced data analyst, and when platforms update their reporting format (data types, column names), things break. All while you're still paying for the ETL pipeline for a "here's 10 CSVs - good luck with them" service.

Option C — Netice (Daily, Platform-Reported Unified Revenue Table to BigQuery)

Netice is built for the exact operational outcome finance and analytics care about: a daily, platform-reported revenue data layer in your warehouse, normalized into Unified field names so teams stop rebuilding the same logic every quarter and instead get consistent platform-reported input into analytics dashboards and finance processes.

FAQ

Does This Unified BigQuery Table Equal Booked/Accounting Revenue?

No. This is platform-reported revenue data shaped for reporting and reconciliation. Booked/invoiced revenue depends on your accounting rules, systems, and recognition policies.

Apple Proceeds vs Google Play Earnings: Which One Is “Net”?

They’re different definitions and sometimes different report families. Apple “Proceeds” is explicitly Customer Price minus taxes and Apple commission. Google Play “estimated sales” is buyer-paid amounts (including tax), and “Earnings reports” are a separate lens. In a unified table, you should label this via source_report instead of guessing.

Why Do Google Play Totals Differ by Report?

Estimated sales reports and Earnings reports represent different lenses and timing. Treat them as separate reporting truths and keep both if you need both.

What Should I Do If Rows Change After They Appear?

Don’t hide it. Track it. Use is_final and source_report so finance can see what is still subject to change.

What to Do Next

If you want the DIY route: implement the raw + unified model pattern above and treat semantics as a contract. If you want the fast route: use Netice to get a daily, platform-reported unified layer in BigQuery with a stable schema and field dictionary.

Last reviewed: 2026-02-21

Sources

• Apple App Store Connect — Proceeds definition and “Sales and Trends proceeds aren’t final”: developer.apple.com
• Apple Reporting Reference — Sales and Trends proceeds vs closed transactions: developer.apple.com
• Google Play Console — Revenue data based on estimated sales (amounts paid by buyers, including tax): support.google.com
• Google Play Console — Download Estimated sales reports vs Earnings reports: support.google.com
• BigQuery — Partition boundaries are UTC-based: docs.cloud.google.com