Implement Instrumentation Plan

Nobody has claimed this yet.

### Is your feature request related to a problem?

This feature implements research and planning done for the [Delegator UX Analysis RFP](https://forum.livepeer.org/t/rfp-delegator-ux-analysis-self-custody-vs-custodial-staking/3254).

### Describe the solution you'd like

1. Purpose and scope

The purpose of this instrumentation plan is to make the Explorer delegation funnel measurable without turning the Delegator UX RFP into a broader analytics buildout.

The plan focuses on aggregate funnel health: whether users are finding the delegation flow, expressing intent to delegate, connecting a wallet, selecting an orchestrator, submitting a delegation transaction, and successfully completing or exiting the flow.

This plan does not propose user profiling, wallet-level behavioral tracking, session replay, heatmaps, or any other invasive analytics layer.

2. Recommended analytics approach

The recommended approach is to use Vercel Web Analytics custom events for the delegation funnel. Explorer is already hosted on Vercel, and Livepeer already has access to a Pro account, so this should keep instrumentation low-lift and avoid introducing a new backend or analytics vendor.

The event set should remain small and focused on key delegation journey stages rather than broad Explorer analytics. The goal is to provide enough visibility to evaluate future delegator UX changes without expanding the scope into a full analytics implementation.

3. Delegation funnel and proposed events

The proposed event set maps the main stages of the delegation journey: discovery, orchestrator selection, wallet connection, delegation intent, review, transaction submission, transaction result, monitoring, redelegation, and exit.

Explorer’s current delegation flow does not begin on a dedicated delegation page. Today, the likely path is that a user opens the Orchestrators page, selects a specific orchestrator by opening its detail page, connects their wallet from the orchestrator detail page, and then continues through the delegation widget. Future UX improvements may add a clearer “Earn” indicator or entry point that routes users into the Orchestrators page, but the core discovery surface is still expected to be the Orchestrators page.

Funnel stage | Proposed event | Trigger
-- | -- | --
Discovery | earn_entry_point_clicked | User clicks a future Earn entry point that routes to the Orchestrators page (TBD after Design Brief is complete)
Discovery | orchestrators_nav_clicked | User clicks Orchestrators in the main nav
Discovery | orchestrators_page_viewed | User views the Orchestrators index page
Orchestrator consideration | orchestrator_detail_viewed | User opens a specific orchestrator page
Wallet connection | wallet_connected | User connects a wallet; should only be interpreted as delegation-related when it occurs from a delegation-relevant surface
Delegation intent | delegation_form_started | User begins a delegation attempt after wallet connection, such as entering a valid non-zero amount in the delegation widget; should fire once per attempt, not on every input change
Review | delegation_review_opened | Future-state event if a transaction review step is added
Transaction submission | delegation_transaction_submitted | User submits a delegation transaction
Transaction result | delegation_transaction_confirmed | Delegation transaction succeeds
Transaction result | delegation_transaction_failed | Delegation transaction fails
Monitoring | account_delegating_tab_viewed | User views the Delegating tab on the My Account page
Redelegation | redelegation_started | User starts switching delegation to a different orchestrator
Exit | unbonding_or_exit_started | User starts unbonding or exiting delegation

The event spec should avoid any properties that identify individual users or create wallet-level behavioral profiles. The plan should not include PII, wallet addresses, ENS names, raw transaction hashes, IP addresses, session replay, heatmaps, fingerprinting, or long-term user tracking.

The goal is to understand aggregate movement through the delegation funnel, not to reconstruct individual user journeys.

5. Baseline and future evaluation

Baseline measurement should be captured at the beginning of a future Delegator UX Implementation phase, before any major delegation UX changes are shipped. This teardown defines the recommended measurement approach, but the actual baseline should reflect the Explorer experience immediately before implementation begins.

The baseline should include both aggregate event counts and step-to-step conversion rates. Aggregate counts can show whether more users are entering the delegation journey, while conversion rates can show whether users are moving through the journey more successfully once they arrive.

The most important comparisons should be the conversion rates between major funnel stages, such as Orchestrators page viewed → orchestrator detail viewed, orchestrator detail viewed → wallet connected, wallet connected → delegation form started, delegation form started → transaction submitted, and transaction submitted → transaction confirmed or failed.

Future delegation UX changes should be evaluated by comparing post-change counts and conversion rates against this baseline. Raw counts should be interpreted carefully, especially if overall Explorer traffic changes. Where possible, success (of the new UX) should be judged by normalized funnel conversion improvements rather than delegation volume alone.

### Describe alternatives you've considered

There are numerous analytics alternatives, but we have chosen Vercel Analytics since the Explorer is already hosted on a Vercel Pro plan and Vercel Analytics retains privacy that Explorer users most likely desire.

### Additional context

_No response_

Start by tracing Explorer’s current delegation flow from the Orchestrators page through the orchestrator detail page, wallet connection, delegation widget, and My Account. Use the proposed Vercel Web Analytics custom events as the implementation checklist, keeping events aggregate and excluding PII, wallet addresses, transaction hashes, and long-term tracking. Done means the listed delegation funnel stages are measurable without introducing a new backend or analytics vendor.

Written by the indexing model from the issue text.