Google Play Estimated Sales vs Google Play Earnings

The short version

Use Google Play Estimated Sales when the question is: what happened in Google Play app revenue activity by day? Use Google Play Earnings when the question is: what did Google Play report for the monthly finance period?

The revenue distinction is two-fold. Daily App Sales is the analytics layer for day-by-day app revenue. It can include Google Play alone, or it can unify Google Play with Apple App Store revenue in the same clean table when both providers are enabled. Finance Unified is the monthly platform-finance layer for finance-team review.

In Netice, Google Play Estimated Sales uses the Daily App Sales source mode google_apple_app_sales, source kind SALES, and source report labels such as GP_ESTIMATED_SALES and GP_SUBSCRIPTIONS. Google Play Earnings uses finance_unified, source kind FINANCE, and source report label GOOGLE_PLAY_EARNINGS.

Security and access boundaries

Google Play source access and destination access remain separate. Google Play source access lets Netice read selected Play reporting inputs. BigQuery, Snowflake, GCS or S3 destination access lets Netice write selected outputs into the customer-owned destination.

Customer secret material, including source and destination credentials, is encrypted and handled through Netice secret management. Saved connections reduce repeated credential entry, but they are not credential viewers: raw secret values are not shown back after saving.

Public examples stay synthetic. They do not include real service-account material, report bucket IDs, package names, app IDs, product IDs, source paths, source row hashes, destination names, task IDs, run IDs, logs, secret references or customer revenue values.

What Google Play Estimated Sales is

Google Play Estimated Sales is the daily sales-style source family used for operational app revenue analytics. Netice maps Google Play Estimated Sales rows into Daily App Sales with source = 'GOOGLE_PLAY', platform = 'ANDROID', source_kind = 'SALES' and source_report = 'GP_ESTIMATED_SALES'.

Daily Google Play output can also include subscription lifecycle context where available. Those rows use source_report = 'GP_SUBSCRIPTIONS'. A lifecycle row is not automatically a revenue row, so Daily App Sales includes fields such as event_has_revenue to distinguish revenue-bearing rows from lifecycle-only rows.

What Google Play Earnings is

Google Play Earnings is a monthly finance report family. In Netice, it belongs to Finance Unified, not Daily App Sales. Finance Unified keeps monthly finance report semantics visible through fields such as fiscal_period, calendar_period, period_start, period_end, effective_revenue_date and finance event fields.

Google Play Earnings rows normalize into source = 'GOOGLE_PLAY', platform = 'ANDROID', source_kind = 'FINANCE' and source_report = 'GOOGLE_PLAY_EARNINGS'. They can preserve ledger-style finance rows such as sales, refunds, platform fees, fee reversals, tax rows and adjustments when those are present in the source report.

Estimated Sales vs Earnings comparison

The two Google Play report families are separate and should not be collapsed into one anonymous “Google revenue” dataset. They differ in source family, time shape, event taxonomy, fee visibility, tax treatment and intended destination.

Date and period differences

Estimated Sales is daily. It belongs in a daily analytics table using revenue_date. That date is useful for reporting trends, comparing products, tracking country-level patterns and understanding recent app activity.

Earnings is monthly finance reporting. It belongs in a finance-period output where fields such as fiscal_period, calendar_period, period_start, period_end, transaction_date, settlement_date and effective_revenue_date carry the relevant meaning. Google Play Earnings should not be forced into daily revenue_date semantics.

Fees, tax, refunds, rebills and adjustments

Fee and tax interpretation is one of the clearest differences between Estimated Sales and Earnings. Google Play Estimated Sales does not itemize service fee like monthly Earnings. In the daily layer, fee values can be method-coded estimates, and tax is treated as source-truth only when the method context supports that interpretation.

Google Play Earnings can preserve ledger-style finance rows. Earnings rows can represent sales, refunds, platform fees, platform fee reversals, tax, rebill variants and adjustments when the source provides those events. Fee and tax rows can have null customer-charge fields because they are not customer charge events.

Currency and report-currency boundaries

Daily App Sales can include report-currency analytics fields such as estimated_gross, estimated_net, estimated_tax and estimated_fee. Those values are useful for daily analysis, but they remain daily analytical fields with method context.

Finance Unified keeps native finance values and report-currency presentation fields separate. Google Earnings rows can include native_net_proceeds, native_customer_charge, report_net_proceeds, report_customer_charge and fx_rate where applicable. Unknown finance values remain null, not fake zero.

Output destinations: app_sales_daily, finance_unified and raw reports

In Netice, the safest architecture keeps daily, finance and raw outputs separate. Daily App Sales can unify Google Play and Apple App Store revenue into one clean analytics table when both providers are enabled. Finance Unified remains a separate monthly finance output for finance-team review.

Why Estimated Sales and Earnings do not reconcile row by row

