One Click to Accept, Five to Refuse
Meta description: A compliant-looking cookie banner and a compliant cookie banner aren't the same thing — the difference is measured in click counts and visual weight, not whether a banner exists at all. A breakdown of two consent-design enforcement cases for any team running a standard ad-tech stack.
Most consent-design failures don't involve a missing cookie banner. They involve a banner that exists, looks like every other cookie banner on the web, and still fails, because the two choices it presents — accept or reject — aren't actually built with equal effort. That's the mechanism behind two of the clearest consent-design enforcement cases on record: France's CNIL against Google and Facebook, and California's first public CCPA enforcement action against Sephora. Neither case involves a company hiding that it uses cookies or ad tracking. Both involve a company disclosing it, and doing so through an interface that structurally favored one answer over the other.
Two distinct violations, easy to conflate
It's worth separating two things the CNIL punished, because they're different failures with different lessons, even though both concern cookies.
In December 2020, the CNIL fined Google €100 million and Amazon €35 million for a more basic problem: on amazon.fr and certain Google properties, advertising cookies were deposited automatically when a user arrived at the site — in some cases before any banner appeared at all, and in others via traffic arriving through an ad click, where no banner displayed regardless. This is a consent-mechanism-didn't-run problem: no meaningful choice was ever presented for a share of the traffic.
A year later, in a decision published December 31, 2021 (reported widely in the press as breaking in January 2022), the CNIL fined Google €150 million and Facebook €60 million for a different, subtler problem on their consent banners: accepting all cookies took one click, while rejecting them required several. On google.fr and youtube.com, the CNIL found, users could accept in a single click but had to navigate multiple screens to refuse. On facebook.com, the "refuse" option sat at the bottom of a second window. The banner existed. The choice was disclosed. The two paths to exercising it were not built to the same standard.
The second case is the more instructive one for a design or growth practitioner, because the first case is a straightforward technical-compliance gap (the consent mechanism didn't fire), while the second is a design decision about effort parity between two buttons that both, individually, look completely ordinary.
The environment that produces an asymmetric banner
Consent rate is directly load-bearing for any business funded by advertising, analytics-driven personalization, or ad-tech partnerships — a lower consent rate doesn't just reduce data quality, it can reduce revenue in a measurable, immediate way for a business built around that data. That creates the same structural pattern seen elsewhere in this series: whichever design lever affects the metric closest to the revenue model is the lever most likely to drift, incrementally, through a series of individually-reasonable design decisions, toward favoring that metric.
A cookie banner is frequently built once, using a template — from a consent-management platform, a design system component, or a previous project — and then left largely unexamined once it's shipped and "working." That's a meaningfully different failure mode than the Iliad-flow or Fortnite cases elsewhere in this series, where the design was actively iterated on over years. Here, the more common pattern industry-wide is closer to: a banner gets built once by whoever owns onboarding or the design system, optimized implicitly for "get through this quickly" the way any interstitial is, and the accept/reject asymmetry is inherited from a template rather than deliberately engineered — which doesn't change the legal exposure, but does change where the fix belongs organizationally.
What "choice architecture" actually means here
The regulatory theory in both the CNIL and Sephora cases doesn't require proving intent to deceive. It requires showing that the mechanics of a choice — button count, click count, visual prominence, default state — made one option structurally easier to select than the other, even though both were nominally available. A few concrete patterns show up repeatedly across these enforcement actions:
- Click-count asymmetry. One click to accept, multiple clicks or a secondary screen to reject — the CNIL's central finding against Google and Facebook.
- Visual weight asymmetry. A high-contrast, prominent "Accept" button next to a low-contrast text link or de-emphasized secondary button for "Reject" — a pattern not unique to these two cases and common across consent-banner templates generally.
- Default-state asymmetry. Pre-checked "accept" toggles inside a granular settings panel, where a user has to actively uncheck each category rather than starting from a neutral or opt-in state.
- Signal non-recognition. The Sephora case adds a fourth pattern distinct from the CNIL cases: California's Global Privacy Control (GPC) lets a user set a browser-level, machine-readable "don't sell my data" preference once, instead of clicking through every site's individual banner. California's Attorney General found that Sephora's site did not honor that signal, meaning a user who had already expressed a clear opt-out preference at the browser level still had their data treated as available for sale at the site level — a choice-architecture failure one layer removed from the banner itself.
The definitional trap: what counts as a "sale"
The Sephora case turns on a detail that catches a large share of ordinary tech stacks off guard: CCPA's definition of "sale" is broader than a literal cash transaction. Sharing browsing data with a third-party analytics or advertising platform in exchange for their service — the standard arrangement behind most analytics pixels, ad-conversion tags, and marketing tag-manager setups — falls inside that definition. California's Attorney General found that Sephora had not disclosed to consumers that this kind of data-sharing constituted a "sale" under the law, and had not provided a way to opt out of it consistent with the statute.
This matters beyond the specific company, because the underlying tech stack — a tag manager, a handful of standard analytics and ad pixels, installed the way most marketing teams install them by default — is close to universal, present in early-stage startups just as often as in large retailers. The Sephora case is useful precisely because nothing about the setup it describes is unusual or sophisticated; it's the default configuration a lot of teams ship without treating it as a disclosure decision.
What this means for a marketing or growth team running a standard stack
- Audit click count and visual weight together, not separately. A banner can pass a quick glance ("there's an accept and a reject button") and still fail an effort-parity standard if reject requires more clicks, more screens, or smaller/lower-contrast controls than accept. Measure both dimensions explicitly before shipping a banner redesign, the same way you'd measure a conversion funnel.
- Treat your tag-manager configuration as a disclosure surface, not just a technical one. Whatever pixels and analytics tools are firing by default are, functionally, a list of parties data may be "sold" to under a CCPA-style definition — that list needs to match what the privacy disclosure actually says, and it needs review whenever a new tool gets added, not just at initial launch.
- Support machine-readable opt-out signals, not just a manual link. A "Do Not Sell My Personal Information" link that a user has to find and click is a different standard than automatically recognizing a signal like GPC that the user has already set once, at the browser level. Where applicable law recognizes these signals, honoring them programmatically closes a gap a manual-only approach leaves open by design.
- Give consent-banner changes the same review tier as pricing or funnel changes. Because a banner is often built once and left alone, it doesn't get the recurring design review a funnel page does — building a periodic audit into the same cadence as a CRO program catches drift before a regulator does.
None of this requires abandoning cookie-based analytics or ad tech, and none of it requires a reject option to be more prominent than an accept option — only that a user's data-sharing choice not be constructed to favor one answer through mechanics disclosed nowhere but the interface itself.
This is part of a series on the design and decision-making behind marketing-compliance enforcement actions. See the full series or get in touch if you want a second read on whether your consent flow's mechanics match what your privacy disclosure says.