Skip to main content
Cookie Gate
green gradient background, "The Future of Application Security Is Already Here." and a read the report button.
Category: CMP Implementation

setConsent Method

Also known as: SetConsent, setConsent command
Simply put

The setConsent method is a programming command used within various software development kits (SDKs) and web SDKs to record and update a user's consent choices for data collection and processing. When it is called, it replaces the default consent settings that were in place before the user made a decision. It is one technical building block that helps organizations act on consent, though it does not by itself determine whether the consent collected is legally valid.

Formal definition

setConsent is a method exposed by several SDKs and tag platforms (for example, the Firebase SDK in the context of Google Consent Mode, the Adobe Experience Platform Web SDK, and the Zeotap SDK) that is invoked to update a user's consent state after an application or page has loaded. In Consent Mode implementations, invoking setConsent overrides the previously configured default consent settings, adjusting the behavior of tags and data collection accordingly. In the Adobe Experience Platform Web SDK, the setConsent command updates the user's profile attributes directly in the Profile store as one of its actions. The method operationalizes recorded consent signals within a given vendor's stack; it does not, on its own, establish that consent meets the standards required under the ePrivacy rules governing access to and storage of information on a device, or the GDPR standards for processing any resulting personal data. Whether opt-in (as generally required in the EU and UK) or opt-out (as commonly applied under US state privacy laws such as the CCPA/CPRA) governs, and whether the surrounding consent flow is valid, depend on legal and configuration factors outside the scope of the method itself.

Why it matters

The setConsent method sits at the point where a user's consent decision is translated into technical behavior across an organization's data stack. Whether an analytics or advertising tag fires, whether data collection proceeds, and how a vendor SDK behaves after a user makes a choice can all depend on this method being called correctly. Because it overrides the default consent settings that were in place before the user decided, a misconfigured or missing setConsent call can mean that tags continue to behave according to defaults rather than the user's actual preferences, creating a gap between what a consent banner appears to promise and what the underlying systems actually do.

For privacy and compliance teams, the significance of setConsent lies in this gap between recording a choice and honoring it. The method operationalizes a consent signal within a given vendor's environment, but it does not by itself establish that the consent collected is legally valid. Valid consent under the GDPR must generally be freely given, specific, informed, and unambiguous, and in most EU and UK contexts the ePrivacy rules require prior consent before non-essential information is stored on or accessed from a user's device. Under US state frameworks such as the CCPA and CPRA, an opt-out model commonly applies instead. The setConsent method does not determine which of these standards governs, nor whether the surrounding consent flow satisfies them.

Because of this, treating setConsent as a compliance control in itself is a common source of risk. The correctness of the consent choices being passed to the method, the timing of the call relative to when tags load or data is collected, and the legal adequacy of the banner or preference flow that produced the choice all sit outside the method's own behavior and must be verified separately.

Who it's relevant to

Web Developers and SDK Implementers
Developers integrating Firebase, the Adobe Experience Platform Web SDK, Zeotap, or similar platforms are responsible for calling setConsent correctly, including passing the right consent values and ensuring the call happens at an appropriate point after the user decides. Because the method overrides default consent settings, implementation errors can cause tags or data collection to behave inconsistently with the user's actual choice.
Consent and Tag Management Teams
Teams managing consent management platforms and tag configurations need to understand how setConsent connects the consent banner to downstream tag behavior, particularly in Consent Mode setups where default settings apply until the method is invoked. Verifying that recorded choices actually reach and update the vendor's consent state is part of confirming that a configured consent flow behaves as intended.
Privacy Officers and Data Protection Professionals
Compliance stakeholders should recognize that setConsent operationalizes a consent signal but does not, on its own, establish that the consent meets the ePrivacy standards for storing or accessing information on a device or the GDPR standards for processing personal data. Whether an opt-in model (as generally applies in the EU and UK) or an opt-out model (as commonly applies under US state laws such as the CCPA and CPRA) governs, and whether the surrounding flow is valid, must be assessed separately from the method's technical function.
Legal and Compliance Counsel
Counsel advising on cookie and tracking compliance should treat setConsent as one technical building block rather than evidence of a lawful consent process. The legal adequacy of the consent flow that produces the values passed to the method, and the applicable jurisdictional standard, are questions that depend on facts outside the method itself and require independent legal judgment.

Inside setConsent Method

Consent State Parameters
The setConsent method typically accepts parameters representing the user's consent decisions across defined categories or purposes, such as analytics, advertising, functional, and strictly necessary cookies. These values communicate to a tag manager, SDK, or vendor script whether processing tied to each category may proceed.
Granular Category Signals
Rather than a single accept-or-reject flag, the method generally conveys granular signals per purpose so that non-essential technologies (analytics, advertising) remain gated while strictly necessary functions, which are generally exempt from consent under EU ePrivacy rules, may operate.
Default and Update Modes
Implementations commonly distinguish a default state, applied before any user choice is captured, from an updated state reflecting the user's affirmative action. The default should reflect no consent for non-essential categories in EU contexts, since consent must be obtained before placing or accessing non-exempt information on the device.
Integration Point with a CMP
The method is typically the technical bridge between a consent management platform (CMP) that captures the user's choice and the downstream tags, pixels, local storage, or SDKs that must honor it. It is a mechanism for propagating consent, not itself a determination of legal validity.
Scope Limitation
The method governs how consent signals are passed to technologies; it does not, on its own, establish whether the underlying consent was freely given, specific, informed, and unambiguous, nor whether the categorization of cookies is accurate. Those remain matters of legal and organizational judgment.

