Google Play revenue to Snowflake

What Google Play revenue to Snowflake means in Netice

In Netice, Google Play revenue to Snowflake means loading Google Play daily app-sales analytics into a customer-owned Snowflake table. The workflow belongs to Daily App Sales, using the source mode google_apple_app_sales with Google Play selected as the provider.

Google Play can be used by itself, or combined with Apple App Store if the customer wants one clean daily revenue table across both major app stores. In a combined setup, Apple and Google Play rows share the same Daily App Sales table, while fields such as source, platform, source_kind and source_report keep the providers and report families distinct.

The resulting Snowflake output is not a raw Google Play report archive and not the monthly Google Play Earnings finance report. It is the managed daily app-sales table APP_SALES_DAILY, with fields for revenue date, platform, source report, product identifiers, report currency, native values, method fields, data completeness and source lineage.

Google Play by itself, or unified with Apple App Store

A Google Play Snowflake task can be configured for Android-only daily analytics. That is useful when the customer only needs Google Play revenue. But the larger Netice model is cross-platform: when Apple App Store is enabled too, both providers can feed the same Daily App Sales output so the customer gets one clean table for app-store revenue analytics.

The table is unified, but not vague. Apple rows keep Apple source labels, Google Play rows keep Google source labels, and lifecycle rows can be separated from money-impacting rows. That is the difference between a useful unified table and a dangerous blended “revenue” dump.

Google Play source mode and provider selection

The Netice source mode for Daily App Sales is google_apple_app_sales. Google Play can be selected without Apple where only Android daily app-sales output is needed. Apple App Store can be added when the customer wants unified Apple + Google Play daily revenue analytics.

For a Google-focused Snowflake article, the important source labels are Android-specific. Google Play daily revenue rows use source = 'GOOGLE_PLAY', platform = 'ANDROID', source_kind = 'SALES', and source_report = 'GP_ESTIMATED_SALES'. Google Play subscription lifecycle rows can use source_report = 'GP_SUBSCRIPTIONS'.

The APP_SALES_DAILY Snowflake table

The default Snowflake table for daily Google Play app-sales output is APP_SALES_DAILY. It is a managed enriched analytics table, not a raw provider file dump. In public examples, use synthetic fully qualified names such as EXAMPLE_DATABASE.EXAMPLE_SCHEMA.APP_SALES_DAILY.

The table carries the Daily App Sales field groups. It includes source identity, report currency, native/local values, method fields, lifecycle flags, data completeness and provenance. Daily rows use source-readiness context, not a public daily is_final accounting-finality field.

Report currency, native values and method fields

Google Play daily Snowflake rows include both report-currency analytics fields and native/source currency context. report_currency is the configured reporting currency for the task. Native/local fields preserve source context where available. FX fields and method fields explain how daily analytical values were derived or converted.

Method fields are especially important for Google Play. Google Play Estimated Sales does not itemize the Google service fee as a monthly finance ledger row. Daily fee and net values can therefore be method-coded or estimated. Tax values are interpreted together with method context instead of treated as unexplained final finance facts.

Snowflake destination setup and secret handling

Google Play source access and Snowflake destination access are separate. Google Play access lets Netice read selected Play Console reporting inputs. Snowflake destination access lets Netice write the managed output table in the customer’s Snowflake environment. A valid Google Play source connection does not mean Snowflake can be written, and a valid Snowflake connection does not mean Google Play reports are accessible.

Snowflake destination setup is designed around key-pair access for these app revenue workflows. Snowflake private-key material, passphrases and destination credential material are encrypted and handled through Netice secret management. Saved Snowflake destination connections reduce repeated setup, but they are not credential viewers and they remain separate from Google Play source access.

Public examples use synthetic Snowflake identifiers. Real account names, users, roles, warehouses, database/schema/table names, private keys, passphrases, stage paths, query IDs, logs, task IDs, saved connection IDs and customer identifiers remain private.

Staged loads and scoped refresh behavior

Netice is not a blind append-only dump. The customer-facing model is a managed Snowflake table that can be refreshed for selected windows and source scopes. Candidate rows can be staged, checked and then used to update the managed table.

This matters because Google Play data can arrive or change after an initial run. Reruns and recurring refreshes update selected windows without turning every run into a duplicate append or a destructive full-table rewrite.

Backfills, reruns and Google Play provider-late data

Daily app-sales pipelines need refresh behavior because recent Google Play data may not be fully stable the first time it is fetched. Netice supports recurring refresh behavior for recent completed windows, plus explicit backfills and reruns within supported source availability.

It is also important to keep failure categories separate. A Google Play provider-late condition is different from a Google Play source permission failure. Both are different from a Snowflake write permission failure. Clear operational messaging keeps those categories distinct.

Google Play Earnings and raw reports stay separate

A Google Play Snowflake destination page can mention Finance Unified and raw reports while keeping them out of the daily table.

Google Play Earnings belongs to Finance Unified. It uses monthly finance semantics and a finance source report such as GOOGLE_PLAY_EARNINGS. It belongs outside APP_SALES_DAILY.

Raw Google Play reports use a separate source mode. Raw reports preserve provider-native files rather than applying the Daily App Sales schema, report currency, FX conversion or method fields. Raw reports are separate from the daily Snowflake analytics table.

Safe synthetic examples

The examples below are synthetic. They are designed to show safe shape and interpretation only. Real Snowflake identifiers, Google Play report bucket IDs, package names, source paths, row hashes, task IDs, logs, credentials and customer values remain private.

Safe Snowflake target

Account: EXAMPLE_ACCOUNT
Warehouse: EXAMPLE_WAREHOUSE
Database: EXAMPLE_DATABASE
Schema: EXAMPLE_SCHEMA
Daily table: APP_SALES_DAILY
Fully qualified table: EXAMPLE_DATABASE.EXAMPLE_SCHEMA.APP_SALES_DAILY
Stage: NETICE_STAGE
Source provider: Google Play
Optional second provider: Apple App Store
Report currency: EUR

Google-only daily Snowflake query

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

Unified Apple + Google daily Snowflake query

SELECT
  revenue_date,
  source,
  platform,
  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 source_kind = 'SALES'
  AND event_has_revenue = TRUE
  AND revenue_date BETWEEN DATE '2026-02-01' AND DATE '2026-02-29'
GROUP BY revenue_date, source, platform, source_report, report_currency
ORDER BY revenue_date, source, platform, source_report;

Subscription lifecycle rows

SELECT
  revenue_date,
  transaction_type,
  COUNT(*) AS lifecycle_events
FROM EXAMPLE_DATABASE.EXAMPLE_SCHEMA.APP_SALES_DAILY
WHERE source = 'GOOGLE_PLAY'
  AND source_report = 'GP_SUBSCRIPTIONS'
  AND event_has_revenue = FALSE
GROUP BY revenue_date, transaction_type
ORDER BY revenue_date, transaction_type;

These queries are for daily analytics. They are not Google Play Earnings queries, finance-close queries, payout reconciliation queries or internal Netice merge SQL.