Enhanced conversions, consent mode v2 and you.

The two pieces of measurement infrastructure that every paid-media account in the EU should now have are Enhanced conversions and consent mode v2. They are independent but related; both address signal loss caused by the deprecation of third-party cookies and tightening privacy law. Both are getting easier to implement than they were two years ago. And both are still done badly more often than not. Here’s the working version of how we set them up.

Enhanced conversions: what it actually does

Enhanced conversions sends hashed first-party data — usually email address, sometimes phone number or postal address — alongside the conversion event to Google. Google matches the hash against logged-in user data and recovers conversions that would otherwise have been lost to cookie deletion or cross-device journeys. Real-world uplift varies; in our portfolio we see 8% to 22% additional reported conversions for clients who implement properly. The variation is mostly explained by how clean the source data is.

Two implementation paths, one preferred

You can implement Enhanced conversions via the JavaScript tag (client-side) or via the Google Ads API offline conversion import (server-side). We strongly prefer server-side, with one exception. Server-side gives you a single auditable point of conversion data, lets you enrich the conversion with offline events (refunds, qualified leads, sales-stage transitions), and is robust to the AdBlock and ITP attacks that increasingly break client-side firing. The exception: if you genuinely cannot operate a server-side endpoint, the Tag-based path with the Enhanced conversions form-element selectors is acceptable as a starting point, but plan to migrate.

Server-side implementation outline

The shape of a working server-side Enhanced conversions integration is:

1. Conversion event is captured in your application database with a click identifier (GCLID) and the user’s identifying information.
2. A scheduled job — we run it every 15 minutes — queries new conversions and posts them to the Google Ads API UploadClickConversions endpoint.
3. The user identifying fields (email, phone) are SHA-256 hashed, lowercased and stripped of whitespace before being included in the upload.
4. If a conversion lacks a GCLID but has a hashed user identifier, fall back to UploadConversionAdjustments with user-identifier matching.

One detail almost everyone gets wrong: the “conversion action” you reference in the API call must be configured as “Include in ‘Conversions’” and have the appropriate conversion_environment setting. A misconfigured action will accept uploads silently and never affect the bidding signal you’re trying to improve.

Consent mode v2: the version everyone cared about

Consent mode v2 was a hard requirement from March 2024 for any advertiser using EEA-resident user data in Google Ads or GA4. The change from v1 was the addition of ad_user_data and ad_personalization consent signals on top of the existing ad_storage and analytics_storage. Most consent platforms (Cookiebot, OneTrust, Iubenda, Usercentrics, the major CMP players) shipped support during 2024.

What v2 actually requires from you

• Your CMP must be configured to send the v2 signals on the user’s consent state — not just the v1 storage signals.
• Your gtag or GTM container must read those signals and pass them to Google Ads on every event.
• If you operate in “basic” consent mode (no consent = no Google tags fire at all), you lose roughly 60% to 70% of conversion data on EEA traffic.
• If you operate in “advanced” consent mode (no consent = pings sent without identifiers, modelled conversions filled in by Google), you keep roughly 80% to 90% of conversion data, with a small accuracy hit on the modelled portion.

Advanced consent mode is the right default for any business where conversion data drives bidding strategy. The accuracy trade-off on the modelled conversions is real but small enough to be worth the recovered signal volume.

Common mistakes we see on takeover audits

• Consent signals fire on page load instead of on interaction with the consent banner. Result: every visitor counts as “granted” consent regardless of their actual choice. This will fail any privacy audit and is technically non-compliant; it will also mask legitimate consent-related traffic patterns.
• Enhanced conversions implementations that hash but don’t lowercase the email. Match rates drop by half.
• Server-side endpoints that don’t deduplicate the conversion ID. Same conversion gets uploaded multiple times; bidding overcounts. We see this on roughly one in three takeover audits.
• Conversion actions configured as “secondary” rather than “primary for goal”, with no acknowledgement that this means the conversion has zero effect on the bid strategy.

What good looks like

The simplest health-check question to ask of any account: open the Conversions section of Google Ads, find the conversion action you care about, and confirm three things. One: it has a green “Recording conversions” status. Two: the “Enhanced conversions” column shows “On” with a recent diagnostic. Three: the conversion is marked “Primary for goal”. If any of those three is wrong, the account is leaving money on the table.