App revenue to Snowflake

What Netice sends to Snowflake

Netice app revenue workflows can write managed Snowflake outputs for app-store reporting. Daily App Sales uses the default Snowflake table APP_SALES_DAILY. Finance Unified, when enabled for a workspace or task, uses a separate default Snowflake table named FINANCE_UNIFIED.

Those two tables should not be merged mentally. Daily App Sales is for operational daily app revenue analytics. It uses Apple App Store Sales and Trends / Summary Sales style reporting and Google Play Estimated Sales style reporting. Finance Unified is the monthly platform finance layer for Apple financeReports and Google Play Earnings where configured. Raw reports are a third category: provider-native file custody, not the managed daily or finance Snowflake table.

Daily App Sales table: APP_SALES_DAILY

The main Snowflake table for daily app-sales analytics is APP_SALES_DAILY. It is produced by the google_apple_app_sales workflow and uses the current daily app-sales field contract. Apple and Google rows can coexist in the same daily table, but the table keeps source fields visible so downstream users can tell which provider and report family produced each row.

That source context matters. Apple daily rows are based on Sales and Trends / Summary Sales style reporting, not Apple financeReports. Google daily rows are based on Estimated Sales and subscription reporting, not Google Play Earnings. The daily table uses source_kind = 'SALES', not FINANCE.

Finance Unified table: FINANCE_UNIFIED

Finance Unified is a separate Snowflake output for monthly platform finance data where configured. Its default Snowflake table is FINANCE_UNIFIED. It is not a daily app-sales table and it should not be used as a replacement for daily product analytics.

Finance Unified uses monthly finance report families: Apple App Store Connect financeReports and Google Play monthly Earnings. Those are different from Apple Summary Sales and Google Play Estimated Sales. The finance table uses source_kind = 'FINANCE', period fields such as fiscal_period, native/report-currency finance fields, event types, and derived finance-finality context.

Use Finance Unified when it is enabled for the relevant workspace and task. Keep it separate from Daily App Sales, and do not treat it as a general ledger, audit opinion, bank reconciliation product, or accounting-close system.

Snowflake destination setup

Snowflake destination access is separate from Apple or Google source access. Apple App Store Connect access lets Netice read Apple reporting inputs. Google Play access lets Netice read selected Play Console reporting inputs. Snowflake destination access lets Netice write managed output tables to a customer-owned Snowflake target.

Netice uses key-pair authentication as the preferred Snowflake setup path for app revenue workflows. Snowflake setup includes account, user, warehouse, database, schema, table, role, and stage context. Customer Snowflake credential material is encrypted and handled through Netice secret management, and saved connection summaries do not display raw private keys or passphrases. High-privilege administrative roles should not be used; Snowflake destination access should follow least-privilege principles.

Customer-facing examples use synthetic values rather than real Snowflake accounts, users, roles, warehouses, databases, schemas, tables, stages, private keys, passphrases, query IDs, task IDs, logs, or customer identifiers.

Credential encryption and secret management

Snowflake private-key material, passphrases and destination credentials are sensitive customer secret material. Netice encrypts customer secrets and handles credential material through secret management instead of storing raw credentials in task text, article examples, support snippets or browser-visible summaries.

Saved Snowflake connections reduce repeated setup, but they are not a credential viewer. After saving, the interface shows safe status and connection metadata, not raw private keys, passphrases, secret references, internal credential IDs, task IDs, query IDs or logs.

How Netice refreshes Snowflake tables

The customer-facing model is a stable managed table, not a new public table on every run. For Daily App Sales, Netice keeps the selected APP_SALES_DAILY table current. For Finance Unified, Netice keeps a separate finance table current where that workflow is configured.

The Snowflake daily write path is designed around managed loading and scoped refresh behavior for selected windows. Candidate rows can be checked before the managed table is updated. Replacement is scoped by the relevant reporting window and source context rather than being an unbounded table wipe.

Backfills, reruns, and provider-late data

App stores can publish or update recent data after the first time a date is processed. That is why Snowflake output should support first runs, backfills, recurring refreshes, and reruns of selected windows. Daily app-sales workflows refresh recent completed days. Finance output follows finance periods rather than daily revenue dates.

Provider-late data is not automatically a destination failure. A Google Play report can be late or unavailable while Snowflake destination access is valid. A Snowflake write failure can happen while Apple or Google source access is valid. A good Snowflake article must keep those failure classes separate.

Raw reports and Snowflake

Raw reports are intentionally separate from this managed Snowflake destination story. Raw Google Play and Apple App Store reports preserve provider-native files and columns. They do not apply the daily app-sales schema, report currency, method fields, or FX conversion.

Raw reports are normally treated as provider-native object-storage artifacts rather than rows in the managed Snowflake daily or finance tables. Plan raw report custody around GCS or S3 unless a specific raw warehouse workflow has been enabled. Do not describe raw reports as automatically loading into APP_SALES_DAILY or FINANCE_UNIFIED.

Safe synthetic examples

The examples below are synthetic. They show how a Snowflake customer might query Netice-managed outputs without exposing real Snowflake account names, app IDs, SKUs, row hashes, task IDs, logs, credentials, or customer data.

Daily App Sales Snowflake target

Account: EXAMPLE_ACCOUNT
Warehouse: EXAMPLE_WAREHOUSE
Database: EXAMPLE_DATABASE
Schema: EXAMPLE_SCHEMA
Table: APP_SALES_DAILY
Stage: NETICE_STAGE

Finance Unified Snowflake target

Account: EXAMPLE_ACCOUNT
Warehouse: EXAMPLE_WAREHOUSE
Database: EXAMPLE_DATABASE
Schema: EXAMPLE_SCHEMA
Table: FINANCE_UNIFIED
Stage: NETICE_STAGE

Daily App Sales query

SELECT
  revenue_date,
  platform,
  source,
  source_report,
  report_currency,
  SUM(estimated_net) AS estimated_net_report_currency,
  SUM(units) AS units
FROM EXAMPLE_DATABASE.EXAMPLE_SCHEMA.APP_SALES_DAILY
WHERE revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-29'
  AND source_kind = 'SALES'
  AND event_has_revenue = TRUE
GROUP BY revenue_date, platform, source, source_report, report_currency
ORDER BY revenue_date, platform, source_report;

Finance Unified query where configured

SELECT
  fiscal_period,
  platform,
  source,
  source_report,
  report_currency,
  SUM(report_net_proceeds) AS report_net_proceeds
FROM EXAMPLE_DATABASE.EXAMPLE_SCHEMA.FINANCE_UNIFIED
WHERE source_kind = 'FINANCE'
  AND fiscal_period BETWEEN DATE '2026-02-01' AND DATE '2026-04-01'
GROUP BY fiscal_period, platform, source, source_report, report_currency
ORDER BY fiscal_period, platform, source_report;

The first query is daily operational analytics. The second query is monthly finance-period analysis where Finance Unified is configured. Neither query is payout reconciliation, audit evidence, tax advice, or accounting close.