CCPA Compliance Implementation: After opt-out, Advertising tags send the correct downstream signal (GPP / IAB US National)

Overview

This check confirms that when an advertising tag classified under your "CCPA Sale/Share" label does still fire in a limited-use or consent-gated context, it passes the correct downstream consent signal so the receiving vendor also honors the opt-out on its own systems. There isn't one universal variable name to check, most vendors converge on the IAB's standard strings (the legacy US Privacy String, us_privacy/usprivacy, and the newer Global Privacy Platform string, gpp/gpp_sid), but several of the largest ad platforms instead expose their own proprietary flag that has to be checked by name. A short reference, current as of this writing: always confirm against the vendor's own current documentation, since these names and formats do change:

Vendor / Tag	Variable or parameter to check	Notes
Google Ads / Floodlight (gtag.js)	`restricted_data_processing`	Google's own CCPA flag, set via `gtag('set', 'restricted_data_processing', true)` - separate from the IAB strings and won't show up in a `us_privacy`/`gpp` search.
Meta / Facebook Pixel	`dpo`, `dpoco`, `dpost` (Limited Data Use / `dataProcessingOptions`)	Meta's LDU flags, set via `fbq('dataProcessingOptions', ['LDU'], state, country)`; distinct naming from the IAB strings.
The Trade Desk	`usprivacy`, and increasingly `gpp` / `gpp_sid`	Appended as pixel/tag call parameters; TTD has been an early GPP adopter.
Criteo	`us_privacy`	Appended to the OneTag/pixel call.
Amazon Ads	`us_privacy`	Appended to Amazon's ad tag calls.
Adobe Advertising Cloud / AAM	Consent passed through Adobe's Experience Platform Web SDK `Consent.setConsent()` call, not a single fixed tag-level parameter	Verify against your specific Adobe implementation; the variable name is implementation-defined rather than a fixed string like the others.

Note: This guide is provided for informational purposes only and does not constitute legal advice. Consult qualified legal counsel regarding your organization's specific CCPA/CPRA compliance obligations.

Why it is important

Opting a tag "off" on your own site is only half the compliance surface; where a tag legitimately still fires (for example, under a service-provider relationship or a limited-use exception), it must communicate the opt-out state downstream so the receiving vendor doesn't independently process the data as if consent were granted. A tag that fires correctly gated but carries a stale or default "opted-in" privacy string effectively defeats the opt-out at the vendor's end, even though your own site behaved correctly, and because Google's and Meta's flags don't contain the strings "us_privacy" or "gpp" at all, a check that only looks for those two substrings will silently miss them entirely.

Implementation

Run a Tag Variables audit against every tag labeled "CCPA Sale/Share," under both the Accept-All and Reject-All/GPC consent states.
Check the pre-built ObservePoint report for Advertising Tags Missing us_privacy or GPP Signal — this generic report catches any tag whose variable name contains "us_privacy" or "gpp", which covers The Trade Desk, Criteo, Amazon, and any other vendor using the IAB-standard names, but it will NOT catch Google's restricted_data_processing or Meta's dpo/dataProcessingOptions flags since those names don't match either substring.
For Google Ads/Floodlight and Meta Pixel tags specifically, build a second, vendor-scoped report (or extend this one in the report builder UI) filtering TAG for "Google Ads"/"Floodlight" or "Meta Pixel"/"Facebook Pixel" and TAG_VARIABLE_NAME for their own flag names from the table above, a tag missing from both this vendor-scoped check and the generic 34265 report is the one you need to fix.

Remediation

For remediation, follow the next steps:

Where the opt-out signal variable is missing entirely, work with the tag configuration (typically in the tag manager's variable settings) to bind the CMP's consent state directly to the correct vendor variable (us_privacy/gpp for IAB-standard vendors, restricted_data_processing for Google, the LDU flags for Meta) rather than hardcoding a static value.
A hardcoded "opted-in" default is a common root cause when a tag was configured before the CMP integration was finalized. Where the variable is present but encodes the wrong value under opt-out, confirm the CMP's consent-string output matches what the tag expects, since a mismatch here is often a CMP-configuration issue (wrong category mapping) rather than a tag-configuration issue.
Re-run both the generic and vendor-scoped Tag Variables reports after remediation and confirm the correct signal value appears under both the Reject-All and GPC states.

Conclusion

This check closes the loop between "we stopped the tag from firing" and "we told the vendor the visitor opted out," which matters specifically for the tags your business has determined must still run under a service-provider or limited-use exception, and because the largest ad platforms don't all speak the same signal name, a single generic report isn't enough on its own; pair it with the vendor-specific checks above, and revisit the variable table periodically since vendors continue rolling out native GPP support that can change the expected name.