How to Set Up Enhanced Conversions in Google Ads via Server-Side Tagging

Browser-based conversion tracking has become unreliable. Safari's Intelligent Tracking Prevention, Chrome's cookie deprecation, and ad blockers all interfere with pixel-based signals. Enhanced Conversions solve this by letting you send hashed customer data (email, phone, address) directly to Google's servers. Server-side tagging eliminates the middleman: your backend talks to Google without relying on browser cookies or third-party pixels.

This setup requires three components: a server-side tagging container, a Google Ads conversion tag, and hashed customer identifiers from your conversion source. The process is straightforward, but each step must be configured correctly to avoid losing conversion credit.

What you'll achieve: Conversions tracked even when cookies are blocked, improved match rates between your customer data and Google's network, and clearer attribution across devices and sessions.

Understand the Data Flow

enhanced conversions work by matching customer identifiers in your data to Google's user graph. When a customer completes a purchase, your backend collects their email, phone, or address. You hash these values using SHA-256 (a one-way encryption), then send them to Google alongside the conversion value and timestamp. Google matches the hashed data to accounts in its network, crediting the ad that drove the conversion.

Server-side tagging sits between your website and Google. Your backend sends conversion events to your tagging server instead of directly to Google. The server-side container then routes the data to Google Ads, applying any transformation or validation rules you've set. This architecture keeps sensitive customer data off the browser and gives you a single source of truth for conversion events.

The key difference from pixel-based tracking: you control the data. The browser does not. If a user has cookies disabled or an ad blocker running, your server still sends the conversion to Google because the data originates from your backend, not the client side.

Set Up Your Server-Side Container

Start by creating a server-side tagging container in Google Tag Manager (GTM). This container runs on your domain or a subdomain, not in the browser.

Log into your GTM account and click Create Container. Choose Server as the container type. Name it something clear like "Production Server Container." GTM will generate a server container ID and provide setup instructions for your backend.

You have two deployment options: run GTM's server container on your own infrastructure (using Docker or a managed service), or use a third-party server-side tagging provider that hosts the container for you. Hosting it yourself offers maximum control but requires DevOps expertise. Using a managed provider (like Stape, Tagtician, or even Google Cloud's own setup) is faster for most teams.

Once the container is live, your backend will send events to an endpoint like https://yourdomain.com/gtm. Test this connection before moving forward. Send a test event from your backend and verify it arrives in the server container's debug mode.

Create a Google Ads Conversion Tag in GTM

Inside your server-side container, create a new tag for Google Ads conversions. Click New Tag and select the Google Ads Conversion Tracking tag type (or Google Ads Conversion Linker, depending on your GTM version).

Fill in the required fields:

• Conversion ID: Your Google Ads account ID (found in Google Ads under Tools > Conversions > Settings)
• Conversion Label: The unique identifier for this specific conversion action (e.g., "purchase_usd" or "lead_form_submit")
• Conversion Value: The monetary value of the conversion (optional, but recommended for e-commerce)
• Currency: The currency code (e.g., USD, EUR)

Enable Enhanced Conversions in the tag settings. This option appears as a checkbox or toggle. When enabled, it tells the tag to accept hashed customer data.

Under User Data, map the fields your backend will send to the hashed identifiers Google expects:

• email_address (hashed)
• phone_number (hashed)
• first_name (hashed)
• last_name (hashed)
• street_address (hashed)
• city (hashed)
• state (hashed)
• postal_code (hashed)
• country (hashed)

You do not need to send all fields. Email and phone are the strongest signals. Address fields help when email/phone are unavailable. Leave blank any fields your backend does not have.

Set a firing trigger: typically Custom Event matching the event name your backend will send (e.g., "purchase" or "conversion_event"). Test the tag in debug mode to confirm it fires and receives the correct data structure.

Hash Customer Data on Your Backend

Before sending customer identifiers to GTM, hash them using SHA-256. Google requires hashed data for privacy and security. Hashing is one-way encryption: you cannot reverse it to recover the original email or phone number.

Most programming languages have built-in or widely available SHA-256 libraries. In Python, use the hashlib module. In JavaScript (Node.js), use the crypto module. In PHP, use hash('sha256', $value).

Before hashing, normalize the value: convert to lowercase, remove leading/trailing whitespace, and remove special characters (for phone numbers, remove dashes and spaces). Example normalization for email:

normalized_email = email.lower().strip()

Then hash it:

