Consent Mode v2, Tag Order, and a Post-Enforcement Conversion Drop
Luma Health operates in the EU and UK. After enforcing Consent Mode v2 in March, its GA4 property shows a 28% drop in purchase key events and Google Ads shows a 31% drop in imported conversions. The CMO wants to 'turn off the banner for returning visitors' to recover numbers. The implementation uses a CMP that fires a default consent state of denied for analytics_storage and ad_storage, then updates to granted after acceptance. A recent audit found that the Google tag loads before the CMP in the page source on 20% of page views, and that ads_data_redaction is not enabled. The team has a 30-day Google Ads conversion volume of 1,100 before consent enforcement and 760 after. They ask whether the drop is a tracking bug or expected, and how to improve measurement without violating consent.
1. Is the 28–31% drop a tracking bug, expected consent impact, or both? Diagnose the specific implementation issues.
Read the worked answer
Both, and the two need separate treatment. A drop after consent enforcement is expected: users who deny analytics_storage and ad_storage will not be measured the same way, so observed purchases and imported Ads conversions fall. That is the intended privacy outcome, not a tag failure.
The audit findings are real defects:
- If the Google tag loads before the CMP sets the default consent state on 20% of page views, tags can fire before consent is known. Consent Mode requires the default to be established before any Google tag loads, then updated on interaction. That can cause both over-collection and unreliable modeling.
ads_data_redactionnot enabled is a configuration gap for ads data when consent is denied; fix it to match policy.- Check that the CMP updates all required consent types, not just analytics, and that the update reaches the tag before conversion events.
So: fix tag order and redaction, then measure the remaining drop as consent impact. Do not label the whole drop a bug.
2. The CMO wants to disable the banner for returning visitors. Evaluate and propose alternatives that improve measurement without violating consent.
Read the worked answer
Disabling the banner for returning visitors is not a measurement fix; it removes the choice those users are entitled to and would make the consent signals untrustworthy. It also risks regulatory exposure and could invalidate the property's modeling eligibility. Reject it.
Legitimate alternatives:
- Fix the tag/CMP order so every page has a valid default before tags fire.
- Ensure the CMP is configured for Consent Mode v2 and passes the required ad user data and ad personalization signals in the EEA and UK.
- Use consent-mode modeling where eligible: behavioral modeling for analytics and conversion modeling for Ads can estimate some denied traffic, but only at sufficient volume and only if the implementation is correct. Do not promise a specific recovery percentage.
- Improve the value exchange in the banner and test copy to raise opt-in, rather than removing choice.
- Use aggregated, consented first-party data (CRM, offline conversions) for the gaps that matter.
Measure the opt-in rate and modeled-conversion eligibility separately from raw event counts.
3. What would you check in Tag Assistant or DebugView and in Google Ads to confirm the fix before re-forecasting?
Read the worked answer
In Tag Assistant or DebugView, load a fresh session with consent denied and confirm: the default consent state appears before the Google tag, config, and event requests; no purchase or generate_lead hit is sent with granted storage before the user acts; after acceptance, a consent update is sent and subsequent events carry the updated state. Check that the CMP does not reload the page and lose the update. Check ads_data_redaction behavior on an ads click with denied consent.
In Google Ads, confirm the imported conversion action is still recording, that the conversion source is GA4, and that the counting setting and attribution window have not changed. Compare a 7-day pre/post window on the same channel mix, not a raw month-over-month total. Check whether modeled conversions are appearing in the UI and whether the property meets eligibility. Re-forecast with a range: observed conversions plus eligible modeled conversions, not a single recovered number.