You Should Own Your Marketing Data Warehouse. Most Vendors Disagree.

Where your marketing data physically lives determines how much leverage you hold over every analytics vendor you will ever sign with. Not the contract. Not the SLA. The storage location. And most vendors in the marketing analytics category are structured so that location is their cloud, because the alternative would make it far too easy for you to leave.

This never comes up in the sales call. The demo is about dashboards and connectors and how fast you can see blended ROAS. Ask where the underlying tables sit and who holds the encryption keys and the IAM policies, and the conversation gets vague. It should be the first question you ask.

The rental model

The distinction is simple to state. In a rented setup, the vendor's pipelines copy your ad, analytics, and store data into infrastructure the vendor controls, and you access your own history through their interface or, for an extra fee, their API. In an owned setup, the data lands in a warehouse inside your own cloud project, under your own access controls, and the vendor operates inside it with permissions you granted and can revoke.

A large share of the marketing data tools sold today follow the first model. They ingest Meta Ads, Google Ads, GA4, and your store data into their systems, put a reporting layer on top, and charge a monthly fee. Part of what that fee buys is storage of data that was yours to begin with. You are renting access to your own history.

The product usually works. That is what makes the model durable. The dashboards load, the numbers reconcile well enough, and for the first six months nobody thinks about the architecture underneath.

The switching cost compounds monthly

Every month you stay, the vendor's copy of your history grows and yours does not. Two years in, the only complete record of your campaign performance, your conversion trends, and your channel mix sits in someone else's database.

The metric definitions compound the same way. How this vendor computes blended CAC, how it deduplicates conversions across platforms, how it handles refunds: all of that logic runs in code you cannot read, expressed only through their UI. When you eventually migrate, you do not just move data. You reverse-engineer two years of definitions from screenshots.

Then there is the API tier. Programmatic access to your own data is often sold as an add-on, which tells you how the vendor thinks about ownership. And when you terminate, the standard offboarding is a CSV export. Flat files, no models, no definitions, no history of how a metric was computed in March versus November. The generous vendors give you thirty days to download it.

None of this is malicious. The architecture produces it on its own. A vendor whose margin depends on retention will not volunteer an easy exit.

What ownership looks like instead

The owned model inverts every one of those defaults. Your data lands in a warehouse, typically BigQuery, inside a Google Cloud project that belongs to your organization. Your IAM policies decide who and what can touch it. The vendor works inside that project through a scoped service account: enough access to run pipelines and build models, nothing more.

The transformations are readable SQL sitting in your project, not logic sealed inside an application. When someone asks why last month's CAC moved, an analyst can open the model and trace the answer. The definitions live in files you can version and audit.

Ownership also changes what your history is worth. Raw tables in your own project can feed whatever comes next: a different BI tool, an attribution experiment, an AI assistant that needs governed data underneath it. Rented history can only ever do what the vendor's interface does. The same two years of data is an asset in one model and a hostage in the other.

And leaving is a permissions change. You revoke the vendor's grant, and everything stays: every raw table, every model, every definition, the whole history. The next tool, or your own team, picks up exactly where the last one stopped. Nothing about the relationship depends on the vendor holding your data hostage, so the relationship has to survive on the quality of the service. That pressure is healthy, and vendors who accept it are telling you something about their confidence.

The exit test

If you take one thing from this piece, take a question to ask every analytics vendor you evaluate: describe day one after cancellation.

A rented-model vendor will answer with an export process. Listen for the details. What format, how long do you have, do the transformed models come with it or only raw extracts, what happens to scheduled jobs, who owns the metric definitions. The honest ones will admit you get flat files and goodwill.

An ownership-model vendor has a boring answer, and boring is what you want. Day one after cancellation looks identical to the day before, minus their access. The tables are in your project. The SQL is in your project. Your dashboards keep querying the same warehouse. You have lost a service, not an asset.

A useful follow-up is who owns the transformation logic. Raw data is the replaceable part; four months of API pulls can rebuild most of it. The definitions are where the value concentrates, because they encode every argument your team ever settled about what counts as a conversion or a returning customer. If those live only inside the vendor's application, the export they hand you on the way out is missing the expensive half.

Every other diligence question is downstream of this one. Security posture, pricing, roadmap: all negotiable, all changeable. Where the data lives is set on day one and gets more expensive to change every month after.

The tradeoff, stated honestly

Ownership has a cost, and pretending otherwise would be the same kind of omission the rental vendors make. If the warehouse is yours, someone has to run it. Pipelines break when ad platforms change their APIs. The GA4 export has quirks that surface at the worst moments. Models drift as the business changes. This operational load is the honest reason rented platforms win deals: they absorb it, and for a team with no data engineer that is genuinely worth something.

There are two ways to carry that load without giving up the asset. One is hiring for it, and you should go in with clear eyes about what that costs. We priced it out in the real cost of the self-built data stack, and the engineering time dwarfs the license fees. The other is a newer model: a managed service that operates the entire stack inside your cloud project. The vendor runs the pipelines, the transforms, and the semantic layer; the data and the code never leave your infrastructure. You get the rental model's convenience with the ownership model's exit.

If the objection is that running your own warehouse sounds expensive, it mostly is not. For marketing-sized data, BigQuery bills tend to land within a rounding error, and we worked through the actual numbers separately.

Where Verity fits

Verity is built on the second model. Managed pipelines land your marketing data in your own BigQuery project, transforms run as readable SQLMesh models with tests and lineage, and a semantic layer holds your metric definitions in the open. If you cancel, you revoke one grant and keep every table and every model. Plans start at €500 per month, and the details are on the pricing page.