A marketing automation platform (an ESP, a campaign manager, a CDP) is only as good as the data feeding it. Underneath every "send to this segment" button sits an infrastructure stack that has to pull data out of source systems, clean and reshape it, and land it somewhere the automation platform can query or import on a schedule. Get the infrastructure wrong and the symptom shows up as a marketing problem — stale segments, duplicate sends, missing fields — even though the root cause is upstream.

ETL vs. ELT, and why marketing usually prefers ELT today

ETL (Extract, Transform, Load) transforms data in a separate processing layer before it ever reaches the warehouse — historically necessary when warehouses were too limited or expensive to hold raw, un-transformed data at scale.

ELT (Extract, Load, Transform) loads raw data into the warehouse first, then transforms it in place using the warehouse's own compute (via SQL, dbt, or similar). Modern columnar warehouses (BigQuery, Snowflake, Redshift) make ELT the default pattern for marketing data: it's cheaper to iterate on transformation logic when the raw source data is already sitting in the warehouse and every rebuild doesn't require re-extracting from the source system. ETL still shows up where transformation must happen before data lands for compliance reasons, or when the destination can't hold raw volumes.

marketing_elt_pipeline.txt

text

Source systems                 Warehouse (raw)           Warehouse (modeled)         Consumption
---------------                 -----------------          -------------------          -----------
CRM (Salesforce)   --extract-->  raw.crm_contacts    \
Ecommerce (orders) --extract-->  raw.orders           >--transform (dbt/SQL)--> marketing_mart.dim_customer --> ESP segment sync
Web analytics      --extract-->  raw.events          /                          marketing_mart.fact_orders  --> BI self-service
Email engagement   --extract-->  raw.email_events    /                          marketing_mart.fact_engagement --> Campaign tool API pull

Data marts: why marketing usually gets its own

The enterprise data warehouse (EDW) is built to serve finance, operations, and marketing all at once — which means its core modeling decisions optimize for auditability and cross-functional consistency, not for the speed and flexibility marketers need. A data mart is a scoped-down, purpose-built subset of the warehouse modeled specifically for one function's queries.

A marketing data mart typically denormalizes customer and campaign history into wide, pre-joined tables (the star schema pattern), refreshes on a cadence marketing cares about (daily, often hourly for key tables), and exposes only the fields marketing actually uses — hiding the financial and operational complexity the core EDW has to carry for other teams. This isn't marketing being precious about having its own copy of data; it's the same reasoning that gives finance its own mart for GL-level reporting.

Core EDW vs. marketing data mart

Aspect	Core EDW	Marketing data mart
Scope	All business functions	Marketing and campaign data only
Schema design	Normalized / audit-friendly	Denormalized, star-schema, query-fast
Refresh cadence	Often daily, finance-period-driven	Daily to hourly, campaign-driven
Primary consumers	Finance, data engineering, BI	Marketers, campaign ops, growth analysts
Change velocity	Slow — governance-heavy	Faster — owned closer to the business user

A mart without lineage back to the EDW becomes a shadow system

The failure mode of marketing data marts isn't having one — it's letting the mart drift from the source of truth. If marketing's customer count, revenue figures, or segment sizes stop reconciling with finance's numbers, trust in the mart collapses fast. Every table in the mart should have a traceable transformation path back to the raw EDW tables it was built from, so a discrepancy can be debugged rather than argued about.

Orchestration and reliability, not just pipes

Pipelines fail — an API rate limit, a schema change at the source, a credential expiring. Marketing automation infrastructure needs an orchestration layer (Airflow, dbt Cloud, Fivetran's own scheduler, or similar) that retries failed jobs, alerts on failures, and — critically — does not silently let a stale table get picked up by a scheduled campaign send. A failed ETL job that still leaves yesterday's segment table in place can cause a campaign to go out with wrong or incomplete data and look, to the business, exactly like success.

Identity resolution as warehouse infrastructure, not an afterthought

Marketing data warehouses ingest the same customer from multiple source systems — a CRM contact ID, an ecommerce account ID, an email engagement platform's subscriber ID, often with no shared key. Identity resolution (matching these into one canonical customer record) has to happen in the transformation layer before data reaches the marketing mart; it's part of the infrastructure, not something each campaign query re-solves on the fly. Getting this wrong shows up downstream as duplicate sends to the same person under different identifiers, or segments that undercount because records never got stitched together.

What's next

Once the mart exists, the next question is how marketers actually reach it — most of them shouldn't be writing SQL against it directly.

Next: Marketing Data Access & Delivery Methods →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →