Raw App Store and Google Play reports to S3 and GCS

What this raw report storage page covers

This page explains the storage-oriented use case: copying provider-native raw reports from Apple App Store Connect and Google Play into customer-owned S3 or GCS. The goal is source custody and reprocessing flexibility. The output is not a unified analytics table, not a finance schema, and not a merged Apple-plus-Google report.

Netice treats Apple and Google raw reports as separate source modes. Google Play raw reports use google_play_raw_reports. Apple App Store raw reports use apple_app_store_raw_reports. If you need both providers, you configure provider-specific raw tasks rather than expecting one raw task to merge both ecosystems into a single file.

Raw reports are most useful when your data team wants to preserve the provider’s original report shape for audit trails, future reprocessing, parser-drift investigation, or independent internal modeling. If you instead want a query-ready daily revenue table, use Daily App Sales. If you want monthly platform finance semantics, use Finance Unified where configured.

When to use raw S3 or GCS output

Use raw report storage when your first requirement is: keep the official source files or provider-native report artifacts available in our own storage account. This is different from asking Netice to produce one normalized table for BI.

Apple and Google raw sources are separate

Apple App Store Connect and Google Play expose different report families, file shapes, permissions and availability patterns. Netice therefore keeps the raw source modes provider-specific.

This separation helps prevent a common mistake: assuming that raw reports automatically become the same thing as enriched app-sales rows or finance rows. Raw reports remain provider-native artifacts unless a separate normalized workflow processes them.

Recommended report bundles

Raw report setup can use a recommended bundle or selected custom report families. The recommended bundle is the safer default because it avoids centering advanced, setup-required or unsupported report families.

A selected report family can still be unavailable for a provider account, not generated yet, missing for a period, blocked by permissions, or require additional provider-side setup. That is why raw report status should be interpreted by provider, report family and period.

S3 and GCS destination behavior

The public raw-report storage story should be centered on Google Cloud Storage and AWS S3. Current raw object destination evidence supports GCS and S3. Raw report warehouse loading may exist behind internal gates or future paths, but it should not be advertised as the public default for this buyer page.

Provider-native means no unified schema, currency conversion or FX

Raw reports and enriched outputs solve different problems. A raw Google Play report or raw App Store Connect report is useful because it preserves provider-native shape. That also means it should not be described as a clean unified schema, report-currency export, or FX-normalized analytics table.

First run, refresh and provider-late reports

Raw report tasks run in the background. A submit or setup action should not be described as synchronously fetching every provider report inside the browser request. The task queues or schedules work, checks provider availability, writes eligible artifacts and records safe status categories.

Provider report timing matters. A report can be unavailable because the provider has not generated it yet. That is different from missing source credentials or a destination write failure. A safe raw report article should distinguish provider not ready, source permission failure, destination write failure, setup required and unsupported report family.

Raw reports vs enriched daily sales vs Finance Unified

The safest way to explain Netice app revenue data is to keep the three output families separate. They can all be useful, but they answer different questions.

Safe setup checklist

Raw report setup has two sides: source access and destination access. Source access lets Netice read Apple or Google provider reports. Destination access lets Netice write to the customer-owned S3 or GCS location.

Safe synthetic examples

These examples are synthetic and simplified. They show the shape of raw report object storage without exposing real buckets, provider paths, task IDs, source files, credentials, app identifiers or customer data.

GCS raw report folder

gs://example_bucket/app-revenue/raw/

S3 raw report folder

s3://example_bucket/app-revenue/raw/

Synthetic raw object examples

gs://example_bucket/app-revenue/raw/google_play_estimated_sales.csv.gz
gs://example_bucket/app-revenue/raw/google_play_earnings.csv.gz
gs://example_bucket/app-revenue/raw/apple_app_store_summary_sales_daily.txt.gz
gs://example_bucket/app-revenue/raw/apple_app_store_subscription_event_daily.txt.gz

s3://example_bucket/app-revenue/raw/google_play_estimated_sales.csv.gz
s3://example_bucket/app-revenue/raw/apple_app_store_summary_sales_daily.txt.gz

Synthetic decision checklist

Need source-native official files? Use raw reports.
Need daily query-ready analytics? Use Daily App Sales.
Need monthly platform finance semantics? Use Finance Unified.
Need both Apple and Google raw files? Configure provider-specific raw tasks.
Need customer-owned object storage? Use GCS or S3 where enabled.

The object names above are category examples, not real provider source filenames and not guaranteed exact output names for every family. Do not replace them with real buckets, report object paths, task IDs, run IDs, app IDs, SKUs, source rows, source hashes, signed URLs or credentials.