WPP’s documented pattern combines shared data projects, separated processing compute, canonical audience definitions, and orchestrated pipelines.
The practical lesson for developers is simple: production AI starts below the model layer. Models need a shared, governed data backbone before they can support reliable marketing workloads.
Build a reusable boundary
Centralize identity, consent, lineage, and common cohort rules. Let domain teams own context-rich data products under shared standards.
This boundary gives enterprise marketing, martech, growth, RevOps, and data-platform teams a common foundation without stripping domain teams of ownership. Shared governance defines what must remain consistent; domain products preserve the context each workload needs.
Turn audience meaning into an interface
Canonical audience definitions should behave like a governed data contract, not logic copied into every pipeline.
Here is a vendor-neutral dbt pattern that makes that contract concrete. It illustrates the architecture rather than WPP’s exact schema:
-- models/interfaces/canonical_audience.sql
{{ config(materialized='view') }}
with identity as (
select customer_id
from {{ ref('shared_identity') }}
),
consented_customers as (
select customer_id
from {{ ref('shared_consent') }}
where is_marketing_eligible = true
),
cohort_membership as (
select
customer_id,
audience_key,
audience_name
from {{ ref('common_cohort_membership') }}
)
select
identity.customer_id,
cohort_membership.audience_key,
cohort_membership.audience_name
from identity
inner join consented_customers
on identity.customer_id = consented_customers.customer_id
inner join cohort_membership
on identity.customer_id = cohort_membership.customer_id
The interface keeps identity, consent, and common cohort dependencies explicit. Domain teams can consume it and add context downstream without silently redefining the shared audience.
Review the pipeline before the prediction
Before celebrating model performance, review the operating system around it:
- Freshness: Is the input current enough for the workload?
- Pipeline reliability: Does orchestration behave consistently?
- Retry safety: Can failed work be retried without unsafe side effects?
- Lineage: Can the team trace an input through to its output?
- Cost: Is the workload visible as an operating expense?
- Service-level compliance: Does the system meet the commitment attached to the use case?
A model is only one component. The platform must also keep its data and operational promises.
Add capabilities in sequence
Start with governed analytics. Add predictive targeting once that foundation works. Introduce generative asset workflows only after review and safety controls can support them.
This sequence forces the platform to establish governance and operational discipline before adding more complex workflows.
Choose the architecture by workload
A customer data platform, warehouse-native design, and hybrid design are implementation shapes, not maturity rankings. Choose according to the workload rather than the category label.
The central tradeoff is shared control versus local context. Centralize reusable governance while leaving context-rich data products with the domain teams that understand them.
If you separate compute, you must explicitly unify your observability layer. Keep freshness, reliability, retry safety, lineage, cost, and service-level compliance visible across workload boundaries.
Look beyond the model
WPP’s blueprint points to a broader definition of production AI marketing: a reusable data system with enforceable controls, not a collection of model demonstrations.
Before adding another AI tool, inspect the foundation. Are identity and consent shared? Are audience definitions canonical? Can teams trace orchestrated work across separated compute? Can they review operational evidence before evaluating model output?
Where would you place a canonical audience interface in your stack, and what would you keep domain-owned?
📖 Read the full guide → AI Marketing Platform: WPP's Data-Engineering Blueprint
Top comments (0)