Google Enhanced Conversions 2026 update: most agencies still haven't checked if theirs works

In June 2026, Google Ads changed how Enhanced Conversions works. The two separate products, Enhanced Conversions for Web and Enhanced Conversions for Leads, each with its own settings screen and implementation method, were merged into a single on/off toggle. 

Google framed it as a simplification, and it is one. But the update also does something less obvious. It removes the visible reminder that Enhanced Conversions is an active system with moving parts, not a switch you flip once and forget. If you set yours up a while ago and haven't looked since, there's a decent chance it's no longer doing anything.

A large share of Enhanced Conversions setups look active in Google Ads while sending little or no usable data. The toggle says on. The conversion action shows activity. But the hashed user data that makes the whole feature work never actually reaches Google in a usable form. Nobody notices, because nothing in the interface screams that something is broken.

Here's what actually changed in June 2026, why Google Enhanced Conversions setups fail without any visible error, how to check if yours is one of them, and why routing the setup through server-side GTM removes most of the failure points in the first place.

What Google Enhanced Conversions actually do

Enhanced Conversions exist because cookie-based conversion tracking has a gap. Google Ads normally attributes a conversion using a GCLID, a click identifier stored in a browser cookie. When that cookie is missing (blocked, cleared, or the user converted on a different device), the conversion still happens, but Google can't tie it back to the ad that caused it.

Enhanced Conversions close part of that gap with a second identifier. When a user converts, your site captures first-party data (usually an email address) and hashes it with SHA-256 before sending it to Google. Google compares that hash against hashes derived from its own signed-in account data. If they match, the conversion gets attributed even without a working GCLID.

That's the whole mechanism: hash, send, match. The hashing runs one-way, so Google never receives a readable email address, only a fingerprint of one.

For the full breakdown, including Enhanced Conversions for Web vs. Leads, match rate mechanics, and setup instructions for each implementation path, see our complete guide into Google Enhanced Conversions.

Google Enhanced Conversions June 2026 update: what changed

Before June 2026, Enhanced Conversions for Web and Enhanced Conversions for Leads were separate features. Each had its own settings screen, and advertisers had to pick one implementation method (the Google tag, GTM, or the API) per conversion action.

Starting in April 2026, Google began accepting user-provided data from website tags, Data Manager, and API connections at the same time, rather than forcing a single method. Starting in June 2026, that flexibility became the default: the two products merged into one feature with a single on/off toggle, and the method selection screen disappeared from the interface entirely.

For agencies managing multiple accounts, three things are worth checking after the merge.

Existing setups were migrated automatically, but only for accounts that had already accepted Google's customer data terms. If a client account never explicitly accepted those terms (common when Enhanced Conversions was enabled by a previous agency or an in-house team that didn't complete the full setup), the migration doesn't happen cleanly, and the account may show Enhanced Conversions as available but inactive.

The interface change hides some of the diagnostic breadcrumbs that used to exist. When method selection was visible, you could at least confirm which implementation path a conversion action was supposed to be using. With that screen gone, verifying the setup now depends more on the diagnostics and less on the settings page matching what you expect.

Opt-out still exists at the conversion action level, and nothing about the merge changes the underlying Data Processing Terms requirement. Google still expects advertisers to have agreed to those terms and to be handling user-provided data in a policy-compliant way. The toggle got simpler but the compliance obligation didn't move.

Working setups keep working. But this is a natural point to check accounts that were set up a while ago and never revisited, because the merge is exactly the kind of change that surfaces problems nobody was looking for.

Why Enhanced Conversions fails silently and how to catch it

Google Enhanced Conversions has a specific failure mode that makes it easy to miss. The conversion tag can fire correctly, the conversion still gets recorded, and Google Ads can show the conversion action as active, while the enhanced data itself never actually reaches Google in a usable state.

Google's own diagnostics report defines several statuses for exactly this reason. "Recording enhanced conversions" means it's genuinely working. "Waiting to receive enhanced conversion data" can mean it's just early, since status can lag up to 48 hours. But "Setup issues detected" and, for leads, an "Urgent" status both point to a setup that looks live but isn't producing anything useful. The gap between those states is where most broken setups sit for months, untouched, while nobody thinks to look.

The most common causes aren't dramatic. They're small configuration details that don't throw an error anywhere:

