Web3 Product Analytics: From Events to Onchain Outcomes

Most Web3 analytics failures do not start with a missing dashboard. They start with a team measuring settled transactions while having no view of what users tried to do in the app.

I saw this clearly during Morpho's migration work. Onchain data showed roughly $38M in migrated liquidity by October 2024. That looked positive at first. But the distribution told a less comfortable story: most of the activity was on Base, while Ethereum had only 70 migration transactions. I instrumented the migration funnel alongside the onchain analysis, including the CTA hover, click and conversion steps. The migration button had near-zero engagement because a dark button disappeared into a gray background.

The fix was not another dashboard. It was a product decision: make the CTA visible, improve the migration prompt, communicate the feature properly, and redesign the flow. Ethereum migrated liquidity rose from about $6M to about $32M in January, a 433% increase. Total migrated liquidity later crossed $86M. The public case study is available here.

That is the useful definition of Web3 product analytics: connecting user intent in the product to the onchain outcome the business actually cares about.

TL;DR

• Treat frontend behavior, onchain state and business context as different measurement layers, then reconcile them.
• Design events around decisions and transaction states, not a long list of clicks.
• Use wallets as a useful reporting entity without pretending they always equal people.
• Give every metric an owner, definition and review cadence before it reaches a leadership dashboard.
• A good funnel exposes the next product decision. It is not a collection of charts.

Web3 product analytics has three layers

In a conventional app, a conversion can often be read from a stable account, a page view and a completed action. In Web3, the same journey can cross a website, a wallet extension, a network switch, a signature request, a transaction and a smart contract. A transaction that settles successfully tells you something important, but it does not tell you what happened to the users who never got that far.

That is why I separate a setup into three layers.

Layer	What it answers	Typical evidence
Product behavior	What did a visitor or connected wallet try to do?	Page view, wallet connect, quote seen, CTA click, signature request
Onchain outcome	What actually settled and created economic value?	Deposit, swap, position opened, fee paid, reward claimed
Business context	Which segment or decision should change?	Campaign, feature version, chain, cohort, referral, user segment

These layers should not compete for the title of source of truth. They do different jobs. The chain is the source of truth for settled protocol actions. Product tracking is the source of truth for intent and friction in the app. Business context makes both useful in a decision.

If 5,000 wallets begin a transaction and only 2,800 complete it onchain, the gap is not a data-quality annoyance. It is the product question. Is the issue a network switch, a wallet prompt, a slippage warning, insufficient balance, or a flow that users never understood? Without the first layer, the chain cannot answer it.

Begin with one business decision

Before selecting a tool or writing a tracking plan, write down the decision that analytics must improve. "Understand the user" is too vague to produce a useful event model.

Better starting questions look like this:

• Which step prevents a connected wallet from reaching its first successful deposit or swap?
• Does a product change improve completed onchain actions, not just clicks?
• Which acquisition sources create activated wallets that return?
• Which chain, vault or asset segment is losing users after first value?

Each question needs a definition of success. For a migration flow, that might be a successful migrated position rather than a clicked button. For a trading app, it may be a first completed trade within seven days of wallet connection. For a protocol with a recurring action, it may be the share of first-time wallets that return and complete a second meaningful action.

This sounds basic, but it avoids one of the most common analytics mistakes: instrumenting every visible element and still being unable to explain why a KPI moved.

Model transaction states, not one generic conversion event

"Transaction completed" is not a funnel. In crypto, several distinct states can fail for very different reasons. Collapsing them hides the diagnosis.

For a transaction-based journey, I normally want a clear state model such as:

1. The user sees the relevant product state, quote or CTA.
2. The user initiates the action.
3. The wallet signature is requested.
4. The user signs or rejects it.
5. The transaction is submitted.
6. The transaction confirms, reverts or is abandoned.
7. The resulting onchain position or balance is validated.

The exact names are less important than the semantic distinction. A rejected signature is not the same problem as a reverted transaction. A submitted transaction is not the same thing as a confirmed position. If a dashboard combines all three, it may tell a tidy story while the product team fixes the wrong step.

The migration example made that real for me. Tracking hover, click and conversion showed that the problem appeared before wallet execution. The team did not need to debate a theoretical source of friction. There was a clear place to improve the interface.

Choose the reporting entity conservatively

Web3 teams often ask whether the user is a wallet, an account, a device or a person. The answer depends on the decision, but the dangerous answer is to act as if they are all interchangeable.

A wallet is often the most reliable initial reporting entity because it is observable onchain. It is useful for activation cohorts, successful protocol actions and wallet-level retention. It is less reliable when an executive KPI claims to represent distinct humans, because one person can control multiple wallets and one wallet can be used by more than one actor.

Start with explicit entities: anonymous visitor, connected wallet, transacting wallet and known account, where the product legitimately has one. Add mappings only when you can explain the rule and its limitations. A conservative identity model is more valuable than a clever stitched graph that nobody trusts in an investment or product review.

