If your GA4 reports show sessions and pageviews but not enquiries, the fix is a three-event plan: generate_lead only when a form submission is confirmed, a dedicated event for WhatsApp taps, and a separate event for phone-number taps. Mark them as key events, test them in GTM preview and DebugView, and your reports answer which pages and channels produce enquiries.
The short answer: the three-event plan, in one table
| Event | Fires when | Key parameters | Key event? |
|---|---|---|---|
| generate_lead | Form success is confirmed | form_name, lead_source, value + currency if value is set | Yes — primary |
| whatsapp_click | A wa.me or WhatsApp link is tapped | button_location, page path | Yes — secondary |
| click_to_call | A tel: link is tapped | button_location, page path | Yes — secondary |
The problem: sessions are not enquiries, and GA4 does not bridge the gap by itself
GA4 collects useful events automatically, and enhanced measurement adds outbound clicks and form interactions. None is a lead count. A WhatsApp tap appears, at best, as a generic outbound click — indistinguishable from a tap to a map. A tel: tap is not labelled as an enquiry at all. And form_submit records a submission, not an arrived lead: on many sites it fires when validation has failed and nothing was sent.
So the owner judges the website on traffic, and ad spend follows visits. The gap is not a reporting setting — it is missing events.
Plan before Tag Manager: name the events, parameters and what each one proves
Write the plan down before opening Tag Manager. Use Google's recommended name for the form lead: generate_lead, defined for a lead generated through a form, with parameters including lead_source, plus value and currency — currency, in three-letter ISO format, being required whenever value is set. The taps have no recommended equivalent, so give them clear custom names — whatsapp_click and click_to_call — used exactly, everywhere.
Decide what each event proves. generate_lead proves contact details were received. A tap proves only intent — the visitor may never have sent or said anything. Keeping the two separate stops reports claiming leads your team never received. Add only parameters you will report on — form_name, button_location, lead type — and register each as an event-scoped custom dimension in GA4 Admin, or it will not appear in standard reports. The form fields themselves are covered in Arabic form design for UAE websites.
Forms: generate_lead on confirmed success — never on the submit click
The submit click is the wrong trigger: it fires when the phone number is incomplete, a required field is empty, or the server never receives anything. Fire generate_lead on confirmed success instead, in this order of reliability:
- Best: a data-layer push in the form's success handler, after the form system confirms receipt, with a GTM Custom Event trigger listening for it.
- Next: a thank-you page that loads only after a successful submission.
- Fallback: GTM's Form Submission trigger with validation checking enabled, or a visibility trigger on the success message.
Never create the same event twice: two sources for one lead is the commonest cause of wrong counts. Mark generate_lead as the primary key event; leave form_submit as a diagnostic only.
WhatsApp clicks: a dedicated event for wa.me taps, with button location
In GTM, create a Click – Just Links trigger firing when the Click URL contains wa.me or api.whatsapp.com, and a GA4 event tag named whatsapp_click on it. Add a button_location parameter — header, sticky mobile bar, service page, footer — from a data attribute on each button. Without location you know taps rose, but not which placement earned them.
How the link itself is built is covered in WhatsApp click-to-chat links with Arabic prefill; this article only measures the tap. Moving to the platform itself — our WhatsApp Business API setup service — needs its own measurement.
Call clicks: tracking tel: taps — and being honest that a tap is not a call
The pattern is the same: a Click – Just Links trigger where the Click URL starts with tel:, firing click_to_call with button_location and page path — call intent by page and placement.
Be honest about the limit: this counts taps, not connected or answered calls, and not call duration. Some taps are abandoned in the dialler. Answered-call data is a call-tracking service's job — a separate purchase. Until then, treat taps as intent, keep them secondary, and never add taps and confirmed leads together and call the total "leads".
Key events, values and importing to Google Ads without double-counting
In GA4 Admin, under Data display, mark generate_lead as a key event, and the two tap events as secondary key events. Google's limit is 30 key events on a standard property, 50 on Analytics 360 — a lead-generation site needs three. If you set a value on leads, derive it from your own CRM history and always send currency with it.
For Google Ads bidding: link GA4 to Google Ads, keep auto-tagging on, and create conversions from the GA4 key events. Then enforce one rule: one source per action. A lead imported from GA4 must not also be counted by a separate Google Ads tag — double-counting teaches bidding to chase the duplicated action. Clean measurement also makes channel reporting credible — see SEO services in the UAE.
Consent and privacy: what consent mode changes, and what must never go into GA4
First, never send personal data to GA4: Google prohibits sending data it could use or recognise as personally identifiable, including email addresses and phone numbers. No form-field values in parameters, no phone numbers inside captured URLs or link text, and a specific check for leaks in testing.
Second, expect consent to change your numbers. In a basic consent-mode implementation, tags stay blocked until the visitor interacts with the banner; if consent is refused, no data is sent at all. In an advanced implementation, tags load with consent denied by default and send cookieless pings, and Google may model some key-event behaviour from those signals. Either way, refused consent means fewer recorded events than real enquiries.
For UAE context, keep it operational: the UAE PDPL (Federal Decree-Law No. 45 of 2021) generally requires the data subject's consent for processing personal data unless a listed case applies, and that consent must be provable, clear, simple, unambiguous and easy to withdraw. This article asserts no GA4-specific legal requirement — that judgement belongs with your legal adviser.
Testing it properly: GTM preview, DebugView and the GA4-vs-CRM count check
Do not trust the setup until every check passes:
- Submit each form with valid data — exactly one generate_lead in DebugView, all parameters present.
- Submit with invalid data — no generate_lead.
- Refresh the thank-you page — no second generate_lead.
- On a real phone, tap every WhatsApp and call button — one event each, correct button_location.
- Inspect parameters and URLs — no names, email addresses or phone numbers anywhere.
- Repeat with consent refused — behaviour matches your consent-mode setup; nothing personal leaks.
- Re-run after any redesign, form-plugin change or new page.
GTM preview shows which tags fired; DebugView shows the events arriving for your test device. Finally, compare GA4's generate_lead count with the CRM's new-lead count for the same period: a small gap is normal; a large or sudden gap means a tracking fault. This checks only whether GA4 counted what the site produced. Leads produced but never arriving in the CRM are lead-delivery leakage, covered in why website leads never reach the CRM.
Reading the result: which pages and channels actually produce enquiries
Two reports do most of the work. Traffic acquisition, filtered to generate_lead, shows which channels produce leads rather than visits; filtered to the tap events, which channels produce intent — where they disagree, a channel starts conversations your forms never see. Pages and screens, by the same key events, shows which pages earn enquiries: high traffic with no key events is a conversion problem; a high enquiry rate on low traffic deserves more promotion.
Read taps and leads side by side, never merged. Over a quarter, the pattern shows where to spend — and which traffic to stop funding.
Common mistakes
Counting the submit click, so failed validation becomes "leads". Marking form_submit, scrolls or pageviews as key events. Running two sources for one action. Sending a phone number or email inside a parameter or captured URL. Testing only on desktop, when most taps happen on phones. Treating a tap as a lead in the headline total. Never re-testing after the site changes.
FAQ
Why does GA4 show form_submit events but no leads?
Because form_submit records a submission attempt, not a confirmed lead. Fire a deliberate generate_lead on confirmed success instead, and mark it as a key event in GA4 Admin.
Should WhatsApp and call taps be marked as key events?
Yes, as secondary key events: real enquiry intent, but a tap is not a conversation or a connected call. Keep them separate from generate_lead, so intent and leads are never merged into one inflated total.
How much difference between GA4 and CRM lead counts is normal?
A small gap is normal: consent refusals, blockers and abandoned taps mean GA4 never sees every enquiry. A large or sudden gap after a site change means a tracking fault.
Can I send the customer's phone number or email address to GA4 as a parameter?
No. Google prohibits sending data it could use or recognise as personally identifiable, including email addresses and phone numbers. Send only non-personal parameters — form name, button location, lead type.
What happens to lead tracking when a visitor refuses analytics consent?
With a basic implementation, Google tags stay blocked and no event data is sent. With an advanced one, tags send cookieless pings and Google may model some key-event behaviour. Either way, expect fewer recorded events than real enquiries.
Need a site built to be measured? (CTA)
Every step above gets harder when the website resists it: forms with no success state, WhatsApp buttons built five different ways, no data-layer hooks, no GTM access. Our SEO-friendly web development service builds sites ready to be measured from day one — consistent enquiry markup, clean success states, tracking hooks agreed before launch. Tell us how your enquiries arrive today for an itemised proposal within 24 business hours.