• The user_data field is present but empty. The tag fires, the wrapper reaches Google, but the hashed email or phone field inside it is blank. Google logs the ping as received and moves on. It doesn't flag "nothing useful was in there." This is usually a GTM variable that was never mapped to the right dataLayer key, and it's the single most common cause of a healthy-looking setup that adds no signal.
• Double-hashing. Some teams hash the email address themselves before pushing it to the dataLayer, then GTM or the Google tag hashes it again before sending. Google ends up comparing a hash of a hash against its own database of single hashes. Nothing matches, ever, and there's no error to point at the cause. The fix is to always send the raw value and let GTM or gtag.js handle the hashing.
• Turning on the toggle without touching the tag. Enabling Enhanced Conversions in the Google Ads interface doesn't automatically reconfigure your GTM tag. If the user_data fields in the conversion tag were never set up, flipping the account-level toggle does nothing except make the setting look active.
• CSS selector breakage after a site redesign. If the original setup captured the email field by targeting a CSS selector on the confirmation page, a redesign that changes element IDs or class names breaks the selector without anyone noticing. The tag still fires. It just stops finding anything to hash. Data layer variables don't have this problem, which is one reason they're the more durable option.
• Consent gating that looks like normal variance. When ad_user_data consent is denied, Enhanced Conversions simply doesn't send the hashed data for that user. That's correct behavior, not a bug, but it means match rate naturally drops in consent-heavy regions. The trick is telling the difference between expected consent-driven variance and an actual technical failure, which is hard to do without checking the numbers directly.

Diagnosing any of this starts with the same two checks: open GTM Preview mode and confirm the user_data object on the conversion tag actually contains hashed values, not an empty object. Then check the network request itself for the em parameter. If it's missing, the tag isn't configured to send it. If it's present but reads something like tv.1~em. with nothing after it, the field is firing empty. Either way, the fix is in GTM, not in the Google Ads settings screen.

How server-side GTM makes Google Enhanced Conversions more reliable

Most of the failure points above share something in common: they happen in the browser, where the tag depends on the page's DOM, the dataLayer being populated correctly, and nothing intercepting the request before it leaves. Moving the setup to server-side GTM doesn't eliminate every failure mode, but it removes several of them by changing where the work happens.

With a server container in place, the browser's job shrinks. It sends the event (with the raw user data) to your own first-party endpoint. The server container, not a browser-side tag, builds the user_data object, applies the hashing, and forwards the request to Google. That single change removes the double-hashing problem entirely, because the hashing logic lives in one place instead of being split between the page and the tag.

It also removes the ad blocker risk. A browser-side Enhanced Conversions tag sends its request from the user's browser, which means an ad blocker or tracking protection feature can intercept or drop it before Google ever sees it. The tag can be perfectly configured and still lose data to something entirely outside your control. A server-to-server request from your container to Google's API doesn't have that exposure, because there's nothing in the browser for a blocker to catch.

Worth noting: the server-side hop only helps if the browser-to-server leg is itself resilient. Make sure you're running the Enhanced Tracking Script from TAGGRS to keep that initial request fully invisible to ad blockers, otherwise the same interception risk just moves one step earlier in the chain.

None of this replaces the need to configure things correctly. A server-side setup with an empty user_data field is still an empty user_data field. But it does mean fewer places where a working configuration can stop working without throwing any error, which is exactly the kind of failure that's hard to catch without actively looking for it. For agencies managing multiple client accounts, that reliability difference compounds quickly – fewer silent failures means fewer audits, fewer gaps in attribution data, and fewer conversations explaining to clients why their conversion numbers don't match reality.

• For the full setup path, including field-level configuration for Google Ads through server-side GTM, see the Enhanced Conversions setup documentation and the Google Ads server-side tracking overview.
• If you're also handling offline conversions from a CRM alongside Enhanced Conversions for Leads, the offline conversion tag documentation covers that specific setup, and this piece on proving real ROAS from offline conversions covers why that data matters for reporting beyond just Smart Bidding.

Google Enhanced Conversions and GDPR: what EU agencies need to know

Enhanced Conversions sends personal data, and hashing doesn't change that classification under GDPR. A SHA-256 hash of an email address is pseudonymized data, not anonymized data, because Google (the party receiving it) can compare it against data it already holds and re-identify the person behind it. The distinction matters: pseudonymized data still falls fully under GDPR, with all the same obligations around lawful basis, consent, and data subject rights.

