No single tool follows a crypto campaign from ad impression to on-chain action, which is why most teams run three at once. Web3 marketing analytics tools split into four groups that answer different questions, and the most common budget mistake is buying two from the same group and none from the others. A query platform tells you what happened on chain. A wallet intelligence tool tells you who the wallet is. An attribution platform tells you which campaign caused the visit. Product analytics tells you what the user did inside your app.
This guide is written from the buying side rather than the vendor side. We run campaigns and pay for these tools, so the useful part is which question each one actually answers and where the measurement breaks.
What are the four groups of Web3 marketing analytics tools?
| Group | Tools | Question it answers | Where it breaks |
|---|---|---|---|
| Blockchain query platforms | Dune, Flipside Crypto | What happened on chain, aggregated any way you can write SQL | Needs someone who writes SQL; tells you nothing about the ad that caused it |
| Wallet intelligence | Nansen, Arkham | Who this wallet is, what else it holds, how it behaves | Describes wallets, not campaigns; expensive per seat |
| Attribution | Spindl, Addressable, Cookie3, Formo | Which campaign or channel produced the wallet connection | Wallet identity does not travel like a cookie; coverage is partial by design |
| Product analytics | Mixpanel, Amplitude wired to wallet-connect | What the user did inside the product after arriving | Blind to everything before the connect event |
Market data services such as DeFiLlama and Messari sit outside these four. They describe protocols and markets rather than your users, and they belong in competitive research rather than in campaign measurement.
Which web3 marketing analytics tool should you start with?
Start with the question that is currently unanswered, not with the most capable tool. If you can already see on-chain activity but cannot say which channel produced it, the gap is attribution. If you can see which channel produced a signup but not what the wallet did afterwards, the gap is a query platform. Buying Dune when the real problem is attribution produces beautiful dashboards that still cannot justify a media budget.
Dune and Flipside
These are query platforms, and their strength is that nothing is hidden: if the data is on chain, it can be counted. The practical cost is staffing. A dashboard is only as good as the SQL behind it, and a marketing team without an analyst tends to end up with a copied dashboard nobody can modify or verify.
Nansen and Arkham
Wallet intelligence is for qualification rather than measurement. It answers whether the wallets arriving are the kind you wanted: their history, holdings and behaviour. It is a strong pre-campaign and post-campaign tool and a poor day-to-day one, because it describes wallets rather than the campaigns that produced them.
Spindl, Addressable, Cookie3 and Formo
Attribution is the group built specifically for the problem crypto marketing has and Web2 marketing does not: the boundary between a click and a wallet. These tools bridge it with tagging, fingerprinting and signed wallet messages, and each covers the path slightly differently. Expect partial coverage rather than complete attribution, and treat any vendor promising full-path certainty with suspicion, because the identity simply does not travel the way a cookie does.
Product analytics with wallet-connect events
The most under-used option, and often the cheapest. Standard product analytics wired to the wallet-connect event answers what happened after arrival, which is where retention lives. It cannot see the ad that caused the visit, so it works as the second half of a pair rather than on its own.
What breaks in Web3 attribution?
The boundary itself. In Web2 a cookie or device identifier follows a user from impression to purchase. In crypto the user arrives as a browser session and converts as a wallet, and those two identities are not linked by anything the platform gives you. Every attribution tool in this category is a different attempt to reconnect them after the fact, which is why coverage is always partial and why two tools measuring the same campaign will disagree.
- Decide the conversion event before buying anything. Wallet connection, first transaction and first deposit are three different events with three different costs.
- Expect disagreement between tools and pick one as the reported number. Reconciling two attribution platforms every month is a job nobody has time for.
- Instrument the campaign, not just the product. A coded link or campaign-specific landing page set up before launch beats any attempt to reconstruct the path afterwards.
- Measure at day 30. Arrival is cheap in crypto and retention is not, so the figure that matters is the share still active a month later.
How do we use web3 marketing analytics tools in practice?
For influencer work the vetting happens before any spend: accounts entering our roster are screened through Wallchain, Sorsa and TwitterScore, because the fastest way to ruin an attribution model is to pay for an audience that is not real. across our active X roster of 85 crypto accounts, the average account holds 102,199 followers but delivers 12,615 median views per post at a 1.74% engagement rate, and no analytics stack recovers a budget spent on the difference between those two numbers.
For task and community campaigns the reported figure is verified participants rather than completions, and the result is read at day 30 rather than at the peak. Three 2026 campaigns run that way moved member counts from 35,000 to 47,000, from 130,000 to 141,000 and from 40,000 to 45,000.
Deciding which gap to buy for first is the part worth getting right: how we scope measurement.
Setting up web3 marketing analytics correctly
Buying from the right group solves half the problem. The other half is setup, and most measurement failures we see are not tool choice at all: an event that never fired, a link that lost its parameters, a conversion nobody defined the same way twice. The order below is what keeps a stack honest once the invoices are paid.
Write the conversion event down first
Name the event before you shortlist anything. Wallet connection, first transaction and first deposit are separate moments with different costs, and a team that has not chosen between them will quietly change the answer whenever a report looks bad. Write the definition in one sentence, put it where the media buyer and the analyst can both see it, and date it.
Then write the secondary events you will also count, and what each is for: one number to optimise the campaign on, one to report to whoever pays for it. Keeping those apart stops the weekly optimisation metric from becoming the headline number, which is how a campaign that produced connections and no deposits gets called a success.
Instrument before launch, not after
Coded links and a campaign-specific landing page cost an hour before launch and cannot be reconstructed afterwards. Agree the parameter naming with everyone who places a link, including influencers and community managers, because a channel that arrives with no parameters becomes direct traffic, and direct traffic is where attribution goes to die.
Check the whole chain on the day before launch: click the link on a phone, go through the wallet browser people actually use, connect a wallet, and confirm the event lands in both the attribution tool and the product analytics with parameters intact. In-app browsers and redirect chains drop parameters routinely, and finding that out during a launch costs the week.
Decide what happens to traffic you cannot attribute before you see it, because there will be a lot of it. A share of arrivals always lands as direct or organic with nothing attached, and a plan that treats that bucket as failure pushes the team toward channels that are easy to tag rather than channels that work. Give it a name, measure its size monthly, and judge campaigns on the tagged portion.
Check a vendor before you sign
Ask which part of the path the vendor observes and which part it infers, and expect a straight answer. Ask what happens to your data at the end of the contract, whether raw events can be exported rather than dashboards, how seats are counted, and what the notice period is. A tool you cannot export from becomes the reason you keep paying for it.
Run one campaign on a trial before signing an annual deal, with the conversion event already defined, and compare the result against what your own instrumentation shows. Any vendor promising complete path certainty is overselling, since a browser session and a wallet are separate identities, so judge coverage against a campaign you understand rather than against the pitch.
Get the commercial terms in writing at the same level of detail as the technical ones: what a seat includes, what happens if the team grows mid-term, whether historical data stays reachable after the contract ends, and who answers when the integration breaks. Attribution setups break during launches, and a support commitment agreed after the fact is worth nothing.
Who owns the numbers internally
Decide who is responsible for the stack before it exists. Query platforms need someone who writes SQL, and a marketing team without one ends up with a copied dashboard nobody can modify or verify. Attribution needs whoever places links to follow the naming convention. Product analytics needs an engineer to keep events firing through releases.
Write those responsibilities into the plan with names against them and a monthly slot to review what broke. Tools in this category do not fail loudly: an event stops firing and the chart simply flattens, which looks like a market change until somebody opens the console. A scheduled check catches it while the campaign is still running.
What to do when reports disagree
Two tools measuring the same campaign will produce different numbers, and the difference is not a bug to be fixed. It comes from where each one is allowed to look. The job is to make the gap explainable rather than to close it, and to make sure everyone in the room is arguing about the same campaign and the same window.
Pick one number as reported
Choose one tool as the reported figure before the campaign runs and keep the others as diagnostics. Reconciling two attribution platforms every month is a job nobody has time for, and a monthly report whose source keeps changing is worse than one that is consistently conservative. Record the choice and the reason alongside the campaign brief.
Then work out the usual size of the gap between the two on a campaign you understand, and treat that as normal. A sudden change in the gap is the actual signal: it usually means something broke in the tracking rather than something changed in the market, and it is far easier to spot against a known baseline than in isolation.
Where the tracking usually breaks
The common faults repeat. The wallet-connect event fires on the wrong step or twice. A redirect strips parameters. A task farm arrives in volume and inflates connections. Staging traffic lands in the production project. The same campaign is named three ways across channels. Each is cheap to find in an hour of checking and expensive to discover in a quarterly report.
Keep a short list of those checks and run it at the start of every campaign rather than when a number looks wrong. Confirm the event fires once, that parameters survive the redirect, that internal traffic is filtered, and that campaign names follow one convention. Much of what gets blamed on attribution tools is a naming problem in the campaign sheet.
Reading results at day thirty
Arrival is cheap in crypto and retention is not, so read the result at day 30 rather than at the peak. Hold the reporting window steady across campaigns, because a channel that looks expensive on day one often looks different a month later, and comparing a week-old number with a month-old one produces decisions nobody can defend.
Report the same shape every time: the defined conversion event, the tool it came from, the window, and what is known to be missing. Naming the blind spot is what makes the rest credible, and it is the difference between a measurement stack that survives a budget review and a set of dashboards that get quietly ignored.
Keep the raw numbers somewhere you control rather than only inside a vendor dashboard. Export the events on a schedule and store them with the campaign names and dates, and the history survives a change of tool, a lapsed contract or a price rise that makes the old plan untenable. Rebuilding a year of campaign history from invoices and memory is the real cost of skipping a weekly export.
Before you pick tools, read our walkthrough on how to run crypto market research so you know which numbers are worth tracking in the first place.
Once the tracking is in place, our crypto marketing ROI benchmark figures give you a reference point for the numbers your dashboard reports.
Frequently Asked Questions
Which Web3 analytics tool is best?
There is no single best tool, because the four groups answer different questions and none covers the full path from ad impression to on-chain action. Most teams run a query platform, an attribution platform and product analytics together.
What is the difference between Dune and Spindl?
Dune is a query platform: it counts what happened on chain, in whatever shape you can write in SQL. Spindl is an attribution platform: it tries to connect an off-chain marketing touchpoint to an on-chain event. Dune tells you what happened, Spindl tries to tell you why.
Can Web3 attribution ever be complete?
No, and a vendor claiming otherwise is overselling. A browser session and a wallet are separate identities that the platform does not link for you, so every tool in this category reconnects them partially and by inference.
Do I need Nansen for marketing?
Only for qualification. Wallet intelligence answers whether the wallets you attracted are the kind you wanted, which is useful before and after a campaign but not as a running measurement tool.
If you would rather have this run for you, see our analytics and SEO work.