A daily Meta Ads import can succeed as a scheduled task and still leave reporting incomplete. The useful question is whether the account, entity, date, and requested breakdown coverage is complete enough for the reports that depend on it.
I have worked on advertising ingestion and recovery within a marketing analytics product. This note focuses on getting missing or incomplete inputs into BigQuery. Recomputing downstream models is a separate step.
A task marked successful can contain a failed extraction
In one investigated incident, an entity request imported its first page but failed during later pagination. The pipeline recorded an account-level failure and returned a summary. The orchestrator therefore treated the task as successful and continued to transformations.
Other tasks had imported ads and performance rows that referenced parent entities which were missing. Downstream assertions detected the inconsistency.
Historical retrieval later recovered the missing parents. A subsequent transformation run rebuilt from the recovered inputs. The important distinction was between extraction completeness, raw-state recovery, and the time at which a reporting model had materialized.
The investigation identified failure-propagation and observability gaps. Diagnosis and recommended fixes should not be described as a production fix without a deployment and validation record.
Define what missing means
A missing calendar date is not automatically an ingestion defect: an account may have no activity. Row counts alone are insufficient.
Useful checks include:
- The account was eligible and authorized for the requested range.
- The complete pagination sequence finished.
- Imported children have the parent entities required by reporting.
- Requested dimensions, metrics, and breakdowns are present.
- The source response and warehouse totals agree for a comparable scope.
- Empty-but-successful results are distinguishable from failed requests.
Store collection status alongside the data. A reporting query should not have to infer whether an empty partition means no activity or an unsuccessful extraction.
Use a bounded recovery scope
The following example is synthetic:
| Observation | Recovery action |
|---|---|
| An account reconnects after a lapse | Recheck accessible historical coverage for that account |
| Two historical dates are incomplete | Retrieve those dates and the required entity context |
| A breakdown request fails | Retry that source/request family rather than every table |
| A parent-entity page is incomplete | Recover the entity collection before rebuilding dependent reports |
A useful job scope identifies account, date range, request family, settings, and expected downstream consumers. It also records which requests succeeded. A partially failed batch should not mark every account as recovered.
Make reruns safe
Collection and loading are different stages. Preserve enough raw context to understand the request, then load through a deduplication/merge strategy suited to the source grain.
A simplified control flow is:
claim a bounded recovery job
→ retrieve all required pages
→ validate extraction completeness
→ load/merge source data
→ record successful scope
→ invalidate affected downstream outputsThe completion checkpoint must follow successful work. OAuth/token recovery, retryable request errors, and source permissions also need distinct handling: a retry cannot repair an access problem indefinitely.
Validate recovery before declaring the report repaired
Check entity relationships, date coverage, duplicates, and comparable source totals. Then rebuild the downstream models that used incomplete inputs and validate their output.
Backfilling raw data does not change a reporting table that already materialized from an earlier snapshot. Reconnect recovery and warehouse recomputation therefore need an explicit handoff.
My marketing-platform case study describes how ingestion, reporting layers, and analysis fit together within the wider product.
Start with the failing report or account
You do not need to replace an entire platform to improve recovery. A first engagement can trace one missing-history problem, define completeness checks, and implement a bounded recovery path.