It is normal for daily Estimated Sales totals and monthly Earnings totals to differ. They can differ because of report-family definitions, date and period semantics, FX treatment, fee and tax visibility, refunds, adjustments, provider-late data and finance finality.

The safe comparison is aggregate and source-aware. Do not subtract daily Estimated Sales from monthly Earnings and call the difference an error without first understanding source report, period, event type, fee/tax treatment, currency and finality.

Safe synthetic examples

The examples below are synthetic. They are not Google Play source rows, not real customer output and not accounting-close examples.

Daily Google Play Estimated Sales row

revenue_date,platform,app_id,source_kind,source,country,report_currency,estimated_gross,estimated_net,estimated_tax,estimated_fee,native_currency,gross_local,net_local,tax_local,fee_local,net_method,fee_method,tax_method,data_completeness,source_report,event_has_revenue,subscription_period,units,item_id,item_name,transaction_type,source_row_hash
2026-02-10,ANDROID,com.example.app,SALES,GOOGLE_PLAY,US,EUR,9.990000,6.990000,1.500000,1.500000,USD,10.990000,7.690000,1.650000,1.650000,GOOGLE_ESTIMATED_NET_FROM_CHARGED_AMOUNT_MINUS_ESTIMATED_FEE,GOOGLE_ESTIMATED_FEE_30PCT_FROM_SOURCE_STANDARD,GOOGLE_TAXES_COLLECTED,MATURE,GP_ESTIMATED_SALES,true,P1M,1,premium_monthly,Premium Monthly,PURCHASE,synthetic_hash_google_daily_001

Google Play Earnings finance rows

platform,source,source_kind,source_report,report_grain,fiscal_period,period_calendar_type,app_id,sku,event_type,event_category,event_subtype,commission_disclosed,native_currency,native_net_proceeds,native_customer_charge,report_currency,report_net_proceeds,report_customer_charge,fx_rate,source_row_hash
ANDROID,GOOGLE_PLAY,FINANCE,GOOGLE_PLAY_EARNINGS,GOOGLE_EARNINGS_LEDGER_LINE,2026-02-01,GOOGLE_PLAY_EARNINGS_MONTH,com.example.app,premium_monthly,SALE,REVENUE,,true,EUR,9.990000,9.990000,EUR,9.990000,9.990000,1,synthetic_hash_google_earnings_sale_001
ANDROID,GOOGLE_PLAY,FINANCE,GOOGLE_PLAY_EARNINGS,GOOGLE_EARNINGS_LEDGER_LINE,2026-02-01,GOOGLE_PLAY_EARNINGS_MONTH,com.example.app,premium_monthly,PLATFORM_FEE,DEDUCTION,COMMISSION,true,EUR,-3.000000,,EUR,-3.000000,,1,synthetic_hash_google_earnings_fee_001
ANDROID,GOOGLE_PLAY,FINANCE,GOOGLE_PLAY_EARNINGS,GOOGLE_EARNINGS_LEDGER_LINE,2026-02-01,GOOGLE_PLAY_EARNINGS_MONTH,com.example.app,premium_monthly,TAX,DEDUCTION,TAX,true,EUR,-1.000000,,EUR,-1.000000,,1,synthetic_hash_google_earnings_tax_001

Unified daily Apple + Google analytics query

SELECT
  revenue_date,
  source,
  platform,
  source_report,
  report_currency,
  SUM(estimated_net) AS estimated_net_report_currency
FROM `example_project.example_dataset.app_sales_daily`
WHERE source_kind = 'SALES'
  AND event_has_revenue = TRUE
  AND revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-28'
GROUP BY revenue_date, source, platform, source_report, report_currency
ORDER BY revenue_date, source, platform, source_report;

Source-aware comparison query

SELECT
  'daily_app_sales' AS output_family,
  revenue_date AS reporting_date,
  source_report,
  SUM(estimated_net) AS net_report_currency
FROM `example_project.example_dataset.app_sales_daily`
WHERE source = 'GOOGLE_PLAY'
  AND source_kind = 'SALES'
  AND revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-28'
GROUP BY reporting_date, source_report

UNION ALL

SELECT
  'finance_unified' AS output_family,
  fiscal_period AS reporting_date,
  source_report,
  SUM(report_net_proceeds) AS net_report_currency
FROM `example_project.example_dataset.finance_unified`
WHERE source = 'GOOGLE_PLAY'
  AND source_kind = 'FINANCE'
  AND fiscal_period = DATE '2026-02-01'
GROUP BY reporting_date, source_report;

The first query shows the daily analytics layer, which can include both Google Play and Apple App Store rows when both providers are enabled. The second query keeps daily analytics and finance output separated. Neither query is payout reconciliation, accounting close evidence or exact row-level matching.