Substantively updated October 9, 2026. Original publication date retained.
A customer opening your contact page and a customer successfully sending an inquiry are different events. If you only measure pageviews, you cannot tell them apart.
Google Analytics 4 can collect events for specific actions, but the names and triggers need to match what actually happened. This guide helps you plan a small event set, implement a lead measurement, and test it before using the numbers to make decisions.
Choose the right event type first
GA4 distinguishes automatically collected events, enhanced measurement events, recommended events, and custom events. Recommended events have predefined names and parameters; custom events are appropriate when the other types do not fit. Google explains the event types.
For an inquiry, consider the recommended generate_lead event. You still need to implement it; naming an event does not make Analytics detect the action automatically. See Google’s recommended events.
Enhanced measurement can collect outbound link clicks, certain downloads, form interactions, scrolling, and supported YouTube video interactions. Each has conditions: the standard scroll event represents reaching about 90% of the page, not proof that the text was read. Check which events already arrive before adding another implementation. Read the enhanced measurement definitions.
Write down what each event proves
Start with a question and define the evidence needed to answer it.
| Business question | Event or record | What it establishes |
|---|---|---|
| Did an inquiry reach the form’s success state? | generate_lead, triggered after confirmed acceptance | The measured submission succeeded; it may still be spam or unqualified |
| Did someone tap the phone link? | A custom event such as click_to_call | A tap, not a completed call |
| Did someone open the quote form? | A custom event such as quote_form_open | Interest in opening the form, not a lead |
| Which project types were selected? | A custom event such as portfolio_filter | A selected filter, not a buying intention |
| Did the business win the work? | A sales or booking record | A confirmed outcome, outside ordinary button tracking |
The custom names above are examples, not automatically collected GA4 events. Keep a record of the trigger, allowed parameters, owner, and date tested for each one.
Avoid interpreting a download as a warm lead or a scroll as understanding. Events show observable behavior; the reason for it still needs investigation.
A simple setup: a lead confirmation page
Suppose your contact form takes a visitor to a dedicated confirmation page after the server accepts the submission. Google’s key-event tutorial shows how to derive generate_lead from that page’s page_view event.
With the necessary property permissions, the current workflow is:
- Open Admin → Data display → Events, then Create event.
- Name the event
generate_leadand mark it as a key event if this is a business outcome you want to report prominently. - Choose Create without code, select
page_viewas the existing event, and specify your confirmation-page URL. - Save the event, complete a test submission, and check that the expected event arrives.
This is appropriate only if the confirmation page is a reliable proxy. Direct visits, reloads, or an error that redirects there anyway can inflate the count. Test those paths and compare received inquiries with recorded events. Do not also send the same lead event from a tag or application callback unless you have deliberately prevented duplication.
If the form stays on the same page, ask your developer to send an event after the application confirms success. A Google Tag Manager trigger can respond to that signal, but clicking the submit button is not enough. Client validation or the server may reject the request.
GA4’s event-creation interface derives events from information it receives; it cannot invent tracking for a button whose interaction was never sent. See how event creation works.
Add useful parameters without collecting form answers
A parameter supplies context, such as form_type set to contact or placement set to footer. Prefer a small set of stable, non-sensitive values.
Check for a suitable predefined dimension first. For reporting on a custom parameter, you may need to register an event-scoped custom dimension. In Admin → Data display → Custom definitions, create a dimension with Event scope and the exact event-parameter name. Google notes that reporting availability can take 24–48 hours after the parameter is sent and the definition created. Follow the custom-dimension instructions.
Do not send names, email addresses, phone numbers, or free-text form responses into standard GA4 events. Check page URLs and query strings too; a confirmation URL should not contain submitted personal information. Google’s guidance on avoiding personally identifiable information describes common collection risks.
For medical transportation or other sensitive services, avoid collecting ride details or health information as event parameters. Review whether the measurement is appropriate for the site before installing tags, and honor the site’s consent configuration.
Test success, failure, and duplication
Enable debug mode for your test device and use Admin → Data display → DebugView to inspect events and parameters. Tag Assistant or Google Tag Manager’s preview workflow can help enable debug mode. Google’s DebugView guide explains the setup.
Test a valid submission, a missing required field, a rejected request, a double click, and a confirmation-page reload. Verify that each produces the intended result. Also confirm that the message reaches the person who answers inquiries.
If an event is missing, check the tag, trigger, consent state, filters, and browser blocking before assuming no one took the action. DebugView is for implementation checks; routine reports can take longer to process.
Use key events deliberately
In GA4, a key event marks an action important to your business. Google Ads conversions are a related but distinct configuration for advertising measurement and bidding. Read Google’s key-event explanation.
For a service business, a successfully accepted inquiry is often a useful key event. A phone-link tap can be valuable to monitor, but label it accurately and avoid adding it to a “confirmed leads” total.
Turn the data into a question you can investigate
Imagine a hypothetical month with 40 distinct sessions starting a form and 10 of those sessions completing it. The observed completion rate is 10 ÷ 40 = 25%; 30 sessions did not complete within the defined observation period. That does not tell you why they stopped, whether they returned later, or whether they called instead.
First verify the tracking. Then test the form, ask the team about inquiry quality, and consider whether the requested information is reasonable. If you change the form, compare periods with the same definitions and account for traffic mix and seasonality. A before-and-after difference alone does not establish causation.
A contractor might review project-category selections alongside quote inquiries. A seasonal attraction might compare ticket-button taps with completed ticket sales from its booking provider. A professional service might compare consultation requests with accepted appointments. Each needs its own event definitions.
Our Search Console and Analytics guide puts those website actions alongside search discovery. Keep the event set small enough that someone will review it and test it again when the website changes.