Netice app revenue data infrastructure
Google Play reporting access setup for app revenue pipelines
Google Play reporting access is the source side of a Netice app revenue pipeline. It lets Netice read selected Google Play reporting inputs such as daily Estimated Sales, monthly Earnings, or provider-native raw reports. It is not the same as BigQuery, GCS, S3, or Snowflake destination access.
What Google Play source access means in Netice
Google Play source access controls what Netice can read from Google Play reporting. It is the permission and credential side of the source. It is separate from where Netice writes the output. A working Google Play source connection does not automatically write to BigQuery, Google Cloud Storage, AWS S3, or Snowflake.
This matters because Netice supports multiple Google Play-related app revenue workflows. Daily App Sales uses Google Play Estimated Sales and subscription lifecycle reporting. Finance Unified uses monthly Google Play Earnings where configured. Raw Reports preserve provider-native Google Play report artifacts. Each workflow has different semantics, output shapes, and failure modes.
A good Google Play setup page should therefore answer three questions: which Google Play report family is being read, which destination will receive the output, and whether the saved or new access record has the right permissions for the selected task.
| Google Play source context | Netice source mode | Report family | Common output family |
|---|---|---|---|
| Daily App Sales | google_apple_app_sales |
Google Play Estimated Sales and subscription lifecycle rows | Daily enriched analytics, such as app_sales_daily or equivalent destination output. |
| Finance Unified | finance_unified |
Google Play monthly Earnings | Monthly platform finance output, such as finance_unified where configured. |
| Raw Reports | google_play_raw_reports |
Provider-native raw Google Play report families | Raw report files and status output, with object storage as the primary customer-facing raw-report destination. |
The non-negotiable boundary: source access is not destination access
Google Play source access lets Netice read selected Google Play reports. It does not grant permission to write to BigQuery, GCS, S3, or Snowflake. Destination access must be configured separately.
This is especially important for managed or recommended Google Play source access. Managed Google Play source access is source-only and cannot be reused as a GCP destination credential. If a task writes to BigQuery or GCS, the destination side still needs its own verified destination access.
Daily Estimated Sales vs monthly Earnings vs raw reports
Google Play reporting access is not one universal switch that proves every report family is available. Daily analytics, monthly finance, and raw report custody are separate use cases.
Daily App Sales uses Google Play Estimated Sales and subscription lifecycle rows where available. In the daily enriched output, Google Play daily sales rows can be labeled with source = 'GOOGLE_PLAY', platform = 'ANDROID', source_kind = 'SALES', and source_report = 'GP_ESTIMATED_SALES'. Subscription lifecycle rows can use source_report = 'GP_SUBSCRIPTIONS'.
Finance Unified uses Google Play monthly Earnings, not Estimated Sales. Raw Reports use a separate provider-native raw mode and preserve raw report families without applying the daily app-sales schema, report currency, or FX conversion.
| Question | Daily App Sales | Finance Unified | Raw Reports |
|---|---|---|---|
| Primary source family | Estimated Sales | Google Play Earnings | Provider-native selected report families |
| Source mode | google_apple_app_sales |
finance_unified |
google_play_raw_reports |
| Source kind | SALES |
FINANCE |
Raw/provider-native |
| Wrong assumption | Estimated Sales proves Earnings access. | Earnings feeds app_sales_daily. |
Raw reports are automatically normalized. |
Saved Google Play access
Netice can use saved Google Play source access so recurring app revenue tasks should not require the user to re-enter source setup every time. The saved connection concept is useful, but it must be described carefully. Saved connections are workspace-scoped access records. Credential values are write-only after saving and should not be shown back to the browser as raw secrets.
A saved Google Play connection can make task setup cleaner, but it does not remove the need for correct provider permissions, report availability, report bucket context, finance-report visibility, or destination access. A saved source connection can still fail if the selected report family is unavailable or if the task target requires destination credentials that have not been configured.
| Saved connection behavior | Customer-facing explanation | Boundary |
|---|---|---|
| Reusable source access | Saved Google Play access can be selected for recurring tasks. | Report-family permissions and availability still matter. |
| Workspace scope | Saved access belongs to the relevant workspace/client context. | Saved connections stay scoped to the relevant workspace context. |
| Write-only credentials | Credential values are not shown back after saving. | Credential material is encrypted, handled through secret management, and not shown back in the product. |
| Safe summaries | Connection cards can show safe metadata and status. | Connection summaries show safe metadata, not raw credential material or internal references. |
| Delete behavior | Delete can be blocked while tasks still reference the connection. | Provider-side access must be revoked in the provider console where applicable. |
Recommended managed setup and advanced fallback
Netice can support a managed or recommended Google Play source access path for eligible workspaces. An advanced fallback path can also use customer-provided Google Play credentials. In both cases, sensitive credential material is encrypted and handled through Netice secret management rather than stored as visible task fields.
Managed Google Play source access is source-only. It cannot be used as a GCP destination credential. If the customer wants to write Google Play revenue into BigQuery or GCS, the destination side must still have its own GCP destination access and any task-specific target verification required by the workflow.
| Setup path | Use | Boundary |
|---|---|---|
| Managed/recommended Google Play source access | Reduces customer credential handling for eligible workspaces. | Source-only; not destination write access. |
| Saved Google Play access | Lets users reuse source access for recurring tasks. | Still depends on report family permissions and provider availability. |
| Advanced uploaded credential fallback | Customer-provided source credential path where needed. | Credential examples stay out of customer-facing docs and UI summaries. |
| Destination connection | BigQuery, GCS, S3, or Snowflake write access. | Separate from Google Play source access. |
Reports bucket and pubsite context
Google Play reporting often involves a private Play Console reporting bucket context. In raw report workflows, Google Play reports bucket values are private source-side identifiers. Customer-facing setup guidance can describe the expected reporting-bucket concept, but examples should use synthetic values rather than real bucket IDs, pubsite IDs, service-account emails or source object paths.
The reports bucket is a source-side concept. It is not the same as a customer-owned destination bucket. For example, a Google Play raw source bucket and an AWS S3 destination bucket are different things with different permissions and different failure modes.
| Concept | Customer-facing explanation | Keep out of public examples |
|---|---|---|
| Google Play reports bucket | Private Play Console reporting source bucket. | Real pubsite_prod_rev... values. |
| Package filter | Use synthetic package names in examples. | Real package names or app IDs. |
| Destination bucket | Customer-owned target such as GCS or S3. | Descriptions that blur the source bucket and destination bucket. |
| Object paths | Use generic synthetic paths only. | Source file names, signed URLs or provider object names. |
Safe synthetic source/destination distinction
Google Play source reports bucket: pubsite_prod_rev_SYNTHETIC
Package filter: com.example.app
Raw destination example: s3://example_bucket/app-revenue/raw/google-play/The values above are synthetic. They should never be replaced with real customer identifiers in .
Source access vs destination access
The fastest way to create setup confusion is to treat source access and destination access as the same credential. Netice should explain them separately in every setup page.
| Access type | What it authorizes | What it does not authorize |
|---|---|---|
| Google Play source access | Reading selected Google Play reporting inputs. | Writing to BigQuery, GCS, S3, or Snowflake. |
| BigQuery / GCS destination access | Writing output to customer-owned Google Cloud targets. | Reading Google Play reports. |
| AWS S3 destination access | Writing files or raw reports to a customer-owned S3 bucket. | Reading Google Play reports. |
| Snowflake destination access | Writing managed warehouse output to Snowflake. | Reading Google Play reports. |
Advanced credential reuse should also be described carefully. Netice allows conditional reuse paths only where credentials have the relevant permissions and target verification passes. The practical setup rule is that source access and destination access are separate setup areas.
Common failure states
Google Play setup failures should be diagnosed by category. A provider-not-ready report is different from a permission failure. A destination write failure is different from a source read failure. A saved connection tenant mismatch is different from an invalid reports bucket value.
| Failure category | Likely meaning | Keep out of public examples |
|---|---|---|
| Missing Google Play source access | The task cannot read the selected Google Play source. | Credential values, saved connection IDs, secret IDs. |
| Missing destination access | The task cannot write to BigQuery, GCS, S3, or Snowflake. | Real project, bucket, table, stage or account names. |
| Managed source reused as destination | Managed Google Play source access is source-only. | Internal connection IDs or task IDs. |
| Invalid raw reports bucket | The Google Play reports bucket value is not a valid source bucket identifier. | Real bucket IDs or source object paths. |
| Provider not ready | The selected report family or period is not available yet. | Raw provider response bodies or logs. |
| Saved connection delete blocked | Tasks still reference the connection. | Task IDs or customer workflow identifiers. |
Security, encryption and redaction boundaries
A setup guide should make the user more confident without turning into a credential or identifier viewer. Netice encrypts customer secret material and handles it through secret management. The product can show safe connection metadata, status and setup guidance while keeping service-account JSON, private keys, service-account emails, report bucket IDs, package names, task IDs, logs, internal secret-management references and source rows out of public content and user-facing summaries.
| Useful to explain | Keep out of public content and summaries |
|---|---|
| Source access category | Service-account JSON or private keys |
| Saved connection concept | Saved connection IDs or secret IDs |
| Safe status/reason categories | Raw logs, stack traces, report rows or provider responses |
| Synthetic bucket/package examples | Real report bucket IDs or real package names |
| Source-vs-destination distinction | Customer project, bucket, table, Snowflake account or S3 target names |
Safe synthetic setup examples
The examples below are deliberately synthetic. They show setup shape only. They are not credentials, not provider screenshots, not source report paths, and not customer configurations. They also should not show how secrets are stored internally.
Daily Google Play analytics to BigQuery
Source mode: google_apple_app_sales
Selected provider: Google Play
Google Play access: saved connection named example_google_play_reporting
Destination access: saved connection named example_bigquery_app_revenue
Output target: example_project.example_dataset.app_sales_daily
Report currency: EURRaw Google Play reports to S3
Source mode: google_play_raw_reports
Google Play reports bucket: pubsite_prod_rev_SYNTHETIC
Package filter: com.example.app
Destination: s3://example_bucket/app-revenue/raw/google-play/Google Play Earnings to BigQuery
Source mode: finance_unified
Selected provider: Google Play Earnings
Destination: example_project.example_dataset.finance_unified
Reporting period: 2026-04None of these examples prove provider permissions, destination permissions, finance availability or production customer output. They are only safe patterns for explaining source and destination roles.
FAQ
What Google Play access does Netice need?
Netice needs Google Play source access for the selected report family: daily Estimated Sales, monthly Earnings, or provider-native raw reports. The exact setup depends on the selected workflow.
Is Google Play source access the same as BigQuery destination access?
No. Google Play source access lets Netice read Play reporting inputs. BigQuery destination access lets Netice write output to a customer-owned BigQuery table.
Can managed Google Play access write to BigQuery or GCS?
No. Managed Google Play source access is source-only and cannot be reused as a GCP destination credential.
What is the Google Play reports bucket?
It is a private Play Console reporting source bucket context. Use synthetic examples such as pubsite_prod_rev_SYNTHETIC when explaining this concept publicly.
Does Estimated Sales access prove Earnings access?
No. Estimated Sales and Earnings are different report families. Daily analytics access does not prove monthly finance-report access.
Can I save Google Play access for recurring tasks?
Yes, saved Google Play access can be used where configured. Saved access reduces repeated credential handling but does not remove provider permission, report availability or destination-access requirements.
Are saved Google Play credentials shown back after saving?
No. Google Play credential values are write-only after saving. Netice encrypts customer secret material and handles it through secret management; saved connection summaries show safe metadata, not raw credential material.
Does Netice encrypt Google Play credential material?
Yes. Customer secret material is encrypted and handled through Netice secret management. The setup interface and saved connection cards should show safe status and metadata, not raw service-account JSON, private keys or internal secret-management references.
What happens if I delete a saved Google Play connection?
Delete can be blocked while tasks still reference the connection. Deleting the Netice saved connection does not automatically revoke provider-side Google Play permissions.
Why can a report be missing even when credentials are valid?
A report can be provider-late, outside the selected period, not generated, unavailable for the selected account, or blocked by a report-family-specific permission. Missing does not automatically mean zero revenue.
How are raw Google Play reports different from daily enriched app sales?
Raw Google Play reports preserve provider-native files and should not apply the Daily App Sales schema, report currency, FX conversion or enriched method fields.
Set up Google Play source access without mixing up the destination
Netice helps app teams keep Google Play source access, saved connections, daily analytics, monthly Earnings, raw reports and customer-owned destinations clearly separated.
