Handling changes to a website's consent settings

A consent-banner change can alter conversion data even when the campaign and website sales are stable. Treat it as a tracking release: document what changed, test every permission state and mark the date in reporting.

Map the current flow

List each browser tag and server event, the data it sends and the rule that permits it. Check whether a declined choice blocks or changes the relevant route. Record the tag or event, destination, consent type and expected behaviour for granted and denied choices.

For example, map the site's choice about storing information about behaviour to a Google Analytics tag only if that is the consent type its configured check uses. Record Google Ads, third-party tags and custom server routes separately against the consent checks they actually use.

Locate the consent settings in the site's Consent Management Platform (CMP) or custom consent solution, and note where the choice is communicated to tags. Many CMPs send consent state to Google; a custom consent solution needs a method to communicate that state, and Google Tag Manager can use built-in checks or custom configurations to help tags respect it.

Google consent mode has basic and advanced implementations. Basic blocks Google tags until consent; advanced loads tags with default settings and adjusts their behaviour based on consent, allowing more detailed conversion modelling. Google tags may limit data collection when consent is denied and use pings to communicate consent status and key events; this does not automatically govern a social platform's pixel or a custom server integration.

For Australian operations, check OAIC guidance on tracking pixels and privacy obligations alongside the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs). The Act sets the APPs as standards for handling personal information, including its collection, use, disclosure and storage; review their application with the privacy owner rather than treating a technical workaround as permission.

Google Consent Mode: Basic vs Advanced Implementation

Test before and after release

Before publishing, save a dated version or change-log entry for the consent configuration. Record the old and new settings, affected consent types and tags, consent-mode implementation, test results and a rollback step; keep the previous configuration available in case the release fails testing.

Use a clean browser profile and repeat the test for each consent type in granted, denied and changed-choice states. In the network tab, check the request destination, tag or event and any consent state communicated; check server logs for the test conversion and whether it followed the mapped route.

For a granted choice, pass when the mapped tag follows its permitted route and the request matches the data recorded in the map; fail if a tag follows a route not permitted by the choice. For a denied choice, check the map's expected behaviour: basic-mode Google tags stay blocked until consent, while advanced-mode tags adjust to the denied state and may send consent-mode pings.

Do not treat every request in advanced mode as a failure: Google consent-mode pings communicate consent status and key events. Check that the observed behaviour matches the selected implementation and the denied state, and that third-party tags or custom routes follow their own mapped rules.

Change a saved choice during the test, then revisit the page. Confirm the updated preference is reflected in the banner and mapped tag behaviour, persists as expected, and does not permit an event to fire unexpectedly twice.

Check that event IDs, value and currency remain correct where sending is allowed. Inspect network requests and server logs for the permitted test conversion, and compare the observed route with the consent map.

Annotate dashboards with the release date and compare platform events with an independent business count. A lower reported conversion rate after the change may reflect reduced observation, worse campaign performance or both.

If a test fails, restore the previous consent configuration and repeat the permission-state checks before releasing again. Do not “repair” the difference by sending unpermitted events from the server; fix the implementation, explain the measurement break and evaluate business outcomes with the limitation visible.

Testing Consent Settings Changes: Key Steps for Australian Websites