Netice app revenue data infrastructure
App Store Connect Daily Sales Reports to BigQuery
Netice loads Apple App Store Connect Sales and Trends / Summary Sales reporting into a customer-owned BigQuery table, so analytics and finance teams can query Apple app revenue without maintaining App Store Connect report scripts in-house.
Netice loads App Store Connect Sales and Trends / Summary Sales reporting into a customer-owned BigQuery table named app_sales_daily by default. The table is for daily operational app revenue analytics, not Apple financeReports, payout reconciliation, bank reconciliation, or accounting close.
What App Store Connect data Netice sends to BigQuery
This page is about Apple App Store Connect daily sales-style reporting in BigQuery. In Netice, Apple-only delivery uses the same Daily App Sales workflow as combined Apple + Google Play reporting. Netice writes the output to a customer-owned BigQuery table and manages the recurring load, refresh and schema-aware output for that configured target.
The important difference from a generic connector is that Netice does not treat Apple revenue as just another CSV export. Apple reporting has its own source fields, report timing, proceeds concepts, subscription-event behavior and finance boundaries. The BigQuery output keeps those semantics visible through fields such as source, platform, source_report, source_kind, apple_proceeds_currency, apple_proceeds_native, net_method, fee_method, tax_method and data_completeness.
A typical synthetic BigQuery target looks like example_project.example_dataset.app_sales_daily. Apple rows can then be queried with filters such as source = 'APPLE_APP_STORE', platform = 'IOS' and source_report = 'ASC_SUMMARY_SALES'.
| Use Netice for | Do not use this daily table for |
|---|---|
| Daily Apple app revenue analytics | Final Apple payout reconciliation |
| App, product, country and storefront trend analysis | GAAP, IFRS or ASC 606 accounting conclusions |
| Recurring BigQuery refreshes and backfills | Bank reconciliation or booked revenue close |
| Apple Sales and Trends / Summary Sales reporting | Apple monthly financeReports analysis |
What this BigQuery table is not for
App Store Connect daily sales reporting in BigQuery is not Apple financeReports data. It is not final payout data, settlement data, bank reconciliation, audited revenue, accounting close, GAAP, IFRS or ASC 606 revenue recognition.
The daily Apple rows described here are operational analytics rows. They help teams analyze daily revenue trends, product performance, storefront/country behavior, subscription lifecycle signals and recent changes. Apple financeReports belong to the separate finance workflow, not to the daily app_sales_daily table.
Apple source reports behind the table
App Store Connect exposes more than one kind of report. This page focuses on the Apple daily sales side of the workflow: Sales and Trends style reporting, especially Summary Sales, plus subscription event rows when available. It does not describe every possible Apple report family and it does not claim that raw App Store reports are normalized into this same BigQuery table.
| Apple report family | How Netice represents it in daily app sales | What it is for | Boundary |
|---|---|---|---|
| App Store Connect Sales and Trends / Summary Sales | source_report = 'ASC_SUMMARY_SALES' |
Daily Apple sales-style reporting for operational analytics. | Not Apple financeReports or transaction-level settlement. |
| Apple subscription events | source_report = 'ASC_SUBSCRIPTION_EVENT' |
Lifecycle reporting when subscription-event rows are available. | Some lifecycle rows may not carry revenue amounts. |
| Apple financeReports | Separate finance workflow, not this daily table. | Monthly platform finance or settlement-style reporting. | Do not mix with Summary Sales in this BigQuery daily table. |
| Raw App Store reports | Separate raw-report workflows. | Provider-native archival or downstream custom processing. | No automatic unified schema or currency normalization claim. |
How the Apple-only BigQuery workflow works
In a typical Apple-only setup, the user selects Daily App Sales, selects Apple App Store Sales as the provider, connects App Store Connect reporting access, chooses BigQuery as the destination, and configures the BigQuery project, dataset, table, report currency and staging bucket. Netice then materializes Apple daily rows into the enriched daily app-sales field set and writes the output to the configured customer-owned BigQuery target.
| Step | What is configured | Why it matters |
|---|---|---|
| Choose source mode | Daily App Sales / unified enriched revenue | Uses the enriched daily app-sales workflow, not raw reports and not monthly finance. |
| Select provider | Apple App Store Sales | Limits the workflow to Apple rows while still using the same daily app-sales schema. |
| Connect Apple source access | Saved Apple App Store access or new App Store Connect setup | Allows Netice to read the selected Apple sales report family. |
| Select destination | Google BigQuery | Sends the output to the customer-owned warehouse. |
| Configure destination target | Project, dataset, table and staging bucket | Defines where the BigQuery table lands and how loading is staged. |
| Choose report currency | Three-letter presentation currency | Controls report-currency fields while preserving Apple source context. |
| Set history and refresh behavior | Initial backfill and recurring recent-window refresh | Keeps the managed table useful beyond a one-time export. |
Apple source access requirements
Source access and destination access are separate. Apple source access lets Netice read App Store Connect reporting. BigQuery destination access lets Netice write the output table. A valid Apple connection does not automatically grant BigQuery write access, and a valid BigQuery destination does not automatically grant Apple report access.
App Store Connect setup requires API access and the relevant Apple vendor context. Netice uses those access details to read the selected App Store Connect report family. Saved credential values are not displayed back in the interface after setup, and public examples use synthetic labels instead of real vendor numbers, keys, app identifiers or customer-specific values.
| Apple setup category | Customer-facing explanation | Handling boundary |
|---|---|---|
| App Store Connect API access | Used to read the selected App Store Connect reports. | Credential values remain write-only after setup. |
| Vendor context | Used to identify the Apple reporting scope. | Examples use synthetic labels instead of real vendor numbers. |
| Sales and Trends access | Required for daily sales-style reporting. | Sales and Trends access is separate from Apple financeReports semantics. |
| Saved Apple connection | Lets the user reuse stored Apple access for future tasks. | Saved connections expose safe metadata, not raw credential material. |
BigQuery destination requirements
The BigQuery side needs a destination configuration that can receive the managed output. For Apple daily app-sales to BigQuery, the relevant target is the BigQuery project, dataset and table. The current default table name is app_sales_daily. A GCS staging bucket is also part of the BigQuery loading path; it supports loading and is not the final analytical table.
| BigQuery requirement | Synthetic example | Why it matters |
|---|---|---|
| GCP project | example_project |
Defines the customer-owned cloud project for the BigQuery destination. |
| BigQuery dataset | example_dataset |
Groups the managed output table in the warehouse. |
| Output table | app_sales_daily |
Receives the Apple daily app-sales rows. |
| Staging bucket | example_bucket |
Supports BigQuery loading; it is not the final managed table. |
| Destination access | Saved or new BigQuery/GCP destination access | Lets Netice write to the selected destination without exposing credentials in page copy. |
What the Apple rows look like in BigQuery
Apple rows in the managed daily app-sales table are source-aware. They can be filtered using source = 'APPLE_APP_STORE', platform = 'IOS', and Apple-specific source report labels such as ASC_SUMMARY_SALES or ASC_SUBSCRIPTION_EVENT.
The table below summarizes the Apple-specific field groups that matter most for analytics and finance review.
| Field group | Representative fields | Apple-specific meaning |
|---|---|---|
| Source identity | source, platform, source_kind, source_report |
Identifies Apple App Store rows, iOS platform rows, daily sales source kind and Apple report family. |
| Date and storefront | revenue_date, country |
Represents Apple daily reporting date and storefront/country context when available. |
| App and product | app_id, item_id, item_name, subscription_period, transaction_type |
Supports app, SKU, product title and lifecycle reporting without exposing real IDs in public examples. |
| Apple proceeds | apple_proceeds_currency, apple_proceeds_native |
Preserves Apple-specific proceeds context when the source provides it. |
| Report-currency amounts | report_currency, estimated_gross, estimated_net, estimated_tax, estimated_fee |
Gives a presentation layer for daily analytics, with method fields explaining estimation. |
| Method and FX context | gross_fx, net_fx, tax_fx, fee_fx, net_method, fee_method, tax_method |
Explains how daily analytical amount fields were derived or converted. |
| Freshness and provenance | data_completeness, event_has_revenue, source_row_number, source_row_hash, ingested_at, meta_json |
Supports safe review, freshness interpretation and traceability without publishing raw source rows. |
Apple proceeds, tax and fee interpretation
Apple daily sales data should not be read as a full finance ledger. Apple Summary Sales does not itemize Apple commission and tax in the same way a finance report would. Netice therefore keeps method fields visible when daily values are derived or estimated.
For Apple rows, fields such as apple_proceeds_currency and apple_proceeds_native preserve Apple-specific proceeds context. Fields such as estimated_net, estimated_tax and estimated_fee should be interpreted together with net_method, tax_method and fee_method. The method fields are not optional decoration. They are how a BigQuery reader avoids treating daily analytical estimates as settled platform finance facts.
Backfills and recurring refreshes
A one-time App Store Connect export can answer a narrow question. It does not create a reliable warehouse workflow. Netice is built around saved tasks, first runs, backfills and recurring refreshes so the Apple BigQuery table can stay useful over time.
A first run can load historical completed days, depending on the configured task and available Apple reports. Recurring refreshes update recent completed days so late source availability or changed provider data can be reflected in the same managed output. Historical coverage and exact availability depend on the configured source access, selected report family and Apple report availability.
| Run behavior | Apple BigQuery meaning | Boundary |
|---|---|---|
| Initial run | Creates the first managed Apple daily app-sales output in BigQuery. | Depends on configured source and destination access. |
| Backfill | Loads selected historical completed days when source reports are available. | Historical range depends on Apple report availability and task configuration. |
| Recurring refresh | Refreshes recent completed days in the same managed table. | Provider-late data is different from a bad credential or failed destination write. |
| Rerun | Rebuilds a selected window after review or source availability changes. | A rerun updates a selected window rather than blindly appending duplicate rows. |
Safe Apple-only BigQuery examples
The examples below are synthetic. They show the shape of Apple daily app-sales data in BigQuery without using real apps, SKUs, vendor numbers, projects, datasets, buckets, source files, real row hashes, credentials, logs or customer amounts.
Example BigQuery target
```Project: example_project
Dataset: example_dataset
Managed table: app_sales_daily
Fully qualified table: example_project.example_dataset.app_sales_daily
Provider filter: source = 'APPLE_APP_STORE'Example Apple Summary Sales row
```revenue_date,platform,source,source_kind,source_report,app_id,item_id,country,units,report_currency,estimated_net,apple_proceeds_currency,apple_proceeds_native,net_method,data_completeness,event_has_revenue,source_row_hash
2026-02-10,IOS,APPLE_APP_STORE,SALES,ASC_SUMMARY_SALES,com.app.example,premium_monthly,US,1,EUR,6.99,USD,7.69,APPLE_PROCEEDS,EXAMPLE_COMPLETENESS_STATUS,true,synthetic_hash_apple_001Example Apple subscription lifecycle row
```revenue_date,platform,source,source_kind,source_report,app_id,item_id,transaction_type,report_currency,estimated_net,event_has_revenue,subscription_period,source_row_hash
2026-02-10,IOS,APPLE_APP_STORE,SALES,ASC_SUBSCRIPTION_EVENT,com.app.example,premium_monthly,TRIAL_START,EUR,,false,P1M,synthetic_hash_apple_event_001
The lifecycle example intentionally has no estimated_net. It shows why event_has_revenue matters: a subscription event can be operationally useful without being a revenue row.
Example Apple-only SQL query
```SELECT
revenue_date,
source_report,
item_id,
transaction_type,
SUM(estimated_net) AS estimated_net_report_currency,
SUM(units) AS units
FROM `example_project.example_dataset.app_sales_daily`
WHERE source = 'APPLE_APP_STORE'
AND platform = 'IOS'
AND revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-29'
GROUP BY revenue_date, source_report, item_id, transaction_type
ORDER BY revenue_date, source_report, item_id, transaction_type;This query is for Apple daily operational analytics. It is not Apple payout reconciliation, not Apple financeReports, and not accounting-close evidence.
Status and failure states to separate
A real App Store Connect to BigQuery workflow needs more than a success/error label. Source access, source availability, destination permission, table compatibility and provider format are different problems. Treating them as one vague failure mode makes it harder for data and finance teams to understand the state of the output.
| Status category | What it means | How to think about it |
|---|---|---|
| Missing Apple source selection | Apple App Store Sales has not been selected for the task. | The workflow cannot produce Apple rows without the Apple provider selected. |
| Apple source access failure | The configured Apple access cannot read the selected report family. | Fix Apple source access; BigQuery permissions will not solve it. |
| Apple report not available yet | The expected source report has not arrived or matured. | Provider-late data is different from a bad credential. |
| BigQuery destination access failure | Netice cannot write to the selected BigQuery destination. | Fix destination access; Apple source access will not solve it. |
| Schema or table compatibility issue | The existing target table is not compatible with the expected typed output. | Type conflicts should not be silently overwritten. |
| Data validation issue | Candidate rows or the existing table need review before Netice updates the managed output. | Diagnostics should stay bounded and avoid raw source rows. |
| Finance readiness | The question belongs to monthly finance, not the daily table. | Use the finance workflow instead of forcing finance meaning into daily rows. |
Apple Summary Sales vs Apple financeReports
The most common mistake is to treat an Apple daily sales report and an Apple finance report as if they were two formats of the same thing. They are not. Apple Summary Sales is daily sales-style reporting. Apple financeReports are separate finance-period reports. They answer different questions and should land in different output contracts.
| Question | Daily App Store Connect to BigQuery | Apple financeReports / finance workflow |
|---|---|---|
| Primary use | Daily operational analytics and app revenue trends. | Monthly platform finance or settlement-style reporting. |
| Source family | Sales and Trends style salesReports. |
App Store Connect financeReports. |
| Typical row date | revenue_date |
Finance period, transaction, settlement or effective revenue dates depending on finance schema. |
| Output table | app_sales_daily |
Separate finance output such as finance_unified when configured. |
| Can it be used for payout reconciliation? | No. | Closer to platform finance review, but final booked revenue remains the customer's accounting process. |
FAQ
Can Netice load App Store Connect daily sales reports into BigQuery?
Yes. Netice can load Apple App Store Connect daily sales-style reporting into a customer-owned BigQuery table for operational analytics. This Apple-specific workflow is separate from raw App Store report archival and separate from Apple financeReports.
Which App Store Connect reports feed this BigQuery table?
The daily Apple output is based on Sales and Trends style reporting such as Summary Sales, with subscription event rows when available. In the BigQuery table, these appear through source-report labels such as ASC_SUMMARY_SALES and ASC_SUBSCRIPTION_EVENT.
Is this Apple financeReports data?
No. This page describes daily App Store Connect sales-style reporting to BigQuery. Apple financeReports belong to a separate finance workflow.
What BigQuery table does Netice use by default?
The current default BigQuery table is app_sales_daily. Public examples use synthetic names such as example_project.example_dataset.app_sales_daily.
What Apple access is required?
The setup requires App Store Connect access that can read the selected Sales and Trends style reports, plus the relevant Apple vendor context. Credential values remain write-only after setup, and public examples use synthetic identifiers instead of real keys, vendor numbers or app-specific values.
Why do Apple fee and tax fields use methods?
Apple Summary Sales does not itemize commission and tax like a finance report. Netice keeps method fields such as fee_method and tax_method visible so daily analytical values are not mistaken for settled finance facts.
Does the table include Apple subscription lifecycle events?
It can include Apple subscription event rows when available. Some lifecycle rows may not carry revenue, so fields such as event_has_revenue are important for interpretation.
Can I use this for payout reconciliation?
No. Use this BigQuery output for daily operational analytics. Apple payout or monthly finance review belongs to the finance workflow and the customer's accounting process.
Why does BigQuery setup need a GCS bucket?
The BigQuery write path uses a configured GCS staging bucket to support loading into BigQuery. The managed output is the BigQuery table, not the staging object.
How should Apple rows be queried in a combined app-sales table?
Filter or group by fields such as source, platform and source_report. For Apple-only analysis, use filters such as source = 'APPLE_APP_STORE' and platform = 'IOS'.
Related guides
Move Apple daily app revenue into your warehouse
Netice helps app teams move App Store Connect daily sales reporting into BigQuery with Apple source context, report currency, backfills, recurring refreshes and clear finance boundaries.