In practice, that means Google Enhanced Conversions needs the ad_user_data consent signal from Consent Mode V2 to be granted before it fires. If a user denies that consent, the Google tag won't include the hashed data in the conversion hit at all. This is by design, not a bug, and it's the correct compliant behaviour. Aggregate conversion modeling still applies to users who don't consent.

For EU agencies, the practical risk isn't usually Enhanced Conversions itself. It's the setups where ad_storage is granted but ad_user_data was never explicitly configured, so the consent banner technically works, while the underlying signal Google actually checks for Enhanced Conversions was never wired up. The tag fires, data goes out, and there's no consent record backing it. That's a compliance gap that won't show up in a match rate report, because from Google's side, everything looks like it's working. It's the kind of thing you only find if you go looking, and the kind of thing that's expensive to explain after the fact.

Server-side GTM doesn't remove the consent requirement, and it shouldn't. What it does is centralise where consent gets checked. Instead of relying on multiple browser-side tags to each respect the consent state correctly, the server container can gate the entire user-data payload in one place before anything gets sent to Google, Meta, or any other platform.

For the full picture on consent signals and server-side tracking, see the GDPR and server-side tracking guide.

Where TAGGRS fits

Auditing Enhanced Conversions across every client account after a Google update isn't a realistic workflow for most agencies. Nobody has time to open GTM Preview mode for fifty accounts every time Google changes something.

TAGGRS runs Enhanced Conversions through the same server-side GTM container that handles the rest of an account's tracking. Because the hashing and the user_data construction happen server-side instead of across a patchwork of browser tags, there are fewer places where a silent failure like an empty payload or a double-hashed field can creep in without anyone noticing.

The consent gating also lives in one place. Instead of checking whether every browser-side tag on a client's site respects ad_user_data correctly, the server container enforces it centrally, before any user data leaves for Google, Meta, or another platform.

For teams already running Google Ads tracking through TAGGRS, Enhanced Conversions are part of the same pipeline as every other conversion event, which can be monitored at the centralised analytics dashboards inside the TAGGRS account. 

Conclusion

The June 2026 update made Enhanced Conversions easier to turn on and easier to forget about. That's the risk hiding inside a simplification: fewer settings to manage also means fewer visible reminders to check whether the thing you set up months ago is still doing its job.

A setup that looks active in Google Ads can still be sending nothing useful. The only way to know is to check the diagnostics report and the actual network request, not just the toggle. And if the goal is fewer places for that failure to happen in the first place, moving the setup server-side removes most of the browser-dependent points where it tends to break.

Auditing Enhanced Conversions across every client account is exactly the kind of work a server-side setup is meant to save you. You can create a free TAGGRS account to get started, or browse the setup guides if you'd rather see how it works first.

FAQ

What changed with the June 2026 Enhanced Conversions update?

Google merged Enhanced Conversions for Web and Enhanced Conversions for Leads into a single on/off toggle and removed the screen where advertisers picked an implementation method. Existing accounts that had already accepted Google's customer data terms were migrated automatically. The underlying hashing and matching mechanism didn't change.

Why would Enhanced Conversions look active but not actually work?

Because the conversion tag and the enhanced data are two separate things. The tag can fire and the conversion can get recorded normally while the user_data field inside it is empty, double-hashed, or missing entirely. Google Ads shows the conversion action as active either way, since the base conversion is still being tracked correctly.

How do I check if my Enhanced Conversions setup is actually sending usable data?

Open GTM Preview mode, fire a test conversion, and confirm the user_data object contains hashed values rather than being empty. Then check the network request for the em parameter. If it's missing or empty, the enhanced data isn't reaching Google even if the base conversion is tracked.

Does server-side GTM fix every Enhanced Conversions problem?

No. A misconfigured field is still misconfigured regardless of where the hashing happens. What server-side GTM removes is the browser-dependent failure points: ad blockers intercepting the request, CSS selectors breaking after a redesign, and double-hashing caused by logic split between the page and the tag.

Are Enhanced Conversions still GDPR compliant after the update?

Yes, and the requirement didn't change. Enhanced Conversions still needs ad_user_data consent granted through Consent Mode V2 before it can send hashed data. Hashing doesn't make the data anonymous under GDPR, since Google can still match it against account data it holds.

Do I need to redo my Enhanced Conversions setup because of the merge?

Not necessarily. If your account had already accepted the customer data terms, the migration happened automatically. It's still worth checking the diagnostics report, since the merge is a good trigger to catch a setup that was already broken before the update, just without anyone noticing.