In short
Data consent is a user’s recorded permission for specific uses of their data. In practice it is a signal captured by a consent management platform and then carried with every event, so each downstream system can honor the choice rather than guess at it. The point that trips up most stacks is that consent is per-purpose: analytics consent does not imply advertising consent, and permission to personalize does not imply permission to share. A single yes-or-no flag is therefore not enough, because the pipeline has to carry which purposes were permitted and enforce each one independently. Consent is also not a one-time event, since users can withdraw it, and a withdrawal has to propagate as reliably as the original grant. Treated properly, consent is measurement infrastructure as much as compliance: a stack that records per-purpose consent at collection and enforces it at every destination both satisfies regulators and preserves the maximum usable signal from the users who did say yes.
Where consent breaks
Three common failures: banners that fire after tags, so the first pageview reports no consent; consent recorded client-side but never propagated to server-side events; and consent treated as one bit instead of per-purpose flags.
Consent as a performance input
Platforms fully use only consented, well-recorded data, and modeled conversions depend on properly implemented consent signals. Clean consent capture is a measurement advantage, not just a legal requirement.
Why is one consent flag not enough?
A visitor consents to analytics but not to ad personalization. A per-purpose consent signal lets the stack record the analytics event and withhold ad identifiers, rather than crudely dropping the user from all measurement.
Reference: ICO, consent under the UK GDPR