hashed_email = hashlib.sha256(normalized_email.encode()).hexdigest()

Do this for every customer identifier you have. If you send unhashed data, Google will reject it. If you hash incorrectly (wrong algorithm, missing normalization), Google will not match the data to its user graph, and you will lose conversion credit.

Send Conversion Events from Your Backend

After a customer converts (completes a purchase, submits a form, etc.), your backend constructs a conversion event and sends it to your server-side tagging endpoint.

The event payload should include:

• event_name: The name of the event (e.g., "purchase")
• conversion_value: The monetary amount (e.g., 99.99)
• currency: Currency code (e.g., "USD")
• transaction_id: A unique identifier for this conversion (prevents duplicate counting)
• user_data: An object containing the hashed identifiers (hashed_email, hashed_phone, etc.)
• timestamp: When the conversion occurred (Unix timestamp or ISO 8601 format)

Example payload (JSON):

{ "event_name": "purchase", "conversion_value": 149.99, "currency": "USD", "transaction_id": "order_12345", "user_data": { "hashed_email": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6", "hashed_phone": "z9y8x7w6v5u4t3s2r1q0p9o8n7m6l5k4j3i2h1g0f9e8d7c6b5a" }, "timestamp": 1699564800 }

Send this payload via HTTP POST to your server-side tagging endpoint. Include the server container ID in the URL path. Most server-side tagging providers give you a specific endpoint format in their documentation.

Test with a small batch first. Send 5–10 test events and verify they arrive in your GTM server container debug mode. Check that the data structure is correct and the tag fires without errors.

Verify Conversions Are Recorded in Google Ads

After sending test conversions, wait 24–48 hours for Google to process and match the hashed data. Then check your Google Ads account to confirm conversions are being recorded.

Go to Tools > Conversions and click on the conversion action you set up. Look at the Conversion Details table. You should see a row for your conversion action with a count greater than zero. If the count is still zero after 48 hours, troubleshoot.

Common issues: Hashing was incorrect (wrong algorithm or missing normalization). The conversion label in GTM does not match the label in Google Ads. The event name in your backend does not match the firing trigger in GTM. The transaction ID is duplicated, and Google is deduplicating the events.

Enable debug mode in your server-side container to see the exact data GTM is receiving. Look at the user data fields: are they hashed correctly (64-character hex strings)? Are all required fields present? If a field is missing or malformed, GTM will still send the conversion, but Google may not match it to a user, reducing your match rate.

Monitor Match Rate and Adjust

Google Ads shows a match rate for Enhanced Conversions: the percentage of conversions where Google successfully matched your hashed data to a user in its network. A healthy match rate is 70% or higher. Below 50% indicates a data quality issue.

Low match rate usually means one of three things: the hashed data is incorrect, the customer data you have is incomplete (missing email/phone for many users), or the normalization step is inconsistent across events.

To improve match rate, send more customer identifiers per event. If you have email, phone, and address, send all three. Google's matching algorithm is probabilistic: more data points increase the chance of a match. Also audit your normalization logic. Email addresses should always be lowercase. Phone numbers should have country codes when applicable. Addresses should follow a consistent format.

Monitor the match rate weekly. If it drops suddenly, check your hashing logic or data pipeline for recent changes.

Scale to Multiple Conversion Actions

Once your first conversion action is working, add more. Create additional Google Ads conversion tags in your server-side container for different actions (e.g., add_to_cart, checkout_start, lead_submit). Each tag needs its own conversion label from Google Ads.

Your backend can send multiple events per user session. Route each event to the appropriate tag in GTM using the event name and firing triggers. This way, you capture the full customer journey, not just final conversions.

Test each new conversion action in debug mode before enabling it in production.

Reality Check: When to Use Server-Side Enhanced Conversions

Server-side Enhanced Conversions are best for e-commerce, lead generation, and app installs where you have reliable customer email or phone data at the point of conversion. If your business model does not capture customer contact information (e.g., a content site with anonymous traffic), this approach will not help.

Also consider your technical capacity. Server-side tagging requires backend engineering time to hash data and send events. If your team lacks DevOps or backend resources, a managed server-side tagging provider can reduce the burden. However, you still need to own the data pipeline.

Browser-based conversion tracking is not dead, but it is unreliable. Server-side Enhanced Conversions are now the industry standard for high-accuracy tracking. If you are still relying on pixels alone, this setup will significantly improve your conversion visibility.

FAQs

People Also Ask