A paid visit is useful only if you can tell what happened after the visitor arrived. A submit-button click can look like a lead even when validation blocks the form, the network request fails, or a refresh sends the same confirmation event twice. The result is a report that counts activity instead of confirmed inquiries.
These six lead conversion tracking tests give you a small, repeatable check before a campaign starts. The examples are hypothetical. You can use a test environment, a fictional email address, and a test label that cannot enter your sales queue. A lead means that the form was accepted and the receiving system confirmed the inquiry, not that a button received a click.
Start with a confirmed inquiry
The useful question is not whether a visitor clicked. It is whether the form accepted the inquiry and your receiving system confirmed it. A simple pass rule keeps the report close to the human action you care about and makes failure paths easier to explain.
Set the pass rule before you test
A useful test sheet separates three moments: the visitor action, the capture result, and the analytics event. For example, a test visitor may click Submit, receive a validation message, and produce zero leads. That is a correct result, even though a click event exists.
It helps to choose one test ID for each run and record the observed result immediately. The pass rule for a confirmed submission is one accepted inquiry, one lead event, and one receipt or record in the receiving system. Failure paths should produce zero lead events. Keep test events outside live campaign totals by using a test property, test event name, or filter that your analytics setup supports.
If you need a report that compares visits with confirmed actions, the campaign reporting service page is a useful place to define the fields and checks before traffic starts. The service page is a destination for reporting scope, not a promise that tracking will work without testing.
The table below is a compact copyable version of the pass rules. “Observed” stays blank until you run the test.
| Test | Setup | Expected event | Expected leads | Failure signal | Next check |
|---|---|---|---|---|---|
| 1 | Valid fictional inquiry | Confirmed submission and one lead | 1 | Receipt exists but no lead event, or more than one event | Compare event ID with the receipt ID |
| 2 | Required field is blank or malformed | Validation only | 0 | Lead event fires before acceptance | Move the lead event after successful validation |
| 3 | Request is blocked or returns an error | Error state, no lead | 0 | Lead event fires before the response succeeds | Inspect request status and error path |
| 4 | Submit is clicked twice quickly | One confirmed submission | 1 | Two requests or two lead events | Disable repeat submission and add a deduplication key |
| 5 | Confirmation page is refreshed | One confirmed submission | 1 | Refresh creates another lead | Use an idempotent receipt or one-time event rule |
| 6 | Consent is granted, denied, or undecided | Event follows the permitted state | Depends on state | Tracking fires when it is not permitted | Compare consent log, tags, and event log |
1. A valid submission with confirmed receipt
A valid form can look correct in the browser while the receiving system silently drops the request. A hypothetical visitor enters a fictional address, selects a service, submits the form, and sees “Thanks.” If the inbox, database, or test endpoint has no matching record, a thank-you screen alone does not prove that a lead exists.
A practical step is to use a unique test ID such as LT-01-VALID-001. Submit complete, plausible test values once, then check all three records: the browser confirmation, the receiving system, and the analytics event. The expected result is one accepted inquiry, one matching receipt, and one lead event carrying the same test ID or another safe correlation value.
The test passes when those records agree. If the receipt exists but the event is missing, inspect the success callback or confirmation-page trigger. If the event exists but no receipt exists, the lead event is probably attached to a click or an early form action. A client-side event should follow confirmed acceptance, not merely a visible button state.
2. An invalid submission that should not count as a lead
Validation exposes false positives quickly. A hypothetical visitor leaves the required email field empty and clicks Submit. The form should explain the problem, keep the visitor on the form, and send no lead event because no inquiry was accepted.
You may want to use several invalid cases, such as an empty required field, an invalid email shape, and a value that exceeds the allowed length. For each case, record the validation message and inspect the event log. The expected outcome is a validation event if you use one, zero lead events, zero receiving-system records, and no confirmation page.
A failure occurs when lead fires at button click, form submit start, or field focus. You can move the lead trigger to the confirmed success path, then repeat every invalid case. This test matters because a large number of rejected forms can make a campaign appear to produce inquiries when it produces only attempts.
3. A failed network request
A form can pass validation and still fail between the browser and the receiving system. For a hypothetical test, use a controlled test endpoint or browser network controls to force a timeout, blocked request, or server error. It is better not to use a real customer form for this failure simulation.
The expected result is an error message or retry state, a recorded request failure, zero confirmed inquiries, and zero lead events. A response with an HTTP error status also needs explicit handling. The Fetch API returns a response object for statuses such as 404, so code must check the response status rather than treat every fulfilled request as success. A genuine network failure can reject the request promise.
Inspect the request and response in the browser network panel, then compare the result with the analytics log. If a lead event appears before the request returns successfully, move it into the success branch. If the interface reports failure but a record exists, check whether the server accepted the request before the browser lost the response. That case needs a receipt lookup or idempotent retry rule, not a second blind submission.
4. A repeat click on the submit button
Slow feedback encourages a second click. In a hypothetical run, the visitor clicks Submit twice before the first response returns. Two requests can create two inquiries, two notifications, or two lead events even though the person intended one action.
It helps to use the same fictional inquiry ID and click twice quickly. The expected outcome is one request that can create a lead, one receiving-system record, and one lead event. The interface can disable the button after the first accepted click, but the server should still protect against duplicates because a browser can retry or repeat a request.
A practical step is to check the network panel for request count, then compare IDs in the receiving system and analytics. If you see two requests, add a submission lock in the interface and a server-side idempotency key based on the test inquiry ID. If you see one request but two events, inspect whether both the form handler and the confirmation page send the event. For related checks on repeated conversion signals, read One Order, Two Conversions: Finding Duplicate Purchase Events.
5. A confirmation-page refresh
A confirmation page often loads after a successful submission, so a page-view trigger can be tempting. A hypothetical visitor reaches /thanks, refreshes it, and uses the back and forward controls. If every load sends a lead event, one inquiry becomes several conversions.
First submit one valid fictional inquiry and confirm one receipt. Then refresh the confirmation page twice and revisit it through browser history. The expected outcome remains one lead for the original inquiry. Page views may increase, but the lead count must not increase.
A strong check uses a unique receipt or submission ID and treats the lead event as idempotent. In plain terms, the same accepted inquiry can be recorded again without creating another conversion. If the setup cannot provide a server receipt, keep the confirmation event separate from the lead event and document the limit instead of claiming that a page view proves a new inquiry.
6. A comparison of permitted tracking under different consent states
Consent changes what measurement is allowed to run. A hypothetical test visitor first leaves analytics consent undecided, then denies it, then grants it in separate clean sessions. If the lead tag fires identically in all three sessions, the report may ignore the visitor's choice and create a privacy or governance problem.
You may want to create three test states: undecided, denied, and granted. You can record the consent state before the form loads, the tags or requests that run, the form outcome, and the event count. The expected result depends on your documented purpose, jurisdiction, and consent design.
A measurement event permitted without consent may be different from an advertising or personalization event that requires consent. The important check is that each request follows the rule you have documented.
A denied state should not send tracking that your policy requires consent for. An undecided state should stay blocked until the required choice exists. A granted state can send the permitted event after the valid submission succeeds.
It helps to check both the browser requests and the consent record, because a visual banner alone does not prove that a tag followed the selected state. Privacy rules differ by jurisdiction and purpose, so this test supports compliance review rather than replacing legal advice.
Download and use the test sheet
The lead-tracking-tests.csv worksheet contains the six scenarios, expected counts, and blank observed-result fields. A practical step is to duplicate the rows for a new form or environment, keep fictional IDs in test runs, and fill in observed_event, observed_leads, and status only after checking the receiving system.
The related guide 5 Campaign Tracking Links You Can Copy and Test can help you keep source and campaign labels consistent while you run these tests. It does not replace the six form and consent checks above.
Read the result before buying traffic
A passing test has a clear chain: the visitor completes a valid form, the receiving system confirms one inquiry, and the analytics record contains one permitted lead event. Invalid input, failed requests, repeat clicks, refreshes, and disallowed consent states produce no misleading lead count.
If a test fails, keep paid traffic out of the live report until you can state the failure signal and the next check. A small expected-versus-observed sheet gives you evidence that the measurement path works, while failure-path tests protect you from reporting clicks as real inquiries.