Web3 Analytics: Complete Guide to Blockchain Data Analysis

Master web3 analytics: pipelines, wallet clustering, sybil defense, attribution, cohorts, and decision-ready dashboards for DeFi, NFTs, and gaming.

Define web3 analytics end-to-end: from node/indexer choices and ETL to identity, attribution, sybil defense, cohorts, and decision-ready dashboards. This guide provides a hands-on framework for data teams to implement blockchain data analysis in practice, complete with metrics, checklists, and examples.

Executive Summary: Top Research Insights

Web3 analytics is the discipline of extracting insights from on-chain data across decentralized applications. In 2025–2026, as Web3 adoption expands, analytics has become critical for protocol growth and user retention. Blockchains act as transparent ledgers of every transaction and smart contract call, offering unprecedented data visibility. However, this data is pseudonymous and unstructured, requiring specialized methods (clustering, decoding, multi-chain indexing) to yield business intelligence. Below are five evidence-backed insights for teams investing in Web3 analytics today:

Step-by-Step Implementation Playbook

Step 1 — Objectives & KPIs

Define business goals and metrics: Begin with a clear measurement plan mapping your Web3 project’s objectives to specific Key Performance Indicators (KPIs). For example, if a DeFi protocol’s objective is “increase total value locked (TVL) by 20% QoQ,” relevant KPIs might include weekly net deposits, conversion rate from visitor to depositor, and liquidity provider (LP) retention rate. Outline each objective → metric → data source → owner → reporting cadence in a table for alignment. Avoid vanity metrics (e.g. pure wallet count without quality) and focus on metrics tied to outcomes. Ensure cross-team consensus on definitions to prevent “single question, many answers” inconsistencies.

KPI formulas and benchmarks: Specify how each metric is calculated. For instance, define Daily Active Users (DAU) as the number of unique wallet addresses that perform on-chain transactions with your dApp in a 24h period. Define 7-day retention as the percentage of new users (first-time wallets) who return and transact again within a week. In Web3, you might track TVL (sum of all assets staked/locked in your contracts) and ratios like TVL per active user. If measuring deposit conversion rate, formalize it as unique depositors ÷ unique site visitors who connected a wallet. Include formulas for LTV (lifetime value in terms of fees or tokens accrued), churn (% of users inactive over N days), and other key metrics to create a shared “metric dictionary”.

Pitfalls to avoid: Guard against vanity metrics – e.g., “total transactions” might grow due to bots or airdrop hunters and not reflect real user growth. Instead, emphasize quality metrics: e.g., median user TVL, repeat usage rate, or cost per acquired holder. Also, consider the context: a high DAO vote count might seem good, but if dominated by Sybil accounts it’s a false signal. Align teams by reviewing the measurement plan in a kickoff workshop. By solidifying objectives and KPIs upfront, you set a “north star” for your analytics implementation and ensure everyone knows what success looks like.

Step 2 — Data Foundations: Nodes, Indexers & ETL

Choose reliable data sources (nodes): Your analytics pipeline starts at the blockchain node layer. Decide between running your own full node(s) or using a service, balancing reliability and maintenance. Full nodes (or archive nodes if you need historical state queries) give complete on-chain data but require upkeep; light nodes or third-party RPC endpoints provide ease but at the cost of dependence. Many teams use a hybrid: multiple Ethereum client nodes (e.g. Geth, Nethermind) plus a fallback RPC provider. This multi-node strategy provides redundancy (if one node fails or lags, data ingestion swaps to another) and cross-verification of data consistency. Also implement a confirmation delay: e.g., wait for 12 block confirmations (~2–3 minutes on Ethereum) before treating a block’s data as final to avoid temporary chain reorgs. On unstable testnets or alt-L1s, consider longer finality thresholds if reorgs are common.

Indexing and streaming: To ingest on-chain events efficiently, set up indexing processes. Traditional approach is polling nodes for new blocks or events (e.g., using eth_getLogs filters). However, this can miss context (logs alone lack timestamps or internal call data). More modern approaches use block-level indexing: e.g., pulling full block receipts for all transactions, or leveraging streaming frameworks. Tools like The Graph’s Firehose provide a forked node that streams new blocks and historical ones via gRPC in real-time. This can simplify your ETL: as soon as a block is produced, it’s pushed to your pipeline without heavy polling. Firehose and similar systems also handle chain reorg notifications internally, so your index can automatically revert and reprocess blocks if needed. The goal is a robust ingestion layer that captures every relevant on-chain event (transactions, contract logs, token transfers) with minimal delay and no duplicates.

ETL architecture: Design a pipeline to extract, transform, and load blockchain data into your analytics warehouse. A typical architecture might ingest raw blocks or events via a message queue (e.g., Redis streams or Kafka) for resiliency. Then have worker processes decode and normalize data: for each transaction, parse human-readable fields (timestamps, from/to addresses, decoded event parameters). Store normalized records in a scalable database. Many teams use a combination of a relational database (SQL) for structured querying and a blob storage or NoSQL for raw data. For instance, store core tables like Transactions, Events, Wallets in PostgreSQL or BigQuery for analysis, while keeping raw JSON receipts in cloud storage for replay or auditing. Ensure your schema can handle growth: partition tables by date or block range, index key fields (like wallet addresses) for fast lookup. The indexing latency (from on-chain event to warehouse) should be kept low – data freshness is vital since decisions may be made on daily or even intraday on-chain trends. Diagram your ETL: Node → Queue → Parser → Database. Build monitoring to watch for lags or dropped blocks, with alerts if data freshness SLA (say 1 hour) is breached.

Reorg and data quality handling: Implement logic to handle blockchain reorganizations and data consistency. For example, before finalizing a block’s data, check if its parent hash matches the previous block stored; if not, a reorg occurred. In that case, backtrack and replace stale data with the new chain’s data. Maintain an idempotent pipeline where reprocessing a block (or a range of blocks) won’t duplicate records (e.g., use unique transaction hashes as primary keys). Additionally, use multiple sources to validate data: cross-verify critical metrics (transaction counts, balances) against a blockchain explorer or second node periodically to ensure your indexer’s accuracy. High data integrity (correct, deduplicated, timely records) is non-negotiable – studies show poor data quality can cost organizations significant revenue. By building a strong foundation in nodes and ETL, you set the stage for trustworthy analysis.

Step 3 — Event Taxonomy & Metric Layer

Establish a clear event taxonomy: As you capture on-chain events, define a consistent naming scheme and structure. Each smart contract interaction that matters to your business (e.g., “Deposit”, “Withdraw”, “MintNFT”, “VoteCast”) should have a well-defined event name in your analytics layer. Start by listing all relevant on-chain actions for your use cases: contract events (from ABI logs) and any off-chain events (web or app actions like a wallet link click if you capture those). Create naming conventions, e.g. protocol.action.object format (vault.withdraw.asset, game.completeQuest). Versioning is important: if a contract is upgraded and event parameters change, you might version the event name (e.g., Deposit_v2) or handle logic in the metric definitions. Document each event with its source (contract address and event signature or off-chain trigger), payload fields, and any transformations (units, etc.). This “tracking plan” for on-chain events is analogous to a product analytics spec in Web2, but tailored to smart contract activities.

Chain-specific nuances: Accommodate differences across chains. For instance, Ethereum events have block timestamps (which you’ll convert to human-readable time) and may require decoding topics to get addresses. Other chains like Solana might not have logs in the same way and require parsing transaction instructions. Normalize data where possible: e.g., store all addresses in a standard format and include chain/network identifier for each event (so you can distinguish an event on Ethereum vs. Polygon). Build an event dictionary that describes each event type and includes which chain(s) it applies to. This also means tagging events by vertical or feature (e.g., label certain events as “DeFi:Lending” or “NFT:Marketplace” to enable category-level analysis).

