A Click Is Not a Conversion: Confirm the Business Outcome

Your signup dashboard rises after a button redesign, but the account database does not. The instrumentation may be counting a promise to do something as if the action had already succeeded. Before optimizing a conversion rate, separate the user's intent, the transport result, and the durable business outcome.

I maintain SensorFlow. This AI-assisted tutorial describes a measurement contract and synthetic acceptance scenarios, not customer results or a built-in conversion engine.

What should a conversion event prove?

A conversion event should represent a named business state confirmed by the system responsible for it. A click proves an interaction occurred; an HTTP response proves only what that endpoint's contract says. Neither automatically proves that an account, order, or export completed.

Consider three deliberately separate event names: signup_submitted, signup_accepted, and account_created. The first can describe a valid form entering the request path. The second can describe a service accepting work. The last should follow the agreed account-creation state, such as a committed account record, rather than the request leaving the browser.

Not every application needs all three events. Keep the stages that answer a real diagnostic question, and write down their owners. The client owns the interaction evidence; the account service owns the account state. A dashboard must not silently combine them into one generic success counter.

Why fetch resolving is not business success

MDN's Fetch guide explains that HTTP errors such as 404 do not necessarily reject the fetch promise. A callback running after fetch therefore cannot, by itself, justify a success event.

Checking Response.ok distinguishes the 200–299 range from other HTTP status ranges. It still does not define business completion: an API can return a successful transport response containing an application-level failure or a pending state. The client must interpret a documented response schema, not infer completion from a green network row.

The same boundary applies to Response.json(). Parsing a body produces a JavaScript value; it is not validation of the returned business state. A JSON body with a task ID may mean the task exists, not that its output exists.

For an asynchronous export, a useful contract might distinguish “request accepted,” “job running,” and “downloadable artifact created.” Count export completion at the last agreed boundary. If the business wants to measure requests, call the metric export requests rather than completed exports.

A 202 response belongs in pending, not completed

HTTP 202 Accepted explicitly allows processing to remain unfinished, or not yet started. The accepted work may subsequently fail. Treating 202 as completed converts queue acceptance into a fictional product outcome.

Use a task identifier to connect the request with subsequent state. The state may be exposed through a status endpoint, a service-generated event, or another application mechanism; the transport choice is separate from the metric definition. Do not fabricate a completion event merely because the browser has nothing more to wait for.

For example, a synthetic export request can be accepted at 09:00, fail at 09:03, and be retried successfully at 09:06. That is not two completed exports. Whether the retry is the same logical operation or a new operation must be defined by the application contract before counting either result.

Keep correlation, identity, and deduplication separate

A correlation key connects evidence about an operation. An actor key describes the account or device associated with an event. An event identifier distinguishes a specific event from its retransmissions. Reusing one field for all three purposes makes diagnosis harder.

Suppose one account submits two different exports. Deduplicating by account loses a valid operation. Suppose one export's completion notification is delivered twice. Counting every delivery inflates completion. The event model needs both an operation relationship and a policy for repeated delivery; neither policy should be guessed from the user's identity.

Choose one authoritative producer for the conversion numerator. If both the server and client emit completion observations, keep them distinguishable. Adding both counters together is not an independent confirmation; it is often double counting the same outcome.

This distinction also matters when migrating destinations. A new collector can receive every byte correctly while the report still changes because one side counts client observations and the other counts authoritative service events. Reconcile event semantics before interpreting a numerical difference as ingestion loss.

Test these scenarios before shipping the chart

Use synthetic identifiers and a staging application. The following are expected outcomes under the contract above, not results from a production deployment:

1. A valid submission is rejected by the business service. Submission may increase; completed accounts must not.
2. A request receives 202 and later fails. Accepted work may increase; completed work must not.
3. The service commits the account, but the browser loses the response. A server-owned completion can exist while client confirmation remains unknown.
4. The same completion observation is delivered again. The logical conversion must not increase under the chosen event-deduplication policy.
5. One account completes two distinct allowed operations. Operation count may be two while converting-account count remains one.
6. Completion arrives after a dashboard cutoff. Apply the documented late-arrival/revision policy; do not move occurrence time to the next day just to fit delivery order.

For each scenario, capture the application state, relevant event records, and the expected report cell. A visual toast, an SDK debug line, and a row in the destination are different evidence. A useful acceptance checklist shows exactly which of them proves the business state.

Delivery acknowledgement is another boundary

The analytics request itself has a lifecycle. Navigator.sendBeacon() returns true when the browser successfully queues data for transfer. That return value is not a receipt proving that the collector stored it, much less that the business operation succeeded.

Do not make core application success depend on a marketing report receiving an event. Conversely, do not equate a collector's acknowledgement with an application transaction committing. Instrumentation should preserve the distinction so missing observations can be investigated without rewriting the business truth.

There is also a failure window between committing business data and emitting its analytics event. A durable publishing design and reconciliation may be necessary when that gap matters. Merely moving a callback from client to server does not establish exactly-once behavior or eliminate all loss.

Define the evidence before moving the endpoint

Write a short release contract: the event name, authoritative producer, state that must exist, operation key, repeat-delivery rule, occurrence time, and handling of pending or unknown outcomes. Product, engineering, and QA should be able to apply it to the same fixtures and reach the same answer.

SensorFlow is an open-source, self-hosted event analytics pipeline using the official Sensors Data SDK ecosystem. Open-source deployment and synthetic demo data can run without a license; real SDK payload reception requires commercial license activation. Changing the event destination does not decide what a conversion means or guarantee transactional event publication.

Start with the six acceptance scenarios, then use the SensorFlow integration documentation to locate collection and storage checks. A reliable conversion chart begins with evidence of the outcome, not the convenience of a callback.