Marketing Data Platforms

Marketing Data & Campaign Analytics Platform

Advertising APIs, BigQuery reporting layers, recovery workflows, and campaign analysis behind a marketing analytics product.

Marketing Analytics Product · Product team · Ongoing product work

My role & contribution

Data/backend engineering within an existing product team. I contributed ingestion, warehouse/transformation work, analytical logic, and the data-serving layer; I did not build the entire product or its MCP server.

Marketing platform; transformation migration developed in parallel

Ingestion, analytics, and MCP data-serving workflows support the product. The newer Dataform transformation architecture was developed and validated in parallel with the existing system.

The problem

A marketing analytics product needed more than charts: reliable advertising history, consistent campaign metrics, recovery after account changes, and analysis that could be served to an application. My work spans ingestion and BigQuery modeling, transformation architecture, campaign-health logic, and applied creative analysis within the product team.

The existing workflow

Advertising entities, daily insights, creative metadata, and attribution settings change on different schedules. Reporting must stay consistent when an account reconnects, historical data arrives late, or an upstream request returns only part of its result.

Marketing Data & Campaign Analytics Platform — Illustrative architecture using sanitized labels. It summarizes contributed work; it is not a client dashboard or a claim that every migration component has reached production.

System flow

01
Source ingestion
Advertising APIs provide entities, insights, attribution settings, and creative metadata.
02
Warehouse layers
Raw history feeds cleaned facts/dimensions and reporting marts. Dataform migration work was developed in parallel.
03
Analysis
Campaign rules and validated creative attributes operate on prepared reporting data.
04
Usable outputs
Application/API reporting and an MCP data-serving layer expose prepared outputs.

Key engineering decisions

Separate collection, transformation, and reporting

Raw source payloads remain traceable. Cleaned entities and facts feed reporting marts with explicit grain and metric definitions.

Recover changed history, not only recent dates

Account reconnects and targeted backfills can change old partitions. Refresh logic uses changed inputs and scope rather than assuming a rolling recent window is sufficient.

Validate before interpreting

An investigation traced a downstream Dataform assertion failure to incomplete parent-entity API pagination. Source completeness and workflow failure propagation are separate from whether an orchestrator task appeared successful.

Serve analysis through stable entities

My MCP contribution was the BigQuery data layer, constrained references, and read-time entity status. The server transport/authentication and tool scaffolding were a colleague’s work.

Preparing reporting data for AI access

My MCP contribution was the BigQuery serving layer behind the integration. It made current entity state and analysis available through stable references. A colleague implemented the MCP server transport, authentication, and scaffolding.

Designed current-state serving tables for the entities and outputs used by the integration.
Handled stable references and retired-entity status so reads could distinguish current data from unavailable or outdated entities.
Connected the data-serving layer to prepared campaign and creative analysis outputs.

AI access to your business data →

Difficult problems

Maintaining consistent marts after reconnects, backfills, and attribution-setting changes.
Tracing incorrect numbers from mart to staging, raw data, and source responses.
Keeping parallel transformation refresh state separate from production state.
Combining deterministic campaign rules and validated creative attributes without making generated analysis the source of truth.

Work contributed

Built and maintained advertising API ingestion and BigQuery staging/merge workflows.
Worked on raw → staging/silver → reporting/marts architecture, entity grain, daily/total metrics, and breakdown data.
Implemented transformation patterns for changed historical dates and isolated state during parallel Dataform development.
Developed reusable campaign-health logic using current performance, historical baselines, qualification rules, and funnel comparisons.
Integrated media preparation, structured creative tagging, and similarity/clustering outputs into analytics workflows.
Designed current-state BigQuery serving tables and stable-reference handling for a colleague-built MCP server.

Validation

Compared raw and transformed entity relationships, reporting grain, and source totals.
Investigated an incomplete-ingestion incident using raw history and transformation execution evidence; recommended fixes were distinguished from deployed changes.
Validated changed-date refresh and partition-filter behavior in the parallel transformation work.
Checked retired-entity handling in the MCP data-serving integration.

Supported outcome

Reporting and application outputs were supported by explicit ingestion, transformation, and validation workflows.
Implemented targeted source-recovery and changed-history refresh patterns, with parallel Dataform rollout status explicitly documented.
Campaign-health logic and creative attributes could be served alongside the underlying performance data.
The MCP integration used current-state serving data and explicit entity-status handling.

Technologies in context

BigQuery · Dataform · Apache Airflow · Python · Meta Marketing API · Node.js / TypeScript · Google Cloud Storage · Gemini

Related services & work

Technical reading

Working through a similar problem?

Share the workflow and the output your team needs. We can identify a focused starting point.

Discuss your workflow