Measure where a swap funnel actually fails

Overall swap success rate is too coarse to explain a failing integration. Measure where attempts stop and which evidence was available at that point.

A proposed event vocabulary

• quote_requested, quote_available and quote_unavailable.
• approval_required, approval_submitted and approval_confirmed.
• review_shown, wallet_requested and wallet_rejected.
• transaction_submitted, receipt_success and receipt_failure.
• outcome_unknown and reconciliation_completed.

Attach a local attempt ID and safe provider request ID. Use chain and provider as bounded dimensions. Avoid raw wallet addresses or token pairs as unrestricted metric labels because they create both privacy and cardinality problems.

OpenTelemetry's trace and span model offers a way to connect work across services. A backend quote call can be a span, while the longer trade attempt persists as a domain record across browser sessions.

Measure delay separately from failure

Record quote latency, approval confirmation time, time spent in wallet review and receipt latency independently. A slow wallet decision should not inflate the provider API latency metric. Likewise, user rejection should not count as a contract revert.

Track unknown outcomes until reconciled rather than permanently classifying them as failures. Report sample size and missing telemetry when interpreting conversion figures; closing a tab can interrupt client events.

Use metrics to answer a question

If approvals rise after a deployment, compare the selected engine and spender configuration. If simulations fail only after account switches, inspect context invalidation. If quotes succeed but wallet prompts rarely open, examine the review-to-execution boundary.

These are diagnostic hypotheses, not claims about observed production behavior. Validate instrumentation with controlled fixtures before using it to rank providers or announce an execution success rate.