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

ad_user_data

Also known as: ad_user_data consent type, ad_user_data parameter

Simply put

ad_user_data is a setting in Google Consent Mode v2 that indicates whether a user has consented to having their data sent to Google for advertising-related purposes. When consent is not granted, certain Google advertising and measurement features cannot process that user's data. It is one of the consent signals a website uses to tell Google what a user has agreed to.

Formal definition

ad_user_data is a consent type (parameter) within Google Consent Mode v2 that sets permission for sending and sharing advertising-related user data to Google. According to Google's documentation, it is required for certain measurement use cases; when consent is not granted, features that depend on it, such as remarketing and Enhanced Conversions, which rely on hashed first-party data, will not process that data in Google Ads and GA4. It functions as a signal communicated to Google rather than a legal basis in itself; obtaining valid consent under the ePrivacy Directive (for placing or accessing information on a device) and the GDPR (for any resulting processing of personal data) in the EU/EEA, or meeting the applicable requirements of other regimes, remains a separate obligation. The evidence provided does not detail the parameter's exact technical implementation values or its full interaction with the accompanying EEA and ad_storage parameters, so those aspects are out of scope for this entry.

Why it matters

The introduction of Google Consent Mode v2 made ad_user_data a practical necessity for many organizations that rely on Google's advertising and measurement products in regions where consent is required. Because ad_user_data governs whether advertising-related user data can be sent to Google, the way a website sets this parameter directly affects which features, such as remarketing and Enhanced Conversions, will process a user's data. For privacy and marketing teams, this means the parameter sits at the intersection of compliance obligations and campaign functionality, and misconfiguring it can either undermine advertising performance or, worse, send data to Google without a valid legal foundation.

It is important to recognize what ad_user_data does and does not do. The parameter is a signal that communicates a user's consent state to Google; it is not itself a legal basis for collecting or processing data. In the EU/EEA, obtaining valid consent under the ePrivacy Directive (for placing or accessing information on a user's device) and, separately, meeting the GDPR's requirements (for any resulting processing of personal data) remain distinct obligations that ad_user_data cannot satisfy on its own. Setting the parameter to reflect consent does not substitute for actually collecting consent that is freely given, specific, informed, and unambiguous where such consent is required.

Organizations should therefore treat ad_user_data as one component of a broader consent management approach rather than a compliance solution in itself. The correct value depends on the consent a user has genuinely provided, which in turn depends on the applicable legal regime and the way the consent interface is designed. Because requirements differ across the EU, the UK, and individual US states, and because regulatory guidance continues to evolve, the appropriate configuration and the legal analysis behind it should be assessed for each jurisdiction rather than assumed to be universal.

Who it's relevant to

Marketing and advertising operations teams

Teams running campaigns through Google Ads and GA4 need to understand ad_user_data because it determines whether features such as remarketing and Enhanced Conversions can process user data. Misconfiguration can silently disable these features or send data in ways that do not match the consent a user actually gave.

Privacy and data protection officers

DPOs and privacy professionals should recognize that ad_user_data is a signal communicated to Google, not a legal basis. Where consent is required, such as under the ePrivacy Directive and GDPR in the EU/EEA, the parameter's value must reflect valid, separately obtained consent, and the legal analysis remains a distinct obligation from setting the parameter.

Web developers and tag management implementers

Developers and those managing consent management platforms or tag configurations are responsible for wiring the ad_user_data signal so that it accurately reflects a user's consent decision. They should also account for its relationship to other Consent Mode parameters, while noting that the precise implementation values are beyond the scope of this entry and should be verified against current Google documentation.

Legal and compliance counsel

Counsel advising on cross-border operations should assess how ad_user_data fits within the applicable regime, since consent requirements differ across the EU, the UK, and individual US states. The correct configuration depends on facts specific to each jurisdiction and to the consent interface, and no parameter setting guarantees compliance on its own.

Inside ad_user_data

Consent Mode parameter

ad_user_data is one of the parameters used within Google's Consent Mode framework to signal whether a user has consented to the sending of personal data (such as identifiers or user-provided data) to Google for advertising purposes.

Permitted states

The parameter is typically set to either 'granted' or 'denied', reflecting the outcome of the consent interaction captured by the consent management platform (CMP) or the site's own consent logic.

Scope of the signal

ad_user_data specifically concerns the transmission of user data for advertising, and is generally treated as distinct from ad_personalization, which governs the use of that data for personalized ads. The two are separate signals even though they are often set together.

Relationship to the underlying consent

The parameter is a technical expression of a consent decision; it does not itself constitute or capture consent. The validity of the consent it reflects depends on how that consent was obtained and whether it meets the applicable legal standard.

Interaction with the CMP

In most implementations the value of ad_user_data is set by, or synchronized with, a CMP based on the user's choices, and may be updated when the user changes their preferences.

Common questions

Answers to the questions practitioners most commonly ask about ad_user_data.

Does setting ad_user_data to 'granted' mean I have satisfied my consent obligations for advertising cookies?

