Null, not zero: app revenue finance data policy

What null-not-zero means

The null-not-zero policy is simple: null means unknown, unsupported, unavailable, not disclosed, or not applicable. Zero means known zero. These two meanings must not be collapsed into one value just because a spreadsheet, dashboard, or SQL query looks cleaner with zeros.

This policy matters most in Netice finance_unified, the monthly platform finance output for app revenue data. Finance Unified can represent Apple App Store Connect financeReports and Google Play Earnings data where configured. Those source reports do not always disclose the same fields, the same event types, the same fee/tax details, or the same currency facts. A missing finance value can be meaningful. It stays null instead of becoming a fake zero.

The revenue distinction in Netice is two-fold. Daily App Sales is the analytics layer: Apple App Store and Google Play revenue can be unified into one clean daily table when the customer enables both providers. Finance Unified is the monthly platform-finance layer for finance-team review. Null-not-zero is primarily a Finance Unified policy, while Daily App Sales remains an operational analytics layer with method-qualified estimates.

Policy vocabulary

Finance data needs clear language. These are the meanings Netice keeps separate.

Finance Unified is the primary null-not-zero layer

Finance Unified uses source_kind = 'FINANCE' and is built for monthly platform finance output. It is separate from Daily App Sales. Its finance fields include native values, report-currency values, FX rate, event type, source report, finance period, and lineage context.

In Finance Unified, nullable finance amount fields remain nullable. Examples include native_net_proceeds, native_customer_charge, report_net_proceeds, report_customer_charge, and fx_rate. A null in one of these fields is interpreted through the source report, event type, and quality context, not blindly treated as zero.

Daily App Sales can unify Apple and Google, but it is not finance close

Daily App Sales is the operational analytics layer. When a customer enables both Apple App Store and Google Play, Netice can place both providers into one clean daily app-sales output such as app_sales_daily or APP_SALES_DAILY, depending on the destination. The table keeps provider and report-family context visible through fields such as source, platform, source_kind, and source_report.

That unified daily table is useful for analytics: daily trends, product/SKU reporting, country reporting, lifecycle filtering, and report-currency reporting. It is still not monthly finance truth. Monthly platform finance belongs in Finance Unified, using Apple financeReports and Google Play Earnings where configured.

Apple financeReports examples

Apple financeReports and Apple Summary Sales are different report families. In Finance Unified, Apple finance rows preserve what the Apple finance source supports. Netice does not fabricate separate Apple platform-fee or tax events when Apple does not disclose those components as separate finance facts.

This is a classic null-not-zero situation. If Apple does not itemize a separate tax or platform-fee row, the safe answer is not “tax is zero” or “fee is zero.” The answer is that the component is not disclosed as a separate finance fact in that source context.

Google Play Earnings examples

Google Play Earnings can preserve ledger-style rows such as sale, refund, platform fee, tax, and adjustment rows where the source provides them. That does not mean every finance row is a customer-charge row.

For example, a Google platform-fee row can have native_net_proceeds but a null native_customer_charge. That null is correct because the row is a fee ledger event, not a customer sale. The same logic applies to tax rows. Null customer charge does not mean the customer paid zero for a sale; it means this row is not a customer-charge event.

Missing provider reports are not zero-revenue months

A provider report can be missing, unavailable, delayed, not generated, blocked by permissions, or outside the selected configuration. Netice surfaces that as a provider availability or configuration condition, not as a zero-revenue finance month.

This is especially important for finance review. If an expected Google Play Earnings report is unavailable, writing a zero row would make the output look complete when it is not. Netice preserves the missing-report status and avoids inventing finance facts.

FX gaps: missing conversion is not rate 1

Report currency is a presentation layer. Native values remain native. If native and report currency are the same, finance FX can use 1. But if native and report currency differ and the conversion rate is not available, report-currency fields stay null or are surfaced as a quality issue.

Missing cross-currency FX does not silently become 1. It does not become zero. A missing FX rate means the converted report-currency value is unknown.

SQL patterns that preserve nulls

SQL can accidentally destroy null semantics. The most common mistake is to use COALESCE(field, 0) in finance transformations without preserving a parallel null-coverage measure. That can be acceptable for a display-only chart in some contexts, but it does not replace finance-null storage or finance review logic.

Better coverage query

SELECT
  fiscal_period,
  source_report,
  COUNT(*) AS rows_total,
  COUNTIF(report_net_proceeds IS NULL) AS rows_missing_report_net_proceeds,
  COUNTIF(report_net_proceeds = 0) AS rows_known_zero_report_net_proceeds
FROM `example_project.example_dataset.finance_unified`
GROUP BY fiscal_period, source_report
ORDER BY fiscal_period, source_report;

Unsafe finance-close pattern

-- This hides unknown finance values unless null coverage is preserved elsewhere.
SELECT
  fiscal_period,
  SUM(COALESCE(report_net_proceeds, 0)) AS chart_value
FROM `example_project.example_dataset.finance_unified`
GROUP BY fiscal_period;

Safer presentation query

SELECT
  fiscal_period,
  SUM(report_net_proceeds) AS report_net_proceeds_known,
  COUNTIF(report_net_proceeds IS NULL) AS missing_report_net_proceeds_rows,
  COUNTIF(report_net_proceeds = 0) AS known_zero_report_net_proceeds_rows
FROM `example_project.example_dataset.finance_unified`
GROUP BY fiscal_period
ORDER BY fiscal_period;

These queries use synthetic table names. They are not accounting-close instructions and not bank-reconciliation proof.

Security and secret handling

Null-not-zero is a data-meaning policy, not a credential visibility mechanism. Netice encrypts customer secret material and handles source and destination credentials through secret management. Saved connection values are not shown back as raw credentials after saving.

The examples below remain synthetic. They exclude real Apple vendor numbers, Google Play report bucket IDs, app IDs, package names, product IDs, Snowflake accounts, BigQuery projects, GCS/S3 paths, source row hashes, task IDs, run IDs, logs, private keys, service-account JSON, secret references, and customer revenue amounts.

Safe synthetic examples

The examples below use fake values only. They show policy shape, not real provider rows or customer output.

Apple finance row with no fabricated fee or tax row

platform,source,source_kind,source_report,event_type,event_subtype,commission_disclosed,quantity,native_currency,native_net_proceeds,native_customer_charge,report_currency,report_net_proceeds,report_customer_charge,fx_rate,source_row_hash
IOS,APPLE_APP_STORE,FINANCE,APPLE_FINANCE_DETAIL,SALE,,false,1,EUR,6.990000,9.990000,EUR,6.990000,9.990000,1,synthetic_hash_apple_finance_001

Google fee row with null customer charge

platform,source,source_kind,source_report,event_type,event_subtype,commission_disclosed,quantity,native_currency,native_net_proceeds,native_customer_charge,report_currency,report_net_proceeds,report_customer_charge,fx_rate,source_row_hash
ANDROID,GOOGLE_PLAY,FINANCE,GOOGLE_PLAY_EARNINGS,PLATFORM_FEE,COMMISSION,true,,EUR,-1.500000,,EUR,-1.500000,,1,synthetic_hash_google_fee_001

Missing cross-currency FX example

platform,source,source_kind,source_report,event_type,native_currency,native_net_proceeds,native_customer_charge,report_currency,report_net_proceeds,report_customer_charge,fx_rate,source_row_hash
IOS,APPLE_APP_STORE,FINANCE,APPLE_FINANCE_DETAIL,SALE,USD,6.990000,9.990000,EUR,,,,synthetic_hash_missing_fx_001

Blank cells in these examples represent null. They do not mean zero. The hashes and amounts are synthetic.