Google Ads Lead Form Extensions: Setup, Webhooks, and Where Leads Get Lost

Lead form extensions, now officially called lead form assets, let someone submit their details without leaving Google. The form opens on the ad, it is pre-filled from their Google account, and the friction drops to almost nothing. That is the whole appeal, and it is real: conversion rates on a pre-filled in-ad form beat a landing page form regularly.

It is also where the trouble starts. A form that is this easy to submit produces volume, and volume exposes whatever is weak in your follow-up. This guide covers the setup, the three ways leads reach you, the field-by-field contents of the webhook, and the specific failure that quietly deletes leads you paid for.

Lead form assets are available on Search, YouTube, Display and Demand Gen campaigns, subject to policy eligibility. Google gates them behind an advertiser policy check, and accounts in sensitive categories may not be granted access at all.

The setup itself is short. In the asset section of the campaign you define a headline, business name, a description, the questions to ask, a privacy policy URL, and a submission message with an optional call to action. The part worth slowing down on is the questions.

Choosing questions

Each additional question reduces volume and raises intent. That is a dial, not a problem, and the right setting depends on what your sales team can handle.

• Name, email, phone only. Maximum volume, minimum qualification. Fine if you have capacity to call everyone.
• Add one qualifying question. Budget range, timeline, or the specific product. Cuts volume noticeably and raises the connect rate.
• Add three or more. Approaches landing-page friction, which undermines the reason to use the format.

For UAE advertisers there is a local wrinkle: include phone as a question and expect numbers in several formats and country codes. Whatever receives these leads should normalise phone numbers on the way in, or your deduplication will not work and agents will call the same person twice.

1. Manual CSV download, and the 30-day trap

You can export lead data by hand from the campaign's asset view. This is the default if you configure nothing else, and it is the source of the most expensive failure in this whole format.

Google retains leads for 60 days. The manual download only gives you the last 30. A lead submitted while your media buyer was on leave, with no webhook and no integration attached, becomes unreachable after 30 days and is deleted at 60. It was paid for, it was interested, and it expired inside the ad platform without anyone reading it.

Treat manual download as a backup, never as the delivery method.

2. Email notifications

Configurable at setup, and useful as an alert. As a delivery mechanism it fails for the same reason a shared inbox always fails: no owner, no clock, no deduplication, and no structured record. Use it as a tripwire so somebody notices when leads start arriving, not as the pipeline.

3. Webhook, which is the correct answer

A webhook posts each submission to a URL you control the moment it happens. Configure it with the endpoint URL and a key, and Google sends a test lead to verify the endpoint responds correctly before it goes live.

The payload is JSON, and knowing the fields is the difference between a working integration and a fragile one:

• lead_id is the unique identifier for the submission. Dedupe on this. Google does not guarantee exactly-once delivery, so the same lead can arrive twice and any endpoint without deduplication will create duplicate records.
• user_column_data carries the answers themselves, as an array of column identifiers and values rather than a flat object.
• form_id, campaign_id, adgroup_id and creative_id identify where the lead came from. Store all four. This is what later makes cost per qualified lead answerable at the ad level instead of the account level.
• gcl_id is the Google click identifier. Read the next section before deciding whether you need it.
• google_key is the verification value you configured. Check it and reject anything that does not match, or your endpoint is an open door for anyone who guesses the URL.
• api_version tells you the schema version, and is_test marks Google's verification submissions so they do not enter the real pipeline.

Your endpoint should return HTTP 200 quickly and do the slow work afterwards. An endpoint that does the CRM write, the email send and the WhatsApp notification before responding will eventually time out, and a timeout looks like a failure to Google.

Here is the part that separates advertisers who improve from advertisers who plateau.

gcl_id is the identifier of the click that produced the lead. Capture it and store it against the lead record, and you keep the ability to tell Google, weeks later, that this specific lead became a customer. That is an offline conversion upload, and it is what turns Smart Bidding from optimising toward form submissions into optimising toward revenue.

Discard it at capture, which is what happens by default when leads arrive as a CSV or an email, and that door closes permanently. You can still report on which campaign produced the deal internally. You just cannot tell the bidding algorithm, which means it keeps buying more of whatever produces cheap form fills.

The mechanics of sending qualification back to Google are on the conversion signals page, and the Google-specific side is on the Google lead ads page.

1. No webhook configured. Leads accumulate in Google Ads and expire. Fix first, fix today.
2. No deduplication on lead_id. Duplicate records, duplicate calls, an irritated prospect.
3. gcl_id discarded at capture. Attribution and offline conversions both become impossible later.
4. No owner or SLA on arrival. The format's low friction produces volume, and volume without assignment produces a backlog. An eight-hour SLA clock with an alert makes every miss visible the day it happens, as described on the lead management page.
5. Phone numbers stored raw. UAE leads arrive as 05x, +9715x and 9715x for the same person. Normalise on the way in.

The target state is short to describe and rare to find:

A lead submits the in-ad form. Within a second, a webhook delivers it to your CRM, which verifies the key, dedupes on lead_id, normalises the phone number, stores gcl_id alongside the campaign, ad group and creative, scores the lead against your own closed deals, assigns it to an agent by routing rule, and starts an SLA clock. The agent gets a notification with a drafted opening message. When that lead later reaches a qualifying stage, an offline conversion goes back to Google against the stored gcl_id, and the bidding gets smarter.

That is the loop. Every step that is missing is a place where money leaks out, and the first step is the one that leaks the most. If you are running lead form assets today and cannot say where the leads land, start there, then read the lead attribution page for what becomes possible once the identifiers survive the journey.