Putting Meta Ads data in BigQuery is the beginning of a reporting system. Useful output depends on consistent entities, metric definitions, historical coverage, and recovery when accounts or settings change.
This article has been updated to describe the more recent platform work. Earlier claims about one unified Meta/TikTok model, a fixed GitHub Actions schedule, and a general freshness guarantee are not used to describe the current architecture.
My contribution within the product
I worked on advertising ingestion, BigQuery modeling and transformations, campaign analysis, and data-serving workflows within an existing product team. I did not build the entire product alone.
The full case study separates production platform work from the newer Dataform transformation migration developed and validated in parallel.
Preserve the source, then model the question
The reporting path separates raw source history, staging/silver entities and facts, and marts/gold outputs.
Account, campaign, ad-set, ad, and media entities have different relationships. Daily performance, total metrics, and audience breakdowns need an explicit grain. Creative metadata belongs beside that model without accidentally multiplying performance rows.
This structure also gives incorrect numbers a traceable path: reporting output → staging model → raw history → source payload.
Account changes are reporting changes
Accounts reconnect. Raw dates can be missing. Attribution settings change which performance metrics should be used. A correction to historical inputs may invalidate several downstream models.
Recovery must identify the affected account/date/request scope and hand changed inputs to recomputation. Simply importing recent days or refreshing a dashboard is not sufficient.
The detailed discussions are in Meta recovery and backfills and Dataform recomputation.
Analysis builds on the prepared data
Reusable campaign-health logic compares current results with qualified historical baselines, evaluates funnel deterioration, and produces classifications suitable for reporting. The rules need spend/activity qualification and explicit metric definitions.
Creative processing is a separate supporting workflow: prepare eligible media/previews, request structured semantic attributes, validate the output, and store the resulting tags. Similarity/clustering work helps compare related creative approaches.
These are applied analytics and data-engineering contributions. They are not a claim of standalone ML-engineer ownership or improved campaign performance without measurement.
Serve the same definitions to interfaces
Application reporting and APIs need stable entities and prepared outputs. In an MCP integration, my contribution was the BigQuery current-state serving layer, constrained references, and read-time entity status. A colleague built the MCP server transport/authentication and scaffolding.
In a separate backend engagement, I implemented authenticated Claude/MCP access to existing application and telemetry APIs.
The AI data-access service brings these patterns into a focused engagement. See a synthetic BigQuery-to-Claude example for shared calculations, response context, and answer checks.
Build the useful part first
A reporting engagement can begin with one reliable output and a bounded set of sources. A broader warehouse, recovery system, or analytical layer follows where the requirements justify it.
Refresh frequency and history depend on source behavior and agreed scope; this article does not promise a universal freshness interval.