0% прочитано

A Click Is Not a Successful Action: Track Analytics After the Real Success Boundary

A click on Copy Link shows user intent, but it does not prove that the link actually reached the clipboard. If an action can fail, record the success event only after the operation has actually completed.

26 жовтня 2026 р. 8 хв читанняFrontend

The button was clicked. The handler ran. It may feel natural to increment the metric immediately.

But if the user clicks Copy Link and navigator.clipboard.writeText() rejects, the link was not copied.

The click happened, but the successful action did not.

User intent and the actual result are two different facts, and analytics should distinguish them.

If an action can fail, record the success event after the result is confirmed, not immediately after the click.

A Click Shows Intent, Not the Result

A click answers the question: did the user attempt the action?

If the metric is supposed to mean a successful copy, save, upload, or send, a click is not enough.

Between the button click and the result there may be an asynchronous operation that either succeeds or fails.

The real success boundary
click  |  vattempt action  |  +--> success --> record success event  |  +--> failure --> do not count success

Common Mistake: Recording the Event Too Early

The event is recorded before the copy is confirmed
async function copyLink(url) {    track('copy_link');     await navigator.clipboard.writeText(url);}

In this version, copy_link is recorded before the browser confirms the copy.

If writeText() rejects, analytics already contains a successful action that never happened.

The metric gradually becomes a count of attempts even though its name suggests successful copies.

Record the Success Event After the Operation Completes

Separate success and failure events
async function copyLink(url) {    try {        await navigator.clipboard.writeText(url);         track('copy_link_succeeded');    } catch (error) {        track('copy_link_failed');    }}

Now copy_link_succeeded appears only after writeText() completes successfully.

A failure can be recorded separately when it is useful for technical monitoring.

The important part is not to mix attempt, success, and failure into one metric.

User Feedback Should Follow the Same Boundary

Confirmation only after the action succeeds
async function copyLink(url) {    try {        await navigator.clipboard.writeText(url);         track('copy_link_succeeded');        showToast('Link copied');    } catch (error) {        showToast('Could not copy link');    }}

If the interface shows "Link copied" before the operation completes, the user may receive confirmation for an action that never happened.

User feedback and the success analytics event should therefore rely on the same confirmed result.

The Event Name Must Match What Is Actually Measured

Three facts, three events
copy_link_clickedcopy_link_succeededcopy_link_failed

copy_link_clicked means the user clicked the button.

copy_link_succeeded means the link actually reached the clipboard.

copy_link_failed means the attempt failed.

These values may be close, but they answer different questions.

A Successful Copy Still Does Not Prove an Actual Share

If the SHARES metric increments after Copy Link, at minimum it should wait until the clipboard write succeeds.

But even then, we only know that the link was copied. We still do not know whether the user actually sent it to anyone.

I cover that distinction separately in the separate article about a share action and a later visit through the shared link.

The same logic is useful for other actions where the result may differ from the intent:

  • saving a form;
  • uploading a file;
  • sending a message;
  • creating a payment;
  • adding a bookmark;
  • changing settings.

If the operation can fail, attach the success event to the confirmed result.

The Negative Test Matters as Much as the Positive One

Minimal test coverage
1. Click starts the copy attempt.2. Successful writeText() records the success event.3. Failed writeText() does not record the success event.4. "Copied" feedback appears only after success.5. Failure has separate feedback.

The positive test proves that the event is recorded after success.

The negative test proves something equally important: the system does not count a failed action as successful.

Analytics Should Describe a Fact, Not an Assumption

A click is a fact. An attempt is also a fact. Successful completion is a separate fact.

The problem begins when one event is named as if it represented another.

If the metric says "link copied," record it after the copy succeeds. If it says "button clicked," it can be recorded immediately.

Good analytics starts with a precise definition of the moment when the measured action actually happened.

Do not count intent as the result. Record the success event where success has actually been confirmed.