Automate Google Ads Enhanced Conversions with Make.com (2026)

1. Why the Standard Google Tag Is Failing

The standard Google Tag fires a JavaScript event from the user’s browser when they land on your purchase confirmation page. Like the Meta Pixel, this method depends entirely on the browser’s willingness to execute the script and store the attribution cookie that connects the conversion event back to the original ad click.

In 2026, that dependency represents a systematic data gap that degrades Smart Bidding performance over time.

Safari’s Intelligent Tracking Prevention caps most JavaScript-set first-party cookies at 7 days by default.

But when a landing URL carries tracking parameters from a domain ITP classifies as a cross-site tracker — which includes the gclid parameter Google Ads appends to every ad click — that cap drops sharply to 24 hours instead of the usual 7 days.

A customer who clicks a Google Ad on Monday and completes a purchase on Wednesday has their gclid-linked cookie deleted before the transaction occurs, since it falls under this stricter 24-hour rule rather than the general 7-day one.

The Google Tag fires on the confirmation page but cannot connect the purchase to the original ad interaction, and the conversion appears as an unattributed direct visit.

Ad blockers suppress the Google Tag script entirely before it executes. Cross-device journeys — where a user clicks a mobile ad but purchases on desktop — produce two disconnected sessions with no shared cookie that allows Google to join them.

The practical consequence is that Google’s Smart Bidding algorithm operates on an incomplete conversion dataset. When the algorithm does not see sufficient conversion signals, it interprets the campaign as underperforming and reduces bid aggressiveness. Target CPA creeps upward.

Target ROAS targets are missed. Budget is automatically redistributed away from campaigns whose conversions are invisible to the tag. The algorithm is not performing poorly — it is performing accurately on the data it can see, which is an incomplete subset of your actual customer transactions.

According to Google’s official Enhanced Conversions documentation, Enhanced Conversions can improve conversion measurement accuracy by providing additional first-party identity signals that help match server events to signed-in Google accounts across devices and sessions. This is the mechanism that closes the attribution gap the standard tag cannot close.

2. Google Ads Enhanced Conversions: What It Actually Does

Enhanced Conversions supplements your standard Google Tag with hashed first-party customer data. When a purchase completes, instead of only sending the standard conversion event from the browser, you simultaneously transmit a server-side payload containing the customer’s SHA-256 hashed email, phone, name, and address to Google’s API.

Google uses these hashed identifiers to match the server event to a signed-in Google account — even when the original gclid cookie has been deleted, the user switched devices, or the standard tag was blocked.

The matching works because Google maintains a database of hashed identifiers associated with signed-in Google accounts.

When your server sends a hashed email for a customer who is also signed into Google on any device, Google can connect that server event to the account and attribute it back to the ad click that drove the original visit.

That matching window extends well beyond what the 24-hour ITP cookie cap allows for.

This is why Enhanced Conversions consistently recovers conversions that the standard tag cannot capture — it uses identity matching rather than cookie continuity as the attribution mechanism.

3. Enhanced Conversions for Web vs Enhanced Conversions for Leads

Google offers two distinct Enhanced Conversions implementations designed for different business models. Understanding which applies to your setup is the first configuration decision.

For operators running direct response e-commerce or digital product funnels where payment completes on your website, Enhanced Conversions for Web is the correct implementation.

For operators running lead generation campaigns where the sale occurs offline — high-ticket sales calls, B2B enterprise sales, booked appointments — Enhanced Conversions for Leads is required, and the gclid must be stored in your CRM at the point of lead form submission so it is available when the offline conversion is uploaded later.

4. The Make.com Pipeline Architecture

The complete Enhanced Conversions pipeline intercepts your payment webhook, extracts and normalises the customer data, and routes the hashed payload to Google’s API without any manual intervention. Here is the exact five-stage sequence.

5. Data Normalisation and Hashing Requirements

Google applies strict normalisation rules before hashing customer data for identity matching.

If your Make.com scenario hashes data without first applying these normalisation steps, the resulting SHA-256 hashes will not match Google’s stored hashes for the same customer — the conversion event arrives at Google’s API but fails to match to any signed-in account, producing an upload with zero attribution value.

6. The API Payload Structure

Make.com’s native Google Ads modules handle the OAuth 2.0 authentication and API versioning automatically. You provide the payload data and the module handles transmission. For the HTTP Make an API Call approach, the conversion upload endpoint and the required JSON structure follow Google’s Enhanced Conversions API documentation.

The core payload for an Enhanced Conversion upload requires the following fields:

{
  "conversions": [
    {
      "gclid": "YOUR_GCLID_VALUE",
      "conversion_action": "customers/CUSTOMER_ID/conversionActions/CONVERSION_ACTION_ID",
      "conversion_date_time": "2026-05-08 14:30:00+00:00",
      "conversion_value": 997.00,
      "currency_code": "USD",
      "user_identifiers": [
        {
          "hashed_email": "SHA256_HASHED_EMAIL"
        },
        {
          "hashed_phone_number": "SHA256_HASHED_PHONE"
        }
      ]
    }
  ],
  "partial_failure": true
}

The partial_failure field set to true is important — it allows the API to process successfully formatted conversions even if some records in a batch contain errors, rather than rejecting the entire batch due to a single malformed record. Always include it in production pipelines.

7. Verification and Match Rate Diagnostics

After deploying your Make.com Enhanced Conversions pipeline, navigate to Google Ads and open Goals then Conversions then Summary. Select your Enhanced Conversion action and click the Diagnostics tab.

This view shows upload status, the number of conversions processed versus rejected, and the match rate percentage — the proportion of uploaded conversions that Google successfully matched to a signed-in account.

Allow 48 to 72 hours after your first upload batch before evaluating match rate statistics. Google requires a minimum volume of processed conversions to calculate reliable match rate figures, and the initial display may show incomplete data during the first few days.

A match rate above 60% indicates your normalisation and hashing is working correctly. A match rate above 80% is strong and indicates your customer data is consistently matching to active Google accounts.

A match rate below 40% almost always indicates a normalisation error in the hashing step — the most common cause is hashing email addresses that still contain uppercase characters or trailing whitespace.

Infrastructure Stack

Related Attribution Guides

8. Frequently Asked Questions