Automate Google Ads Enhanced Conversions with Make.com

Use Make.com to route first-party conversion data from your checkout, CRM or other business system into Google Ads Enhanced Conversions. The important part is not simply sending hashed customer data: the enhancement must be associated with the correct conversion, use Google’s current normalization rules, avoid duplicate counting and arrive within the applicable processing window.

1. What Google Ads Enhanced Conversions Actually Does

Enhanced Conversions supplements normal Google Ads conversion measurement with first-party customer information such as email address, phone number, name and address. Google hashes the information and uses it to match customer information with signed-in Google accounts and relevant ad interactions.

The goal is not to create a second unrelated conversion. The goal is to give Google additional first-party signals that can improve conversion measurement and, where applicable, bidding optimization.

This distinction matters because many older tutorials describe Enhanced Conversions as if Make.com simply posts a new conversion containing a GCLID, value and email address. That is not the correct architecture for the current Enhanced Conversions for Web API workflow.

Google states that API-based Enhanced Conversions for Web requires a normal website conversion tag and recommends using a transaction/order ID so the API enhancement can be matched to the original conversion and duplication can be avoided.

Google: Enhanced Conversions for Web with the Google Ads API

2. Choose the Correct Implementation Flow

The right workflow depends on where the conversion occurs. Do not copy an offline-lead workflow into an online purchase implementation simply because both use hashed customer data.

3. What Make.com Actually Provides in 2026

Make’s current Google Ads Conversions documentation lists:

• Upload a Call Conversion
• Upload a Conversion Adjustment
• Upload a Conversion Enhancement (Experimental)
• Bulk Upload a Call Conversion (advanced)
• Make an API Call

That matters because the earlier wording “Bulk Upload an Enhanced Conversion for Leads” does not match the current Make module list.

The practical Make architecture is therefore: webhook/input → data preparation → hashing → Google Ads conversion enhancement/API request → logging/diagnostics.

Make: Google Ads Conversions documentation

4. Automating an Online Purchase Conversion

For a Stripe-style checkout, the cleanest architecture is to let the website’s Google tag record the conversion and let Make.com enrich that conversion after the payment system confirms the transaction.

Stripe example: choose the event carefully

Stripe documents checkout.session.completed for successfully completed Checkout Sessions and also provides checkout.session.async_payment_succeeded for delayed payment methods. Your Make scenario should therefore be designed around the actual payment state and fulfillment requirements, not simply around a browser redirect.

Stripe: Handle post-payment events server-side

5. Google’s Normalization and SHA-256 Rules

Hashing is not enough. Google requires normalization before hashing so the same customer identifier produces the expected hash.

Input:
  Jane.Doe+Shopping@googlemail.com

Normalize:
  janedoe@googlemail.com

Then:
  SHA-256(normalized_value)

Result:
  Send the hexadecimal SHA-256 value to Google

Use Google’s own normalization examples as the source of truth rather than copying Meta CAPI normalization rules. The two systems may look similar, but they are not interchangeable.

6. Correct Google Ads API Payload Architecture

This is the most important technical correction to the original article. For an Enhanced Conversions for Web API implementation, the request is an upload of ConversionAdjustment records.

Google specifies adjustmentType: ENHANCEMENT, the relevant conversion action, and an orderId matching the existing conversion. User identifiers contain the normalized and hashed first-party data.

{
  "customerId": "1234567890",
  "conversionAdjustments": [
    {
      "conversionAction":
        "customers/1234567890/conversionActions/987654321",
      "adjustmentType": "ENHANCEMENT",
      "orderId": "ORDER-10027",

      "userIdentifiers": [
        {
          "hashedEmail": "SHA256_HASH"
        },
        {
          "hashedPhoneNumber": "SHA256_HASH"
        }
      ],

      "gclidDateTimePair": {
        "conversionDateTime": "2026-09-30 14:30:00+00:00"
      },

      "userAgent": "ORIGINAL_USER_AGENT"
    }
  ],
  "partialFailure": true
}

Why partialFailure belongs in production

Google recommends partial failure for conversion-adjustment uploads. With partial failure enabled, valid records can be processed while individual invalid records are returned as errors instead of causing the whole batch to fail.

That makes it particularly useful when Make batches several conversions in one request. Your scenario should store the returned error information so the failed record can be investigated without losing the successfully processed records.

Google: Partial failure

7. Offline Leads: Use the Current Data Manager Path

Lead-generation businesses have a different problem. The initial Google Ads interaction may produce a lead today, while the meaningful conversion happens later when a salesperson qualifies the lead, closes the deal or records another offline outcome.

For those workflows, retain the identifiers you can reliably associate with the original lead. Google recommends including GCLIDs whenever possible, alongside user-provided data such as email, phone or address.

Google’s current Data Manager API documentation covers offline conversions, Enhanced Conversions for Leads and additional data-source workflows.

Google: Data Manager API Events

8. Testing and Diagnostics

Do not judge the implementation by whether the Make scenario returns an HTTP success alone. A technically successful request can still contain unusable or poorly matched customer data.

Do not use an arbitrary “60% match rate” target

The current Google Ads diagnostics UI does not define 60% as the threshold for a successful Enhanced Conversions implementation. Google’s current diagnostic model reports states such as INSUFFICIENT_VOLUME, NO_MATCHES, LOW and HIGH; the current documentation describes LOW as 0–15% and HIGH as above 15%.

Therefore the useful optimization question is not “Did I hit 60%?” It is: Are eligible conversions supplying valid customer data, is the data correctly formatted, and is the match/coverage status improving?

Google also notes that diagnostic alerts may not appear when conversion volume is too low to produce a meaningful assessment.

Google: Enhanced Conversions diagnostics

9. Common Implementation Failures

10. Production Architecture Checklist

Before putting the scenario into production, the following architecture gives you a much safer baseline than a simple “webhook → Google Ads” automation.

11. Frequently Asked Questions

12. Official References

Technical specifications change. Last verification for this version: October 1, 2026. Always verify the current Google Ads, Google Developers, Make.com and payment-provider documentation before deploying a production integration.