Do you need a marketing data warehouse, or just a dashboard?

If your reporting reads from one platform, and losing history past that platform's retention window would not hurt, a dashboard is enough. Build the dashboard and stop.

A warehouse earns its cost when at least one of four things is true: you need cross-platform questions answered, you need history beyond platform retention, you need per-location rollups on consistent definitions, or you need numbers that can be reproduced and audited later.

Everything below is about telling which situation you are in, because the cost of guessing wrong in either direction is real.

A marketing data warehouse consolidates ad platform, analytics, call tracking and CRM data into one queryable store, normally BigQuery, with scheduled ingestion and a semantic layer.

A semantic layer is the set of versioned definitions, in SQL, in one place, that turn raw platform data into the metrics you report. It exists so a metric name means exactly one thing regardless of which dashboard displays it.

That definition is the part people skip, and it is the part that produces most of the value. Two dashboards calculating "cost per lead" slightly differently is not a technology problem; it is a definitions problem, and the warehouse is where definitions get to live once.

The retention case is the one most often oversold, so it is worth getting precise. GA4 standard properties offer event-level data retention of 2 or 14 months, and Google is explicit that the setting does not affect standard aggregated reports.

Read that carefully, because it decides whether this condition applies to you. Your headline numbers keep working past the retention window. What expires is the granular event data underneath them, which is what explorations and any new segmentation of the past depend on.

So the honest version of the argument is not "you will lose your numbers". It is that you lose the ability to ask a question you had not thought of yet. If every question you ask is one of the ten you already have a chart for, retention is not your reason to build anything.

If it is your reason, the fix has a deadline attached. GA4's BigQuery export delivers the previous day's raw events on a daily schedule, which means the archive starts on the day you link it, not the day you decided you needed one. Standard properties are capped at one million events per day on the daily export, with filtering available to stay under it, so a high-traffic property needs that configured deliberately rather than discovered.

The Monthly effort row is where manual exports lose. Someone spends the first week of every month pulling, aligning and reconciling spreadsheets, and that cost never appears as a line item because it is absorbed by salaried time.

The Auditability row is where the CFO conversation happens. If a figure is questioned six months later and you cannot reproduce it from source data, the number was never really evidence.

The middle column is underrated by everyone selling the third. A connector into a dashboard covers a genuine majority of mid-market reporting, and its weakness is narrow: it cannot join sources properly and it inherits the platform's retention. If neither of those bites you, the third column is a project you are buying for the feeling of rigour.

For most mid-market marketing datasets, BigQuery storage and query costs are modest, commonly tens of dollars a month rather than thousands, provided tables are partitioned and scheduled queries are bounded.

The mechanism behind that is worth understanding rather than trusting. BigQuery's on-demand pricing charges for the number of bytes processed by each query, with the first 1 TiB of query data per month free. Not rows returned, not queries run: bytes scanned. A dashboard tile that scans a whole table to display one month costs the same as the annual report next to it.

That is why partitioning is the single highest-leverage design decision. A partitioned table lets the engine prune whole partitions from a query, so a query bounded to last month reads last month. Unpartitioned tables scanned by scheduled queries several times a day are the source of essentially every surprising invoice in this category.

Storage is the cheap half, and it gets cheaper. Google prices active storage against anything modified in the last 90 days and long-term storage against anything untouched for 90 consecutive days, and the price drops by roughly half automatically with no difference in performance, durability or availability. The historical archive that justified the project is the least expensive thing in it.

Set a hard guardrail rather than a monitoring habit. BigQuery supports custom query quotas per project or per user, which cap bytes processed per day. A quota fails a runaway query; an alert tells you about it afterwards. Configure this at build time, not after the first surprising month.

Connector licensing, not compute, is usually the larger line. Managed connectors are worth their licence where the source is genuinely complex; where a platform API or a scheduled export does the job, that is what should be built. Connector choice is design work, not an afterthought.

The infrastructure should be billed to your own cloud project directly. If a provider marks up your cloud spend, that is a conflict of interest sitting on top of your data.

Marketing leads are usually persuaded by capability: the questions they could finally answer. Finance is usually persuaded by durability.

Platform retention windows expire. Connectors change formats. Agencies get replaced. A warehouse in your own cloud project means the historical record survives all three, and the transformation that produced any figure is in version control.

That is also what makes the reporting layer replaceable. When the semantic model is the contract, Looker Studio, Tableau or Power BI become a display choice you can reverse rather than a platform you are married to.

The strongest version of that argument is a switching story rather than a feature list. If changing dashboard tools or agencies would currently mean rebuilding every definition from scratch, the warehouse is not buying you analysis, it is buying you the ability to leave.

The version of that argument that lands hardest is a business-to-business one. When the opportunity record lives in a CRM the marketing team does not administer, and the board is asking about pipeline rather than leads, no dashboard sitting on top of the ad platforms can join the two, because the join does not exist in either system. That is the ordinary condition for a technology company in Kanata North, and it is where the warehouse stops being a preference and becomes the only structure that answers the question.

The common failure is not technical. It is a warehouse that becomes a second source of numbers rather than the source, so the organisation now has five disagreeing figures instead of four. That happens when the semantic layer is built after the dashboards rather than before them.

The second failure is silent staleness. A connector changes a field name, ingestion keeps running, and a metric quietly goes to zero or holds yesterday's value. Every pipeline needs freshness and sanity checks that block publication rather than warn, which is the same discipline that makes automated reporting trustworthy enough to send.

The third is single-operator risk. A warehouse only its author can modify is not infrastructure, it is a person with a laptop. Version control, a documented model and a runbook are what make it survive a departure.

None of these are reasons not to build one. They are the reasons the build should include a definitions document, a monitoring gate and a handover, and why a quote that only covers pipelines is quoting half the job.

Not with the warehouse. Start by writing down the four definitions of your primary conversion that already exist across the ad platform, analytics, call tracking and your CRM. Most organisations have never seen them side by side, and the exercise sometimes resolves the problem without building anything.

If the numbers disagree in ways nobody can explain, that is a conversion attribution audit first: a warehouse built on unreconciled definitions just centralises the confusion.

If they agree and you still cannot answer cross-platform questions, that is when a marketing data warehouse is the right build. Scope it on source count and location count, and get a monthly cost estimate before anyone provisions anything.

If the honest answer is that you are not ready yet, link the BigQuery export anyway. It is the cheapest thing on this page, it costs you almost nothing while it sits there, and it means the history exists when the decision changes. A franchise operator with more than fifteen clinics needed exactly that foundation before per-location quarterly reporting could run on live data.