How to Track Wallet Attribution in Web3

TL;DR:

• Wallet attribution should connect discovery, product behaviour and a validated onchain outcome.
• Keep deterministic attribution separate from inferred attribution.
• Treat wallet and entity as different reporting units when the distinction changes a decision.
• The goal is decision-grade confidence, not a fictional perfect user graph.

Wallet attribution starts with the decision

Most Web3 teams do not have an attribution problem because they lack a tool. They have one because they have not defined the outcome they want to attribute.

Is the outcome a wallet connection, a first deposit, a successful swap, a first borrowed position, or a wallet that still generates value thirty days later? Those are different conversion events. They deserve different models.

I learned the value of this distinction on Morpho's migration flow. Onchain data showed roughly $38M migrated by October 2024, which looked like healthy traction. But the result was concentrated and Ethereum had only 70 migration transactions. I instrumented the journey around the migration CTA, including hover, click and conversion. The button had near-zero engagement because a dark CTA disappeared into a gray background.

The useful insight was not "attribution solved." It was that the onchain outcome alone could not explain the missed opportunity. Once the product funnel and onchain result were read together, the team had a concrete decision: improve the CTA, the prompt, communications and the flow. Ethereum migrated liquidity rose from about $6M to about $32M in January, a 433% increase. The public case study has the full context.

For acquisition, the same principle applies. Do not ask "which channel gets credit?" before defining the downstream wallet behaviour that makes a channel valuable.

Use three layers of evidence

Layer	What it proves	Examples
Discovery	How someone reached the product	UTM, referral, partner link, landing page, self-reported source
Identity handoff	Which observable identifier can join the journey	Wallet connection, signed message, known account
Outcome	Whether value was created	Confirmed deposit, swap, borrow, repeat action, retained balance

The chain is the source of truth for a settled protocol action. It is not the source of truth for the user's intent, the page they saw, or why they dropped before a signature. Product events explain intent. Attribution connects the two only where the join is defensible.

Start wallet-first, then enrich carefully

For many protocol questions, a wallet is the most reliable starting entity. It is observable and durable. But it is not automatically a person, and a set of wallets is not automatically a set of independent users.

In an internal analysis of the top pools on a Solana concentrated-liquidity DEX, I found that fewer than 1% of LP wallets controlled roughly 82% of the cohort's TVL. Entity attribution showed that more than 18 addresses belonged to one automated-vault counterparty. Raw address counts made the liquidity base appear more diversified than it was.

That finding informed product-launch, roadmap and resource-priority decisions. It also illustrates an attribution rule I trust: keep a wallet-level metric when that is what you observed, then add an entity layer only when the mapping is known well enough to explain and maintain. Never silently replace one with the other.

Separate confidence levels

The cleanest path is deterministic. Someone clicks a tagged link, lands on the site, connects a wallet in that session, and completes a defined onchain action. That path is auditable.

Real crypto journeys are not always clean. Users may discover a protocol on Telegram, research later on another device, then transact from a wallet with no complete browser trail. Modelled or self-reported attribution can be useful in those cases. It should not be combined with deterministic results and presented as one equally certain number.

Confidence tier	What belongs there	Reporting rule
High	Tagged touchpoint joined deterministically to wallet and confirmed action	Safe for operational channel decisions
Medium	Strong but incomplete session or account evidence	Show separately and state the rule
Low	Timing, cohort patterns or self-report only	Use for hypotheses, not headline ROI
Unattributed	No defensible join	Keep visible, never default it to organic

False joins are usually more expensive than missing coverage. They can make a team move budget toward a channel that did not create the outcome it claims.

Track the handoffs that matter

The minimum useful event sequence is usually:

1. Landing page and campaign context.
2. Wallet connection attempt and successful connection.
3. Transaction intent, signature request and submission.
4. Confirmed onchain action.
5. A later quality event, such as repeat usage, retained capital or revenue.

The exact sequence depends on the product. What matters is that transaction states are not collapsed into a generic conversion. A signature rejection, a reverted transaction and a confirmed position are different product and growth problems.

Report downstream quality, not just wallet connects

Wallet connection is often an identity handoff, not the finish line. A channel that brings fewer connections but more funded, retained or revenue-generating wallets can be the better investment.

Build at least two views: a simple last-touch view for day-to-day channel operations, and a first-touch or assisted-touch view for discovery. Then carry the cohort forward to the business outcome. This gives growth, product and partnerships a shared language instead of a fight over one oversimplified credit model.

A practical attribution checklist

1. Define the meaningful onchain outcome before implementing tags.
2. Write the identity and attribution rules in plain language.
3. Capture discovery, wallet connection and transaction states in one model.
4. Keep observed, inferred and unattributed results separate.
5. Check quality after conversion, not only the first wallet event.
6. Review the model when a new chain, product flow or campaign type changes.

Perfect attribution is not available in Web3. Decision-grade attribution is. It comes from being explicit about what is observed, what is inferred and what the business will do differently when the number moves.

If you need help connecting acquisition touchpoints to validated onchain outcomes, see Unchain Data's Web3 Attribution service.

Frequently asked questions

Is a wallet the same as a user for attribution?

No. A wallet is often the clearest observable unit for onchain behaviour, but one person may use several wallets and one entity may control many addresses. Report wallet-level measures accurately, then add entity logic only when the mapping is sufficiently reliable for the decision being made.

What is the best wallet-attribution model?

Start with deterministic joins from a tagged touchpoint to a connected wallet and a confirmed target action. Add self-reported or modelled views as separate confidence tiers. There is no universal model because the right event, attribution window and identity rule depend on the product's actual funnel.

Why is onchain data not enough for attribution?

Onchain data confirms what settled. It rarely shows the upstream page, campaign, wallet prompt or product friction that influenced the action. Joining it to product and acquisition events makes the conversion path diagnosable.