Unified daily app sales schema

What this schema is for

This schema describes the daily app-sales output Netice creates from Apple App Store and Google Play reporting surfaces. It gives analytics, finance and data teams a consistent way to query platform-reported app revenue while keeping the source context visible. A row should not become an anonymous revenue number after it lands in a warehouse or a file destination. It should still answer the practical questions: which platform reported it, which report family produced it, which date it belongs to, which app and product it refers to, what currency context applies, and how the amount was derived.

Netice uses this daily schema for the google_apple_app_sales workflow. Customers can select Apple App Store, Google Play, or both as daily sales sources and send the resulting output to a customer-owned destination such as BigQuery, Snowflake, Google Cloud Storage or AWS S3. In BigQuery, the default managed table name is app_sales_daily. In Snowflake, the default table name is APP_SALES_DAILY. In object storage, the managed CSV file follows the pattern app_sales_enriched_<REPORT_CURRENCY>.csv.

The goal is not to hide Apple and Google differences. The goal is to make those differences queryable. Apple and Google Play do not expose identical report families, currency fields, proceeds fields, fee behavior or lifecycle events. The schema therefore keeps fields such as source, platform, source_report, net_method, fee_method, tax_method and data_completeness visible instead of flattening everything into one unexplained amount.

Source reports represented in the daily schema

The source_report field is one of the most important columns in the schema. It keeps the report family visible after Apple and Google Play rows have been normalized into the same output. That matters because the same app, product and date can mean different things depending on whether the row came from daily sales reporting, a subscription lifecycle event, a raw report or monthly finance reporting.

Core field groups

The current daily schema is based on the app_sales_daily_v4 field set. The public schema should be read as a source-aware analytics contract: some fields are direct source values, some are normalized by Netice, some are derived, and some are intentionally nullable when a provider does not expose the same fact.

Field-level reference

The table below gives the practical interpretation of the most important fields. It is intentionally not written as a generic database dictionary. The important part is how each field should be read when Apple and Google Play rows appear together.

Apple-specific behavior

Apple daily app-sales rows are based on App Store Connect sales-style reporting, not Apple finance reporting. The daily Apple report family can support operational questions such as product sales, refunds, preorders, renewals, storefront context, units and daily trends. It does not turn the row into a bank-settled finance event.

Apple also has fields that do not map cleanly to Google Play. In particular, Apple can expose proceeds-related context such as proceeds currency and developer proceeds. The daily schema preserves that context through Apple-specific fields such as apple_proceeds_currency and apple_proceeds_native. These fields are intentionally not forced into Google Play rows. A blank or null Google value is the correct result when a field is Apple-specific.

Fee and tax interpretation also requires care. Apple Summary Sales does not itemize commission and tax in the same way a finance report would. Netice therefore uses method-coded daily estimates where possible and keeps method fields visible. The important public rule is simple: if a value is estimated, the schema should tell the reader how to treat it.

Google Play-specific behavior

Google Play daily sales rows come from Play Console sales-style report exports, not Google Play Earnings reports. In the daily schema, Google rows use source=GOOGLE_PLAY, platform=ANDROID and source-report labels such as GP_ESTIMATED_SALES or GP_SUBSCRIPTIONS.

Google Play can expose tax information in ways that are different from Apple. For example, a Google tax method can indicate source-truth tax when taxes collected are present. But Google Play Estimated Sales does not itemize every finance concept a monthly earnings report would contain. Service-fee interpretation still needs method context. That is why the daily schema keeps fee_method and tax_method visible instead of implying all amount fields are equally final.

Subscription lifecycle rows also need careful interpretation. A subscription event can be useful for lifecycle analytics even when the row does not have a revenue amount. The event_has_revenue field helps downstream users avoid treating every event as a money-bearing transaction.

Report currency, native currency and FX

Netice separates report-currency presentation from native source context. The report_currency field is selected during task setup and is used for comparable daily analytics 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 keep the local amount context visible.

The FX fields — gross_fx, net_fx, tax_fx and fee_fx — explain conversion into report currency where conversion is used. These fields should be read as part of the daily analytics contract. They do not turn a daily source row into a settled finance row.

Data completeness and recurring refreshes

Daily app-store reports can arrive, stabilize or change after the first time a period is available. Netice therefore treats refresh behavior as part of the output contract. The daily schema includes data_completeness so a reader can distinguish very recent rows from more mature rows.

Current completeness labels include LIVE, T_PLUS_2_STABILIZED and MATURE. These are daily source-readiness concepts. They are not settlement finality labels. A row marked as more mature is still part of the daily operational app-sales layer, not the monthly finance layer.

The daily app-sales setup supports a recurring recent-window refresh. Netice can keep the same managed table or file refreshed rather than forcing teams to manually append new exports. For BigQuery and Snowflake, this means the selected managed table stays current. For object-storage destinations, the managed CSV object is refreshed. The article should not claim a hard historical maximum unless a public product limit has been approved, but it can explain the operating model: initial backfill brings historical context into the destination, and recurring refresh keeps recent completed days updated.

Destination output: warehouse tables and CSV files

The same daily field set can be useful in both warehouse and file destinations. The destination changes how the data is consumed, not what the schema means.

For direct object-storage output, the supported file format for this workflow is CSV. The schema article should not promise Parquet object output for google_apple_app_sales unless that product behavior changes and is verified.

Safe synthetic example

The example below is intentionally small. It shows the shape of the daily schema without using real apps, products, buckets, tables, source files, hashes or customer amounts.

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

A typical BigQuery query for operational daily analytics might group by date, platform, report family and product:

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 daily operational analytics. It should not be presented as payout reconciliation, settlement evidence or accounting close output.

How this differs from finance_unified

The daily app sales schema and finance_unified answer different questions. Daily app sales explains platform-reported operational activity by day. Finance Unified is the separate monthly platform finance output. Keeping the two outputs separate prevents a dashboard, analyst or LLM summary from turning daily operational data into a false finance claim.

Setup requirements behind the schema

The schema is not only a list of columns. It is the result of a configured Netice task. For daily app sales, the source mode is google_apple_app_sales. During setup, the user selects Apple App Store, Google Play, or both, then configures the destination and report currency. Source access and destination access are separate concerns: the source configuration must be able to read the selected report family, and the destination configuration must be able to receive the managed table or file.

Failure states this schema helps diagnose

A source-aware schema also makes operational issues easier to understand. If the output keeps source report, provider, date, freshness and method context visible, a team can separate very different states that would otherwise all look like “the revenue number is wrong.”