Server-side enhanced conversions have become, in 2026, the most reliable way to recover the conversions that cookieless and consent erase from your reports. Since Consent Mode v2 tightened on June 15, 2026, with ad_storage now governing the GA4 to Google Ads flow on its own, many advertisers are seeing a sharp drop in reported conversions. Blocked cookies, ITP and ETP, refused consent: a growing share of real purchases no longer makes it back. The answer is not to patch things on the client side, but to send hashed first-party data (SHA-256 email and phone) from your server container alongside the conversion event. The gain typically measured is 10 to 20% more conversion volume, with better ROAS and, crucially, without breaching the GDPR.
The problem in numbers: why your conversions are dropping
Client-side tracking relies on cookies that browsers are dismantling one by one. Safari (ITP) caps JavaScript-set first-party cookies at 7 days, Firefox (ETP) applies similar rules, and blocking extensions strip the tags outright. The well-known result: depending on the audience, 15 to 40% of hits never reach their destination.
On top of this technical erosion comes a regulatory one. Since June 15, 2026, the Google Signals setting no longer acts as a safety net: the ad_storage parameter alone decides whether a conversion reaches Google Ads. When a user refuses advertising cookies, the conversion still exists (the purchase happened) but it is no longer attributed. That is the gap you see between your real sales, your GA4 numbers, and your Google Ads figures.
Enhanced conversions tackle the root cause: instead of relying on an identifier stored in the browser, they use a piece of data the customer has already given you willingly, their email or phone number, to rebuild the link with the user’s Google account.
Quick table: loss source, mechanism, expected gain
| Loss source | Enhanced Conversions mechanism | Expected gain |
|---|---|---|
| Blocked cookies (ITP / ETP) | Matching via hashed email or phone, no cookie | +5 to 12% |
ad_storage refused with no other legal basis | Transmission gated on consent (no unlawful gain) | 0% (compliance preserved) |
| Cross-device attribution gap | Reconciliation on first-party identity at Google | +3 to 8% |
| Hits lost before destination | Server-side collection via Measurement Protocol | +2 to 6% |
These ranges stack up toward the 10 to 20% figure that gets quoted. They depend on your email capture rate at conversion: an e-commerce funnel with customer accounts recovers far more than an anonymous form.
How server-side enhanced conversions work
Three technical building blocks combine: SHA-256 hashing, the Measurement Protocol, and the regional routing introduced in 2026.
SHA-256 hashing of first-party data
You never send the email in clear text. Before sending, the value is normalized (lowercased, whitespace stripped, E.164 format for phone numbers) then turned into an irreversible SHA-256 digest. Google applies the same hash on its side and compares the digests. If they match, the conversion is attached to the signed-in user’s account. No one “decrypts” the email: two digests are compared.
Normalization is the step that breaks most implementations. An email with an uppercase letter or a trailing space produces a different digest, so no match. Here is the expected normalization for an email:
function normalizeEmail(email) {
return email.trim().toLowerCase();
}
async function sha256(value) {
const data = new TextEncoder().encode(value);
const buffer = await crypto.subtle.digest('SHA-256', data);
return Array.from(new Uint8Array(buffer))
.map((b) => b.toString(16).padStart(2, '0'))
.join('');
}
On the GTM Server-Side end, most Google tags apply the hashing automatically if you feed them the clear value inside the server container (which stays under your control). The key point is to never let the clear value leave for Google: it is the digest that travels.
The Measurement Protocol and 2026 regional endpoints
The Measurement Protocol lets you send events to GA4 directly server to server, with no browser involved. It is the channel that carries the enriched conversion when client-side has failed. In 2026, recommended implementations route the call to a regional endpoint based on the user’s location, which cuts latency and clarifies data residency. You select the region in the server container rather than always hitting the global entry point.
The principle is still that of a proxy: the browser sends the event to your subdomain, the server container enriches it with hashed user data (if consent allows), then relays it to Google. For the basics of server-to-server collection, the GTM Server-Side migration guide remains the essential prerequisite.
Step-by-step setup in GTM Server-Side
The implementation assumes a server container already deployed (Cloud Run or equivalent) and a web container that pushes the right data into the dataLayer.
Step 1: expose first-party data in the dataLayer
At conversion time (confirmation page, purchase event), push the email and, when available, the phone number. This data must be clean at the source. If your events are fragile, fix collection first: see the 7 GA4 dataLayer mistakes that skew your data.
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'purchase',
user_data: {
email: '[email protected] ',
phone_number: '+33 6 12 34 56 78'
},
ecommerce: {
transaction_id: 'T-10293',
value: 89.90,
currency: 'EUR'
}
});
Step 2: pass the data to the server container
The web container’s GA4 tag must include the user_data field so the data reaches the server. Only in the server container, under your control, will the hashing and sending happen.
Step 3: configure the conversion tag server-side
In the server container, the GA4 client receives the event. You then add the Google Ads Conversion tag (or the GA4 tag with enhanced conversions enabled) and map user_data.email and user_data.phone_number to the identity fields. The tag normalizes and hashes before sending. Make sure the mapping points to the clear value received from the web, not to an already transformed one.
Step 4: gate sending on consent
Before any user data is transmitted, read the consent state passed by Consent Mode. If ad_user_data (or the applicable legal basis) does not allow user data usage, the tag must not send the identity. You can still send the anonymous conversion event, but without identity fields. The exact framework is covered in Consent Mode v2 in GA4: what changed on June 15, 2026.
GDPR compliance box
Enhanced conversions process personal data: a hashed email is still personal data under the GDPR. Three non-negotiable rules frame the setup.
First, prior consent. User data is transmitted to Google only if the user has allowed it, through your banner wired to Consent Mode. SHA-256 hashing is not anonymization: it lowers exposure but does not remove the need for consent.
Second, transparency. Your privacy policy must mention the use of contact data for advertising measurement, as well as the transfer to Google. The “measurement and attribution” purpose must be readable by the user.
Third, minimization. Transmit only what is needed for matching (email, possibly phone) and nothing more. Document the flow in your records of processing. When the legal basis is unclear, explicit consent stays the safest path, since it aligns directly with the ad_user_data signal.
Validation checklist
Once the setup is in place, validate before you trust the numbers.
On the collection side, open the server container preview (debug mode) and trigger a test conversion. Confirm in the server stream that user_data arrives in clear text, then that the outgoing tag sends a digest and not the email. GA4 DebugView and Tag Assistant confirm the event was received.
On the Google Ads side, open the conversion action details: the enhanced conversions status should move to “Recording enhanced conversions” after a few days of data. Diagnostics flag hashing or mapping errors if the digest is malformed.
On the consent side, run the test twice, once accepting and once refusing. On refusal, the tag must transmit no identity data: this is the most important check, because it is what keeps the conversion gain lawful.
Once all three checks are green, compare conversion volume before and after over two to three weeks. That is the window needed to measure the real lift on your campaigns. To audit the gap at the source and cross-reference raw data, the GA4 BigQuery export remains the most precise tool. And if you are starting from scratch on defining your conversions, begin by setting up GA4 from scratch.
The bottom line
Server-side enhanced conversions are not a way around consent: they recover conversions lost for technical reasons (cookieless, ITP, ETP) while strictly respecting the user’s choice. Implemented well, with clean first-party data, correct SHA-256 hashing, and sending gated on consent, they bring back an average of 10 to 20% of conversions in your reports and give Smart Bidding the signal it needs. It is the brick that connects a high-performing server-side container to compliant advertising measurement in 2026.