Basic and advanced Google consent mode differ in when Google tags load and what they transmit while consent is denied. Choose the intended data behavior first, with the people responsible for privacy and measurement, then verify the implementation against that decision.
The technical distinction
Google's consent-mode overview explains the two arrangements. Basic mode blocks Google tags until consent is granted. Advanced mode loads tags with configured default states and can send consent-state and cookieless measurements while consent is denied. “Cookieless” therefore does not mean “no network request.”
Consent mode communicates choices to supported tags. It does not obtain those choices by itself or decide which implementation is legally appropriate for your business. This comparison describes technical behavior, not a legal assessment. A consent-management platform or custom interface, tag configuration and downstream integrations still need to work together.
Write the expected behavior before selecting a mode
| State | Basic design | Advanced design |
|---|---|---|
| Before a choice | Google tags remain blocked under the basic arrangement. | Tags load with configured defaults; denied states can send cookieless measurements. |
| After rejection | Google tags remain blocked when consent is not granted. | Supported tags adapt to the denied state. |
| After acceptance | Load and update supported tags according to the granted choices. | Update the existing tag behavior according to the granted choices. |
| Other vendors | Review separately; do not assume Google's settings control every third-party integration. | |
Inspect the individual consent types your setup uses. Google's documentation distinguishes advertising storage, analytics storage, advertising user data and personalization. One broad “accepted” variable can conceal differences between those purposes. The business's approved choice model should determine the mapping.
A banner is visible, but the loading order is wrong
Illustrative scenario: a site displays a choice interface, but a Google tag executes before the intended default state is set. The interface looks correct in a screenshot. The sequence can still fail the team's specification because the first request happened under the wrong state.
The implementation brief should specify the initial state, tag-loading order, update behavior and persistence of the visitor's choice. Google's consent implementation guidance covers setting defaults and updating them. Verify that the actual request sequence matches the intended design; visual presence of a banner is insufficient evidence.
A second scenario is a GTM setup whose Google tags adapt correctly while a separate third-party script ignores the choice. That is a wider inventory problem. List tags outside GTM, custom code, platform apps and backend forwarding. Check their behavior individually rather than extending a Google-specific success claim to the whole website.
Use a state-based test plan
- Start a clean test context and record the expected default before any action.
- Observe tag loading, requests and storage before the visitor makes a choice.
- Reject the relevant purposes and inspect behavior again.
- Accept the relevant purposes in another clean context and inspect the update sequence.
- Change or withdraw the choice using the site's supported interface.
- Navigate between relevant pages and check that the intended state persists.
- Inspect server forwarding and non-Google tags separately.
Document device, browser, region configuration and test conditions. A result from one region-specific configuration does not establish the behavior everywhere. Do not copy real customer payloads into a public report. Use the safe testing framework to plan the test boundaries and side effects.
Modeling is not a substitute for an approved data design
Google describes different modeling behavior for basic and advanced implementations. That is a product capability, not a promise that a particular account will recover all missing conversions. Eligibility, data availability and the actual implementation affect what appears in reports.
Do not choose an arrangement solely because a dashboard might show a larger number. The required data behavior, business policy and implementation evidence come first. A modeled aggregate is also different from proof that one individual lead or sale was observed and attributed.
A useful decision record
Write down the approved behavior for each state, the systems in scope, the owner of the decision and the evidence required before release. Basic mode fits a technical requirement to withhold Google-tag transmission until permission. Advanced mode fits an approved design that permits the documented denied-state behavior. Neither label establishes compliance.
This article does not describe or change Track & Optimize's own consent or tracking configuration. For implementation work on any website, agree the intended behavior first and keep legal review separate from technical verification.