App Store and Google Play revenue to BigQuery

What Netice sends to BigQuery

Netice turns daily app-store revenue reporting into a BigQuery-ready app revenue table. The workflow uses the google_apple_app_sales source mode, where Apple App Store and Google Play reporting can be selected together or separately. The output is an enriched daily app-sales table, not a raw file dump and not a vendor dashboard.

The default managed BigQuery table is app_sales_daily. A typical synthetic example is example_project.example_dataset.app_sales_daily. The table keeps source context visible through fields such as source, platform, source_report, source_kind, report_currency, method fields, freshness fields and provenance fields. That is what makes the output useful after it lands in a warehouse: a row still explains where it came from and how it should be interpreted.

This matters because Apple and Google Play do not expose identical reporting data. Apple daily sales-style reporting and Google Play estimated sales-style reporting differ in source fields, timing, proceeds behavior, tax and fee visibility, subscription events and finance meaning. Netice does not hide those differences. It makes them queryable.

Source reports behind the table

A useful app revenue table should not collapse every provider report into a generic revenue field. BigQuery users need to know which source report produced each row. Netice preserves that through source_report and related fields.

BigQuery setup requirements

App revenue to BigQuery needs two separate sides of access: source access and destination access. Source access lets Netice read Apple App Store or Google Play reporting. Destination access lets Netice write the managed BigQuery output. One does not replace the other.

Managed BigQuery table behavior

Netice is designed to keep the same managed BigQuery table current. That is different from a manual export workflow where each report becomes another spreadsheet or one-off file. A recurring app revenue workflow should update the selected reporting window predictably and avoid blind appends that make duplicates harder to detect.

For BigQuery, Netice materializes the selected daily app-sales window, stages the candidate data for BigQuery loading, validates the table shape, and updates the managed table by a guarded reporting window. The customer-facing point is not the internal SQL. The point is that recent daily windows can be refreshed while preserving a stable destination table for downstream SQL, BI and modeling.

Schema and field groups

The BigQuery output uses the current daily app-sales field set. It should not be described with stale legacy table names or older uppercase field contracts. The current public-facing table should be discussed as the app_sales_daily output with source-aware daily fields.

Report currency, native currency and method fields

App-store reports often include currency and amount fields that are not directly comparable across providers. Netice separates native amount context from report-currency presentation. The report_currency field is configured for the task and supports fields such as estimated_gross, estimated_net, estimated_tax and estimated_fee. Native fields such as native_currency, gross_local, net_local, tax_local and fee_local preserve local source context.

The method fields are not cosmetic. Fields such as net_method, fee_method and tax_method explain whether a value came from source proceeds, a provider amount, an estimate, a residual calculation or another supported method. That matters because Apple Summary Sales does not itemize commission and tax like a finance report, and Google Play Estimated Sales does not itemize service fee as a monthly finance output would.

Backfills and recurring refreshes

A useful BigQuery workflow needs history and refresh behavior. A table that only starts today cannot answer historical trend questions. A table that only appends forever can become difficult to reason about when provider reports arrive late, stabilize or need to be rerun.

Netice supports first-run and backfill behavior for historical context, then recurring refreshes for recent completed days. Current validation evidence supports a rolling recent-days refresh window, with a default recent window and a configured upper bound. The public page should avoid promising an exact historical maximum unless that limit is explicitly approved as a product promise. The safe customer-facing claim is that Netice can backfill selected history and refresh recent windows while keeping the managed BigQuery table stable.

Safe BigQuery examples

The examples below use synthetic values only. They show the intended table shape and query behavior without using real project names, datasets, app identifiers, SKUs, source files, hashes, credentials, logs or customer amounts.

Example managed table

Project: example_project
Dataset: example_dataset
Managed table: app_sales_daily
Fully qualified table: example_project.example_dataset.app_sales_daily

Example rows

revenue_date,platform,source,source_kind,source_report,app_id,item_id,country,units,report_currency,estimated_net,net_method,data_completeness,event_has_revenue,source_row_hash
2026-02-10,IOS,APPLE_APP_STORE,SALES,ASC_SUMMARY_SALES,com.example.app,premium_monthly,US,1,EUR,6.99,APPLE_PROCEEDS,T_PLUS_2_STABILIZED,true,synthetic_hash_apple_001
2026-02-10,ANDROID,GOOGLE_PLAY,SALES,GP_ESTIMATED_SALES,com.example.app,premium_monthly,US,1,EUR,6.99,GOOGLE_ESTIMATED_NET_FROM_CHARGED_AMOUNT_MINUS_ESTIMATED_FEE,T_PLUS_2_STABILIZED,true,synthetic_hash_google_001

