How We Fixed a 40% Conversion Drop Caused by Consent Mode Misconfiguration
An ecommerce brand lost 40% of Google Ads conversions after a CMP switch. The banner worked, but consent never reached Google. Here is what we found and how we fixed it.
The situation
An ecommerce brand came to us in late 2025. They had switched to a new consent management platform a few months earlier. Everything looked fine at first. The banner appeared. Users could accept or reject. The CMP vendor had promised full Consent Mode v2 integration.
Then conversions started to drop. Not overnight, but steadily. By the time they reached out, Google Ads was reporting about 40% fewer conversions than before the switch. Spend was the same. Traffic was the same. Something was broken.
They had already tried the usual things. Checked that GA4 was receiving events. Verified the conversion tag was still on the thank-you page. Confirmed the GA4 to Google Ads link was intact. Nothing obvious was wrong. GA4 showed purchases. Google Ads showed almost nothing. That disconnect is a red flag. When GA4 tracks and Ads does not, the problem is usually in how consent signals reach Google. We explain this in why Google Ads conversions break.
What we suspected
When GA4 tracks events but Google Ads does not attribute conversions, the problem is almost always consent. Google Ads is stricter about consent signals than GA4. If Consent Mode v2 is not configured correctly, or if consent updates never reach Google, Ads will suppress conversion attribution even when the conversion request is sent.
We suspected the new CMP was not calling gtag consent update when users clicked Accept. The banner handled the UI. It stored the user's choice. But it never told Google. So from Google's perspective, every user was still in the default denied state. No consent, no attribution.
Running the scan
We ran a ConsentCheck scan on their site. The scan loads the page as a new visitor, simulates reject and accept, and watches what happens to tracking and consent signals.
The results were clear. Consent Mode v2 was detected. Default denied was set correctly before tags loaded. But when we clicked Accept on the banner, nothing changed. No gtag consent update fired. No change in the consent parameters on subsequent requests. The dataLayer showed the same consent state before and after the user accepted.
The CMP was collecting consent. It just was not passing it to Google.
The root cause
The CMP had a Consent Mode integration option. It was enabled. But the integration was incomplete. The CMP knew when the user accepted. It did not call gtag consent update. So the consent state in Google's systems never changed. Every user stayed in the default denied state. Google could not attribute conversions because it had no consent signal to work with.
This is one of the most common Consent Mode v2 mistakes. The banner works. The CMP works. But the bridge between the CMP and Google is missing. For more on this pattern, see our guide on why consent state never updates.
The fix
We did not need to replace the CMP. We needed to wire it to Google correctly.
The fix was to add a consent callback. When the user clicks Accept, the CMP fires an event. We added a listener that calls gtag consent update with the granted states. When the user clicks Reject, we call it with denied. Simple.
The implementation took about an hour. We added the callback in GTM so it would run on every page. We tested in incognito. Reject, check the network. Accept, check again. The consent parameters changed. The fix was live.
The exact code depends on your CMP. Most CMPs expose a callback or event when the user makes a choice. You hook into that and call gtag consent update. For the correct default denied setup that must run before any tags, see gtag consent default denied.
The result
Within a few days, conversions started flowing again. Not instantly. Google needs time to process. But within a week, the numbers were back to where they had been before the CMP switch. The 40% drop reversed.
We ran another scan to confirm. Consent Mode v2 now showed as fully configured. Consent updates fired on Accept. The report passed.
What we learned
First, do not assume CMP integration works just because it is enabled. Many CMPs have Consent Mode options that are incomplete or misconfigured. Test it. Run a scan. Click Accept and see if consent actually updates.
Second, the gap between GA4 and Google Ads is real. GA4 can show events when Google Ads does not attribute them. When that happens, consent is usually the cause. See why GA4 and Google Ads show different numbers for the full picture.
Third, a quick scan can save weeks of guessing. We could have spent days digging through GTM, checking tag firing order, and testing conversion flows. The scan told us in 30 seconds that consent never updated. That focused everything.
How to check your own setup
If you have seen a conversion drop after a CMP change, or if GA4 shows events but Google Ads does not, run a free scan. Paste your URL at ConsentCheck. The scan checks consent signals, tracking behavior, and whether consent updates fire when users accept or reject. No login required.
For a deeper dive on Consent Mode v2 configuration, see how to check if Consent Mode v2 is working and common Consent Mode v2 mistakes. If you use server-side GTM, consent must be passed to the server as well. See how to pass consent from CMP to server-side GTM.
Run a free scan
See if consent or tracking is breaking your Google Ads conversions. No login required.
Run Free Scan