NETICE DOCUMENTATION
Daily App Sales vs Platform Finance
Reviewed
Use Daily App Sales for operational revenue trends. Use Platform Finance for monthly Apple finance and Google Play Earnings data. Use Raw Reports when you need provider-native rows and columns. These outputs are separate because their amounts, periods and row meanings differ.
In Netice, estimated_net in Daily App Sales and report_net_proceeds in Platform Finance are different measures. Neither a matching currency label nor a monthly aggregation makes them equivalent.
| Decision | Daily App Sales | Platform Finance |
|---|---|---|
| Apple source | Summary Sales | Monthly finance reports |
| Google Play source | Estimated Sales | Earnings |
| Time axis | revenue_date |
fiscal_period, with separate transaction, settlement and attribution dates |
| Amount to inspect | estimated_gross, estimated_net, estimated_tax, estimated_fee |
native_net_proceeds and report_net_proceeds |
| Row meaning | Normalized sales/report activity; not a universal order ledger | Source-derived events, including separate Google fees, taxes and adjustments |
| Missing amounts | Some report-currency estimates can be derived or assumed zero; method fields identify the basis | Unknown monetary values remain null; true zero remains zero |
| Managed refresh scope | Reporting date window | Report period plus source scope |
| Default warehouse table | app_sales_daily / APP_SALES_DAILY |
finance_unified / FINANCE_UNIFIED |
Which workflow answers your question?
“How is revenue trending by store and country?” Start with Daily App Sales. Group the report-currency estimate by reporting date and retain the method and completeness fields when assessing quality.
“What does the platform report for this finance period?” Start with Platform Finance. For Google Play, include all relevant event types in a proceeds total rather than selecting only sales. For Apple, retain fiscal-period boundaries rather than assuming a calendar month.
“Which fields and values does the provider report?” Use Raw Reports. It preserves provider-supplied rows and columns in managed files; decoding, period merging and recompression mean it is not a byte-identical archive of every original download.
Why monthly totals can disagree
Daily reports and finance reports can recognize activity in different periods, use different currencies and contain different adjustments. Apple’s fiscal calendar adds another boundary. Netice preserves these distinctions; it does not force a daily-sales sum to equal a financial report.
For example, an operational dashboard may show a daily estimate for a purchase before its eventual finance-period assignment is available. A finance ledger may also contain fee or adjustment events that are absent from the daily source. Treat the difference as a reconciliation question, not automatically as a pipeline error.
Keep both outputs without double-counting
Build separate facts or semantic models for daily sales and monthly finance. Join them only at an intentionally chosen analytical grain, with explicit currency and period definitions. Do not union their amounts into one revenue total: overlapping commercial activity would be counted twice.
Use the Daily App Sales schema, Platform Finance schema and SQL examples to choose measures deliberately.