A GA4 event plan for a lead-generation website: events, key events and the checks that catch broken tracking

A lead-generation website needs a short, written list of GA4 events, not everything GA4 can collect. Send Google's recommended generate_lead for every completed enquiry, add a handful of events for the other ways people contact you (calls, chat, booked meetings), mark only the events that represent a real enquiry as key events, register the few parameters you will actually report on, and check the whole chain once a month. The last step is the one most often skipped, and it is how a form change can stop an event firing for months without anyone noticing.

Key takeaways

  • Google lists six recommended lead events, from generate_lead ("when a lead has been generated (for example, through a form)") to close_convert_lead (a lead that became a customer). Use those names instead of inventing your own.
  • A standard GA4 property can mark up to 30 events as key events. A service business rarely needs more than four or five.
  • Event names are limited to 40 characters and parameter values to 100 characters; parameters only appear in standard reports after you register them as custom dimensions (50 event-scoped dimensions on a standard property).
  • Google's policy is that no data Google "could use or recognize as personally identifiable information" is sent to Analytics. Form contents never go into an event.
  • Test every event in DebugView before you rely on it, and again after any change to a form, a booking widget or the consent banner.

Why does a lead site need an event plan at all?

Because GA4 collects page views and a few interactions on its own, but it cannot know which of them is a business result. Enhanced measurement sends form_start and form_submit when someone interacts with and submits a form, click for links to other domains, file_download, scroll at about 90% of a page and a few video events. That is context, not a lead: form_submit also fires for the newsletter box and for submissions the server rejects.

An event plan is a one-page document that says, for each business action: the event name, when it fires, its parameters, whether it is a key event, and who owns it. Anyone who changes a form reads it first. Without it, a GA4 property drifts into overlapping events that nobody trusts.

Which events should a lead-generation site send?

Start from Google's recommended lead events, because GA4 and Google Ads understand their names and parameters, then add the site-specific contact routes.

Event Fires when Useful parameters Key event?
generate_lead The enquiry form is accepted by the server (not when the button is clicked) form_type (contact, quote, careers), lead_source if known, value and currency if you assign one Yes
book_call_scheduled (custom) A meeting is actually booked in the scheduling tool, not when the widget opens form_type Yes
phone_click (custom) A tel: link is tapped cta_area (header, footer, page body) Usually yes, as a secondary action
whatsapp_click or chat_start (custom) A chat link is opened or a chat starts cta_area Usually yes, as a secondary action
newsletter_signup (custom) The subscription is confirmed none No
cta_click (custom) A primary call-to-action button is clicked cta_type, cta_text, cta_area No
qualify_lead, close_convert_lead Your team marks the lead as qualified or won in the CRM value, currency Optional; see below

Google describes the CRM stages too: qualify_lead is "when a user is marked as meeting the criteria to become a qualified lead", working_lead "when a user contacts or is contacted by a representative", and close_convert_lead "when a qualified lead is successfully converted into a customer". Those happen in your sales process, not on the website, so they are sent from a server with the GA4 Measurement Protocol, which Google says exists to "record server-to-server and offline interactions" and "to augment automatic collection through gtag, Tag Manager, and Google Analytics for Firebase, not to replace it". Only add them once the website events are reliable.

Two rules make the table work. First, fire the lead event on success, not on click: the site code should push the event after the form backend has accepted the submission, so failed and spam-blocked submissions are not counted. Second, let the site describe what happened and let the tag manager decide where it goes. On our own site the code only pushes named events to the data layer, and Google Tag Manager turns them into GA4 events and Google Ads conversions; the GTM and Consent Mode write-up shows that build in detail.

Which events should be key events?

Only the ones that represent a person asking to do business with you. GA4 calls them key events (Google keeps the word "conversion" for Google Ads); you mark an existing event by clicking its star in Admin, Data display, Events, which needs the Editor role. Google's limit is "up to 30 events as key events for standard properties and 50 events as key events for Analytics 360 properties".

For most service businesses that means generate_lead, book_call_scheduled, and probably phone_click and whatsapp_click. Leave cta_click, scroll and newsletter_signup as ordinary events; marking them inflates the "key event rate" until it means nothing. If you advertise, you can create Google Ads conversions from GA4 key events, but Google notes that "Google Ads conversions don't appear in standard Google Analytics reports", so decide which product is the source of truth for bidding and keep the other in step.

Give a key event a value only if you can defend it. A rough average deal value multiplied by your enquiry-to-client rate is a reasonable starting value for generate_lead; a phone click is worth less because many calls are not enquiries. If you cannot estimate, leave values out rather than invent them.

Which parameters are worth registering?