Common questions

Answers to the questions practitioners most commonly ask about setConsent Method.

Does calling the setConsent method by itself make my cookie consent implementation compliant?
No. The setConsent method is a technical mechanism for recording or communicating a user's consent state to a tag manager, CMP, or SDK, but invoking it does not by itself establish valid consent. Under the GDPR, consent must still be freely given, specific, informed, and unambiguous, and collected through a clear affirmative action before any non-essential cookies or similar technologies are placed. The method only reflects a decision the user has (or has not) validly made; it does not create that decision. Compliance also depends on your consent notice, the timing of tag firing, your record-keeping, and applicable legal requirements in each relevant jurisdiction, which are outside the scope of the method itself.
If I set consent to granted through the setConsent method, does that satisfy both the ePrivacy rules and the GDPR at once?
Not necessarily. These are distinct legal regimes and should not be conflated. In most EU jurisdictions, the ePrivacy Directive as implemented nationally governs the placing of and access to information on a user's device, while the GDPR governs any subsequent processing of personal data. Passing a granted state through setConsent does not automatically demonstrate that both sets of requirements were met; each has its own conditions. Whether a single consent action can address both depends on how consent was collected and documented and on the relevant national implementation, which the method's technical behavior does not determine.
When should the setConsent method be called relative to tags or scripts loading?
In an opt-in model, which is generally expected in the EU, the setConsent method is typically used to establish a default denied state before non-essential tags load, and then to update the state only after the user provides a clear affirmative action. This ordering is intended to prevent non-essential cookies and similar technologies, such as pixels, SDKs, or local storage, from being set before consent. The exact sequencing depends on your CMP, tag manager, and site architecture, and should be validated against how your specific tools implement the method.
How can I handle different consent categories through the setConsent method?
Many implementations allow the setConsent method to accept granular parameters mapped to categories such as analytics, advertising, and functional purposes, reflecting that valid EU consent is generally expected to be specific. Strictly necessary or essential cookies are typically treated separately and may not be gated by these parameters, since they are generally exempt from consent. How categories are named and grouped varies by platform, so you should confirm which parameters your particular tool exposes and how each maps to the technologies you deploy.
How should the setConsent method interact with signals like Global Privacy Control?
Where you honor browser-based opt-out signals such as Global Privacy Control, you may translate a detected signal into a corresponding state passed through the setConsent method, for example applying a denied or opt-out state for relevant categories. This is more commonly associated with opt-out frameworks, such as certain US state privacy laws, than with EU opt-in requirements. Whether and how you must respond to such signals depends on the applicable legal regime and evolving guidance, so the mapping between a received signal and the state you set should be reviewed against your obligations rather than assumed.
Does using the setConsent method remove the need to keep consent records?
No. The setConsent method communicates a consent state to your tools at runtime, but it is generally distinct from consent logging or record-keeping. In most EU jurisdictions, controllers are expected to be able to demonstrate that valid consent was obtained, which typically requires maintaining records separate from the transient state passed to a tag manager or SDK. You should confirm whether your CMP retains an auditable log independently of the setConsent call, since the method reflecting a state at a point in time does not by itself constitute a durable record.

Common misconceptions

Calling setConsent with granted values makes cookie use compliant.
The method only transmits a consent state to downstream technologies. It does not verify that valid consent was obtained. Under the GDPR, consent must be freely given, specific, informed, and unambiguous through a clear affirmative action, and under the ePrivacy Directive prior consent is generally required before placing non-exempt cookies. Passing a granted signal that does not reflect a genuine user choice does not create compliance.
A single setConsent call covers all cookies and both the ePrivacy and GDPR requirements at once.
The ePrivacy regime governs the placing of and access to information on the device, while the GDPR governs any subsequent processing of personal data. These are distinct obligations, and a technical consent flag does not automatically satisfy both. Granular per-purpose handling is generally expected, and legal analysis of the processing that follows remains separate.
The same setConsent configuration works identically in every jurisdiction.
Consent obligations differ by region. In most EU and UK contexts an opt-in model applies before non-essential cookies are set, whereas several US state laws such as the CCPA and CPRA generally rely on opt-out mechanisms. A default that assumes granted consent may be appropriate in some opt-out regimes but is generally not acceptable in the EU for non-essential categories.

Best practices

Set defaults so that non-essential categories such as analytics and advertising are denied until the user takes a clear affirmative action, reflecting the prior-consent expectation that applies in most EU and UK contexts.
Map each consent category in the method to a specific, informed purpose and ensure non-cookie technologies such as pixels, local storage, SDKs, and fingerprinting are gated by the same signals where they fall within the same rules.
Configure jurisdiction-aware behavior so that opt-in logic applies in the EU and UK while opt-out models used under laws such as the CCPA and CPRA are handled separately, rather than relying on one universal configuration.
Integrate the method with a CMP that captures and logs the user's choices, and retain consent records to support record-keeping obligations, while recognizing that the tool supports rather than guarantees compliance.
Treat honoring of user-choice signals, including Global Privacy Control where applicable, as part of the update flow, and re-transmit consent state promptly when a user changes their preferences.
Validate that the categorization driving the method reflects an accurate cookie audit and obtain legal review of consent validity, since the method transmits signals but does not resolve the underlying legal questions.
Promotional banner for the Pentest Readiness checklist download