Marketing Data Warehouse Build on BigQuery or Snowflake

A marketing warehouse is finished when a number inside it survives a finance meeting. For an account with six to ten sources that takes us about seven weeks, and the last fortnight of it goes to reconciling modelled spend against the invoices your finance team has already paid. Two percent variance we explain in the handover document. Five percent we treat as a defect and fix before anything ships. What we actually build: A raw landing zone first: one immutable table per source per day, partitioned on ingestion date, never edited. All transformation happens downstream in dbt, in your repository, under your licence. Staging models convert currency against a daily rates table rather than at query time, which matters the moment a Johannesburg account books media in ZAR and reports to a group in USD. Conversion marts carry a restatement window, because platform figures keep moving for weeks after the click: our incremental models re-merge the trailing 35 days on every run instead of treating yesterday as final. On the warehouse itself, BigQuery where the team already lives in Google Cloud and off the GA4 event export, Snowflake where risk or finance is there already and wants one governance surface. We have argued two clients out of Snowflake this year because marketing was the only workload. Where the judgement sits: Not in pipelines. The work worth paying for is deciding what counts as a conversion for an insurer whose lead turns into revenue eleven weeks later, or for an exchange where the step that matters is first deposit rather than sign-up. We write those definitions in SQL, put them in front of the person who will be quoted on them, and get sign-off in writing before a single job is scheduled. UTM taxonomy is enforced at ingestion. Rows that fail the pattern land in a rejects table with the offending value and a named owner. Quietly coercing bad tagging into an "other" bucket is how a channel disappears for a quarter. Regulated work: Financial services clients get row access policies keyed to the licensed entity, identifiers hashed inside the warehouse with SHA-256 over a lowercased, trimmed value so raw email never leaves it, and a retention job that actually deletes. Under POPIA this is a schema decision, not a policy document. Crypto clients bring the opposite problem: little or no personal data to hash, so identity is stitched from wallet address and session, and we label every probabilistic join as probabilistic in the model itself. What we will not do: We do not build on a Looker Studio blend and call it a warehouse. We do not load platform-attributed conversions into the conversion table; those are a vendor's claim about its own performance and they belong in a separate, clearly named model. We do not stand up reverse ETL, audience syncs or bid automation on top of definitions nobody has signed. We take no commission or reseller margin on any tool we recommend. Who this is not for: Teams with no single person empowered to settle a metric argument. Teams whose real problem is that nobody reads the reports they already have; a warehouse will not fix that and we would rather say so in the first call. Anyone who needs this inside a month, because the reconciliation step is the part that would get cut. Handover: Everything sits in your cloud project and your GitHub organisation from the first commit: dbt project, orchestration, a definitions document written in the language your executives use rather than ours, and a recorded working session for whoever inherits it. We keep no copy of your data after the engagement closes.