Google Play Earnings to BigQuery

What Google Play Earnings to BigQuery means in Netice

In Netice, Google Play Earnings to BigQuery means using Finance Unified to normalize monthly Google Play Earnings rows into a customer-owned BigQuery table. The default table is finance_unified. Rows are identified with source = 'GOOGLE_PLAY', platform = 'ANDROID', source_kind = 'FINANCE', and source_report = 'GOOGLE_PLAY_EARNINGS'.

This is not the same workflow as daily Google Play revenue to BigQuery. Daily Google Play app-sales analytics uses Google Play Estimated Sales and lands in a daily table such as app_sales_daily. Google Play Earnings is monthly finance reporting and belongs to Finance Unified. A correct warehouse model keeps those outputs separate.

This page is written for finance operations teams, analytics engineers and data platform owners who want to understand what the BigQuery finance table represents, which fields matter, how null values should be interpreted and why this output should not be treated as accounting close, audit proof, tax advice or final payout truth.

Google Play Earnings source behavior

Google Play Earnings is a monthly finance report family. In Netice Finance Unified, Google Play Earnings rows are normalized as event-grain finance rows. The source report family is distinct from daily sales reports, and the normalized source report label is GOOGLE_PLAY_EARNINGS.

Google Play Earnings access is also different from destination access. Source access allows Netice to read the monthly Play Console Earnings report. BigQuery destination access allows Netice to write the managed finance_unified table. A valid source connection does not automatically grant BigQuery write permissions, and a valid BigQuery destination does not prove Google Play Earnings access.

The finance_unified BigQuery table

The default Finance Unified BigQuery table is finance_unified. Public examples use a synthetic fully qualified table such as example_project.example_dataset.finance_unified. Real projects, datasets, tables, staging buckets, job IDs, task IDs, source paths and customer identifiers should stay out of public examples.

Finance Unified is an event-grain schema. It is not one row per app per month. Google Play Earnings rows can represent sales, refunds, platform fees, fee reversals, tax and adjustments where those event types are present in the source. The event type is part of the meaning of the row and should remain visible in downstream SQL.

Google Earnings event taxonomy

Google Play Earnings rows should be analyzed as finance ledger events. A sale row is different from a platform fee row. A tax row is different from a refund. Adjustments are not automatically the same thing as customer purchases. Finance queries that hide event_type can produce misleading totals.

Netice Finance Unified keeps event types such as SALE, REFUND, PLATFORM_FEE, PLATFORM_FEE_REVERSAL, TAX and ADJUSTMENT visible when they are present in the Google Play Earnings source data. This article does not claim support for additional event families beyond the product’s Finance Unified taxonomy.

Currency, FX and null-not-zero behavior

Finance Unified keeps source-native amounts and report-currency presentation fields separate. Native values remain native. Report-currency fields such as report_net_proceeds and report_customer_charge are populated where the conversion is available and valid.

Same-currency rows can use fx_rate = 1. Missing cross-currency FX should not silently become rate 1, and unknown finance values should not become zero. This is the null-not-zero policy: null means unknown, unsupported, unavailable, not disclosed, or not applicable; zero means known zero.

Google Earnings limitations to preserve

Google Play Earnings should not be expanded beyond what the source and Finance Unified workflow provide. Google Play Earnings should not be described as chargeback coverage, and Google finance rows should not be used to infer daily units when the finance schema leaves quantity null.

BigQuery write and refresh behavior

Finance Unified BigQuery behavior should be described at the product-contract level. Netice writes a managed finance table for the configured customer-owned BigQuery destination. Replacement and refresh behavior is finance-period/source based, not daily revenue-date based.

For Google Play Earnings, the managed BigQuery table is refreshed by finance-period and source context such as platform, source_kind, source, source_report and fiscal_period. Public documentation should not expose internal BigQuery SQL, staging object names, job IDs, target hashes, logs or operational runbooks.

Setup, access and secret handling

Google Play Earnings source access and BigQuery destination access are separate. Google Play Earnings access lets Netice read the monthly finance source. BigQuery destination access lets Netice write the managed table to a customer-owned warehouse.

Netice encrypts customer secret material and handles credentials through secret management. Saved source and destination connections reduce repeated credential entry, but saved credential values are write-only after saving and are not shown back in the product interface. Public documentation should not include service-account JSON, private keys, service-account emails, report bucket IDs, package names, app IDs, payment profile details, source files, source rows, task IDs, run IDs, logs, credentials, secret references or customer data.

Safe synthetic examples

The examples below are synthetic and simplified. They show table and query shape only. They are not real Google Play rows, not accounting examples and not proof of payout reconciliation.

Safe BigQuery target

Project: example_project
Dataset: example_dataset
Table: finance_unified
Fully qualified table: example_project.example_dataset.finance_unified
Source mode: finance_unified
Provider selected: Google Play Earnings
Source report label: GOOGLE_PLAY_EARNINGS
Schema version: finance_unified_v3_event_grain

Safe finance-period query

SELECT
  fiscal_period,
  event_type,
  native_currency,
  report_currency,
  SUM(native_net_proceeds) AS native_net_proceeds,
  SUM(report_net_proceeds) AS report_net_proceeds
FROM `example_project.example_dataset.finance_unified`
WHERE source = 'GOOGLE_PLAY'
  AND source_kind = 'FINANCE'
  AND source_report = 'GOOGLE_PLAY_EARNINGS'
  AND fiscal_period BETWEEN DATE '2026-02-01' AND DATE '2026-04-01'
GROUP BY fiscal_period, event_type, native_currency, report_currency
ORDER BY fiscal_period, event_type, native_currency;

Safe null coverage query

SELECT
  fiscal_period,
  event_type,
  COUNT(*) AS rows_total,
  COUNTIF(report_net_proceeds IS NULL) AS rows_missing_report_net,
  COUNTIF(report_net_proceeds = 0) AS rows_known_zero_report_net,
  COUNTIF(native_customer_charge IS NULL) AS rows_without_customer_charge
FROM `example_project.example_dataset.finance_unified`
WHERE source = 'GOOGLE_PLAY'
  AND source_kind = 'FINANCE'
  AND source_report = 'GOOGLE_PLAY_EARNINGS'
  AND fiscal_period = DATE '2026-02-01'
GROUP BY fiscal_period, event_type
ORDER BY event_type;

The null coverage query intentionally keeps null and zero separate. Do not rewrite it into a finance-close query that hides unknown values with blanket COALESCE.