Issue ticket: https://github.com/livepeer/explorer/issues/696
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.
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.
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 |
This event set is intended to measure movement through the delegation funnel, not every interaction within the Explorer. Future implementers may adjust event names to match Explorer code conventions, but the final event spec should preserve the same funnel coverage. If FAQs or similar links are added to the delegation widget, it is also recommended that events are linked to it to track engagement.
Event properties should be intentionally minimal. In most cases, the event name should provide the primary meaning, and properties should only be used when they add context that is not already captured by the event itself.
Suggested properties include:
| Property | Purpose |
|---|---|
source_surface |
Indicates where the event occurred when the same event can happen from more than one surface |
failure_type |
Provides a broad failure category when available, such as user rejected, wallet error, network error, or contract error |
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.