Google Additional Consent (AC) is a Google-specific extension to the IAB Transparency and Consent Framework. It lets a TCF consent banner also collect consent for Google's ad technology providers that have not registered on the Global Vendor List. The result is a second, simpler string - the AC string - passed to Google tags alongside the standard TC string.

The gap Additional Consent fills

The TCF can only record consent for vendors registered with IAB Europe. Google's advertising ecosystem, however, includes ad technology providers (ATPs) that never registered. Without a mechanism to cover them, a publisher running Google ad products would either drop those partners or collect consent outside the framework entirely.

Additional Consent is that mechanism: Google maintains its own list of ATPs with numeric IDs, the CMP shows them in the same consent flow, and the choices are encoded into the AC string.

What an AC string looks like

Compared with the bit-packed TC string, the AC string is almost readable: a specification version, a tilde, then a dot-separated list of the ATP IDs the user consented to - for example 2~1.35.41.101. Version 2 of the format adds a segment for ATPs that were disclosed but not consented to, mirroring the disclosure logic TCF v2.3 introduced for GVL vendors.

  • The AC string carries consent only - there is no legitimate-interest concept in it.

  • It is meaningful only to Google: other adtech reads the TC string alone.

  • It travels with the TC string through the __tcfapi integration into Google Ad Manager, AdSense, and AdMob requests.

Additional Consent vs Consent Mode v2

The two are frequently confused because both are Google consent signals:

  • AC string: part of a TCF setup. Vendor-level consent for Google's non-TCF ad partners. Relevant to publishers monetising with Google ad products in the EEA and UK.

  • Consent Mode v2: independent of TCF. Page-level granted or denied signals (analytics_storage, ad_storage, ad_user_data, ad_personalization) consumed by Google tags for measurement and modelling. Relevant to virtually every site running Google Analytics or Google Ads.

A publisher can need both at once: TCF plus AC for the ad stack, and Consent Mode v2 for measurement. A typical business site without programmatic ads needs only the latter - test what your own setup sends with the free Consent Mode Checker.

When you actually need Additional Consent

You need AC support when all three are true: you serve Google ad products (AdSense, Ad Manager, AdMob) to EEA or UK visitors; you operate under the TCF (which Google requires for those products in those regions - see AdSense cookie consent); and your chosen ad partners include ATPs outside the GVL. In Ad Manager and AdSense you select which ATPs you work with, and Google's guidance is to keep that list short for the same reason regulators dislike 500-vendor banners: consent must remain informed.

Configuring Additional Consent in practice

The publisher-side setup has three parts:

  1. Select your ad technology providers. In AdSense and Ad Manager, the EU user consent settings include an ATP list. Google's own guidance - and every regulator's reading of informed consent - says to select the providers you actually work with rather than the full commonly-used list. Each selected ATP appears in your consent banner's vendor disclosure.

  2. Enable Additional Consent in the CMP. The CMP must support the AC specification, fetch Google's ATP list, show the selected providers alongside GVL vendors, and emit the AC string with the TC string. Support varies between platforms - it is a line-item worth checking on a CMP comparison checklist.

  3. Verify the pass-through. Google tags pick the AC string up through the same __tcfapi integration as the TC string; ad requests carry both. If ads serve non-personalised despite full consent, the AC string is one of the first things to inspect.

Common Additional Consent mistakes

  • Selecting every ATP. Bloats the banner disclosure and invites the same regulator criticism as maximal GVL lists; select what your ad stack uses.

  • Assuming AC covers GVL vendors. It is strictly for providers NOT on the Global Vendor List; Google's own products remain GVL vendor 755 and live in the TC string.

  • Debugging the AC string first. Because it rides on the TCF signal, an invalid TC string invalidates the pair - always validate the TC string before touching AC configuration.

  • Forgetting the v1 to v2 format change. AC v2 added the disclosed-but-not-consented segment; partners parsing v1-style strings can misread v2 output during migrations.

Verifying your AC string

Because the AC string rides alongside the TC string, most implementation checks start with decoding both. The free TCF String Decoder handles the TC string side; if signals still go missing, work through our guide to common TC string errors - a rejected TC string takes the AC string down with it, because Google ignores Additional Consent when the underlying TCF signal is invalid. And if you are deciding whether this whole stack applies to you, start with does your website need IAB TCF.