Google Ads server-side configuration requires two tags working together, and understanding why each exists is important for getting the setup right. Most implementations get the Conversion Tracking tag deployed correctly and miss or misconfigure the Conversion Linker — which quietly breaks attribution entirely.
The Two Required Tags
Conversion Linker Tag
The Conversion Linker fires on every page view (not just conversion events). Its job is to manage the FPGCLAW cookie — a first-party cookie that stores the gclid click identifier when a user arrives from a Google Ads click.
Without the Conversion Linker, there’s no mechanism to connect a later conversion event back to the original ad click. The conversion tag fires, the conversion is recorded, but Google Ads can’t attribute it to the specific campaign, ad group, or keyword that drove the visit. The conversion appears in your account but attribution is broken.
Configure the Conversion Linker to fire on a trigger that runs on all page views. The built-in Google tag trigger type works, or you can use a Custom trigger with a condition that always evaluates to true. The tag requires no additional configuration beyond the trigger — Google handles the cookie management automatically.
The FPGCLAW cookie is set by the server via HTTP Set-Cookie header, which gives it the same first-party cookie longevity benefits as the GA4 FPID cookie. A gclid stored as a server-set cookie survives Safari ITP’s 7-day cap; the same click ID stored as a JavaScript cookie might expire before a user converts.
Conversion Tracking Tag
The Conversion Tracking tag fires on specific conversion events: purchase confirmations, lead form submissions, phone call clicks — wherever your conversion actions are defined in Google Ads.
Configure it with:
- Conversion ID: found in your Google Ads account under the conversion action settings (format:
AW-XXXXXXXXXX) - Conversion Label: the action-specific label string from the same settings
- Conversion Value: map to your transaction value variable if tracking purchase revenue
- Currency Code: ISO 4217 code (e.g.,
USD,EUR)
The Conversion Tracking tag reads event data that the GA4 Client has already parsed from the incoming request. If the event_name is purchase, your trigger should check for that event name from the GA4 Client — and remember: the Client Name condition is case-sensitive.
Enhanced Conversions
Enhanced Conversions improves attribution when cookies fail. Instead of relying solely on the gclid cookie to connect clicks to conversions, Enhanced Conversions sends hashed user data (email, phone, name, address) that Google matches against signed-in Google accounts.
The technical implementation happens primarily in the web container, not the server container:
Step 1: User-Provided Data variable. In the web container, create a Variable of type “User-Provided Data.” Map it to your form fields:
- Email address
- Phone number
- First and last name
- Street address, city, state, postal code, country
These should read from your checkout or lead form fields — either from the data layer or directly from DOM elements. The variable captures what the user actually typed, before the form submits.
Step 2: Add user_data to GA4 tags. Add the User-Provided Data variable as the user_data parameter on your GA4 Configuration Tag and your conversion event tags. This ensures the user data travels with the hit to your server container.
Step 3: Server container. The Google Ads Conversion Tracking tag in your server container reads user_data from the incoming event data. If you’ve configured step 2 correctly, the data is already in the event — the tag picks it up automatically.
Google SHA-256 hashes the data before sending it to their matching systems. The matching happens on Google’s side against their signed-in user database. You’re not sending raw PII to Google — the hashing happens at the tag level.
Validation takes approximately 48 hours. After implementing, check the Diagnostics tab in your Google Ads conversion action. It should show “Recording enhanced conversions” with a green status. If it shows warnings, the most common causes are:
user_datanot being populated on conversion events (check your data layer)- The variable reading from an element that doesn’t exist on the conversion page
- User-Provided Data format not matching what Google expects (phone numbers especially have format requirements)
What to Expect
Enhanced Conversions typically shows a 5-25% uplift in reported conversions. The range is wide because it depends heavily on how many of your converting users are signed in to Google accounts, and how often cookies are the current gap in your measurement.
Sites where users are frequently signed in to Google (Gmail, Google account, Android) will see higher uplift. Sites where the converting audience skews toward Apple ecosystem users on Safari — where cookies were already being recovered by the server-side FPGCLAW — may see lower incremental gain from Enhanced Conversions specifically.
The 48-hour validation window before Enhanced Conversions start flowing means you can’t immediately verify the setup through conversion volume. Use the Diagnostics tab signal instead. Once Diagnostics shows healthy status, trust that conversions will appear in the following cycles.
Interaction With Consent Mode
Google Ads server-side tags read [[Consent Mode Server-Side GTM Propagation|consent state automatically from the gcs and gcd parameters]] encoded in incoming requests. When ad_storage is denied, the Conversion Tracking tag adjusts its behavior — it may still send a cookieless ping to model the conversion, but it won’t include identifying cookie data.
Enhanced Conversions specifically requires ad_user_data consent granted. If a user hasn’t consented to ad data use, hashed user data must not be sent to Google. This is enforced automatically by the server-side Google Ads tag when consent parameters are present — but the consent parameters must be flowing correctly from the web container. [[GTM Server-Side Common Failures#Consent Signals Not Reaching the Server|Stripping or malforming the gcs/gcd parameters]] in transit breaks this automatic enforcement.
Duplicate Tags Trap
One common failure in Enhanced Conversions setups: the Google tag appears both in the site’s HTML <head> and in GTM, loaded from two places simultaneously. The hardcoded tag doesn’t have access to GTM’s consent state. The GTM-loaded tag respects consent. Result: conversions are being recorded even for users who denied consent, via the hardcoded tag that bypasses consent entirely.
If your implementation uses GTM for tag management, remove any hardcoded Google tags from the site HTML. The GTM-managed version should be the single source.