Netice app revenue data infrastructure
App revenue backfills and reruns
Netice app revenue tasks support first runs, initial history, bounded manual backfills, recurring refreshes and provider follow-up windows. The goal is to keep Apple App Store and Google Play revenue outputs current without turning late provider data, selected reruns or destination updates into duplicate tables, unsafe overwrites or finance-close claims.
What app revenue backfills and reruns mean in Netice
An app revenue backfill is a controlled request to load or rebuild a selected historical window for an app-data task. A rerun is the broader operational idea of repeating a window because data was late, access was repaired, a destination issue was fixed, or a recent period needs to be refreshed again. In Netice, these are not unbounded “run everything again” operations. They map to specific task mechanisms and date windows.
For daily app revenue, the key source mode is google_apple_app_sales. This source produces daily sales-enriched operational analytics for Apple App Store and Google Play reporting. It is not final payout, settlement, bank reconciliation or accounting-close truth. A backfill or rerun of daily app-sales data should therefore be read as a rebuild of operational reporting output, not as an accounting restatement.
The important customer-facing promise is stability: first runs, manual backfills, provider follow-up and recurring refreshes update the managed output for the task. They should not create arbitrary new public tables or files every time they run. The exact write behavior depends on destination, but the user-facing model is the same managed output being kept current.
What backfills and reruns are not
Backfills are not unlimited historical restore tools. They are bounded by source type, provider readiness, current Netice limits, destination safety checks and active task state. They do not repair expired credentials by themselves. They do not make provider data appear before the provider has made it available. They do not automatically resolve provider schema changes.
A manual backfill also does not disable the normal recurring refresh schedule. It is a background update for a selected window. Normal recurring refreshes and provider follow-up can continue as separate mechanisms.
First run vs manual backfill vs recurring refresh vs provider follow-up
These terms should stay separate. Collapsing them into one word like “rerun” makes it harder to understand what happened to the destination output and why a window is still pending.
| Concept | What it means | Typical trigger | Output behavior |
|---|---|---|---|
| First run | The initial task execution after setup. | Task creation and first-run pipeline. | Creates or updates the managed output and can include configured initial history. |
| Initial backfill | Historical data requested during task setup. | User chooses initial history during setup. | Materializes selected history in the first successful managed output. |
| Manual backfill | A bounded date-range request after the task already exists. | User requests a start and end date from the task details. | Queues a background update for that selected window. |
| Recurring refresh | Netice-managed refresh of recent completed days. | Scheduler and task configuration. | Refreshes recent windows in the same managed output. |
| Provider follow-up | A recheck when provider data was not ready or only partly available. | Pending provider window and follow-up timing. | Rechecks the pending tail separately from the normal refresh. |
When to run a manual backfill
A manual backfill is useful when the user wants to rebuild a bounded historical window after setup. Examples include loading a selected date range, retrying after a destination permission issue has been fixed, or rebuilding a window after provider data was late.
It should not be used as a generic answer to every problem. If source credentials are expired, source access has to be repaired. If the destination cannot be written, destination access has to be fixed. If the provider report shape changed, schema or parser review may be needed before a rerun is safe.
| Situation | Backfill/rerun behavior to use | Important boundary |
|---|---|---|
| Need older selected dates in the managed output | Manual backfill for a bounded date range. | The request must be inside supported source/provider limits. |
| Recent provider updates arrived late | Recurring refresh or provider follow-up. | Provider-late data is not the same as credential failure. |
| Destination permission was fixed | Rerun the affected window after access repair. | A backfill cannot write successfully while destination access is still broken. |
| Provider schema changed | Support or parser review before rerun. | Do not assume a rerun automatically solves schema drift. |
| Expired source credential | Reauthorize or rotate credentials first. | A backfill does not repair source access by itself. |
How date windows are chosen and limited
Backfills in Netice are window-based. A manual backfill needs a start date and an end date. The requested window is then checked against source support, provider readiness, active task state and source-specific limits.
For daily unified app sales, the recurring refresh window currently defaults to the latest 7 completed days and validates to a configured range of 1 to 70 days. Initial setup can request daily app-sales history using the setup backfill-days field. Post-setup manual backfills are source-aware and provider-aware.
| Window type | Current app revenue behavior | What not to assume |
|---|---|---|
| Recurring daily refresh | Defaults to the latest 7 completed days for daily app sales. | Do not assume the user chooses the exact recurring clock time. |
| Recurring refresh maximum | Daily app-sales refresh window validates up to 70 days. | Do not apply this to monthly finance output. |
| Initial setup history | Daily app-sales setup can request initial history, currently with a UI max of 365 days. | Do not treat this as a universal source limit for every Netice source. |
| Manual Apple-enabled backfill | Current app-data behavior uses a stricter Apple-enabled cap. | Do not state this as an Apple API guarantee. |
| Manual Google-only backfill | Google-only app-data history can use a larger current cap than combined Apple+Google. | Do not apply Google-only history behavior to Apple-enabled tasks. |
| Too-new dates | Requested dates beyond provider-ready data can be rejected or left pending. | Do not fabricate future or unavailable provider data. |
Apple App Store readiness and backfill limits
Apple and Google Play should not be described as having identical backfill behavior. When Apple is selected for a daily app-data task, current Netice backfill behavior uses an Apple-enabled limit. In combined Apple and Google Play tasks, the stricter Apple-enabled behavior can determine the effective combined range.
Apple daily data can also be provider-late. That means the task may have a requested window, an attempted window, a delivered window and a pending tail. A pending Apple tail is not automatically a user error. It can mean the provider data was not ready when the run executed.
Google Play readiness and late-arriving changes
Google-only app-data backfills can use a larger current history cap than Apple-enabled combined backfills, subject to provider-ready validation and task limits. Google Play report timing and late changes can also make recurring recent-window refreshes valuable.
A Google Play rerun should still be understood as a bounded rebuild of selected provider-ready data, not as a promise that every historical or future date can be pulled at any time.
What happens to BigQuery, Snowflake, GCS and S3 outputs
Backfills and reruns should update the managed output for the task. They should not be presented as creating arbitrary new public tables or files on every run.
| Destination | Backfill/rerun behavior to describe | Boundary |
|---|---|---|
| BigQuery | Daily app-sales reruns use staged data and guarded, scoped window replacement or merge into the managed table. | Do not imply full-table deletes or expose staging object names. |
| Snowflake | Snowflake is an active destination choice for app-data outputs when configured. | Keep Snowflake replacement copy high-level unless destination internals are separately verified. |
| Google Cloud Storage | Direct managed CSV output can be refreshed for overlapping windows. | Do not promise Parquet for daily app-sales object output. |
| AWS S3 | Direct managed CSV output follows the same stable-output idea. | Do not claim automatic restore or bucket version rollback. |
Destination safety also matters. A safe rerun should write to the expected managed destination, not to an arbitrary new path supplied by a client-side request. Destination target verification and scoped replacement help prevent accidental destination drift.
Requested, attempted, delivered and pending windows
The most important status distinction is that the requested window is not always the same as the delivered window. A user may request a date range, but provider availability, active task state or destination validation can change what actually gets delivered.
| Window label | Meaning | Why it matters |
|---|---|---|
| Requested window | The start and end dates the user or schedule asked for. | Not proof that all dates were delivered. |
| Attempted window | The date range the run attempted to process. | Useful for debugging execution scope. |
| Delivered window | The dates actually written or refreshed in the managed output. | Use this when checking what changed downstream. |
| Pending window | Dates not yet available or not yet completed because provider data was late. | Can trigger provider follow-up instead of a customer action. |
Netice task history is intended to show human-safe first run, backfill, refresh and provider follow-up events. That history should not expose raw provider rows, app IDs, SKUs, amounts, credentials, source paths, task IDs or raw logs in public documentation examples.
Failure states to separate
A safe rerun guide should help users understand what kind of issue they have. “Try rerun” is not always the right answer.
| Status | Safe explanation | Unsafe assumption |
|---|---|---|
| Source unsupported | The selected task/source does not support this app-data backfill flow. | Netice can backfill every source. |
| Window required or invalid | A bounded, valid start and end date are required. | Users can rerun entire history without a range. |
| Outside allowed lookback | The requested date range is older than the current allowed source/provider window. | All historical data can always be rebuilt. |
| After provider-ready window | The requested dates are beyond currently available provider data. | Future provider dates can be pulled early. |
| Rate limited or already processing | Backfills have guardrails and conflicting active updates may need to finish first. | Unlimited overlapping reruns are safe. |
| Needs reauthorization | Source or destination access must be repaired before execution can continue. | A backfill fixes expired credentials. |
| Provider pending tail | Available data may be delivered while unavailable dates wait for follow-up. | A degraded run means the customer did something wrong. |
| Schema or provider format drift | A provider report shape may need support or parser review before safe retry. | Reruns always solve schema changes automatically. |
Daily app revenue vs monthly finance refreshes
Daily app-sales backfills and Finance Unified monthly refreshes are separate concepts. Daily App Sales refreshes daily windows. Finance Unified refreshes monthly finance periods. A daily backfill is not the same thing as monthly finance reconciliation.
Finance Unified uses monthly/report-period replacement behavior and finance source scope. Daily App Sales uses daily operational windows. Keep the two outputs separate in destination naming, run explanations and downstream dashboards.
Safe synthetic examples
The following examples are synthetic. They show the operational shape without real tasks, run IDs, app IDs, SKUs, source rows, object paths, bucket names, project IDs, dataset names, tables, credentials, logs or customer data.
Example date-window decisions
| Scenario | Selected providers | Requested window | Expected handling |
|---|---|---|---|
| First run with initial history | Apple + Google Play | Latest 30 completed days | First run materializes recent history if provider data is ready. |
| Normal recurring refresh | Apple + Google Play | Latest 7 completed days | Scheduled refresh updates the same managed output for overlapping recent dates. |
| Manual backfill inside Apple-enabled range | Apple + Google Play | 2026-02-01 to 2026-02-14 |
Queue a bounded background backfill if no conflicting update exists and dates are provider-ready. |
| Manual Google-only historical backfill | Google Play only | 2025-05-01 to 2025-05-31 |
Google-only history may allow a larger current range than combined Apple+Google, subject to validation. |
| Provider-late tail | Apple + Google Play | 2026-02-10 to 2026-02-12 |
Delivered window may end early, leaving a pending tail for provider follow-up. |
Example status rows
run_kind,requested_start,requested_end,delivered_start,delivered_end,pending_start,pending_end,status,safe_reason
manual_backfill,2026-02-01,2026-02-14,2026-02-01,2026-02-14,,,success,synthetic_window_delivered
recurring_refresh,2026-02-08,2026-02-14,2026-02-08,2026-02-13,2026-02-14,2026-02-14,success_degraded,synthetic_provider_tail_pending
provider_followup,2026-02-14,2026-02-14,2026-02-14,2026-02-14,,,success,synthetic_pending_tail_resolved
manual_backfill,2026-02-20,2026-02-20,,,,,failed,synthetic_after_provider_ready_windowThese rows are illustrative only. The date windows and reasons are synthetic. They should not be replaced with real run records in public copy.
Operational checklist
1. Confirm the task source supports app-data backfill.
2. Confirm source access and destination access are healthy.
3. Choose a bounded start date and end date.
4. Check provider-ready date and source-specific lookback limits.
5. Confirm no conflicting update is already active.
6. Queue the backfill and monitor requested, delivered and pending windows.
7. Treat provider-late pending windows differently from credential or destination failures.
8. Keep support examples synthetic and redacted.FAQ
What is an app revenue backfill?
An app revenue backfill is a controlled request to load or rebuild a selected historical date window for an app-data task. It is bounded by source support, provider readiness, task state and current limits.
What is the difference between a backfill and a rerun?
A backfill is a specific bounded historical window request. A rerun is a broader term for repeating a selected window because data was late, access was repaired, a destination issue was fixed, or recent dates need to be refreshed again.
Does a backfill create a new table or update the same output?
For managed app revenue outputs, the customer-facing model is that first runs, backfills and recurring refreshes keep the same managed output current. Destination-specific behavior can differ, but the article should not imply a new public table or file is created for every rerun.
How far back can app revenue be backfilled?
It depends on the source, provider selection, route and current product limits. Current evidence supports different behavior for Apple-enabled tasks and Google-only tasks, so the safe answer is source-specific rather than one universal maximum.
Why can Apple and Google Play have different backfill limits?
Apple and Google Play expose different report families and provider behaviors. Netice therefore uses provider-aware validation instead of assuming one identical history window for both.
What happens if provider data is not ready yet?
The run may deliver available data and leave a pending provider tail for follow-up. Provider-late data is not the same as credential failure.
Does a recurring refresh replace manual backfills?
No. Recurring refresh updates the recent configured window. Manual backfills are bounded selected-window requests after a task exists.
Can I rerun one selected date range?
Yes, where the task source supports app-data backfills and the selected start and end dates pass validation. The request is queued as a background update rather than a synchronous browser operation.
Can a backfill fix expired credentials?
No. If a task needs reauthorization or destination access repair, access must be fixed before a rerun can succeed.
Is a daily app revenue backfill the same as monthly finance reconciliation?
No. Daily app-sales backfills rebuild operational daily analytics windows. Monthly finance output uses separate finance-period semantics and belongs to Finance Unified.
Does Netice expose raw app IDs, SKUs, amounts or provider rows in status summaries?
Public examples and safe summaries should avoid raw provider rows, real app IDs, SKUs, amounts, credentials, task IDs, run IDs, source paths and customer data. Examples should stay synthetic.
Refresh app revenue data without losing source meaning
Netice is built for app teams that need recurring Apple App Store and Google Play revenue reporting in their own destination, with first runs, bounded backfills, provider follow-up and recurring refreshes kept separate and explainable.
