Skip to main content
Cookie Gate
a promotional graphic telling you that PCI Compliance is no longer an annual exercise and that continuous monitory must be built in
Category: Google Consent Mode

Additional Consent Mode

Also known as: AC, Google Additional Consent, Google's Additional Consent, Additional Consent (AC) specification
Simply put

Additional Consent Mode is a technical specification created by Google that lets websites and consent tools pass user consent signals to Google-related advertising vendors that are not covered by the industry's main consent framework. It is designed to work alongside the IAB Europe Transparency and Consent Framework (TCF), filling a gap for vendors that have not yet joined that framework. According to the evidence, it was introduced as a temporary or bridging measure rather than a permanent standard.

Formal definition

Additional Consent (AC) is a Google technical specification that enables publishers, Consent Management Platforms (CMPs), and partners to collect and propagate consent signals for a defined list of Google ad technology providers that are not registered vendors under the IAB Europe Transparency and Consent Framework (TCF). It operates alongside the TCF rather than replacing it, extending consent capture to vendors outside the TCF's Global Vendor List. Per the cited sources, Google positioned it as a temporary bridge for non-TCF vendors. Note that AC is distinct from Google Consent Mode (including Consent Mode v2), which adjusts the behavior of Google tags based on consent states; the two are separately defined mechanisms often discussed together. This entry does not address whether use of AC satisfies consent validity requirements under the ePrivacy Directive's national implementations or the GDPR, which depend on how consent is obtained and remain matters of legal judgment and evolving data protection authority guidance. Implementation details, the current vendor list, and whether the specification remains in force are outside the scope of this definition and should be verified against Google's current documentation.

Why it matters

Additional Consent Mode addresses a practical gap in the EU advertising ecosystem: the IAB Europe Transparency and Consent Framework (TCF) only covers vendors registered on its Global Vendor List, yet publishers frequently work with Google ad technology providers that are not TCF-registered. Without a mechanism to capture and propagate consent for those non-TCF vendors, publishers relying on Google's advertising products could face uncertainty over whether they are lawfully passing consent signals for the full set of vendors involved in serving ads. AC was created by Google to bridge that gap, allowing consent signals to reach these vendors alongside the standard TCF signals.

For privacy and compliance teams, the significance lies in the fact that AC is described in the cited sources as a temporary or bridging measure rather than a permanent standard. This means implementations built around it may need to be revisited as Google's documentation, the vendor list, and the underlying frameworks evolve. Teams should not assume that a mechanism introduced as a bridge will remain in force indefinitely, and should verify its current status against Google's own documentation.

It is important to be clear about what AC does and does not settle. The presence of an Additional Consent signal reflects a technical capture and propagation of consent for a defined set of vendors; it does not, by itself, establish that consent was obtained in a manner meeting the validity standards of the ePrivacy Directive's national implementations or the GDPR. Whether consent is freely given, specific, informed, and unambiguous depends on how the consent interface is designed and presented, and remains a matter of legal judgment and evolving data protection authority guidance rather than something a technical specification can guarantee.

Who it's relevant to

Publishers using Google advertising products
Publishers who monetize through Google ad technology and work with vendors not registered under the TCF are the primary audience for AC, since the specification was designed to let them capture and propagate consent for those non-TCF Google-related vendors. They should track whether the specification, described in the cited sources as a temporary bridge, remains current in Google's documentation.
Consent Management Platform (CMP) providers and implementers
CMPs and the teams integrating them need to understand how AC operates alongside the TCF, because supporting the specification requires collecting and propagating an additional consent signal in addition to the standard TCF signal. Configuration and ongoing maintenance depend on Google's current vendor list and documentation.
Privacy officers and legal counsel
Compliance and legal teams should recognize that AC is a technical mechanism for capturing and passing consent signals and does not by itself determine whether consent meets validity requirements under the ePrivacy Directive's national implementations or the GDPR. Those questions turn on how consent is obtained and presented, and remain matters of legal judgment and evolving regulatory guidance.
Web developers and adtech engineers
Developers implementing Google advertising and consent tooling should be careful to distinguish AC from Google Consent Mode (including Consent Mode v2), which adjusts Google tag behavior based on consent states. The two are separately defined mechanisms that are often discussed together but serve different functions.

Inside AC

Additional Consent (AC) list
A list of advertising technology vendors maintained by Google that are not registered on the IAB Europe TCF Global Vendor List. Additional Consent Mode allows a CMP to collect and pass consent signals for these Google-approved vendors alongside the standard TCF signal.
Companion to the IAB TCF
Additional Consent Mode is designed to operate together with, not as a replacement for, the IAB Transparency and Consent Framework. It supplements the TCF string with a separate signal covering vendors outside the TCF Global Vendor List.
Additional Consent string
A distinct value, separate from the TCF consent string, that encodes user consent for the Google Additional Consent vendors. It is transmitted to relevant partners so that consent status can be communicated for those non-TCF vendors.
CMP responsibility
Consent management platforms that support the feature are responsible for presenting the additional vendors to users and generating the corresponding signal. The mechanism relies on the CMP's implementation rather than being an inherent property of the website.
Legal basis dependency
The signal reflects whether a clear affirmative action was taken for the additional vendors. Its validity as consent still depends on the underlying consent meeting the applicable standard under the ePrivacy Directive for device access and the GDPR for any subsequent personal data processing in EU jurisdictions.

Common questions

Answers to the questions practitioners most commonly ask about AC.

Does using Additional Consent Mode mean I am automatically compliant with the IAB Transparency and Consent Framework (TCF)?
No. Additional Consent (AC) is a mechanism designed to work alongside the TCF, allowing consent to be signalled for certain advertising technology vendors that are not registered on the IAB's Global Vendor List. It supplements the TCF signal but does not itself confer TCF compliance, and it does not replace the legal judgment needed to assess whether your consent collection satisfies applicable requirements. Using AC is an operational integration choice, not a determination that your setup meets EU or other legal standards.
If a vendor appears in my Additional Consent list, does that guarantee I have obtained valid consent for its processing?
No. The presence of a vendor in an Additional Consent string reflects that a signal is being passed for that vendor; it does not by itself establish that the underlying consent was freely given, specific, informed, and unambiguous as generally required under the GDPR in the EU. Whether valid consent exists depends on how it was collected through your consent management platform and how it is presented to the user, not on the technical inclusion of a vendor in the list. The mechanism supports consent signalling but does not substitute for compliant consent capture.
How does Additional Consent relate to the standard TCF consent string in a practical setup?
In practice, a consent management platform (CMP) that supports Additional Consent typically generates the AC signal separately from, but in coordination with, the TCF consent string. The TCF string covers vendors on the Global Vendor List, while the AC signal covers eligible vendors outside that list. Both signals are then made available to downstream advertising technology that is configured to read them. The exact behaviour depends on your CMP's implementation and configuration, so you should confirm how your specific platform handles the two signals.
Which vendors can be included in Additional Consent, and how do I know if one is eligible?
Additional Consent is intended for advertising-related vendors that are not registered on the IAB Global Vendor List but are recognised on the separate list maintained for the AC mechanism. Eligibility is determined by that list rather than by your own choice. To confirm whether a particular vendor can be signalled through AC, you would check the applicable Additional Consent vendor list referenced by your CMP. This definition does not enumerate specific vendors, and inclusion criteria are set by the framework maintainers rather than by individual publishers.
Do I need to configure my consent management platform to enable Additional Consent, or is it automatic?
Support for Additional Consent generally must be enabled and configured within a compatible CMP; it is not typically active by default in all setups. Configuration usually involves confirming that AC is turned on, ensuring your consent interface accounts for the relevant vendors, and verifying that downstream tags are set to consume the AC signal. Because implementation details vary between platforms, consult your CMP's documentation and confirm the behaviour in your particular environment rather than assuming a standard configuration.
Does Additional Consent apply outside the EU, for example under US state privacy laws?
Additional Consent is closely tied to the IAB Europe TCF ecosystem and the opt-in consent model generally used in the EU and, in adapted form, the UK. US state privacy laws such as the CCPA and CPRA in California typically rely on an opt-out model and use different signalling mechanisms, so AC as described here is not the primary tool for those regimes. If you operate across multiple jurisdictions, you should treat consent and preference signalling separately for each applicable framework and not assume that an EU-oriented mechanism satisfies non-EU requirements.

Common misconceptions

Additional Consent Mode is the same thing as Google Consent Mode.
They are generally distinct concepts. Additional Consent Mode concerns collecting and passing consent signals for Google-approved vendors that are not on the IAB TCF Global Vendor List, and it operates alongside the TCF. It should not be conflated with other Google consent-signalling mechanisms; practitioners should verify exactly which mechanism their configuration uses.
Enabling Additional Consent Mode by itself makes vendor tracking compliant.
The feature is a technical means of communicating a consent status; it does not itself establish valid consent. In most EU jurisdictions, consent must still be freely given, specific, informed, and unambiguous through a clear affirmative action, and it must satisfy both the ePrivacy rules on device access and the GDPR rules on personal data processing. The tool supports compliance but does not replace legal judgment.
Additional Consent Mode replaces the IAB TCF.
It is intended to supplement the TCF, not substitute for it. The TCF signal continues to cover vendors on the Global Vendor List, while the additional signal covers Google-approved vendors outside that list. Both may need to be handled together.

Best practices

Confirm with your CMP provider whether Additional Consent Mode is actually implemented and how it interacts with your existing TCF configuration, rather than assuming the feature is enabled by default.
Ensure the additional non-TCF vendors are disclosed to users in a clear and informed manner so that any consent captured for them can meet the applicable standard in the jurisdictions you serve.
Treat the additional consent signal as separate from the TCF string, and verify that both are being generated, stored, and transmitted correctly to the relevant partners.
Maintain records of consent for the additional vendors consistent with your consent-logging and record-keeping obligations, keeping in mind that requirements differ between the EU, the UK, and individual US states.
Do not rely on the mechanism alone to demonstrate lawful processing; assess separately whether device access is covered under ePrivacy rules and whether subsequent personal data processing has a valid basis under the GDPR in EU jurisdictions.
Periodically review the additional vendor list and your CMP's handling of it, since vendor lists and regulatory expectations evolve over time.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.