Example daily analytics query

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

This query is for operational daily analytics. It is not a payout reconciliation query, not an accounting-close query and not a substitute for monthly platform finance reporting.

Example freshness review query

SELECT
  data_completeness,
  source_report,
  COUNT(*) AS rows
FROM `example_project.example_dataset.app_sales_daily`
WHERE revenue_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY)
GROUP BY data_completeness, source_report
ORDER BY source_report, data_completeness;

Status, failures and review summaries

A serious app revenue workflow should separate source problems from destination problems. If a source report is not ready, that is different from a bad credential. If a BigQuery table has an incompatible type, that is different from an empty reporting window. If candidate rows fail validation, that is different from a successful write with no new rows.

Netice review and run-history summaries are designed to be safe. They should explain status and next actions without exposing raw provider rows, real app IDs, SKUs, credentials, table names, buckets, source files, logs, task IDs, payment references or customer data.

How this differs from raw reports to BigQuery

Netice also has raw report concepts, but raw reports are not the same as the daily enriched app-sales BigQuery output. Raw report workflows preserve provider-native report artifacts and source-native tables. The app_sales_daily table is the enriched daily app-sales output with unified fields, report currency, method fields and source context.

When to use finance_unified instead

Use the BigQuery daily app-sales table when the question is about daily platform-reported activity: trends, product performance, country breakdowns, subscription lifecycle signals and recent operational reporting. Use finance_unified when the question is monthly platform finance or settlement-style reporting.

The distinction is not academic. If a dashboard or LLM summary treats daily app-sales rows as final booked revenue, it can create a false finance claim. Netice keeps daily sales, raw reports and monthly finance as separate product/data layers so each can be interpreted correctly.

FAQ

What app revenue data can Netice send to BigQuery?

Netice can send Apple App Store and Google Play daily app-sales reporting into a managed BigQuery table for operational analytics. The workflow is the enriched daily app-sales output, not raw reports or monthly finance reporting.

Is the BigQuery table accounting-final revenue?

No. The table is for daily operational analytics and finance review. It is not final payout, settlement, accounting close, audited revenue or bank reconciliation output.

Which Apple reports feed the BigQuery output?

The daily Apple side uses App Store Connect sales-style reporting such as Summary Sales, with subscription events when available. It is not Apple financeReports.

Which Google Play reports feed the BigQuery output?

The daily Google Play side uses Google Play Estimated Sales-style reporting and subscription lifecycle data when available. It is not Google Play Earnings.

What is the default BigQuery table name?

The current default managed table name is app_sales_daily. Public examples should use synthetic names such as example_project.example_dataset.app_sales_daily.

Does Netice append rows or refresh recent dates?

Netice is designed to keep the same managed table current. Recent date windows can be refreshed instead of blindly appended, and the workflow includes guards for cases such as empty candidate windows, duplicate rows and type conflicts.

Why does Netice need a GCS bucket for BigQuery?

The BigQuery write path uses a configured GCS staging bucket to support BigQuery loading. The staging detail is part of the destination setup and should not be confused with the final managed BigQuery table.

Can Apple and Google Play be combined in one BigQuery table?

Yes. The daily app-sales schema keeps provider context visible through fields such as source, platform and source_report, so Apple and Google Play rows can be queried together without erasing their differences.

What does data_completeness mean?

data_completeness describes daily source-readiness or maturity for operational reporting. It is not a settlement-finality field.

When should I use Finance Unified instead?

Use Finance Unified for monthly platform finance or settlement-style reporting. Use the daily BigQuery app-sales table for daily operational analytics.

Related guides

• Product documentation
• Unified daily app sales schema
• Apple App Store revenue to BigQuery
• Google Play revenue to BigQuery
• Daily app sales vs platform finance reports
• Report currency and FX
• BigQuery warehouse refresh behavior
• Security policy
• Pricing