Who Owns Consent? A Simple Ownership Model for Publisher Teams
The Problem: Everyone Touches Consent, Nobody Owns It
Ask who owns consent at a typical ad-supported publisher and you will hear several answers. Legal wrote the cookie policy. Ad ops added the vendors. Engineering installed the banner. Product changed the design last quarter. Marketing added a new pixel last week. Each of those changes was reasonable on its own, but nobody was responsible for how they fit together — and that is how a site ends up with a tag firing before consent, a vendor missing from the banner, or a redesign that quietly cut the consent rate.
This article proposes a simple ownership model so that consent decisions have a clear owner, a clear approver and a clear process.
Why Ownership Matters for Revenue as Well as Risk
Consent sits between two goals that pull in different directions. Legal and privacy teams focus on whether the setup respects users’ choices and the rules that apply. Ad ops and revenue teams focus on how much inventory can be monetised at full value. Both are right to care. Without a defined owner, disagreements are settled by whoever touched the configuration last, rather than by a decision anyone can explain later.
The Roles
Most publishers can map consent work to five roles, even if one person holds several of them:
- Privacy or legal — interprets the rules, approves purposes, legal bases and banner wording, and owns the cookie policy.
- Ad ops or revenue — manages demand partners and vendor lists, monitors consent-related revenue, and requests changes that affect monetisation.
- Engineering — implements the CMP, controls tag loading and makes sure scripts respect consent signals.
- Product and design — owns the banner experience within the limits legal sets, and runs tests on layout and copy.
- Marketing and analytics — requests new tags and measurement tools and relies on consent signals for reporting.
A RACI for the Decisions That Recur
A RACI lists who is Responsible (does the work), Accountable (makes the final call), Consulted and Informed. Here is a starting point:
Adding a new vendor or tag
- Responsible: ad ops or marketing (whoever requests it).
- Accountable: privacy or legal.
- Consulted: engineering, for how it will be gated.
- Informed: product.
Changing banner design or copy
- Responsible: product and design.
- Accountable: privacy or legal.
- Consulted: ad ops, for expected revenue impact.
- Informed: engineering and marketing.
Changing purposes or legal bases
- Responsible and accountable: privacy or legal.
- Consulted: ad ops and engineering.
- Informed: everyone who relies on consent data.
CMP configuration and releases
- Responsible: engineering.
- Accountable: a named consent owner (see below).
- Consulted: privacy and ad ops.
- Informed: product and marketing.
Monitoring consent and revenue metrics
- Responsible: ad ops.
- Accountable: the consent owner.
- Consulted: product.
- Informed: privacy or legal, especially about anomalies.
Name a Single Consent Owner
The RACI works best when one person is accountable for the consent setup as a whole. This is not necessarily the most senior person; it is the person who keeps the vendor list, banner configuration, tag inventory and cookie policy in step, and who calls the right people together when something changes. In small teams this is often someone in ad ops or engineering with a direct line to legal.
Processes That Make the Model Work
- A request route for new tags. Every new pixel, SDK or partner goes through one intake, with a short form: what it does, what data it collects, which purposes it needs, who requested it.
- A change log. Record every change to vendors, purposes, banner text and design, with a date and an approver. This is invaluable when a metric moves or a question arrives from a partner or regulator.
- A release check. No release that touches tags or the banner goes live without a consent test in a clean browser.
- A regular review. Once a quarter, the owner reviews the vendor list against actual tags, consent metrics against revenue, and the cookie policy against both.
- An escalation path. When legal and revenue disagree, the decision goes to a named person, and the reasoning is written down.
Signs Your Ownership Model Is Missing
- Nobody can say when the vendor list was last reviewed.
- Tags appear on the site that are not in the CMP.
- Banner changes ship without anyone checking the consent rate afterwards.
- Different teams give different answers about which partners receive the TC string.
- Questions from partners about consent signals take days to answer.
Key Takeaways
- Consent touches legal, ad ops, engineering, product and marketing; it needs one accountable owner.
- A simple RACI turns recurring decisions into a predictable process.
- Route every new tag through a single intake with a consent review.
- Keep a change log and review the setup quarterly.
- Write down how disagreements between revenue and privacy are settled.