No. ad_user_data is a signal passed to Google's services indicating whether the user has consented to sending user data for advertising purposes; it is a technical mechanism, not a legal basis in itself. In most EU jurisdictions you must still obtain valid consent under the ePrivacy rules for placing or accessing information on the device and, where personal data is processed, a lawful basis under the GDPR. Passing the signal reflects a consent decision but does not, on its own, demonstrate that the underlying consent was freely given, specific, informed, and unambiguous. The signal supports compliance workflows but does not replace the legal judgment or the record-keeping that a valid consent requires.

Is ad_user_data the same thing as ad_storage, so that setting one covers the other?

No, they address different aspects and should be set independently. ad_storage generally governs whether advertising-related information may be stored on or read from the user's device, which is the area addressed by ePrivacy rules on cookies and similar technologies. ad_user_data generally governs whether user data may be sent to Google for advertising purposes, which relates more to the processing of personal data. Because these can map to distinct consent choices, treating them as interchangeable may misrepresent the user's decision. Each should reflect the specific permission the user has actually given.

How should ad_user_data be wired to my consent management platform?

Typically, a CMP captures the user's advertising-related consent choice and then updates the ad_user_data parameter accordingly, most commonly through Google's consent mode mechanism. The signal should default to a denied state before a choice is made in jurisdictions that require prior consent, and update to granted only after a clear affirmative action. The precise configuration depends on your CMP, your tag management setup, and the categories your CMP presents to users, so the mapping between a user's choice and this parameter should be verified rather than assumed.

What should the default value of ad_user_data be before a user interacts with the banner?

In jurisdictions such as most EU member states and the UK where prior consent is generally required, the default should reflect the absence of consent, meaning the signal is set to denied until the user takes a clear affirmative action. In regimes that rely on an opt-out model, such as certain US state frameworks, the appropriate default may differ. Because obligations vary by geography, the default handling should be aligned to the applicable legal regime for each user, which may require geolocation or region-based logic.

How can I keep a record of the ad_user_data value I applied for a given user?

Consent record-keeping obligations in many jurisdictions call for retaining evidence of what the user was shown and what they chose. In practice this means logging the consent decision that drove the ad_user_data value, along with relevant context such as timestamp and the choices presented, typically within your CMP's consent logging function. The signal value itself is a downstream reflection of that decision, so the authoritative record is the underlying consent event rather than the parameter alone. The specifics of what must be retained depend on the applicable regime and are not fully determined by this parameter.

How do I verify that ad_user_data is behaving as intended before and after consent?

Testing generally involves simulating the pre-consent and post-consent states and confirming that the parameter carries the expected value at each stage, using browser developer tools or the debugging features of your tag management and CMP setup. You may also want to test across the different regional configurations you have implemented, since the expected default can differ by jurisdiction. Verification confirms that the technical signal matches the user's recorded choice; it does not by itself establish that the consent collection meets the applicable legal standard, which remains a separate assessment.

Common misconceptions

Setting ad_user_data to 'granted' makes data transmission to Google lawful on its own.

The parameter only transmits the outcome of a consent decision; it does not create valid consent. Under EU law, consent must generally be freely given, specific, informed, and unambiguous through a clear affirmative action, and the lawfulness of the underlying processing depends on whether those conditions are met, not on how the parameter is configured.

ad_user_data and ad_personalization are interchangeable and can be treated as a single toggle.

They are separate signals addressing different purposes. ad_user_data concerns sending user data for advertising, while ad_personalization concerns using that data for personalized advertising. Conflating them can lead to signaling a level of consent the user did not actually give for a given purpose.

Configuring Consent Mode parameters, including ad_user_data, guarantees compliance with cookie and data protection rules.

These parameters are technical tools that support a consent implementation but do not replace legal judgment. Obligations differ across jurisdictions such as the EU, the UK, and individual US states, and correct parameter configuration does not by itself ensure that consent collection, disclosures, or record-keeping meet applicable requirements.

Best practices

Ensure the value of ad_user_data is driven by the user's actual consent choice captured through your CMP, rather than defaulted to 'granted' without a valid affirmative action where opt-in consent is required.

Treat ad_user_data and ad_personalization as distinct signals, mapping each to the specific purpose the user was asked to consent to, and avoid setting them together unless the consent obtained covers both.

Recognize that this parameter relates to the GDPR's rules on processing personal data for advertising and does not, by itself, address the ePrivacy obligations governing the placing of or access to information on the user's device; verify that both are satisfied.

Align default states with the applicable legal regime, applying prior opt-in consent expectations in most EU jurisdictions and accounting for opt-out based approaches under US state privacy laws where relevant.

Maintain records that link the parameter's value to the underlying consent event, so the consent decision it reflects can be evidenced consistently with consent logging and record-keeping expectations.

Validate the implementation with legal or privacy counsel and monitor evolving data protection authority guidance, rather than relying on the parameter configuration alone to demonstrate compliance.