Google Play revenue to BigQuery

What Netice sends from Google Play to BigQuery

Netice uses its daily app-sales workflow to send Google Play revenue reporting into BigQuery. The internal source mode is google_apple_app_sales, but Google Play can be selected as the provider on its own when the task is configured for Google Play reporting. The resulting managed BigQuery table is designed for daily operational app-sales analytics, not for monthly payout reconciliation or accounting close.

The current default BigQuery table name for this daily layer is app_sales_daily. A typical synthetic destination example is example_project.example_dataset.app_sales_daily. The table keeps Google Play source context visible through fields such as source, platform, source_kind and source_report, instead of flattening Play Console data into a vague revenue number.

For Google Play daily revenue rows, the important report-family label is GP_ESTIMATED_SALES. Subscription lifecycle rows can use GP_SUBSCRIPTIONS. Those lifecycle rows should not automatically be treated as money rows; the table includes event_has_revenue so downstream queries can separate revenue-bearing rows from lifecycle-only context.

Google Play source reports behind the table

Google Play daily app-sales rows come from Play Console Estimated Sales style reporting. Netice preserves that source family in the output through source_report = 'GP_ESTIMATED_SALES'. This matters because Google Play Estimated Sales is not Google Play Earnings.

Estimated Sales is useful for daily app revenue analytics. Earnings is a monthly finance report family. They differ in source object family, date/period shape, fee visibility, tax handling, finance finality and intended use. Treating Estimated Sales as Earnings creates misleading dashboards and finance confusion.

BigQuery destination setup

Google Play source access and BigQuery destination access are separate. Google Play access lets Netice read selected Google Play reporting data. BigQuery destination access lets Netice write the managed output table into the customer’s Google Cloud project and dataset.

In the current BigQuery path, Netice needs a BigQuery project, dataset, managed table name and a GCS staging bucket used to load data into BigQuery. The staging bucket is part of the warehouse loading process. It should not be confused with customer-facing object-storage export output.

Public examples should never include real project IDs, datasets, tables, buckets, staging paths, service-account JSON, report bucket values, task IDs, logs or source rows.

The managed app_sales_daily table

Netice is designed to keep the same managed BigQuery table current. First runs, recurring refreshes and selected reruns should update the managed output instead of creating arbitrary new public tables on every run.

The BigQuery path stages candidate rows before updating the selected reporting window. That gives Netice a chance to validate the candidate output, detect duplicate conditions, check typed table compatibility and avoid treating an empty provider candidate as permission to erase existing data. The customer-facing model is: stable table, selected-window refresh, source-aware rows.

Google Play field groups in BigQuery

The Google Play daily BigQuery output is useful because it carries both analytic amounts and source context. A row should not be read only by its revenue number. The surrounding fields explain which provider produced it, which report family it came from, which currency was used, how estimates were derived and whether the row represents a revenue-bearing event.

Report currency, native currency and method fields

Netice daily app-sales output has a configured report_currency. In examples, this may be EUR. Report currency is a presentation layer for daily analytics. It does not erase the source/native currency context and does not turn daily estimates into final payout or settlement data.

For Google Play Estimated Sales, service fee is not itemized the same way as in monthly Earnings. That is why method fields matter. For example, fee_method can tell downstream users that the fee value is estimated rather than source-truth. Tax can be source-truth when Google Play provides taxes collected and tax_method says so, but that should not be generalized into “all tax values are exact.”

Backfills, provider-late data and recurring refreshes

Google Play reports can arrive late or change after a first run. Netice app-sales tasks therefore support first runs, selected history, recurring refreshes and reruns of bounded windows. The recurring daily refresh model is designed to keep the same managed table current for recent completed days.

In current validation evidence, the recurring daily refresh defaults to the latest 7 completed days and validates up to a configured cap. That is a daily app-sales refresh concept, not a monthly finance period and not a provider SLA. Google Play does not publish a strict daily-ready hour that should be promised in customer documentation.

Google Play Estimated Sales vs Google Play Earnings

The most important finance boundary is simple: Google Play Estimated Sales is not Google Play Earnings. This BigQuery page is about daily Google Play app-sales analytics. Monthly Google Play Earnings belongs to the Finance Unified layer when configured.

Safe BigQuery examples

The following examples are synthetic. They show the shape of Google Play daily app-sales analysis without exposing real package names, SKUs, projects, datasets, tables, source paths, hashes, task IDs, logs or customer data.

Synthetic BigQuery target

Project: example_project
Dataset: example_dataset
Table: app_sales_daily
Fully qualified table: example_project.example_dataset.app_sales_daily
Staging bucket: example_bucket

Daily Google Play revenue query

SELECT
  revenue_date,
  source_report,
  item_id,
  data_completeness,
  SUM(estimated_net) AS estimated_net_report_currency,
  SUM(units) AS units
FROM `example_project.example_dataset.app_sales_daily`
WHERE source = 'GOOGLE_PLAY'
  AND platform = 'ANDROID'
  AND source_kind = 'SALES'
  AND revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-29'
GROUP BY revenue_date, source_report, item_id, data_completeness
ORDER BY revenue_date, source_report, item_id;

Revenue vs lifecycle row check

SELECT
  source_report,
  data_completeness,
  COUNT(*) AS row_count,
  COUNTIF(event_has_revenue) AS revenue_rows,
  COUNTIF(NOT event_has_revenue) AS lifecycle_only_rows
FROM `example_project.example_dataset.app_sales_daily`
WHERE source = 'GOOGLE_PLAY'
  AND revenue_date >= DATE '2026-02-01'
GROUP BY source_report, data_completeness
ORDER BY source_report, data_completeness;

These queries are for operational analytics. They are not accounting close, payout reconciliation or Google Play Earnings queries.