Metric layer and semantic definitions: On top of raw events and tables, create a metric definition layer so that analysts and BI tools can use consistent calculations. This could be implemented via a metrics store or simply through SQL views and YAML definitions (as in dbt or LookML). For example, define “ActiveWallets_7d” as count(distinct wallet_id) where event_date >= today-7 and event_type in (a set of key user actions). Define “RepeatBuyer” cohort as wallets with ≥2 NFT purchase events in a 30-day span, etc. A centralized metric dictionary (maintained in a git repository or BI tool) ensures that when different team members ask “How many active users do we have?” or “What’s the average transaction size?”, they use the same formula and filters. Business units or data owners should sign off on these definitions to align them with business logic (e.g., what counts as an “active” user in context of a DeFi pool might exclude pure contract interactions by automated strategies). Where possible, implement metrics in code as reusable components – for instance, if using a modern data platform, create a YAML metric definition for TVL that sums distinct asset balances from your ledger table, and reuse it in dashboards. This semantic layer will feed the dashboards and queries so non-technical users can trust the numbers without needing to know the underlying SQL each time.

Data quality checks: Build tests for your metric calculations. For example, if “Daily NFT Mints” suddenly drops to zero or spikes abnormally, have automated alerts – it could indicate an upstream data issue or a contract change. Consider implementing unit tests on your data transformations (e.g., ensure that summing by token across events equals known totals from an external source). This is akin to CI/CD for data. It also helps to assign each metric an owner (usually a product manager or data analyst) who is responsible for its definition and accuracy. By meticulously defining your event taxonomy and metrics layer, you pave the way for accurate and efficient analysis – the heavy lifting of interpretation will be done once, centrally, rather than in each new analysis.

Step 4 — Identity & Wallet Clustering

Unify user identities across wallets: Web3 users often interact via multiple wallet addresses, making it crucial to perform wallet clustering. Clustering is the process of linking addresses that likely belong to the same entity (user or organization). Implement heuristic-based clustering and, if available, incorporate external labels. For UTXO-based chains like Bitcoin, a classic heuristic is co-spending: if two addresses appear as inputs to the same transaction, they are controlled by the same owner. In Ethereum and other account-based chains, heuristics differ – one common approach is tracking “create” operations: if Address A creates Contract B, cluster them as A’s addresses. Similarly, repeated patterns of self-transfer between two wallets or a wallet consistently funding another can indicate a single user. Use on-chain metadata as well: ENS domains or vanity addresses can be clues, though they are not deterministic. Some advanced methods use time-based correlation (addresses that always operate in tandem timeframes) or graph analysis (cliques of addresses interacting exclusively). Ground truth is valuable: if you have users signing in via web2 and linking a wallet (through email or OAuth), use that to anchor clusters. Chainalysis, for example, only clusters addresses when they have verified linkage (e.g., exchange deposit addresses known to belong to one service) and can group over a billion addresses into entities using deterministic rules. Aim for high precision in clustering to avoid false merges (treating two unrelated users as one can skew metrics). It’s better to leave some addresses unclustered (counting them as separate users) than to wrongly combine distinct users, especially when measuring user counts, balances, or cohorts.

Label enrichment: Integrate any available labels (address metadata) to augment identity resolution. Labels might come from external databases (e.g., Etherscan or a blockchain analytics API that labels exchange hot wallets, DeFi contracts, known hackers, etc.). By tagging known entity types, you can separate “user” wallets from contracts or institutional wallets. For example, label clusters that correspond to exchanges, bridges, or known whales. This helps in analysis like excluding exchange flows from retention calculations (since an exchange address isn’t an end-user). If your project has user accounts linking multiple wallets, maintain that mapping in a secure table to use in clustering. Additionally, consider user-consented social linkages: some users may link a Twitter or Discord to their wallet via a signature (using tools like Sign-in with Ethereum or others). These can provide additional signals to cluster addresses (e.g., if the same Twitter handle is claimed by two wallet addresses, they’re the same person). Use caution and consent – respect privacy and do not deanonymize beyond what users opt in to. A privacy-aware design might use one-way hashes of identifiers to link addresses without exposing identities directly.

Evaluating clustering accuracy: Periodically evaluate the quality of your wallet clusters using precision and recall metrics. If you have a ground-truth set (perhaps from known airdrop Sybil lists or internal user data), measure how many addresses your clustering correctly groups (true positives) vs. misses or wrongly groups. For instance, a recent study of airdrop Sybil detection achieved over 90% precision and recall in identifying Sybil clusters using graph and temporal features. While your goal might not be to catch Sybils per se here, the same evaluation approach applies: you want a high precision (most clustered addresses truly belong together) and sufficient recall (most real multi-address users are clustered, not left fragmented). An error in clustering can dramatically affect KPIs – e.g., if one user with 5 wallets is not clustered, your DAU could be inflated by counting them 5 times; conversely, if you cluster two different users erroneously, you undercount population size. Therefore, treat clustering algorithms as part of your core data pipeline and invest in continuous improvement. Use manual review on a sample of clusters: for example, examine the transaction graph of addresses in a cluster to see if it intuitively makes sense (addresses funding each other, or a main address moving assets between them). Leverage community or open datasets where possible (such as known Sybil address lists, or Dune dashboards that provide tagged addresses) to validate your methods. Over time, incorporate feedback loops: if downstream analyses or anomalies suggest a clustering issue (e.g., a single “user” cluster suddenly has an implausible spike in activity across chains), revisit the heuristics.

Step 5 — Sybil Detection & Authenticity Scoring

Detect and flag Sybil patterns: Web3 growth initiatives (airdrops, incentive programs) often attract Sybil attackers – one person creating many wallets to claim rewards or manipulate metrics. Implement a Sybil detection module to maintain data quality. Start by engineering features that indicate non-human or multi-account behavior: e.g., the number of sequential addresses created (if one user generates 50 wallets via scripts), the entropy of activity (Sybil wallets often have very regular, scripted transaction patterns), interaction graph structure (Sybil wallets might all funnel tokens to the same main address), and telltale signs like incremental wallet addresses or repetitive funding from a common source (e.g., a faucet or single exchange account funding hundreds of new wallets). Time-based features are useful too – if a supposed “new user” address immediately performs actions at a speed no normal user would (joining 10 different protocols in one day to farm airdrops), that’s a red flag. Some teams use machine learning for Sybil detection: for example, Artemis pooled known airdrop exclusion lists (from Arbitrum, Hop, etc.) to train a model that scores addresses on Sybil likelihood. Graph neural networks or LightGBM models have shown success by analyzing address subgraphs (e.g., an address’s neighbors and activity chronology). If you lack capacity for ML, rule-based filters can catch obvious cases: e.g., “if an address made 5 transactions all to the same contract and nothing else, and was funded by Tornado Cash, flag as Sybil.” Use a combination of such rules and statistical anomalies to tag suspicious wallets.

Integrate Sybil scores into metrics: Once Sybil (or likely-bot) addresses are identified, decide how to handle them in your analytics. A common approach is to maintain an “authentic user” flag or score for each wallet or cluster. For binary classification, you might exclude all flagged Sybils from certain metrics – e.g., when reporting active users or retention, filter out wallets marked as Sybil to avoid skew. For more nuanced approaches, you could weigh activity by the Sybil probability (downweight suspected bot activity rather than removing entirely). The impact of Sybil removal can be significant: for instance, Nansen’s research on a recent Layer-2 airdrop (Linea) found over 50% of participant addresses were likely Sybils. Filtering these out gives a truer picture of real user engagement. When you compare metrics with vs. without Sybil filtering, you’ll often see more realistic retention curves and conversion rates – typically lower absolute numbers, but higher quality. For example, a campaign might show 10,000 new addresses, but if 6,000 are Sybils, the true new users are 4,000 with perhaps a higher retention among them than the mixed pool. Use visuals to communicate this internally: a chart of “raw signups vs. Sybil-filtered signups” can highlight the importance of the filter for realistic KPIs.

