A GA4 funnel exploration helps you find where an observed lead journey loses people: before they start a form, while they complete it, or before the website confirms success. It becomes useful when each step has a clear meaning and the report answers a specific business question.
This walkthrough uses a fictional consultation form. The numbers are illustrative, not industry benchmarks or Rivatra performance data. You can replace the event names and values with your own verified implementation.
Define the decision before building the report
Start with a question such as: “Do mobile visitors who begin our consultation form complete it less often than desktop visitors?”
That is more actionable than “Why is conversion low?” It identifies the audience, the relevant part of the journey, and a comparison. It also suggests what evidence you need before changing the page.
Write down four things:
- The form or service you are investigating.
- The starting action and successful outcome.
- The period and users you want to compare.
- The change you might make if the pattern is confirmed.
Do not put every marketing touchpoint into the first exploration. A compact website funnel can help diagnose form friction. A longer sales journey needs CRM information and a separate definition of qualification.
Create an event plan with observable outcomes
For this example, we propose two custom events and one Google-recommended event. These names are an implementation plan, not a claim that GA4 collects them automatically.
| Step | Example event | Proposed trigger |
|---|---|---|
| Form available | lead_form_view | The consultation form is rendered and visible under your documented visibility rule |
| Form started | lead_form_start | The first meaningful interaction with that form during the defined form visit |
| Inquiry accepted | generate_lead | The application confirms that the inquiry was successfully accepted |
Google includes generate_lead in its recommended events. Implement the trigger carefully: a click on Submit can fail validation or encounter a server error.
Use a stable, non-personal parameter such as lead_form_key=consultation_main on all three events. That keeps the example scoped to the same form. Follow Google’s event-scoped custom dimension instructions if you need to use that custom parameter in reporting.
Do not send the submitted message, name, email address, or phone number as a GA4 event parameter. Your CRM can hold the business record; your website analytics needs a safe description of the action.
Before publishing the event setup, test a normal submission, a validation failure, a server failure, and a refresh of the confirmation page. The success event should correspond to the outcome you defined. Our GA4 lead tracking guide covers that foundation.
Build the exploration in GA4
Open Explore and choose Funnel exploration. Add the three event conditions in order, with the same form-key condition where relevant. Begin with a closed funnel and indirectly followed steps so ordinary intervening events do not break your intended sequence. Add Device category as the breakdown.
Google’s funnel exploration documentation distinguishes closed funnels, which require entry at step one, from open funnels, which permit entry at any step. Required steps still need to occur in sequence. Directly followed steps prohibit intervening events; indirectly followed steps allow them. You can also specify a time limit between steps.
Save the configuration and date range with the report. If you later change the step conditions, treat the new version as a different comparison.
Choose the allowed time between steps to match your question. A quick same-visit form-completion question and a multi-day research journey should not silently share the same interpretation. Document the window rather than accepting an unexplained default.
Read a worked example with consistent denominators
Assume your closed funnel reports the following users for the selected period.
| Step | Users reaching the step | Progression from previous step |
|---|---|---|
| Form viewed | 1,000 | Starting population |
| Form started | 420 | 420 / 1,000 = 42% |
| Inquiry accepted | 210 | 210 / 420 = 50% |
The end-to-end completion rate is 210 / 1,000 = 21%. The start-to-success completion rate is 50%. Both numbers are correct; they answer different questions.
The first transition loses 580 observed users. That may reflect low intent, a weak offer, a form placed too early, or a visibility event firing before the form is meaningfully seen. The second transition loses 210 users and deserves a closer look at form behavior.
Do not immediately conclude that the form needs fewer fields. A missing success event, broken validation, a consent difference, and an actual usability problem can produce similar-looking drops.
Keep the unit consistent. A user-based funnel should not be compared directly with total submit-button clicks or CRM record counts as though every number describes the same population.
Break the example down by device
Suppose the same illustrative data is divided as follows.
| Device group | Form viewed | Form started | Inquiry accepted | Start-to-success rate |
|---|---|---|---|---|
| Mobile | 700 | 280 | 112 | 40% |
| Desktop | 300 | 140 | 98 | 70% |
| Total | 1,000 | 420 | 210 | 50% |
The mobile group supplies most starts and has the lower completion rate. That makes mobile a sensible place to investigate first. It does not establish that screen size caused the difference: traffic source, visitor intent, browser behavior, and measurement coverage could also vary.
A useful planning exercise is to ask what a modest change would mean. If mobile completion increased from 40% to 45% while starts stayed at 280, accepted inquiries would rise from 112 to 126: 14 additional inquiries. That is a scenario, not a forecast or a statistically demonstrated lift.
GA4’s breakdown attribution has its own rules; it should not be interpreted as a perfect record of the device used at every step by someone who switches devices.
Turn a drop-off into a testable hypothesis
Give each investigation an owner and a concrete observation. Avoid assigning a developer the vague task “improve conversion.”
| Observation | Hypothesis to investigate | First useful check |
|---|---|---|
| Mobile starts look normal, success is low | A field or error state is difficult on mobile | Complete the real form on common mobile browsers |
| Success falls on the day of a release | Tracking or submission behavior changed | Compare the release with controlled test submissions |
| One form key has no success events | The confirmation event lacks that parameter | Inspect the event payload during a successful test |
| Booking clicks exist, completions disappear | A third-party handoff is not measured | Review the booking integration and cross-domain route |
| CRM inquiries rise but GA4 successes do not | Collection coverage or event logic differs | Reconcile definitions before changing the page |
For external booking routes, use the GA4 cross-domain tracking checklist. For difficult forms, inspect the landing-page checklist and any recently added spam-prevention controls.
Select one meaningful change, define the success measure, and record when it launched. A before-and-after comparison can suggest progress, but changing traffic mix or seasonality can still confound it. Use a properly designed experiment when you need stronger causal evidence.
Know why an exploration may look incomplete
An empty or shortened report is not automatically evidence of zero demand. Check whether the selected events existed during the period, whether the conditions match exact parameter values, and whether the filters exclude the people you intended to study.
Google’s data retention documentation explains that explorations are affected by retained event-level data. Extending retention does not restore data that has already been deleted. Choose a usable period before interpreting a long-term trend.
New custom dimensions also need time before reporting becomes available. Google describes the processing expectations in its custom dimensions overview. Creating a definition is not a substitute for sending the parameter.
Use DebugView for controlled event checks, while accounting for consent and privacy settings that affect visibility. Do not override a visitor’s choices just to make a debugging panel look complete.
Keep website completion separate from lead quality
A successful inquiry can still be unsuitable, a duplicate, or spam. Website funnel improvement matters when it supports useful business outcomes.
Review accepted inquiries with the team handling them. Compare the resulting qualified leads using the same MQL and SQL definitions across periods. If a shorter form creates more submissions but fewer relevant opportunities, the headline completion rate is not the whole result.
A practical weekly review can fit into five questions: Did collection work? Where did the largest relevant drop occur? What evidence explains it? What single change will we test? Did qualified outcomes improve after enough time passed?
Technical references checked September 25, 2026. All numerical examples are hypothetical. Original illustrations generated for Rivatra.