Netice app revenue data infrastructure
App revenue export files to GCS and S3
Netice can deliver app revenue outputs as files in customer-owned Google Cloud Storage or AWS S3. The important detail is that “file output” is not one single thing: Daily App Sales, Raw Reports and Finance Unified each have different file semantics, refresh behavior and data boundaries.
What file outputs Netice can send to cloud storage
Netice app revenue workflows can produce customer-owned file outputs in Google Cloud Storage and AWS S3. These outputs help app teams keep platform-reported revenue data in their own storage layer, where downstream jobs, lakehouse tools, BI pipelines or internal analytics processes can read from it.
The key is to choose the right output family. A daily enriched app-sales file is different from a provider-native raw report archive. A monthly Finance Unified bundle is different from both. The destination may be the same bucket technology, but the meaning of the file is different.
| Output family | Source mode | Cloud-storage output | Best use |
|---|---|---|---|
| Daily enriched app sales | google_apple_app_sales |
Stable managed CSV such as app_sales_enriched_EUR.csv |
Daily operational app-sales analytics. |
| Raw provider-native reports | google_play_raw_reports, apple_app_store_raw_reports |
Provider-native report files under a configured GCS/S3 folder. | Source-native report custody and reprocessing. |
| Finance Unified | finance_unified |
Finance CSV bundle such as finance_unified_EUR.csv plus sidecars. |
Monthly platform finance review where configured. |
Why this page says GCS and S3, not Azure Blob
Current evidence supports GCS and S3 as the safe public cloud-storage destinations for this article. Azure Blob appears in older or generic code paths, but current app-revenue evidence does not verify Azure Blob as an active public app-revenue cloud-storage destination across the output families covered here.
For that reason, this page should be published as App revenue export files to GCS and S3. Azure Blob should not appear in the title, slug, meta description, examples or FAQ unless product evidence later verifies it for the specific app-revenue output families being advertised.
Daily enriched app sales files
Daily enriched app-sales files are for operational app revenue analytics. They are produced by the google_apple_app_sales workflow and can include Apple App Store and/or Google Play daily app-sales data depending on the configured providers.
In object storage, the current default managed filename pattern is app_sales_enriched_<REPORT_CURRENCY>.csv. A safe synthetic example is app_sales_enriched_EUR.csv. This is a stable managed output file: reruns and recurring refreshes should keep the same output current rather than creating arbitrary new public files every time.
| Daily file concept | Meaning | Boundary |
|---|---|---|
| Default file | app_sales_enriched_EUR.csv |
Synthetic example using report currency EUR. |
| Format | CSV for direct object-storage output. | Do not promise Parquet for this path. |
| Refresh behavior | Overlapping daily windows can refresh the same managed file. | Do not claim every rerun creates a new file. |
| Data meaning | Daily operational analytics. | Not payout, settlement or accounting close truth. |
Raw App Store and Google Play report files
Raw reports are different from daily enriched app-sales files. Raw report tasks preserve provider-native report artifacts. They do not apply a unified schema, report currency, currency normalization or FX conversion.
Google Play raw reports use google_play_raw_reports. Apple App Store raw reports use apple_app_store_raw_reports. These are provider-specific tasks. If a team needs both Apple and Google raw files, it should expect separate provider-specific raw workflows rather than one merged Apple-plus-Google raw file.
| Raw output concept | Meaning | Boundary |
|---|---|---|
| Provider-native | Files keep provider-specific shape where supported. | No unified Apple+Google schema. |
| No report currency | Raw files are not converted into the customer’s report currency. | No FX conversion or enriched amount fields. |
| Destination | GCS or S3 object storage. | Raw warehouse destinations are gated/not public-default in current evidence. |
| Status | Provider readiness, source permission and destination write state can be separate. | Provider-late data is not automatically customer error. |
Finance Unified object output
Finance Unified is the monthly platform finance output. It is separate from Daily App Sales and separate from raw provider-native files. In GCS or S3, Finance Unified uses a CSV-centered object bundle. The primary finance fact file can use a name such as finance_unified_EUR.csv, and related sidecars can use the same stem.
Finance object output can include sidecar artifacts such as a manifest, schema, period status, materialized summary files, SQL view definitions and README content. The manifest is part of the completion contract and should be treated as finance-output-specific behavior, not daily app-sales behavior.
| Finance object artifact | Synthetic example | Purpose |
|---|---|---|
| Fact file | finance_unified_EUR.csv |
Monthly finance rows in report currency context. |
| Manifest | finance_unified_EUR.manifest.json |
Completion and bundle metadata. |
| Schema | finance_unified_EUR.schema.json |
Finance field contract. |
| Period status | finance_unified_EUR.period_status.csv |
Finance period status context. |
| README | finance_unified_EUR.README.md |
Bundle interpretation notes. |
GCS and S3 destination matrix
The same storage technology can receive different Netice output families. The safe way to document this is with a matrix, not a single generic “app revenue file” claim.
| Destination | Daily enriched app sales | Raw reports | Finance Unified |
|---|---|---|---|
| Google Cloud Storage | gs://example_bucket/app-revenue/daily/app_sales_enriched_EUR.csv |
gs://example_bucket/app-revenue/raw/ |
gs://example_bucket/app-revenue/finance/finance_unified_EUR.csv |
| AWS S3 | s3://example_bucket/app-revenue/daily/app_sales_enriched_EUR.csv |
s3://example_bucket/app-revenue/raw/ |
s3://example_bucket/app-revenue/finance/finance_unified_EUR.csv |
These paths are synthetic. Real buckets, prefixes, object names, signed URLs, task IDs, source paths and customer identifiers must not appear in public examples.
File names, folders and formats
Netice separates folder configuration from managed filenames. For direct object outputs, the customer chooses the destination bucket and safe folder/prefix. Netice then writes the managed output pattern for the selected output family.
| Output family | File or folder model | Format behavior |
|---|---|---|
| Daily enriched app sales | Stable managed CSV file, e.g. app_sales_enriched_EUR.csv |
CSV for direct object storage; do not promise Parquet. |
| Raw reports | Provider-native files under selected root/folder. | Provider-native/source-preserving; no unified schema. |
| Finance Unified | Fact CSV plus same-stem sidecars and manifest. | CSV/JSON/SQL/README style bundle; do not promise Parquet. |
Backfills, recurring refresh and reruns
Backfills and reruns should be understood by output family. Daily App Sales refreshes daily windows. Raw Reports re-check provider report periods/files. Finance Unified refreshes finance months or fiscal periods. These are related operational ideas, but they are not one universal mechanism.
| Behavior | Daily enriched files | Raw reports | Finance Unified |
|---|---|---|---|
| First run | Creates or updates the managed daily file. | Queues initial raw sync in the background. | Materializes selected finance periods where configured. |
| Recurring refresh | Refreshes recent completed daily windows. | Re-checks eligible provider periods/files. | Refreshes monthly finance periods. |
| Provider-late data | Recent days can be refreshed into the same file. | Pending files can be picked up later. | Missing provider reports should not create fake zero rows. |
| Wrong assumption | Every rerun creates a new public file. | Raw files become a unified schema. | Finance output is daily analytics. |
Source access vs destination access
App revenue file output requires both source access and destination access. Source access lets Netice read Apple or Google reports. Destination access lets Netice write files to the customer-owned GCS bucket or S3 bucket.
These are separate permissions. Google Play source access does not automatically grant S3 or GCS write access. Apple App Store Connect access does not grant permission to write into the customer’s cloud storage account. Saved source connections and saved destination connections should also remain separate in setup and documentation.
| Access type | Purpose | Never expose in public examples |
|---|---|---|
| Google Play source | Read selected Play Console report families. | Service-account JSON, report bucket IDs, pubsite values, source paths. |
| Apple App Store source | Read selected App Store Connect report families. | Issuer IDs, key IDs, private keys, vendor numbers, app resource IDs. |
| GCS destination | Write customer-owned objects to Google Cloud Storage. | Real bucket names, object paths, service-account emails, signed URLs. |
| S3 destination | Write customer-owned objects to AWS S3. | Access keys, secret keys, role ARNs, external IDs, real bucket names. |
Security and safe diagnostics
File-output documentation must be careful because storage paths and provider metadata can be sensitive. Public examples should use only synthetic buckets, folders, tables, app IDs, SKUs, dates, hashes and amounts.
Diagnostics should distinguish source failures, destination failures, provider-late data, schema/provider format issues and successful output completion without showing raw provider rows, source files, app identifiers, task IDs, logs or credentials.
| Safe diagnostic category | Unsafe diagnostic content |
|---|---|
| Status, reason codes and bounded counts. | Raw provider rows or report contents. |
| Output family and destination category. | Real bucket names, prefixes or signed URLs. |
| Requested/delivered/pending window categories. | Task IDs, run IDs, source object paths or logs. |
| Safe source/report labels. | Real app IDs, package names, SKUs, vendor numbers or report bucket IDs. |
Safe synthetic examples
The examples below are intentionally synthetic. They show the difference between daily enriched files, raw files and finance files without using real customer identifiers.
Daily enriched app sales to GCS
gs://example_bucket/app-revenue/daily/app_sales_enriched_EUR.csvDaily enriched app sales to S3
s3://example_bucket/app-revenue/daily/app_sales_enriched_EUR.csvRaw provider-native reports to GCS or S3
gs://example_bucket/app-revenue/raw/
s3://example_bucket/app-revenue/raw/Finance Unified object bundle
gs://example_bucket/app-revenue/finance/finance_unified_EUR.csv
gs://example_bucket/app-revenue/finance/finance_unified_EUR.manifest.json
gs://example_bucket/app-revenue/finance/finance_unified_EUR.schema.json
s3://example_bucket/app-revenue/finance/finance_unified_EUR.csv
s3://example_bucket/app-revenue/finance/finance_unified_EUR.manifest.json
s3://example_bucket/app-revenue/finance/finance_unified_EUR.schema.jsonDecision checklist
Need daily app-sales analytics? Use Daily App Sales.
Need source-native provider files? Use Raw Reports.
Need monthly platform finance rows? Use Finance Unified.
Need customer-owned object storage? Use GCS or S3.
Need Azure Blob? Do not claim support unless product has verified it for the exact output family.FAQ
Which cloud storage destinations does Netice support for app revenue files?
Current evidence supports Google Cloud Storage and AWS S3 for the app revenue file-output article. Azure Blob should not be claimed for this page unless product verification later confirms it.
Does Netice support Azure Blob for app revenue files?
This article should not claim Azure Blob support. Current evidence does not verify Azure Blob as an active public app-revenue cloud-storage destination across the covered output families.
What is the difference between daily enriched app-sales files and raw reports?
Daily enriched app-sales files use Netice daily analytics fields and report currency context. Raw reports preserve provider-native files and columns without a unified schema, report currency or FX conversion.
What file name does daily app sales use in object storage?
A typical default pattern is app_sales_enriched_<REPORT_CURRENCY>.csv, such as the synthetic example app_sales_enriched_EUR.csv.
Does object storage output support Parquet?
Do not claim Parquet for direct daily app-sales object output or Finance Unified object output based on current evidence. The safe public claim is CSV-centered output for these paths.
How are Finance Unified files different from daily app-sales files?
Finance Unified files are monthly finance outputs with finance-period semantics and sidecar artifacts. Daily app-sales files are operational daily analytics outputs.
Do raw reports use report currency or FX conversion?
No. Raw reports preserve provider-native shape and do not apply report currency, currency normalization or FX conversion.
Does a rerun create a new file or update the same managed output?
For managed app revenue outputs, the customer-facing model is stable managed output that can be refreshed. Do not assume every rerun creates a new public file.
What access does Netice need for GCS or S3?
Netice needs destination write access to the selected customer-owned bucket or prefix. This is separate from Apple or Google Play source access.
Can I use these files for payout reconciliation or accounting close?
Daily enriched files and raw reports should not be described as final payout, settlement, accounting close, audited revenue, GAAP, IFRS, ASC 606 or bank reconciliation truth. Finance Unified has separate monthly finance semantics where configured, but final accounting remains the customer’s process.
Send app revenue files to storage you control
Netice helps app teams deliver daily enriched app-sales files, provider-native raw reports and monthly finance outputs into customer-owned GCS or S3 while preserving the boundaries between analytics, raw custody and finance semantics.