Pick a tool for the problem, not for the logo

I have worked with Web2 product-analytics tools including Matomo, Mixpanel and PostHog, and Web3-specific products including Spindl, Cookie3 and Formo. They are not interchangeable, and no one product removes the need for a sound measurement design.

The practical question is whether the setup can reconcile app behavior with onchain outcomes at the level required for the decision. A managed product tool can be a sensible choice when the team needs fast funnel analysis and already works in that environment. A self-hosted or warehouse-led approach can be the better fit when data ownership, complex modelling, multi-chain coverage or custom reporting matters more. Web3-specific attribution tools can add useful channel context, but they do not replace canonical transaction and product definitions.

The wrong question is "Which tool should we buy?" The useful question is "Which events, identifiers and onchain outcomes must agree before we act on a metric?"

Make the analytics setup an operating system

Analytics becomes unreliable when it is treated as a one-off implementation. Product changes, contract upgrades, new chains and new acquisition channels can all quietly break a funnel.

For every core metric, document four things:

Requirement	What good looks like
Definition	A plain-language explanation and explicit inclusion rules
Owner	One person accountable for changes and questions
Source	The product events, onchain data and model used to calculate it
Review cadence	A recurring product, growth or leadership conversation where it changes a decision

This is not paperwork for its own sake. It is what lets a PM, analyst and founder arrive at the same conversion number without rebuilding it every Monday. It also makes the next change safer: when a new transaction flow ships, the team knows which events, tables and dashboards need review.

The smallest useful dashboard set

At the start, I would rather see four trustworthy views than twenty dashboards with mismatched definitions:

1. Activation funnel: visit or entry point to wallet connection to first successful value action.
2. Transaction-health funnel: initiated, signed, submitted and confirmed, split by the failure states that matter.
3. Retention cohorts: first meaningful action, return action and retained economic behavior by cohort, chain or feature.
4. Growth quality: acquisition source to activated and returning wallet, with downstream value rather than a vanity click count.

Executives need stable trends and definitions. Operators need the diagnostic cuts by chain, asset, campaign, device or product version. Giving both audiences one dashboard usually produces a compromise that serves neither.

A practical setup checklist

Use this before the next major product launch or growth push.

1. Name the business decision and the successful onchain outcome.
2. Map the journey from entry point to confirmed action.
3. Define transaction states and the failure reasons worth recording.
4. Decide which entity each KPI represents, and where it can mislead.
5. Specify how app events reconcile with onchain data.
6. Assign metric owners and a change process.
7. Review the funnel after launch with product, growth and data in the same conversation.

If the team cannot answer step five, it is not ready to trust the conversion rate. That does not mean the launch should stop. It means the metric should be treated as provisional instead of becoming a false source of confidence.

The point is better decisions

The most valuable outcome from product analytics is not a prettier reporting stack. It is finding the one obstacle that blocks real user value, then proving whether the fix worked onchain.

In the Morpho migration case, the onchain view said there was traction. The product funnel showed where a much larger opportunity was being lost. Putting the two together turned an apparently healthy metric into a concrete product decision.

That is the standard I use for Web3 product analytics: every core metric should help a team decide what to change next, and every important product change should be tested against the onchain result it is meant to improve.

If you need help connecting product behavior to onchain conversion, see Unchain Data's Web3 Product Analytics service.

Frequently asked questions

What is Web3 product analytics?

Web3 product analytics connects behavior inside an app, such as wallet connection or a transaction attempt, to validated onchain outcomes such as a completed swap, deposit or position. It is most useful when teams need to understand both what users did onchain and where they faced friction before a transaction settled.

Is onchain data enough to measure product conversion?

No. Onchain data validates settled actions and economic outcomes, but it cannot usually show what a user attempted in the interface, what they saw, or where they abandoned the journey. Combining product events with onchain validation turns a transaction count into a diagnosable conversion funnel.

Should a Web3 team treat each wallet as a user?

Wallets are a practical reporting entity for many protocol metrics because they are observable and durable. They are not always equivalent to people. Teams should label wallet-based KPIs accurately and use more aggressive identity stitching only when its rules, privacy implications and error rate are understood.

Which events matter in a crypto transaction funnel?

Track the states that identify the real source of friction: relevant CTA or quote viewed, action initiated, signature requested, signed or rejected, transaction submitted, transaction confirmed or reverted, and the validated onchain outcome. The names can vary, but a single generic transaction event is too coarse to diagnose most Web3 product flows.

How many dashboards should a Web3 team start with?

Start with a small set: activation, transaction health, retention and growth quality. Each should have one documented definition and a clear owner. Add breakdowns only after the core metric reconciles across product and onchain data and the team has a recurring decision that depends on it.

Verification notes

• Morpho facts and figures: public migration case study, reviewed 2026-07-30.
• Current service framing and CTA: Unchain Data Product Analytics, reviewed 2026-07-30.
• The advice and framework are Vincent's operational perspective, not claims about any particular vendor or protocol implementation.