Raw reports guide for app revenue

What raw reports are

Raw reports are provider-native report artifacts copied from Apple App Store or Google Play reporting systems into customer-owned storage where the selected raw workflow is enabled. The goal is to preserve the original provider report family and file shape, not to convert the data into Netice’s daily app-sales schema or monthly finance schema.

Google Play raw reports use google_play_raw_reports. Apple App Store raw reports use apple_app_store_raw_reports. They are provider-specific workflows because Apple and Google raw files do not share one universal source schema.

Raw mode is useful for source retention, future reprocessing, provider-format investigation, source custody, and support review. It is not the right mode when the goal is one query-ready daily revenue table or one normalized monthly finance table.

Raw Reports vs Daily App Sales vs Finance Unified

Netice separates app revenue into three output families because app-store reporting has two main normalized revenue needs and one source-custody need. Daily App Sales is the cross-platform analytics layer. Finance Unified is the monthly platform-finance layer. Raw Reports are source-native files.

A raw Google Play Earnings file is not the same thing as normalized Finance Unified Google Play Earnings rows. A raw Apple financeReports file is not automatically a Finance Unified row. A raw Apple Summary Sales file is not automatically the Daily App Sales schema.

When to use raw mode

Raw mode is the right choice when your team needs custody of the provider’s source artifacts. It is especially useful when downstream systems need the original report family, when a data team wants to reprocess source-native files later, or when support/debugging needs a safe way to know which report families were requested, delivered, pending or unavailable.

Raw source keys and provider-specific tasks

Netice raw reports are intentionally provider-specific. This prevents a common modeling mistake: treating raw Apple and Google reports as if they were one merged dataset with one stable schema.

Recommended bundle vs custom report families

Raw report selection can start from a recommended bundle or from selected/custom report families. The recommended bundle is the safer starting point because it focuses on supported provider families without implying that every possible provider report is available.

Custom selection is for teams that know exactly which provider-native family they need. Some families can be advanced, setup-required, disabled, unsupported, or unavailable for a given provider account. Netice keeps that visible so raw mode does not become a vague promise of “all reports forever.”

Google Play raw report families

Google Play raw reports preserve provider-native Play Console reporting artifacts where enabled. A Google raw bundle can include common Play report families such as estimated sales, Earnings, reviews, installs, crashes, ratings and subscription statistics. These families remain raw provider reports; they are not automatically transformed into a unified Netice schema.

Google API-style resources such as Android Vitals API endpoints, voided purchases API resources, review-reply APIs and other unrelated developer APIs stay outside raw report output unless Netice explicitly supports them in the customer-facing raw workflow.

Apple App Store raw report families

Apple App Store raw reports preserve App Store Connect source artifacts where enabled. The Apple raw workflow centers on Sales and Trends / subscription-style source families, while finance and customer-review raw families can require additional setup.

Apple Sales and Trends and Apple financeReports must remain separate. A raw Apple Summary Sales file is not an Apple financeReports file. A raw Apple financeReports file remains a source-native artifact unless a separate Finance Unified workflow normalizes it.

Provider-native boundary

Raw mode keeps source meaning visible by preserving provider separation, report family identity, period/status context and safe output metadata. It intentionally avoids creating a false “universal raw schema” that would hide Apple and Google differences.

Object destinations and warehouse boundary

The natural customer-facing destinations for raw reports are Google Cloud Storage and AWS S3. Raw mode is primarily about source-native file custody, so object storage is the clearest fit.

BigQuery and Snowflake are the primary destinations for normalized daily and finance tables, not the standard raw-report story. Raw warehouse loading is workflow-specific and belongs only in customer-facing copy when explicitly enabled for that workflow.

Object path and file behavior

Raw object outputs are designed to be stable and readable under the configured destination root. Netice can write provider/family-style files and a manifest under the same root so teams can see what was delivered without exposing source credentials or private provider paths.

