Marketing Data Warehouse on BigQuery or Snowflake

Most marketing warehouses break on something unglamorous: somebody renamed a campaign. Overwrite the row and January quietly re-labels itself; keep the old name and the joins fail. We model campaign, ad set and creative metadata as type 2 slowly changing dimensions from the first day, so a rename in March leaves January intact and a year over year comparison stays defensible when finance asks where the growth came from. The grain, decided before anything loads: Spend lands at date by platform by account by campaign by country by currency. Conversions land separately at their own grain, and the two are joined in a modelled layer rather than force fitted into one wide table during ingestion. That separation is the difference between adding a new platform in a day and re-modelling the warehouse over a fortnight. We publish the grain as a written contract before the first table is created and do not change it without agreeing out loud what it breaks. BigQuery or Snowflake, and how the bill stays flat: On BigQuery: partition on event date, cluster on platform, and set require partition filter to true so nobody generates a four hundred euro invoice with an exploratory query on a Friday afternoon. Budget alerts wired to an inbox somebody reads. On Snowflake: extra small warehouses with sixty second auto suspend, one warehouse per workload so a backfill cannot slow a dashboard, resource monitors with a hard ceiling rather than a notification. If your volumes fit comfortably in Postgres we will say so and build there instead. What the GA4 export can and cannot tell you: The daily export table lands hours after midnight and events_intraday is not a substitute for it. Consent mode adds modelled conversions in the Google interface that never appear in the export, which is why your warehouse total sits below the platform figure and always will. We document that difference inside the model with the current denial rate attached, rather than letting an analyst discover it in front of a board. Personal data, in a Turkish and European context: Hashed identifiers only. For health and wellness clients, nothing tying a person to a condition, a product or a purchase enters the warehouse, and we will restructure a requested report rather than make an exception to that. KVKK obligations including VERBIS registration and residency questions are settled with your counsel rather than guessed at by us, and we record which region each dataset lives in before it is created. For developer tools clients: The interesting joins are signup to workspace to paid seat, and no ad platform can see any of them. A package install carries no cookie, documentation traffic converts months later, and a self serve trial often ends in a sales conversation nobody logged. We model those paths explicitly and mark which links are observed and which are inferred, so a growth team knows which half of the funnel it is allowed to optimise against. What we refuse: Replicating your production application database in full because it might be useful later. Building a warehouse with no named owner inside your company. Loading everything and deciding the model afterwards, which is how a six figure annual bill ends up attached to eleven tables anyone actually queries. Who should not buy this: Companies whose reporting problem is one broken connector, and companies looking for a data team on subscription. This is a build with an end date, after which your analysts own it.