1. Define the outcome before choosing the signal
A visitor clicks Request a demo, fills out a form and reaches a thank-you page. Which part should count as a conversion? The click shows intent. A successful submission shows that the application accepted a request. The thank-you page shows that a browser reached a route. Those are useful signals, but they answer different questions.
Start with a sentence such as: a conversion means our application has accepted a valid demo request. Then decide whether reaching a route reliably implies that outcome or whether an explicit event is needed. Choosing a goal type first often produces a convenient number with an unclear meaning.
WhoVisited currently supports two matching rules: a page_view with an exact page path, or a custom event with an exact event name. Neither rule independently validates an order, a payment or a lead in your backend. Your application must establish the business outcome before the analytics signal can represent it.
2. Use a success-page goal when the destination is dependable
A success-page goal can work well when a form service redirects to a stable route only after acceptance, or when you can edit that route but cannot add a callback to the submission code. In the website goal settings, choose Success page and enter the exact path, for example /demo/thanks.
Enter the pathname, not a complete URL. WhoVisited stores the path separately from query strings and fragments, and goal creation rejects those extra URL parts. MDN describes pathname as the URL path component. A goal for /demo/thanks is not a wildcard for every route below it; /demo/thanks/ is also a different exact path.
The tradeoff is reachability. If someone can bookmark or directly open the thank-you page without submitting anything, a matching page view can still qualify that session. Guarding the page in your own application can improve the signal, but a client-side analytics rule does not provide that guard.
Also check whether multiple forms share one thank-you route. A shared destination measures arrival there; it cannot distinguish the originating form through query parameters under the current exact-path rule. Use separate stable routes or explicit event names when the distinction matters.
3. Use a custom event when you control confirmed completion
Choose Custom event when your application can identify an accepted operation without relying on a destination page. Configure an event goal for demo_request_accepted and emit that name after the acceptance condition. Avoid using a submit-button click as the completion event: validation, network failure or a backend rejection can happen afterward.
For an illustrative JSON endpoint, suppose the server contract is a successful HTTP response whose body contains status: accepted. The helper below checks both conditions. Replace that contract with your own documented response shape; this is application integration code, not a WhoVisited submission endpoint.
async function recordAcceptedDemo(response) {
if (!response.ok) return false;
let result;
try {
result = await response.json();
} catch {
return false;
}
if (result?.status !== "accepted") return false;
try {
window.whovisited?.track("demo_request_accepted", {
form: "demo",
});
} catch {
// Analytics must not turn an accepted request into a failed UI action.
}
return true;
}MDN defines Response.ok as HTTP status 200 through 299. That alone does not establish your business outcome: an endpoint might return a successful HTTP response containing a validation result or a queued operation. The explicit body check in this example matters. If your endpoint uses 204 with no JSON body, adapt the acceptance rule rather than copying this helper unchanged.
Call the helper once for the response representing the accepted operation, after the tracker is ready when collection is allowed. Its true return means the example acceptance checks passed, not that analytics delivery was confirmed. A missing tracker or analytics exception must not cause a user to resubmit a request that already succeeded.
4. Read conversions as qualifying sessions
In the current Growth report, a session is converted when at least one retained event in the same website and session matches the selected goal. The implementation uses an existence check rather than adding up every matching event. Two accepted requests in one session still contribute one converted session for that goal.
This has a useful consequence for success pages: refreshing the route within the same session does not automatically create two converted sessions. It also has a limit: a direct visit in another qualifying session can create another conversion without a new business transaction. Neither a page goal nor a custom event is a unique-customer or order ledger.
The reporting window scopes sessions by their start time. A matching retained event is associated with its session; do not assume the date selector is an independent event-occurrence filter. Older matching events can be included when you create a new goal, provided the relevant sessions fall in the selected window and the events remain retained.
A browser event is best-effort evidence. Consent, privacy signals, blockers, connectivity and collection eligibility can leave real accepted actions unobserved. Compare analytics with backend totals for diagnosis, but do not promise a perfect match or use the report to determine whether a customer was charged.
5. Test both false positives and missing outcomes
- Failed validation: submit invalid test input. The success route must not appear and the accepted-event signal must not fire.
- Backend rejection: return the documented rejection result. Verify that a click or HTTP response alone does not trigger the accepted event.
- Confirmed acceptance: perform one synthetic valid action and inspect the event or success-page path under the intended website.
- Direct arrival: open the success route in a fresh test session. Decide whether the resulting page-goal match is acceptable for your definition.
- Refresh and retry: refresh the success page, then exercise the application retry path. Distinguish repeated event records from converted-session counts.
- Collection unavailable: repeat with tracking blocked or consent withheld. Confirm the business action still succeeds without an analytics dependency.
Keep synthetic tests separate from real submissions and note the time and timezone. Inspect the events request payload and response, then the resulting visitor journey and selected Growth goal. A script download or a bootstrap response alone does not prove that the specific completion signal arrived.
Prevent repeated business submissions at the application or backend boundary. Session-level conversion counting does not make your form idempotent, and the small helper above does not prevent repeated calls. Reuse the application operation state and server protections you already need for reliable submission.
6. Choose one primary goal for a clear decision
For a redirect-only form, a protected stable success route may be the most practical signal. For a custom application with a dependable acceptance callback, an explicit event usually expresses the outcome more directly. Keep a click or thank-you arrival as a secondary diagnostic if useful, with a name that describes what was actually observed.
Do not sum a page goal and an event goal as though they were independent conversions. Both may describe the same action or session. Choose one primary rule for comparing traffic sources, record the acceptance definition, and validate it again when the form or router changes.
Use stable event names and keep personal details out of properties, paths and page titles. The example sends only a fixed form label; no email, message, transaction ID or customer name is needed to count an accepted demo request. WhoVisited event goals currently match the event name, not a property condition such as form equals demo.
When the meaning changes, create a new goal rather than silently treating old evidence as a different outcome. Goal names can be updated, but changing a matching rule requires a new goal in the current interface. Write down the new definition and check the retained historical matches before interpreting a sudden increase as business growth.