Onchain attribution connects marketing campaigns to wallet activity, transaction volume, protocol revenue, and user retention, closing the measurement gap that traditional analytics tools (like Google Analytics or Mixpanel) can't see past the moment a user connects their wallet.

This guide breaks down why traditional attribution breaks in DeFi, the three core onchain attribution methods, and how growth teams turn wallet data into real ROI reporting.

KEY TAKEAWAYS

• Onchain attribution links GTM/marketing campaigns to wallet activity, protocol revenue, transaction volume, and retention.
• A report from Oct 2025 found 70% of DeFi projects fail to demonstrate marketing ROI, a direct result of using tarditional analytics tools that lose visibility onchain.
• The three core attribution methods are: UTM-to-wallet attribution, referrer-based attribution, and builder code (onchain referral) attribution.
• Multi-wallet identity resolution is essential; without it, CAC looks inflated and retention looks worse than it is.
• Multi-touch attribution models can improve CPA efficiency by 14–36% vs. single-touch models (Impact, 2025).

TIMESTAMPS

00:00 The onchain attribution gap
00:28 Why traditional analytics tools break in DeFi
01:05 DeFi in 2026, by the numbers
01:41 The 3 core attribution methods (UTM, referrer, builder code)
02:14 Attribution models: first-touch vs last-touch vs multi-touch
03:01 Why wallets ≠ users (identity resolution)
03:34 The metrics that matter (CPT, LTV, retention, revenue)
04:09 Building your attribution stack, step by step
04:34 Common attribution mistakes to avoid
04:57 How Formo solves onchain attribution

See the full video: https://www.youtube.com/watch?v=DwpOJ612jVE

To build user-facing products, you need to measure growth, understand user behavior, and prove ROI on campaigns, but the standard tools for doing this come loaded with invasive tracking, third-party cookies, and data collection practices that violate the ethos of the space.

Six years later, the tooling landscape has matured considerably. There are now niche tools, open data platforms, and multiple valid approaches to solving the analytics problem in DeFi. But the landscape is also fragmented, confusing, and full of tradeoffs that aren't obvious until you've committed significant engineering time.

This guide covers the major platforms, the do-it-yourself approaches, and the quirks you'll discover only after you start using them. It's written for founders and growth leads at crypto neobanks, prediction markets, and DeFi apps who need to make a decision.

Key Takeaways

• Traditional analytics tools like Google Analytics and Mixpanel break in DeFi because they cannot see wallet activity and onchain-data.
• Session-level data and onchain transaction data live in separate systems with no shared identity, making attribution, funnel analysis, and retention measurement impossible without a purpose-built layer.
• The three approaches to DeFi analytics: SaaS platforms that handle data ingestion and provide out-of-the-box dashboards (fastest time-to-value, least engineering overhead); custom data pipelines built on blockchain indexers (highest flexibility, highest engineering cost); and hybrid stacks combining both (the most common architecture at scale).
• Most teams underestimate the ongoing cost of custom analytics pipelines. New chain support, API changes, and schema migrations each require dedicated engineering time that scales with protocol complexity rather than team size.
• Using an existing analytics platform lets teams spend less time building data infrastructure & analytics, and more time shipping products users want.

https://formo.so/blog/defi-crypto-analytics-stack

Key Takeaways

• Crypto GTM starts with onchain behavior, not demographics, because wallet actions like staking, swapping, and voting reveal real intent better than Web2-style user profiles.
• Community-led and product-led growth dominate crypto adoption, as protocols like Uniswap and Aave scale by reducing onboarding friction and turning users into advocates.
• Unified analytics is the GTM edge in Web3, since linking website visits to wallet transactions lets founders measure true campaign ROI instead of guessing attribution.

Most crypto projects fail. It’s a hard truth, but one that founders must face. Often, the reason isn't a technical failure or a flawed concept. It’s a poor go-to-market (GTM) execution. While a brilliant idea can get you started, it's a deliberate GTM strategy that drives adoption, liquidity, and ultimately, success. Companies like Uniswap and Aave didn't just build great products; they built a playbook to get those products into users' hands.

For crypto startups, a GTM strategy is the blueprint for acquiring users, driving onchain activity, and building sustainable revenue. Yet, our discovery calls with web3 teams show that user acquisition and product analytics remain their biggest challenges. Traditional GTM playbooks fall short because they don't account for the unique dynamics of web3, like pseudonymous users and onchain data.

This guide is for you, the onchain builder. We’ll cover the core components of a crypto-native GTM strategy, explore effective growth motions, and show you how to use data to make decisions that lead to real growth.

https://formo.so/blog/crypto-gtm-strategy

Are you launching on mainnet? Here's a guide for you: https://formo.so/blog/defi-testnet-to-mainnet-launch

Key Takeaways

• Testnet traction does not predict mainnet adoption. Testnet users are experimenting with test tokens, not committing real capital. Most testnet activity is noise.
• What matters on testnet is one thing: can your target user complete the core action end-to-end without help? Raw user counts and transaction volumes do not matter.
• You are ready for mainnet when onboarding works, analytics are instrumented, liquidity is seeded, and docs are live. If growth has to guess what is breaking, you are not ready.

Key Takeaways

• KOL campaigns work when built around a narrative, an ICP-matched creator, and multi-week exposure, not a single post.
• Impressions and follower growth measure distribution only, not whether users connected a wallet or completed any onchain action.
• Web3 attribution breaks at the wallet: offchain clicks and onchain conversions are invisible to standard analytics tools.
• Referral and UTM persistence through wallet connection is the single most impactful fix for KOL attribution most teams skip.
• Cost per activated wallet, not cost per click, is the metric that makes KOL spend comparable to any other channel.

https://formo.so/blog/defi-kol-campaign-measurement

Key Takeaways

• Glamsterdam is Ethereum's next major hard fork, combining the Amsterdam (execution layer) and Gloas (consensus layer) upgrades. It is planned for Q3 2026, though the exact timeline remains subject to devnet testing progress.
• Parallel transaction processing arrives via EIP-7928 (Block-Level Access Lists). Nodes can now see which transactions do not conflict and process them simultaneously, laying the groundwork for significantly higher gas limits.
• Third-party relays are no longer required. EIP-7732 enshrines proposer-builder separation directly into the protocol, reducing centralisation risk and expanding the block propagation window from 2 seconds to roughly 9 seconds.
• State creation and access get repriced. EIP-8037 introduces a cost-per-state-byte model targeting 120 GiB/year growth, while EIP-8038 updates state-access opcode costs to reflect modern hardware. Both changes affect contract deployment and storage-heavy applications.
• ETH transfers now emit a standard log. EIP-7708 closes a long-standing blind spot: every non-zero ETH transfer or burn will produce a trackable event, removing the need for custom tracing in bridges, exchanges, and wallets.
• Cross-chain address consistency is solved. EIP-7997 mandates a universal CREATE2 factory across all participating EVM chains, giving developers deterministic addresses without chain-specific deployment scripts.
• No action required for ETH holders. Balances and existing contracts are completely unaffected. Node operators and stakers must update client software before mainnet activation.

https://formo.so/blog/ethereum-glamsterdam-upgrade