Ask three teams who owns user consent and you'll get three confident, incompatible answers. Product will say they built the banner. Marketing will say they defined the requirements. Data will say they're the ones cleaning up when the two don't match. They're all a little right, which is exactly why consent is so often broken.
Product builds it, but doesn't feel the consequences
The consent management platform, the SDK gating, the consent-mode wiring — that's engineering work, and it lands on the web or app developers. They implement it correctly to the ticket. But a developer usually has no reason to know what a given consent state means downstream: which ad network stops receiving a signal, which conversion silently disappears from optimization, which campaign goes blind. To them it's a boolean. To marketing it's a budget.
Marketing needs it, but can't build it
Marketing is the business stakeholder here. They know exactly what the ad networks and tracking systems require, which events must fire, and what breaks if consent is handled the wrong way. What they usually can't do is implement any of it — or even specify it in terms an engineer can act on without translation. So the requirement arrives as an outcome ("we need Meta to receive purchases") and has to be reverse-engineered into technical steps by someone else.
Data sits between the two worlds
This is the seat I've spent most of my career in. The data team is the only group that routinely holds both halves: the technical understanding of how consent flows through the stack, and the business understanding of what each signal is worth. Data sees the combined picture — the events the frontend fires, the consent states attached, and whether the numbers that reach the ad networks actually make sense. It's the natural translator, whether or not anyone appointed it.
"Technically correct" is the worst kind of wrong
Here's the failure I see again and again: a consent implementation that passes code review, matches the spec, and satisfies legal — and still doesn't serve the business. Events fire but with the wrong parameters. Consent mode is wired to the letter but suppresses a signal marketing depends on. Or worse, the reverse: a tag fires without consent and quietly creates a compliance risk nobody notices until an audit. A consent banner can be flawless in code review and useless the moment it meets an ad network. Technically correct, business-wrong.
So who owns it?
Nobody owns it alone, and that's fine — but "shared" only works with a translator and a defined handshake. Marketing owns the requirements. Product owns the implementation. Data owns the meaning — validating that what got built actually produces the signals the business needs, in the states the law allows. Give it a dedicated point of contact on each side and a habit of checking the outcome, not just the ticket. Consent isn't a feature you ship once; it's a contract between three teams that has to be re-read every time the product changes.