Tuning and review process: Maintain a feedback loop for your Sybil detection. Sybils evolve tactics (e.g., splitting funds between addresses to appear more “legit”), so your rules and models should be updated periodically. Monitor false positives especially – you don’t want to accidentally classify legitimate power users as Sybils. If a user is wrongly flagged (perhaps they legitimately created multiple wallets for privacy but are a single person who actually uses the product in each), that could distort your analysis of high-value users. One strategy is to tier your Sybil flags into confidence levels: “Tier 1 – Highly likely Sybil (e.g., known flagged in other airdrops), Tier 2 – Suspicious pattern, Tier 3 – Mild anomaly.” Analysts can then choose to exclude only Tier 1 for certain analyses or do sensitivity checks. Document the detection criteria transparently (at least internally) and, if applicable, communicate to the community when Sybil filtering is used (for instance, some protocols publicly announced removing Sybil addresses from an airdrop eligibility, which also serves as a deterrent). On the data side, track the effect of Sybil filtering on metrics like retention or TVL – often you’ll notice that unfiltered metrics give an inflated view (e.g. retention including Sybils drops off a cliff after incentives end, whereas filtered retention shows the genuine user loyalty). This difference underscores why having a Sybil defense mechanism is vital for any Web3 analytics stack dealing with user metrics.

Step 6 — Attribution (UTM→Wallet)

Link off-chain marketing to on-chain action: Traditional marketing attribution uses things like UTM parameters, cookies, and user IDs – in Web3, the challenge is connecting a user’s journey from a web click to an on-chain transaction. Set up a mechanism to capture an off-chain identifier at the point of dApp entry and tie it to the on-chain wallet address. One common approach is using a unique referral or UTM code that the user carries into the dApp: for example, when a user clicks a campaign link, have them land on a page where they connect their wallet. At that moment, log an event linking the UTM campaign and the wallet address (this could be stored in your database or a service like Segment if you use one). Another technique is having users sign a message containing a referral code or campaign ID, which proves ownership of the wallet and links it to that marketing source. For instance, if running an airdrop signup, include a step where the user’s wallet posts a signed payload that includes their UTM parameters – now you have an on-chain verifiable link of “wallet X came from campaign Y.” In practice, teams like Spindl have SDKs to track wallet journeys from ad click to on-chain event via fingerprinting and signatures. Implement either a homegrown solution or integrate such a tool to establish the off-chain → on-chain connection.

Multi-touch attribution modeling: Rarely is a conversion (e.g., a user making their first deposit) driven by a single touchpoint. Marketing might involve multiple touches – a Twitter ad, then a community AMA, then the user tries the dApp. Develop a multi-touch attribution model using your data. First-touch attribution (which source brought the user initially) and last-touch attribution (the last thing before conversion) are simple starting points. For example, record the first campaign a wallet was associated with and the last campaign or referrer just before they executed the key action. Then explore models like time-decay (more recent touches get more credit) or position-based (e.g., 40% credit to first and last, 20% distributed to middle touches). In Web3, an example: a user’s wallet might first be seen coming from a Discord link, but later they click a blog link and then perform a swap on-chain. Attribution would distribute conversion credit between “Discord” and “Blog” touchpoints per your model. Use SQL or a scripting approach to join off-chain tracking data with on-chain events. For instance, you might have a table of wallet sessions (with timestamps and referral info) and you join it to the first on-chain transaction time for that wallet. An SQL example: SELECT wallet, session.campaign, session.source FROM Sessions s JOIN OnChainEvents e ON s.wallet = e.wallet AND e.type = 'FirstDeposit' AND s.timestamp < e.timestamp ORDER BY e.timestamp LIMIT 1 per wallet to get the last touch before conversion. More sophisticated: create a path table of all touches for each wallet and apply weights. Document the chosen attribution logic so marketing and product teams understand how credit is assigned.

Track funnel and ROI: Build a funnel view from marketing through on-chain conversion and beyond. For example, track how many site visitors (by campaign) connect a wallet → how many of those do an on-chain action (mint, deposit) → how many of those retain or perform secondary actions (stake, trade again, etc.). Use this to calculate metrics like cost per acquired user or ROI per channel. If you spend $X on a campaign that brought in 100 wallets, of which 20 became active users with an average LTV of $Y (in fees or tokens), you can compute ROI. Attribution is key for this – without linking wallet to campaign, you’d have no way to tie those 20 users back to the campaign spend. Implement dashboards for this funnel: e.g., a chart of conversion rate by campaign for users from click → on-chain action. Another crucial aspect is experimenting and measuring incrementality: run A/B tests or holdout groups where possible. For instance, maybe you target a specific region with an ad and compare on-chain adoption in that region vs. a control region – that can show lift attributable to the campaign. While harder to do in decentralized contexts, even simple before/after comparisons or using unique promo codes on-chain can serve as proxies for lift. Finally, ensure attribution data is fed back into decision-making quickly. If one influencer referral yields high-LTV users (e.g., wallets from influencer A have 2x the retention of those from influencer B), surface that insight so you can adjust spend or strategy accordingly. A multi-touch, end-to-end attribution system connects the dots from marketing efforts to actual on-chain success, closing the loop for growth teams.

Step 7 — Cohort & Lifecycle Analytics

Cohort analysis for user lifecycle: Group your users into cohorts to understand how their behavior and retention evolve over time. A common approach is to cohort by start month (or week): e.g., “users who first used the dApp in January 2025” and then track what percentage of them are still active in subsequent months. This reveals retention curves. Use on-chain activity to define “active” (e.g., at least one transaction in the protocol). Construct a cohort table: rows = cohort start month, columns = month 0 (initial count), month 1 retention %, month 2 retention %, etc. A real example: Token Terminal’s data shows that for some DeFi protocols like Synthetix, a cohort of users acquired during a short-term incentive campaign had very low retention – users came for the rewards and left. Meanwhile, cohorts who joined organically in other periods had higher retention, indicating more genuine engagement. Such insights are invaluable: you might find, for instance, that only 10% of the wallets that tried your game in the first week continued playing a month later – perhaps a sign of poor onboarding or too many speculators. By visualizing cohort decay, you can communicate the “leaky bucket” problem to the team and prioritize fixes (e.g., improve tutorial, adjust incentives for repeat usage).

Lifecycle segments & behavior analysis: Besides time-based cohorts, segment users by lifecycle or behavioral attributes. For example, segment by whale vs. minnow – high balance users vs. low balance – to see if retention or activity differs. Or segment by user persona: in an NFT marketplace, you might categorize wallets as “collectors” (hold NFTs long-term), “flippers” (buy and sell quickly), or “creators” (mint NFTs). Each group might have different engagement patterns. Perform RFM analysis (Recency, Frequency, Monetary value) on on-chain data: e.g., recency = days since last on-chain action, frequency = total number of transactions in protocol, monetary = total value transacted or fees paid. This helps identify top tiers of users (your most loyal and valuable). A cohort analysis on top of that can show, say, that “high frequency traders have a 50% 3-month retention, whereas one-time users have 10%” – indicating the need to nurture more users into high-frequency usage. For each lifecycle stage (new user, active user, lapsing user, churned user), define criteria and monitor counts. For example: a churned user might be defined as a wallet that was active last quarter but had zero transactions this quarter. Track the percentage of new users that convert into active, active that lapse, etc., as a pipeline. This is akin to a traditional user funnel but in on-chain context.

Use case-specific metrics: Tailor cohort and lifecycle metrics to your domain. In DeFi, look at cohort TVL retention: of the capital that is deposited by a cohort of users, what % remains after 1 month, 3 months (money can “churn” just like users). You might find that users who joined during a liquidity mining program withdrew 80% of their funds after the program ended – a sign of incentive-driven behavior. In NFTs, examine collector cohort behavior: e.g., users who made their first NFT purchase 6 months ago – what fraction have made another purchase since? Are they still holding the NFTs or have they sold? Metrics like median hold time of an asset for different cohorts can be insightful. If you have a blockchain game, define cohorts by level reached or by the in-game asset acquired, to see how gameplay milestones correlate with retention. Always connect these back to outcomes: does early engagement lead to higher lifetime value? For instance, “Players who complete 5 on-chain quests in their first week have a 3x higher 30-day retention than those who complete only 1 quest.” That suggests a KPI around early depth of engagement. Use cohort charts and maybe retention curves in dashboards for clarity. A retention curve typically flattens at some point – that flat plateau is your long-term retained user base. Compare that across cohorts to see if newer cohorts are improving (a good sign that product changes are boosting retention) or worsening. Cohort and lifecycle analytics turn raw on-chain logs into stories of user journeys – showing how initial behaviors translate to long-term outcomes, which is gold for product strategy.

Step 8 — Cross-Chain & Bridge Flows

Track users across multiple chains: In 2025’s multichain world, a single user may interact with your dApp on Ethereum, then move to Polygon, then an L3 – you need to capture this full picture. Implement address normalization and cross-chain identity mapping. If your dApp deploys on multiple networks, consider using the same identifier for a user’s addresses across chains (many users will use the same wallet address on EVM-compatible chains, since it’s derived from the same key). Leverage this: you can treat an address 0xABC on Ethereum and 0xABC on Arbitrum as the same user if you know they control the same private key (assuming they are EOA wallets, not contract addresses). For non-EVM or where addresses differ, look at bridge transactions: e.g., if a wallet on Ethereum sends assets to a bridge and then a similar amount appears on a Polygon address shortly after, that’s likely the same user transferring. Some analytics setups maintain an “address mapping table” where known bridges provide a link (like a mapping of Ethereum address → corresponding address on another chain if the bridge transfers ownership). At the very least, tag events with the chain they occur on, so you can analyze activity by chain easily.

Bridge flow analytics: The movement of assets through bridges is an important data source itself. Track how users move funds in and out as part of their journey. For example, if you see many users bridging from Chain A to Chain B to use your application, that’s a signal of cross-chain demand. Construct Sankey diagrams or flow tables: e.g., “30% of new Polygon users came via our Ethereum bridge contract, 20% via direct onboarding on Polygon, etc.” Also track the reverse: do users leave one chain after incentives end and bridge assets elsewhere? This can prevent misinterpreting a drop in activity on one chain as churn, when it might be migration to another chain. Include bridge addresses and common custody addresses in your clustering so you don’t double-count a user who simply moved networks. When measuring something like total active users across chains, count unique clusters of addresses rather than sum of chain-specific actives (otherwise one user using 3 chains appears as 3 users). Cross-chain normalization might involve creating a unified user ID if possible. If not, carefully aggregate using the clustering methods from Step 4 with chain dimension included.

Path and funnel analysis across chains: Map out the typical cross-chain paths users take. For example: Wallet starts on Ethereum, acquires token, then moves to Polygon to use a game. You can create a funnel: “Percentage of Ethereum users who bridged to L2 and took action there.” If that number is low, maybe your bridge UX or awareness is an issue. If it’s high, it means cross-chain is a common growth path. Analyze bridge events in context: what triggers bridging? Possibly a governance vote on L1 then yield farming on L2. This can inform product decisions, such as improving in-app prompts to bridge or providing tutorials. From a data perspective, ensure your data model can handle multi-chain sequences: you may need to join events from different chain schemas. A practical tip is to use a unified table with a column for chain, or use tools like Dune that allow cross-chain queries in one view. Another challenge is address format differences (e.g., Solana addresses vs EVM addresses) – consider normalizing them to a standard string and tagging with chain so you can combine in one column.

Metrics for cross-chain coverage: Define KPIs that capture cross-chain behavior. For instance, “cross-chain retention” – what % of users who leave one chain continue on another? Or “bridge conversion rate” – of users who click the bridge, how many complete a transaction on the other side. Monitor the distribution of your protocol’s activity: e.g., Ethereum vs. L2 share of transactions or TVL. If one network is lagging in user uptake, that might prompt more targeted growth efforts there. Also be mindful of double-counting TVL: if the same liquidity is represented on two chains (like a receipt token), you might inadvertently sum them. Industry research noted double counting issues in TVL calculation when assets move across protocols. A “unique TVL” that accounts for bridges can be a complex but valuable metric (some call it vTVL – verifiable TVL counting only unique assets). In summary, incorporate cross-chain dimensions in all relevant analyses – it will give a more holistic view of user journeys and system health, ensuring that success on one chain isn’t hiding attrition on another (or vice versa).

Step 9 — Dashboards, Alerts & Decision Ops

Build role-specific dashboards: With your data pipeline, metrics, and identity resolution in place, surface insights via dashboards. Create a set of dashboards tailored to different stakeholders – for example: a Growth dashboard showing new users, activation rates, conversion funnels (with attribution insights); a Product dashboard showing feature usage metrics and cohort retention; an Operations dashboard for protocol health (transaction volumes, fees, contract error rates, etc.). Ensure each dashboard is concise (5–10 key charts) and uses clear visualizations (line charts for trends, cohort heatmaps for retention, funnel charts for conversion, etc.). Include benchmarks or target lines where applicable (e.g., highlight the weekly active user target). Use descriptive titles and annotations to make them self-explanatory. For instance, instead of “Series1 vs Series2,” label a chart “Daily Active Wallets: Total vs. Sybil-Filtered” to immediately convey the insight. By making dashboards easy to interpret, you encourage adoption – stakeholders should regularly consult these dashboards in meetings and decision-making.

Alerts and anomaly detection: Set up automated alerts for significant deviations in your metrics. For example, if daily transactions drop by >30% day-over-day, or if new user count triples overnight (could indicate a bot surge or viral event), send an alert to the team via Slack/Email. Define thresholds that matter for your operations (these could be statistically derived or set by knowledge of business cycles). Additionally, employ anomaly detection models on key time series – some tools can catch an unusual pattern that might be missed by static thresholds. Alerts should be actionable and not too noisy: focus on metrics where a human needs to investigate when off-norm. For instance, an alert on “smart contract failures spiked above X” could catch a bug in a new contract release. Or an alert on “TVL dropped >10% in a day” could flag a potential security issue or whale withdrawal. Tie each alert to an owner who can follow up. Maintain runbooks for common scenarios (e.g., if user retention dips, check if a new competitor launched, or if network fees spiked causing user drop-off). This operational readiness turns your analytics from passive reports into an active monitoring system for the business.

Data-driven decision cadence: Institute a weekly or bi-weekly cadence where the team reviews key metrics and decides on experiments. For example, every Monday, review the dashboards: how are we trending on active users versus last week? What did last week’s cohort retention look like? If something stands out (say, an experiment branch had higher conversion), decide on next steps (roll out to all users, iterate, etc.). Encourage a culture where questions are answered with data – e.g., if there’s a debate on whether a new NFT drop brought valuable users, check the cohort metrics of those users’ retention and spend. Maintain a “metrics to-do” list: questions that arise get assigned for deeper analysis by an analyst who can report back. Also, integrate analytics into product development: any new feature should have success metrics defined (e.g., “Quest Mode feature – success = +15% 30-day retention for new players”). After launch, those metrics should appear on dashboards or reports. In terms of tools, use your semantic layer so that new analyses can be done quickly using the defined metrics (analysts shouldn’t have to reinvent definitions). Provide self-serve tools to product managers if possible (e.g., the ability to tweak filters on a dashboard to answer their own questions). Finally, invest in training the team to use the data tools – a dashboard is only as good as its adoption. Track dashboard usage if you can (some BI tools show view counts); if certain dashboards aren’t being used, find out why (maybe they need different metrics or better visualization). A company deeply practicing web3 analytics will treat these dashboards as part of decision-making meetings and growth experiments, much like how Web2 companies operate with growth dashboards – in fact, surveys have shown data-driven organizations significantly outperform others in profitability and customer acquisition. Making decisions “ops” (operationalized) via alerts and regular reviews ensures analytics translate to action and ROI.

Vertical Playbooks

DeFi

Liquidity and lending analytics: For decentralized finance protocols, track metrics that matter to liquidity providers, borrowers, and traders. Monitor liquidity depth in pools (e.g., how the AMM pool sizes change over time) and order book slippage for DEXs – this indicates trading experience quality. Analyze LP churn: what percentage of liquidity providers withdraw within N days of providing liquidity? If churn is high, perhaps yields are not competitive or risk is perceived. Look at spread and fees in lending markets: e.g., the utilization rate of lending pools and how often interest rates hit extremes – this can signal user behavior (farmers vs. genuine borrowers). Overlay these metrics with user clustering: are a few big whales dominating liquidity? If so, your metrics like TVL might be driven by a small cohort. Implement metrics like Gini coefficient of liquidity distribution to capture holder dispersion. Also incorporate MEV and validator analytics: track if MEV bots are interacting heavily with your protocol (e.g., sandwich attacks on your DEX) – an increase might degrade user experience. Possibly correlate on-chain governance or validator behavior with protocol metrics (if relevant, e.g., a sudden drop in TVL after a governance proposal – was it related?). Use dashboards specifically for DeFi health: e.g., a “risk dashboard” showing collateral ratios, liquidation volumes (if your protocol has loans), and any anomalous fund movements. The goal is to ensure you have visibility into both user growth and the financial stability of the protocol.

Case example – Uniswap v3: A practical example of DeFi analytics is clustering Uniswap v3 liquidity providers or traders to understand behavior patterns. Analysts have identified clusters of LPs by their activity (some focus on stablecoin pairs, others on volatile exotic pairs). These insights help in tailoring liquidity incentive programs – e.g., you might find “Passive LPs” vs “Active rebalancers” and ensure your UI or education caters to both. Another example: analyzing retention of DeFi users who come via liquidity mining. If data shows that incentivized cohort retention is 5% after incentives, whereas organic is 20%, it suggests to tweak incentive structures for more stickiness (maybe require longer lockups or reward gradual usage). In summary, DeFi analytics should blend user-centric metrics (retention, conversion from viewer to depositor) with financial metrics (yield, utilization, liquidity migration). The combination will guide both product (improving UX to retain users) and protocol decisions (adjusting rates or incentives to maintain healthy liquidity).

NFTs

Marketplace and community metrics: For NFT platforms or projects, key metrics revolve around user engagement and asset value. Track holder dispersion: how many unique holders does an NFT collection have and what’s the concentration (whales vs. many individuals)? A more dispersed holder base usually indicates healthier community and less risk of a single holder crashing the price. Compute statistics like top 10 holders’ % of supply. Monitor trading volumes and wash trading: use clustering and known addresses to filter suspected wash trades (e.g., the same entity buying from itself at inflated prices). Chainalysis and others have reported significant portions of NFT volume in 2021-2022 were wash trades; by filtering those out you measure true organic volume (if you have a way to flag them). Look at NFT pricing and liquidity: track floor price over time, average sale price, and how often NFTs are listed vs. sold (liquidity ratio). A highly rare NFT might have a high price but if it never trades, liquidity is low. Also analyze rarity vs. behavior: do holders of rare NFTs behave differently (e.g., hold longer, participate more in governance if applicable)? Create cohorts by rarity tier to see, for example, if common NFT holders churn more quickly than rare NFT holders. In terms of user funnels: measure conversion from viewing an NFT to buying it (if your platform has browsing data), or from joining a Discord to actually purchasing an NFT on-chain – these indicate the effectiveness of community engagement.

NFT gaming/Guild analytics: In NFT-driven games or metaverses, merge on-chain and off-chain actions. Track things like asset velocity: how frequently are in-game NFTs changing hands? If assets are meant to be used in-game but are frequently traded, perhaps speculators outweigh players. Conversely, if assets rarely trade, maybe the game is sticky or maybe there’s not enough demand. Analyze the lifecycle of an NFT: e.g., % of minted NFTs that get listed for sale within one week (a quick flip indicator), and % of those that sell vs. sit delisted. If a high fraction is flipped immediately, users might be treating the launch as profit opportunity more than joining the game/community. For NFT guilds or player segments, look at retention of creators vs. collectors. Many NFT projects have far more secondary market participants than original minters – track how many original minters are still holding after X months, or how many secondary buyers become repeat buyers. These help in tailoring future drops or royalty strategies. Another vertical-specific metric is community engagement: if you issue tokens for participation, measure how participation correlates with holding (do active Discord participants tend to hold NFTs longer?). While some of these metrics require integrating off-chain community data (Twitter, Discord), you can approximate some on-chain (e.g., an airdrop as a proxy for active community members). The NFT space is prone to hype cycles, so analytics can ground your team in reality – for instance, if active wallets transacting on your marketplace drop for 3 months straight despite social media buzz, it’s a signal to innovate or re-engage users in new ways.

Gaming

Player journey funnel: Blockchain games often have a hybrid on-chain/off-chain flow. Map out the full player journey: e.g., “Visits site → connects wallet → buys starter NFT or tokens → plays game (on-chain actions like battles or asset mints) → retains over time.” Track conversion at each step. You might find a large drop-off at wallet connect if the game appeals to Web2 players – maybe that calls for a smoother onboarding (social logins with wallet creation behind the scenes). Once in-game, track on-chain events that signify progression: leveling up, minting new items, winning rewards, etc. Use these to define an engagement score or player level. Then cohort players by those levels to see retention: e.g., players who reached level 3 are 2x more likely to still be active a month later than those who stopped at level 1. This informs you that getting players deeper into the game early is key. Look at session frequency: how often and how regularly are players transacting on-chain in the game? For instance, average sessions per week per active player. If it’s low, maybe the game lacks reasons to come back daily/weekly.

Economy monitoring: Games with tokens and NFTs need careful economic analytics. Monitor the token sinks and sources: how many tokens are being minted (rewards) vs. burned/spent in-game. If supply continually outpaces sinks, your token may inflate (classic play-to-earn issue). Track player LTV in terms of token spend or NFT purchase – e.g., what’s the median revenue per user on-chain (could be measured by how many tokens a player buys or brings into the game ecosystem). Identify whales versus free players: perhaps 5% of players account for 80% of NFT purchases. That could be fine, but you’d want to ensure whales are satisfied while also trying to broaden the base. Use clustering to see if many player wallets are controlled by guilds or the same entity – guilds might show patterns like one wallet funding 50 player wallets. That’s important for understanding true player count vs. proxy players. Also track off-chain ↔ on-chain merges: for example, if your game allows email sign-ups but later linking a wallet to withdraw assets, see how many actually convert to on-chain users. That ratio is a big indicator of how compelling the on-chain value is to mainstream players.

Churn and re-engagement: Define what an inactive player is on-chain (e.g., no game transactions in 14 days) and measure churn rate. Then analyze factors correlated with churn or retention. Perhaps players who join a guild (on-chain guild NFT or off-chain guild membership) have higher retention – then you’d encourage social features. Or players who earn a rare NFT in first week stick around more. Conversely, if a lot of players cash out their rewards token after earning it, that might predict they won’t be long-term players. Identify those signals and feed them to the game design team. From a metrics perspective, this might involve logistic regression or survival analysis on the cohort data to find predictors of retention. But even simple group comparisons (e.g., retention of players who bought any NFT vs. those who didn’t) can highlight actionable differences. Ultimately, the gaming vertical needs to blend gameplay metrics with on-chain economy metrics. Dashboards for the game team might show “Daily active players (on-chain transactions)” alongside “Token price and velocity” and “New player growth by source”. The interplay of these indicates the health of the game – for example, if active players are flat but token price is only upheld by speculators, that’s a red flag. By systematically analyzing these, the data team can help game PMs tweak features (to boost engagement) or adjust tokenomics. Remember, a sustainable Web3 game often aims to separate speculators from genuine players in metrics – your analytics should enable that separation so decisions are made with the right user group in mind.

Governance, Risk & Compliance

Data governance and privacy: Handling on-chain data still requires good data governance practices, especially as you enrich with off-chain info. Ensure you have policies for data retention – for example, if you collect email addresses or IPs linked to wallets (for attribution or user accounts), you may need to comply with GDPR or other privacy laws. That could mean anonymizing or deleting personal data after a period. Since blockchain data is public and permanent, your main focus is on any personal data you link to it. Keep those linkages secure and, if users request deletion of their off-chain data, be able to comply. Consider implementing privacy-by-design: e.g., using hashed identifiers where possible instead of plain emails, and aggregating analytics such that individual behavior isn’t exposed beyond what’s necessary. Also transparently communicate to users, if appropriate, what data you collect – many Web3 users are privacy-conscious. On the analytics team side, restrict access to sensitive mappings (like a table connecting real identities to wallets) – use role-based access control so only certain analysts can see PII while others work with anonymized data.

Security and compliance monitoring: Your analytics platform can double as a risk monitoring tool. Track unusual patterns that could indicate hacks or compliance issues. For example, if a normally steady metric (like daily withdrawals) spikes dramatically, that could signal a security incident or bank run scenario – an alert here would prompt the team to check for news (maybe a smart contract exploit). Monitor interactions with high-risk addresses or sanctioned entities. If you integrate a service that flags addresses (OFAC sanctions list, known darknet mixer addresses, etc.), you can alert if any of those interact with your protocol. Some protocols need this for compliance – e.g., if a sanctioned address provides liquidity, you might decide to take action. At minimum, keep an eye on it and potentially exclude that from certain counts if needed. Have an audit log of key on-chain events: for instance, for a lending platform, track liquidations, and if any single liquidator (address or cluster) is dominating, review if that’s expected or some abuse. On governance, analyze voting patterns: are a handful of wallets controlling proposals? If yes, inform the community – analytics can bring transparency to decentralization claims. Perhaps produce a “governance dashboard” that shows proposal participation rates, top voters (maybe anonymized clusters), and how token distribution vs. voting power looks. This can highlight if governance is healthy or at risk of capture.

Preventing data misuse and bias: As you cluster and attribute data, be mindful of the potential for deanonymization beyond acceptable limits. While it’s useful internally to know user cohorts, sharing or acting on that data in ways that violate user expectations can cause backlash. For example, avoid publicly calling out a user’s multiple wallets if they haven’t voluntarily doxxed that information. Internally, use aggregated cohort data for decisions rather than targeting individuals. Also be aware of biases in your data: on-chain users are by nature those willing to transact publicly; if you analyze feedback only from on-chain actions, you might miss silent dissatisfied users (who just left without doing anything). Counter this by occasionally supplementing with off-chain data like surveys or community polls to validate your analytics interpretations. In summary, incorporate compliance not just in the legal sense, but also ethical data use. If you’re using advanced analytics like machine learning predictions (say predicting likelihood of a user churn or a user being Sybil), consider the false positive/negative impact. For instance, if you automatically flag some users as Sybil and exclude them from rewards, have a manual appeal process in case you’re wrong. These governance measures will become increasingly important as Web3 analytics matures and potentially faces regulatory scrutiny – being proactive in responsible data practices protects both your users and your organization.

Maturity Model & 90-Day Roadmap

Maturity model levels: Gauge your organization’s Web3 analytics maturity on a scale (Level 1 to 4) across key dimensions. For example:

• Level 1 (Ad Hoc): Data is pulled manually from explorers or basic APIs, no central repository; metrics are inconsistent and mostly vanity (e.g., Twitter follower count, discord members).
• Level 2 (Basic Tracking): Some on-chain events are indexed into a database, basic dashboards exist for daily users and volume, but no identity resolution or advanced analysis; teams sometimes rely on external dashboards (Dune) for insights.
• Level 3 (Operational Analytics): Dedicated data pipeline in place aggregating multi-chain data, wallet clustering and Sybil filtering implemented, rich dashboards for different teams updated daily; experiments are being run and measured, attribution tracking in place; data quality checks and alerting in use.
• Level 4 (Data-Driven Optimization): Analytics is deeply embedded – real-time dashboards, proactive anomaly detection, predictive models (churn prediction, LTV forecasting) in use; decisions from marketing to product are consistently guided by data; privacy and compliance measures are robust, and the organization can quantify ROI on analytics initiatives.

Identify where you are on this spectrum. Many projects start at 1–2 and aim for 3 within a few quarters. The benefits compound as you progress – e.g., moving from 2 to 3 often correlates with catching issues faster and running growth experiments weekly instead of quarterly.

90-day roadmap: Plan out a three-month journey to improve your analytics stack by hitting specific milestones:

• Month 1: Infrastructure setup – Stand up a basic indexing pipeline (perhaps using an indexer like The Graph or a custom script to pull events) and create a initial data warehouse (could be as simple as Google BigQuery or PostgreSQL). Deliverable: a daily updated table of core on-chain events (transactions, key contract events). Also, define the initial measurement plan (from Step 1) and get team buy-in. Success metric: 100% of key events are being captured in the data store within acceptable lags.
• Month 2: Metric definitions and dashboards – Implement the metric layer (possibly using dbt to define metrics like DAU, retention, conversion rates) and build the first set of dashboards for stakeholders. Simultaneously, roll out wallet clustering for known major cases (e.g., cluster exchange addresses, known multi-address users) and integrate a Sybil flag for obvious bots. This month could also involve instrumenting attribution: e.g., adding UTM tracking and logging wallet connects with campaign info. Success metric: Dashboards are live for at least 3 functional areas (e.g., Growth, Product, Ops) and in use, and clustering/attribution systems identify at least, say, 80% of user base (rest unclustered or unknown to tackle later).
• Month 3: Optimization and experimentation – With data flowing and visible, begin using it to run one or two experiments. For example, test a new user incentive and measure impact on retention using your cohort analysis. Also implement advanced analytics like a retention model (even simple cohort projections) or an alerting mechanism on top of the data. This month, address any gaps found in previous months (maybe you discovered the need for tracking a new event or a particular contract upgrade that wasn’t handled). Work on improving data quality: for instance, refine Sybil detection rules based on Month 2 observations. Success metric: A growth or product experiment is completed and analyzed using the new system (demonstrating capability), and at least one proactive insight (like an alert or analysis of an anomaly) was delivered that affected a decision.

This 90-day plan is aggressive but achievable if you have a small data team or even a savvy developer/analyst. It moves you from basic data collection to actually leveraging the data for decisions. Beyond 90 days, plan for Level 4 activities like predictive modeling, but those first 3 months lay the crucial foundation.

Troubleshooting & Pitfalls

Blockchain quirks and data correctness: Be prepared for edge cases like chain reorganizations (your pipeline might ingest a block that later is orphaned – ensure you handle that as discussed), node sync issues (if a node falls behind, your data could lag or miss events – monitoring node health is key), and forks or upgrades (protocol changes can break data parsing if not accounted for). Always watch out for duplicate counting – a common pitfall is double-counting an event if it’s emitted in multiple contracts. For example, if your protocol has a proxy contract that emits an event as well as the logic contract, you might inadvertently count two events for one user action unless you de-duplicate by transaction hash or such. Implement safeguards in your SQL or processing (e.g., group by tx hash where applicable).

Label and cluster drift: Over time, your wallet clusters and labels can become outdated – new exchange addresses appear, users change behavior. Set a schedule to update your clustering heuristics and refresh labels from external sources. A pitfall is relying on a one-time clustering and never updating it; months later, your metrics might degrade in accuracy because, say, a major liquidity provider started using new wallets that you see as “new users” erroneously. Investing in continuous improvements (and possibly leveraging community data sources) mitigates this. Similarly, Sybil tactics will evolve – what caught bots in one airdrop might miss them in the next if they randomize behavior more. Stay informed via research forums or partnerships (some analytics providers share Sybil intel).

Over-filtering and under-filtering: Find the right balance in filtering out activity. If you overdo Sybil or bot filtering, you might remove legitimate users from your analyses (false positives), leading to underestimation of usage. If you under-filter, you’re back to inflated vanity metrics. It’s a fine line – consider presenting both unfiltered and filtered metrics in internal reports to show the range. Also, be cautious with new user definitions – e.g., if an existing user creates a new wallet, you might count them as new if you haven’t clustered them, thus inflating new user counts. This is hard to avoid completely, but be aware of the potential and note assumptions when reporting figures like “new wallets = new users” (they’re proxies).

Cross-chain duplicates and syncing: If you’re aggregating multi-chain data, ensure you’re not double counting the same user’s actions on different chains as separate. We touched on clustering across chains – failing to do so can lead to errors like summing “active users on Ethereum + active on Polygon” and getting a number bigger than total unique users because many used both. Use union distinct logic or a user ID approach to avoid that. Another pitfall is not syncing time – different chains have different block times and your data may come in with timestamps that aren’t aligned (some in UTC, some in Unix, etc.). Standardize to a common time reference for your warehouse (typically UTC ISO timestamps). Small mismatches can confuse daily aggregations (e.g., if Polygon data is offset by a few hours, your daily active count might split a user’s activity into two days in different datasets).

Misinterpreting causation: With so many metrics, be careful not to jump to conclusions about causality. For instance, you might see “Users who stake tokens have 4x retention of those who don’t” – that doesn’t necessarily mean staking causes retention (it could be that committed users are the ones who choose to stake). Use controlled experiments or at least logical reasoning before acting on correlations. Another example: “A spike in transactions coincided with a tweet, so Twitter caused it” – verify if those transactions were user actions or perhaps just one whale before crediting marketing. Always consider alternative explanations (maybe gas fees dropped, enabling more transactions, etc.). Bring domain knowledge into your analysis – on-chain data alone might not tell the whole story (e.g., a regulatory news event could cause outflows which your data sees but can’t explain). The pitfall is becoming data deterministic without context – avoid that by keeping communication open with other teams (community managers, developers) to correlate data findings with real-world events.

In summary, treat your Web3 analytics implementation as a living system that needs maintenance, validation, and critical thinking. Troubleshoot issues as they arise (and they will) methodically – check data at each pipeline stage, keep an eye on known “gotchas” like reorgs or API quirks, and don’t be afraid to iterate on your data model as you learn more about your users and their behaviors.

Worksheets & Templates

• Measurement Plan Template: A table listing Product Objectives → Key Metrics → Definition → Data Sources → Owner → Review Cadence. Use this to align team on what success looks like and who is responsible for each metric.
• Event Taxonomy Sheet: A dictionary of on-chain events (and any off-chain events) your dApp tracks. Columns might include Event Name, Description, Contract/Source, Parameters, Example, Version Notes. This is essentially a tracking plan for Web3 actions.
• Metric Dictionary: Document that defines each KPI and analytic metric. For each metric, include formula (in plain language and SQL if useful), data source tables, and any exclusions or filters (e.g., “Active users = unique wallets with ≥1 tx, excluding contract wallets”). This ensures everyone uses metrics consistently.
• Clustering & Sybil Evaluation Sheet: A worksheet to periodically evaluate identity clustering and Sybil detection. It might list a sample of address clusters with manual verification notes, precision/recall calculations against known ground truth (if available), and adjustments made. Use this to track improvements in your heuristics or models.
• Attribution Model Chooser: A simple decision tree or table for selecting an attribution model. E.g., columns for First-Touch, Last-Touch, Multi-Touch, and rows for Pros, Cons, When to Use. This can help marketing teams choose how to credit campaigns in various situations. It also includes placeholders to fill in your specific business’s approach (maybe you decide a 40/40/20 split model is best – document that here).

Glossary & FAQ

What is web3 analytics?
Web3 analytics refers to the analysis of blockchain-based user and transaction data to derive insights, typically for decentralized applications. It involves tracking on-chain events (like token transfers, contract interactions) and sometimes off-chain events, then interpreting user behavior, financial metrics, and network health. Unlike traditional analytics, it deals with pseudonymous wallet addresses instead of logged-in users, requiring techniques like wallet clustering to understand user activity. Web3 analytics helps protocols answer questions like “How many unique users do we have across chains?”, “Which marketing campaign led to these on-chain deposits?”, or “What is our user retention after 1 month?” using the transparent data on blockchains.

How do I build a web3 analytics pipeline?
To build a web3 analytics pipeline, you start by connecting to blockchain node(s) to retrieve raw data (blocks, transactions, logs). Next, you index this data – parsing it into structured tables (for example, a transactions table, an events table for contract logs, etc.). Then, you’ll want to enrich it (e.g., decoding contract data to readable form, adding labels like token names or wallet cluster IDs). Store the data in a database or data warehouse optimized for analytics queries. On top of that, define metrics and dashboards. Key components include: an ETL process to Extract (from RPC or streaming APIs) → Transform (decode JSON, apply business rules) → Load into your database; a set of analytic queries or materialized views to compute KPIs (like daily active users, volume, balances); and visualization tools for dashboards. Tools like The Graph can simplify indexing by letting you define a subgraph to index specific contract events, or you might use a custom script with Web3 libraries. Ensuring data freshness and accuracy (handling reorgs, etc.) is a big part of the engineering. Once the data is flowing, you iterate on it by adding more data sources (multiple chains or off-chain data like Google Analytics events if needed) and optimize performance. Security of keys (if running your own nodes), cost of data storage (blockchain data can be large), and maintenance are practical considerations. Many start simple: e.g., export data from Dune Analytics or use their API, then gradually build a custom pipeline as needs grow.

How can I detect sybil activity on-chain?
Detecting sybil activity (multiple addresses controlled by the same entity to game systems) involves looking for patterns in how addresses behave. Some common methods: graph analysis (seeing many addresses send funds to a single address – that single address could be the “master” of a Sybil farm), timing analysis (hundreds of addresses created or transacting in the same short window, often with similar amounts or interacting with the same contracts, suggest a script or bot controlling them), and transaction pattern analysis (for example, an airdrop Sybil farm might have each address do the minimum qualifying actions and nothing else – very low engagement footprints). You can also use clustering techniques to group addresses and then see clusters that are unnaturally large (one person controlling an abnormally large cluster). A practical tip is to leverage known Sybil lists: after major airdrops, projects like Arbitrum released the lists of addresses they blocked. Those can serve as training data for what Sybil behavior looks like (e.g., many Arbitrum Sybils made several small deposits from unique addresses all to the same L1 escrow). On-chain, Sybils often exhibit telltale signs such as all being funded by the same one or two source addresses (like one central wallet sending ETH to 50 new wallets for gas). By querying for clusters of wallets with a common funding source, you can catch many Sybils. Another sign is entropy of connections: a normal user might interact with a variety of contracts and other users over time, whereas Sybils tend to have very structured, limited interactions (just the target dApp, then send funds back to main wallet). Tools and libraries (like graph algorithms or machine learning as in academic research) can automate this detection. Once detected, you might assign a Sybil score to addresses or simply filter them out in analysis. Community-driven efforts like Gitcoin Passport are also emerging, where addresses build a trust score to prove they’re likely unique humans, which conversely helps identify those with no proof who might be Sybils.

How do I link UTM campaigns to wallet activity?
Linking UTM campaigns (web marketing tags) to on-chain wallet activity is done by capturing the UTM info when the user enters your app and associating it with the wallet address when they connect or perform an action. Concretely, suppose a user clicks a link yourdapp.com?utm_source=twitter&utm_campaign=summer. When they land, your web app should store those UTM parameters (in localStorage or a cookie). If the user then connects their wallet or triggers a signup event, you grab those UTM values and send them to your backend along with the wallet address. This can be logged as a mapping: wallet X → campaign = Twitter-Summer. You might log an analytic event “WalletConnected” with properties including utm_source, utm_campaign, etc. Now, when that wallet shows up on-chain (e.g., does a deposit transaction), you have the campaign attribution in your database, so you can attribute that on-chain action back to the campaign. Another way: generate unique referral codes as part of the UTM (like &utm_content=ref123) and have the smart contract accept that code in a registration transaction – but that’s on-chain storage heavy and complex; simpler is to do it off-chain as above. Using a customer data platform or even Google Analytics’s measurement protocol could help: for instance, record a conversion in GA with the wallet ID as a user identifier when an on-chain event happens (if you have a backend listening to on-chain events, it can ping GA). A purpose-built tool (e.g., Spindl) would have you include a script that automatically ties a web session to a wallet and later to on-chain events. If building yourself, ensure data flows like: web session -> (user connects wallet) -> send UTM + wallet to DB -> (later) join with on-chain data by wallet. Finally, in analysis, you can create reports like “Total volume by campaign” by summing on-chain volume for wallets that came from each UTM campaign. This closes the loop from marketing spend to blockchain usage.

What are the best KPIs for DeFi/NFT analytics?
The best KPIs depend on your project goals, but generally:

• For DeFi: Total Value Locked (TVL) – how much capital is in your contracts; Volume – trading or loan volume daily; Number of Active Users (distinct wallets interacting, e.g., making a trade or deposit, in a given period); Average Revenue per User (if you charge fees, how much fee or interest per user); Retention of Liquidity Providers or Borrowers – do users come back or keep funds over time (could be measured by churn rate or cohort TVL retention); Utilization (for lending, how much of the supplied liquidity is borrowed); and perhaps Protocol Revenue (fees accrued) if you track financial health. A key KPI often cited is user growth (WAU/MAU – weekly/monthly actives) but adjusted for Sybils as noted. Also, more DeFi-specific: collateralization ratio (if applicable), liquidation count (monitoring risk), and token price-related metrics if the protocol has a token (like market cap, but that’s more for token health).
• For NFT: Unique Holders – how distributed the ownership is; Floor Price – lowest ask price for an NFT in the collection, indicating market valuation; Trading Volume – daily/weekly sales volume; Active Traders – number of wallets buying or selling in a period; NFTs Minted vs. NFTs Sold – if a project is ongoing, how many have been sold out or remain; Average Hold Time – indicates collector versus flipper behavior; Community Growth metrics – could be off-chain like Discord members, but on-chain proxies might be number of wallets that hold the NFT and also hold governance tokens or have interacted with community proposals (if applicable). If it’s an NFT marketplace: GMV (gross merchandise value, total value of NFTs traded), Take Rate (fees / GMV), and Liquidity (e.g., listings to sales ratio).
• For Web3 Gaming: Daily Active Players (on-chain interactions in the game per day); New Player Conversion – how many new visitors or downloads convert to on-chain players; Retention rates (D1, D7, D30 retention of players performing an on-chain action); Average Spend per Player – how much a player spends on NFTs or tokens in-game; and Active Wallets vs. Active Users (if one user has multiple wallets, try to account for that). In-game economy KPIs like inflation rate of game token, marketplace liquidity of game items, etc., also matter.

In all cases, an important KPI in Web3 is often some measure of engaged users – since raw “transactions” or “wallets” can be inflated, something like “engaged addresses” (those that perform a meaningful action X times or across X days) could be a custom KPI to track quality usage. Similarly, retention is king: whether it’s DeFi or NFTs or gaming, showing that users stick around and continue to use the product is crucial to prove long-term value, so cohort retention or repeat usage rate is often the north star metric after initial growth.

References

• [1] Chainalysis Team (2024). The Data Accuracy Flywheel: How Chainalysis Consistently Identifies and Verifies Blockchain Entities. Chainalysis Blog.
• [2] Van Aken, A. (2024). Announcing Sybil Detection. Artemis Research Blog, March 8, 2024.
• [3] Fintech Review (2025). Cross-Chain Identity Solutions. (Analysis Article, May 12, 2025).
• [4] Efy, M. & Krasovytskyi, I. (2024). The Critical Role of Data Freshness in Business Decision-Making in 2025. OWOX BI Blog, Feb 26, 2024.
• [5] Murray, S. (2023). Experimentation: How Data Leaders Can Generate Crystal Clear ROI. Monte Carlo Data Blog, Apr 12, 2023.
• [6] Token Terminal (2023). Introducing the "Cohort analysis" data set. Token Terminal Blog, Sep 14, 2023.
• [7] Rock’n’Block (2025). A Deep Dive into How to Index Blockchain Data. RocknBlock Blog, Jul 9, 2025.
• [8] Merkle Science (2023). Transforming Blockchain Security: Introducing Our Advanced Clustering Algorithms and Heuristics for Bitcoin and Smart Contract Chains. Merkle Science Blog, Dec 7, 2023.
• [9] Liu, Q. et al. (2025). Detecting Sybil Addresses in Blockchain Airdrops: A Subgraph-based Feature Propagation and Fusion Approach. arXiv preprint arXiv:2505.09313.
• [10] Smith, T. (2025). Web3 Analytics Stack: How to Build an Attribution System Without Google Analytics. Coinbound Blog, Mar 24, 2025.
• [11] Cealicu, V. (2024). On-Chain Data Series I: Ingesting Blockchain Data – The Backbone of On-Chain Intelligence. CCData (CoinDesk) Blog, Feb 15, 2024.
• [12] Formo (2023). Mapping the Web3 Tooling Landscape for Communities. Formo Blog, 2023.