Original framework
Form evidence ladder
Separate interaction signals from completed and commercially useful outcomes.
Define the successful state
Identify the system response that proves validation and storage succeeded: a server-confirmed response, unique success state or controlled thank-you destination. A submit-button click alone cannot prove that an enquiry was received.
Separate diagnostics from key events
Form views, starts, validation errors and abandonment can help diagnose friction, but they should not all be marked as key events. Reserve the lead event for the agreed successful state and document the form or purpose it represents.
Prevent duplicates
Test repeated clicks, browser refreshes, history navigation, slow responses and single-page application state changes. A success event should normally fire once for one accepted submission, not whenever the success interface renders.
Keep personal data out of analytics
Do not send names, email addresses, phone numbers, message text or other user-provided form fields to GA4. Use privacy-safe operational identifiers only when their purpose and governance are approved.
Validate the whole path
Test invalid fields, server errors, spam controls, consent states, mobile and desktop submissions, analytics debug tools and the destination system. Compare test records across the website, analytics and CRM or inbox.
Report measured leads honestly
Analytics can miss events because of consent choices, browser restrictions or implementation failures. Reconcile with the source system and distinguish accepted submissions from qualified opportunities.
Primary sources
Platform behavior and documentation can change. These primary references were reviewed for this guide: