Blanket consent cannot express granular preferences

What it is

Bundled consent compresses separable data purposes, recipients, or channels into one accept-or-decline decision. It records willingness to take the package but cannot represent a person who accepts data necessary for a core service while rejecting advertising, cross-service profiling, or public display. Granularity does not mean prompting for every technical event; it means separating choices with meaningfully different purposes and consequences.

Why it happens

Preferences are conditional. One person may accept on-device personalization but reject raw upload, or accept security alerts but reject promotions. A single switch projects a multidimensional preference onto a binary outcome, so the system cannot identify which component an accepter endorsed or which one a decliner rejected. When the package contains a depended-upon function, uptake largely reflects the value of that component while optional purposes free-ride on its authorization.

Studying it

Discrete-choice experiments or conjoint analysis can vary purpose, datum, recipient, and benefit to estimate each attribute's contribution. Interface studies can compare bundled and grouped controls on selection stability, completion time, and later revision. Analyses should detect random responding caused by excessive options and use repeated tasks or delayed retest for consistency. Splitting every field confuses implementation granularity with meaningful decision granularity.

Where it stops holding

Not every processing step needs an independent choice. Inseparable operations jointly delivering one explicit request can be explained as a functional unit; excessive fragmentation creates fatigue and inaccurate mental models. Dependencies must remain visible when disabling one purpose degrades another feature. A lawful basis and consent granularity are separate questions, so polished switches cannot substitute for a necessity assessment.

Applying it

• Group by user-comprehensible purpose and consequence, then ask whether each group can be disabled independently; do not mirror internal tables or vendor count.
• Separate necessary service operations from optional advertising, disclosure, public display, and training, stating what each decision changes.
• Offer a combination summary and one action to reject all optional uses, with expandable detail for people who want customization.
• Test representative preference combinations against observed flows; data sent for a disabled purpose, or a core task broken by an unrelated refusal, reveals faulty granularity.

Related

• Same group: O1.05.1 Lengthy terms go unread in practice · O1.05.3 Take-it-or-leave-it access is not a free choice · O1.05.4 Request timing determines whether attention is available · O1.05.5 Small mobile screens further constrain understandable consent · O1.05.6 A simplified summary can omit decisive exceptions · O1.05.7 Repeated requests produce habitual acceptance rather than understanding
• Adjacent: O1.10 Consent granularity and withdrawal · O2.06 Consent-interface design and abuse
• Search terms: bundled consent · granular consent · discrete choice experiment