On-chain attribution: connecting a click to a wallet that matters

Google Analytics tells you someone clicked. Your wallet connect button tells you they connected. Then the trail goes cold.

Everything you actually care about happens after that point. Did they deposit? How much? Did they come back? The channel that produces the most wallet connections is frequently not the channel that produces the most deposited value, and until you can see both, you’re optimising the wrong number.

Why connections are a bad target

Wallet connections are cheap to generate. Airdrop hunters connect. Curious people connect. Bots connect. A campaign that promises anything free will produce an excellent cost-per-connection and contribute almost nothing.

We’ve seen the same pattern repeatedly: a channel looks like the clear winner on connection cost, then you look at what those wallets did afterwards and the picture inverts completely. The channel that looked expensive brought in fewer people who each deposited far more.

That’s not a small correction. It’s frequently the difference between a growth plan that works and one that burns through a budget while the product grows slowly.

The three layers

Layer one — session and click tracking. Standard stuff. Campaign parameters, source, medium, creative, landing page, device. You almost certainly have this.

Layer two — the bridge. At the moment a user connects a wallet or completes signup, you record the association between that session and the address, server-side, with consent handled properly. This is the piece most teams don’t build, and it’s the piece that makes the rest possible.

Layer three — on-chain behaviour. From the address, you can see everything that follows. Deposits, trades, holding period, whether they returned, whether they interacted with a competitor afterwards. Tools like Dune and Nansen do the heavy lifting here.

Skip layer two and layers one and three never meet. That’s the entire problem in one sentence.

Building the bridge

The engineering is not complicated. The details are where it goes wrong:

• Persist the session properly. Users click on mobile and convert on desktop more often than you’d like. A first-touch record that dies on device switch loses your highest-intent conversions.
• Store the pairing server-side. Not in a client-side tool, not in a third-party pixel. This data deserves proper handling.
• Handle multiple wallets per person. Power users have several. Decide early whether you’re measuring wallets or people, and be consistent.
• Handle consent. You’re associating a pseudonymous address with session data that may be identifiable. Under GDPR and comparable regimes that’s a real obligation, not a formality. Disclose it, establish a lawful basis, keep retention minimal.
• Record the timestamp of the first on-chain action, not just the connection, so you can measure the gap.

What to measure instead

Once the bridge exists, the metrics that matter change:

• Cost per funded wallet, not cost per connection.
• First deposit distribution, not just the average. A channel with a handful of large depositors and a long tail behaves completely differently from one with uniform mid-sized users, and the average hides that.
• 30-day retention of acquired wallets. Did they come back?
• Net value by cohort over time. The only metric that answers whether the spend paid for itself.
• Time from connection to first action. A long gap usually means the onboarding, not the acquisition, is the constraint.

The awkward findings

When teams first get this working, a few things tend to surface:

Airdrop and quest campaigns look terrible. Enormous connection volume, minimal deposited value, near-zero retention. Sometimes there’s a strategic case for that spend anyway. It should be made explicitly rather than hidden behind a flattering cost-per-connection.

Content and search outperform expectations. Slower, smaller volume, and consistently better depositor quality. People who arrived by reading something tend to understand the product.

Some creator campaigns are excellent and some are decorative. Without attribution they average out and you keep funding both.

Referral programmes need harder scrutiny. On-chain data makes self-referral and farming patterns visible in a way that click data never did.

What drives the build

• Whether your signup flow already captures a server-side event at wallet connect, or whether that has to be added.
• How many chains you operate across, since each needs its own indexing.
• Existing analytics maturity. Teams with defined events are much closer than teams with page views only.
• Privacy and consent requirements in your markets, which affect both design and retention policy.
• Whether you need real-time reporting or can work from daily batches, which is a meaningful difference in infrastructure.

The recommendation

Build the bridge before you scale spend. It’s a modest piece of engineering and it changes what every subsequent decision is based on.

Running paid acquisition for a Web3 product without on-chain attribution isn’t flying blind exactly — you can see clicks. It’s worse than that. You can see a number that looks like performance and points the wrong way.