A conversion alert fires. Product analytics shows a drop. Payments looks stable. The order database tells a third story.

The instinct is to compare queries, time zones, filters, and attribution rules. Sometimes that is enough. Often the disagreement began much earlier: each system was built to observe a different part of the journey.

The metric is not the agreement

“Checkout conversion” sounds precise until a team tries to act on it.

Does the journey begin when someone sees checkout, clicks the button, creates a payment intent, or reaches the first server boundary? Does success mean an authorized payment, a persisted order, or a confirmation shown to the buyer? Which bots, retries, internal sessions, and abandoned attempts belong in the population?

A dashboard can calculate a rate without answering any of those questions. It will still produce a number. The number may even be stable. That does not make the underlying agreement complete.

Start with the decision

Before choosing events, write down the decision the answer should support.

Are legitimate checkout journeys reaching an authoritative confirmed order?

That question forces useful choices:

  • what makes a journey legitimate;
  • where the product first observes intent;
  • which server-side outcome is authoritative;
  • how browser and server evidence correlate without using customer identity;
  • when missing evidence makes the answer unknown.

Only then should the team decide which events and fields are required.

Instrument the smallest proof

More telemetry does not automatically create more certainty. It often creates more definitions to reconcile.

The goal is the smallest evidence topology that can prove or disprove the expected behavior. A browser observation can show what the buyer experienced. A server event can show what the business system accepted. Neither should be silently promoted into the other.

The instrumentation should also encode its limits. If the correlation is incomplete, the system should report degraded measurement. If the population is too small, the answer should remain unknown. Missing data is not zero, healthy, or an incident.

Make the definition reviewable

Tracking plans drift when they live in a document separated from the code that emits them.

A stronger boundary is a normal code review: named events, closed fields, runtime-specific clients, tests, and a versioned contract. Engineering can see exactly where evidence is produced. Product and data teams can see what the answer means. Security can see what is allowed to leave the application.

That review is not process overhead. It is the moment the organization agrees on what it intends to know.

Keep the question alive

Once the reviewed change is deployed, the useful product is not another event stream. It is a standing answer:

  • whether the business is behaving as expected;
  • where the journey changed;
  • which segments are affected;
  • whether the measurement itself can be trusted.

Dashboards disagree when each one starts from its own data. Business observability starts from the question and works backwards to the evidence.