Only those you will filter or break down by. Each event can carry up to 25 parameters, but a parameter does not appear in standard reports until you register it as a custom dimension, and a standard property allows 50 event-scoped and 25 user-scoped custom dimensions. For a lead site four are usually enough:

  1. form_type: which form produced the lead (contact, quote, careers). Careers applications are not sales leads; filter them out of sales reporting.
  2. cta_area: where on the page the click happened (header, hero, body, footer).
  3. cta_type and cta_text: which button wording was used, so you can compare calls to action.
  4. traffic_type: the value your tag manager sets for staff visits, which GA4's internal-traffic filter then excludes.

Keep names short and consistent: event names are capped at 40 characters and parameter values at 100 characters, and events with longer names "aren't processed".

How do you keep personal data out of GA4?

By never sending what the visitor typed. Google's guidance is that "no data be passed to Google that Google could use or recognize as personally identifiable information", and it names emails and personal phone numbers. The usual leaks are a thank-you page URL that carries the email address as a query parameter, a page title that includes a name, and a site search that captures whatever people type into it. Check those three before launch. GA4's data redaction can strip email addresses from URLs on a best-effort basis and remove query parameters you list, for web data streams only; treat it as a safety net, not as the plan.

Hashed contact details for Google Ads enhanced conversions are a separate, consent-dependent mechanism; they do not belong in a GA4 event parameter.

How do you test that the events work?

Use DebugView and a written test script. Google's instructions: "You must enable debug mode to use DebugView"; on your own device, Tag Assistant or Tag Manager's preview mode turns it on by adding a parameter to the page address. DebugView shows the events logged in the last 60 seconds and the last 30 minutes for each debug device.

The test script for a lead site:

  1. Submit each form with valid data. Expect exactly one generate_lead with the right form_type, after the success message, not before.
  2. Submit each form with an invalid email. Expect no generate_lead.
  3. Book a test meeting and cancel it. Expect book_call_scheduled once.
  4. Tap the phone and chat links on a phone. Expect one event each, with cta_area.
  5. Repeat step 1 from a location where your consent banner shows, and decline. DebugView will not show the events, because Google notes they may be hidden "if you use consent mode and users haven't consented to Analytics cookies"; the tag manager preview should show the tags held by consent. Our guide to analytics when visitors decline cookies covers what this means for the numbers.
  6. Mark your own test traffic as internal so it does not reach reports. Google warns: "It's important to filter out traffic while debug mode is on."

What should you check every month?

Ten minutes, the same day each month, prevents most silent failures:

  • Count against the source. Compare generate_lead events with the enquiries that actually reached your inbox or CRM. Some gap is normal (consent, ad blockers), a sudden change is not.
  • Zero days. Any day with zero leads in GA4 but enquiries in the inbox means something broke.
  • Unexpected events. New event names you did not plan usually mean a plugin or a developer added tracking.
  • Data retention. Set event data retention to 14 months, the longest a standard property allows; it affects explorations and funnel reports, not standard reports, so a short setting quietly limits year-on-year analysis.
  • The plan document. Update it whenever a form, booking tool or consent setting changes, and rerun the test script.

Once the events are trustworthy, you can start asking which channels produce clients, which is the subject of our article on measuring marketing ROI and attribution.


Impinge Solutions plans and sets up GA4 events, key events and Tag Manager containers as part of its digital marketing and analytics work. Run our free website audit to see which tags and conversion hooks your page shows.

FAQ

What is the difference between an event and a key event in GA4?

Every interaction GA4 records is an event. A key event is an event you have marked as important to the business, such as a submitted enquiry, so GA4 reports it separately and attributes it to channels. A standard property can have up to 30 key events; a lead-generation site usually needs four or five.

Is enhanced measurement's form_submit enough to count leads?

No. It fires when a form is submitted, including newsletter boxes, site search and submissions the server later rejects. Use it as context and send your own generate_lead event only after the server has accepted the enquiry.

Should I use Google's recommended event names or my own?

Use the recommended names where one fits, such as generate_lead, qualify_lead and close_convert_lead, because Google's reports and integrations understand them. Create custom events only for actions Google has no name for, such as a phone or chat click, and keep the names short and consistent.

Can GA4 track leads that become customers later?

Yes, if your CRM sends the later stages to GA4 with the Measurement Protocol, using the client_id captured with the original enquiry. Google positions the protocol as a way to add server-side and offline events to normal tagging, not to replace it. Get the website events right first.

How do I stop my own visits from counting?

Define internal traffic in GA4 by office IP ranges, add a traffic_type value for staff on other networks (for example through a first-party cookie set by a special link), run the filter in testing mode, then activate it. Also filter out debug traffic, which Google warns can distort reports.

Sources

Are you ready to partner with us?

Our good-natured team is waiting to hear your business requirements.

Book a free project call

Stay informed with our newsletter