One Toggle Per Purpose: Why Granular Consent Beats Accept All
Most banners offer two choices: accept everything, or open a settings panel and turn off five toggles one by one. Most visitors take the first choice, not because they want everything, but because the second choice is work. The banner is not collecting consent. It is collecting the path of least resistance.
The bundle is the problem
Consent under the GDPR has to be specific: given for a particular purpose, not for tracking in general. A single Accept All button bundles analytics, marketing, personalization, and social media into one yes, and the user who wants analytics but not marketing has no way to say so without opening the settings panel and doing the work toggle by toggle. The bundle is convenient for the site and useless for the user, and the consent it collects is weaker for it, because a user who did not understand what they agreed to did not give informed consent.
The practical cost shows up in the data. A site that only knows accept or reject has two buckets: everything on, or everything off. The analytics team loses data from every user who rejects, including the users who would have said yes to analytics and no to marketing. A granular banner recovers that data, because a user who toggles analytics on and marketing off is a user whose analytics data is valid and usable. The bundle loses the analytics data along with the marketing data, and it loses it from the users who were willing to share it.
What granular actually looks like
Granular consent means one toggle per purpose, in plain language, with the purpose named the way a visitor understands it: analytics, marketing, personalization, functional. Each toggle defaults off for non-essential purposes, and each toggle stays where the user puts it. The banner shows the toggles on the first layer, not buried in a second panel, because a choice the user cannot see is a choice the user cannot make. The record of the choice includes the timestamp and the purposes selected, because a consent record that only says accepted proves nothing about what was accepted.
The objection is that granular banners lower the accept rate, and that is true in the narrow sense: fewer users say yes to everything. But the accept rate for everything was never the metric that mattered. The metric is valid, specific consent per purpose, and granular banners produce more of it, for the purposes users actually want, with a record that survives an audit. For the consent-mode side of this, see Consent Mode v2: Basic vs Advanced, and What Each One Actually Sends, and for the performance cost of the banner itself, The Consent Banner Performance Cost: Tag Loading Order.
The implementation that survives contact with users
Put the purpose toggles on the first layer of the banner, in the order the user cares about: functional first, analytics second, marketing third. Label each toggle with what it does in one line, not a paragraph. Default all non-essential toggles off. And log the choice with the purposes and the timestamp, because the record is the evidence, and a record that says accepted with no purposes is not evidence of anything.
Frequently asked questions
Why is Accept All a problem?
Consent has to be specific to a purpose. Accept All bundles analytics, marketing, and personalization into one yes, and a user who wants analytics but not marketing has no way to say so without doing the work toggle by toggle.
Does granular consent lower the accept rate?
For everything, yes. But it raises valid consent per purpose, because users who would say yes to analytics and no to marketing can finally say so, and their analytics data becomes usable instead of lost.
Should toggles default on or off?
Off, for every non-essential purpose. A toggle that defaults on is not a choice, it is a pre-selection, and pre-selected consent is not freely given.
What should a consent record include?
The timestamp and the purposes selected. A record that only says accepted proves nothing about what was accepted, and it does not survive an audit.