A Data Warehouse for Marketing: The Spine Under Every Number You Report

Someone in the board meeting asks what a customer costs to acquire. Three people have three numbers. Finance divides all marketing spend by all new logos. The performance marketer quotes the ad platforms, which together report more conversions than the company had customers. The CRM counts opportunities the platforms never saw. Every number is defensible, none reconciles, and the question is deferred.

That is not an analytics problem. It is the absence of one place where spend, leads, opportunities and revenue sit in the same database and can be joined. That place is a warehouse, and marketing teams have spent a decade being told they are too small for one.

The old argument against a warehouse is gone

The objection used to be real. A decade ago a warehouse meant a licensed appliance, a capacity plan and a data engineering hire before a single row was loaded. Marketing could not justify it and bought point tools instead, each with its own private store.

Cloud warehouses separated storage from compute and changed the shape of the bill. Storage runs at roughly a couple of cents per gigabyte per month, a rounding error for a B2B team's entire history. Compute is charged by what you run: BigQuery bills on bytes scanned, Snowflake and Databricks on credits while awake, and both fall to nothing when nobody queries. A warehouse holding ad data, CRM objects and a few million product events usually costs less per month than one seat of the average revenue intelligence tool. DuckDB queries hundreds of millions of rows on a laptop, so the early modelling work is free.

If someone says a warehouse is too expensive at your stage, ask what they think it costs. The figure they have in mind is usually from 2016.

What should land in it

Five sources, in order of value.

Ad platform spend and delivery, daily, at campaign, ad set and ad level. Do not settle for aggregated exports: every interesting question turns out to be a breakdown the pre-built dashboard does not offer.

CRM objects, and critically the history of stage changes rather than current state. Current state answers "where is this deal". History answers "how long does a deal sit in evaluation", and only the second says anything about the funnel.

Product events: signup, activation, and the two or three actions that correlate with retention. These let marketing argue about quality rather than volume.

The signal ledger, the first-party record of what accounts did on your properties. It is the only one of the five you own outright and the only one unaffected by a platform changing its API terms.

Support and billing last: churn reasons and payment behaviour are the honest end of the funnel.

Getting data in is largely solved: Fivetran and Airbyte maintain connectors, and most platforms offer a native scheduled export. Either beats a bespoke pipeline that breaks when an API version changes. Land raw and transform afterwards, because cleaning on the way in throws away what you need when a definition changes.

Definitions belong in version-controlled SQL, not a BI tool's private logic

This is what decides whether the warehouse works or becomes the fifth disagreeing number.

The modelling layer is SQL between the raw tables and anything a human looks at. It resolves accounts to one identity, builds a daily spend table and an opportunity table with stage durations, and defines the metrics: what a qualified lead is, what counts as pipeline, which opportunities belong to a campaign.

Where that logic lives matters more than how it is written. In a BI tool it is invisible: a calculated field inside one dashboard, editable by anyone with admin, with no diff and no history. Six months later two dashboards disagree and nobody can find out why, because the definition is not a document, it is a setting.

In version-controlled SQL, which in practice means dbt or something like it, a qualified lead is a file with an author, a review, a history and a test, traceable from raw table to the number on screen. Changing it means a pull request with a reason attached: marketing as code applied to numbers instead of copy.

Activation is what stops it being a reporting database

A warehouse that only feeds dashboards is worth having and is not worth what it costs. The return arrives when data flows back out.

Reverse ETL tools, Census and Hightouch being the common ones, read a table or query result and write it into an operational system. Three patterns matter. An audience sent back to an ad platform as a customer list for targeting or suppression, built from warehouse logic rather than whatever the platform infers. A score written back to the CRM so a rep sees it on the record instead of in a report nobody opens. Closed revenue exported as offline conversions, the mechanism behind closed-loop attribution.

The shape is always the same: the warehouse holds the definition, the operational tool executes on it. One suppression list in the warehouse is correct everywhere at once. Six maintained by hand in six tools are wrong in six ways by March.

The costs nobody budgets

Query spend will surprise you once. Not from analysis, but from automation: a dashboard refreshing every fifteen minutes, scanning a full events table, for a screen three people open. Partition large tables by date, cluster on what you filter by, and set per-user byte quotas before you hand out access. Then read the query history in month two. There is always one job costing more than the rest combined.

The modelling work is the real budget line. Connectors are cheap. Turning raw CRM tables into a trustworthy opportunity model takes weeks, most of it spent discovering that identity resolution is worse than you thought, that three campaigns share a name, and that the field everyone reports on has been free text since 2023. Budget it or the project stalls where the data is loaded and nobody trusts it.

A warehouse solves nothing on its own. It is a place where data can be joined. It does not decide what a qualified lead is, it does not fix two teams meaning different things by pipeline, and it will not change anyone's Tuesday. It makes those disagreements visible and expensive to ignore, which is not the same as resolving them. Without a decision inventory behind it, a warehouse is an archive with a dashboard on top. What collapses those dashboards into something people act on is a command center reading one set of definitions.

When you genuinely do not need one yet

Plainly: if you run one or two channels, your CRM holds a few thousand accounts, and one person can answer most questions from a CSV export, you do not need a warehouse. You need that person to write their definitions down.

The threshold is not headcount or revenue. It is the moment a routine question takes more than a day because answering it means joining two systems by hand, often enough that somebody keeps a spreadsheet of it. That spreadsheet is the warehouse you already have, maintained by the most expensive possible method. When you find it, it is time.

Frequently asked questions

Does a marketing team really need a data warehouse?

Not always. A team running one or two channels with a few thousand CRM accounts, where one person answers most questions from a CSV export, is better off writing its metric definitions down than provisioning infrastructure. The signal that one is needed is a routine question taking more than a day because answering it means joining two systems by hand.

What data should a marketing warehouse contain?

Ad platform spend and delivery at daily campaign, ad set and ad level; CRM objects including the history of stage changes rather than only current state; product events for signup and activation; the first-party signal ledger of what accounts did on your properties; and support and billing data. Land it raw and transform afterwards.

Why should metric definitions live in SQL rather than in a BI tool?

Because a definition inside a BI tool is a setting, not a document. It has no diff, no review and no history, so when two dashboards disagree nobody can trace why. Defined in version-controlled SQL, typically with dbt, a qualified lead is a file with an author, a reviewer, a test and a traceable path from raw table to reported number.

What is reverse ETL and why does marketing need it?

Reverse ETL, using tools such as Census or Hightouch, reads a table or query result from the warehouse and writes it into an operational system: audiences back to ad platforms for targeting or suppression, scores onto CRM records where reps work, closed revenue to the platforms as offline conversions. It turns a warehouse from a reporting database into infrastructure that acts.