One Year of Zero Google Ads Conversions: A Consent Mode Defaults Story

An ad account spent for over a year and recorded exactly zero Google Ads conversions. The conversion action's “last activity” timestamp was frozen at August 23, 2024. A full year with no conversions, while the budget kept flowing. The first instinct is to blame the landing page or the offer. This time, the problem was locked inside the consent code itself.

GA4 was fine. Google Ads was not.

Our first assumption was that consent mode had broken everything. It had not — not evenly, anyway. In the consent updates fired on page load and on preference save, analytics_storage was actually granted. The site's Performance preference was on by default, so GA4 had been collecting data normally the whole year.

The three Google Ads permissions were a different story. ad_storage, ad_user_data, and ad_personalization were denied for effectively 100% of visitors, with no path to change it. Conversion events never left the browser, so the account recorded zero conversions for a year while spend continued.

The root cause: the default value itself

The site had a cookie preference panel — opened manually from the footer, not an intrusive popup. The Marketing toggle in that panel defaulted to off. In the consent default code, all four permissions were set to denied by default, with no wait_for_update. The code did call consent.update on startup and on preference save — and that call was working perfectly. It was faithfully translating a “default off” preference into denied permissions.

The bug was not a missing update call. The bug was that the default value itself was a denial. No amount of update logic could rescue a consent state that started every session locked.

The fix: granted by default, regional exceptions

We changed the consent default to granted for all four permissions, with a small regional exception block keeping the EU and UK at denied — four lines of insurance. The footer preference panel stayed exactly where it was: visitors who want to opt out still can, explicitly and at their own initiative. We only stopped defaulting to no before anyone had chosen.

One rule: do not delete the consent code. Under Consent Mode v2, an uninitialized tag is a signal Google has to guess about, and Ads behaves less predictably uninitialized than explicitly granted. Keeping explicit defaults and regional exceptions is the safer, more explainable configuration.

Reusable checklist

1. Check the conversion action's “last activity” date. A frozen timestamp with ongoing spend is the classic sign.
2. Use Tag Assistant or the Network tab to confirm whether the Ads tag fires and consent is read at all.
3. Separate GA4 permissions from Ads permissions — one can be granted while the other is denied.
4. Read the consent default block. Check both the values and whether wait_for_update is present.
5. Verify the preference panel actually presents itself. A panel that never shows cannot ever grant consent.
6. Change the defaults and add regional exceptions. Do not delete the consent code.

A year of blind ad spend ended with a six-line configuration change, and the fix taught our whole team a lesson about defaults: a consent system that works mechanically can still be strategically wrong. Designing consent defaults, auditing tags, and automating the fix is exactly the work our ads automation module at iport does — one of the real cases that shaped our approach.