The examples below are synthetic. They use generic file names and destinations to explain the shape of the output. Actual family names and file formats can vary by provider, workflow and selected report family.

Synthetic GCS example

gs://example_bucket/app-revenue/raw/
gs://example_bucket/app-revenue/raw/google_play_estimated_sales.csv.gz
gs://example_bucket/app-revenue/raw/apple_app_store_summary_sales_daily.txt.gz
gs://example_bucket/app-revenue/raw/netice_raw_manifest.json

Synthetic S3 example

s3://example_bucket/app-revenue/raw/
s3://example_bucket/app-revenue/raw/google_play_earnings.csv.gz
s3://example_bucket/app-revenue/raw/apple_app_store_subscription_daily.txt.gz
s3://example_bucket/app-revenue/raw/netice_raw_manifest.json

Manifest and safe status metadata

Raw report manifests and status summaries describe sync outcomes without exposing raw report contents. Safe status metadata can include provider, report family, period, status, requested/delivered/pending ranges, file counts, source file counts, reason categories and customer-action flags.

Synthetic manifest row shape

{
  "report_id": "estimated_sales",
  "provider": "google_play",
  "report_family": "revenue_sales",
  "period": "2026-04",
  "status": "synced_changed",
  "requested_range": {"start": "2026-04", "end": "2026-04"},
  "delivered_range": {"start": "2026-04", "end": "2026-04"},
  "files_written": 1,
  "source_file_count": 1,
  "safe_reason_code": "SYNTHETIC_RAW_SYNC_OK",
  "customer_action_required": false
}

This JSON is a synthetic documentation fragment for explaining manifest meaning. It is not a customer record, source API response or operational log.

Security, encrypted secrets and redaction boundaries

Raw report workflows involve sensitive source access and destination access. Netice encrypts customer secret material and handles credentials through secret management. Saved connections are designed to reduce repeated credential entry while keeping raw credential values write-only after saving.

Examples and user-facing summaries can describe credential categories, destination type, provider family, status and safe metadata while excluding service-account JSON, private keys, App Store Connect key material, issuer IDs, key IDs, vendor numbers, app resource IDs, report bucket IDs, saved connection identifiers, secret references, task IDs, run IDs, logs, source rows and customer-specific object paths.

Backfill, refresh and provider availability

Raw reports can be requested for historical windows and refreshed for recent eligible provider periods. The exact model differs by provider and report family. Google Play raw history is often month-oriented. Apple raw history can combine daily report windows and monthly report windows depending on the selected family.

Provider availability is not the same thing as customer failure. A report can be pending, not generated yet, outside the selected period, unavailable to the provider account, blocked by source permissions, or blocked by destination write permissions. Netice keeps those cases as safe status categories instead of turning them into raw error dumps.

Failure states and diagnostics

A raw reports guide helps users interpret status without leaking sensitive details. The most useful distinction is between provider availability, source access, setup requirements and destination write behavior.

Safe source selection examples

The examples below are synthetic and simplified. They show safe configuration shapes without real provider identifiers, destination paths or task metadata.

Google Play raw source example

source_key: google_play_raw_reports
selection_mode: recommended_bundle
included_family_examples: estimated_sales, earnings, reviews, stats_installs
destination: google_cloud_storage
destination_root: gs://example_bucket/app-revenue/raw/

Apple raw source example

source_key: apple_app_store_raw_reports
selection_mode: selected_report_families
selected_family_examples: summary_sales_daily, subscription_event_daily
destination: aws_s3
destination_root: s3://example_bucket/app-revenue/raw/

Decision checklist

Need source-native files? Use raw provider-specific tasks.
Need one daily analytics table? Use Daily App Sales, not raw mode.
Need Apple and Google revenue in one clean daily table? Enable both providers in Daily App Sales.
Need monthly finance rows? Use Finance Unified, not raw mode.
Need both Apple and Google raw files? Create separate provider-specific raw tasks.
Need raw warehouse output? Confirm the workflow explicitly before treating it as available.