Onchain Attribution: How to Link Marketing Campaigns to Users and Revenue

Onchain attribution combines blockchain data with traditional analytics to link marketing touchpoints to onchain activity. It helps Web3 teams follow an observed journey from a campaign visit to a wallet connection and a confirmed protocol action, then assign credit under a defined attribution model.

The distinction between observation and attribution matters. A blockchain can verify that an address submitted a transaction and that a contract emitted an event. It cannot tell you why the transaction happened, whether one person controls several wallets, or which campaign caused the outcome. Those conclusions depend on the identity links, attribution rules, conversion definitions, and quality controls around the onchain record.

Understanding Onchain Attribution in Web3 Marketing

Onchain attribution fuses blockchain data with conventional analytics to map user journeys that span Web2 touchpoints and Web3 wallet interactions. Traditional analytics relies on signals such as browser identifiers, campaign parameters, product events, device data, and centralized accounts. Web3 attribution adds wallet addresses, signature events, transaction receipts, and recorded ledger events to that measurement model.

These additional signals extend measurement, but they do not make attribution automatically transparent, private, or user-controlled. Those properties depend on how the product collects offchain data, links it to wallets, obtains any required consent, limits retention, and explains its attribution rules.

The core distinctions:

Onchain attribution links marketing touchpoints, including ads, social posts, content, and campaigns, to concrete onchain outcomes such as transactions, deposits, and volume. It does this by associating captured campaign and session context with observed wallet identifiers and indexed onchain events. Teams can then apply a supported attribution model to identify which campaigns receive credit for higher-value wallets, repeated contract interactions, or retained protocol use.

Each connection in that path is a data join, not a fact supplied by the blockchain. The system must preserve the acquisition context, observe the wallet in the product journey, confirm the transaction on the correct chain, decode the relevant protocol event, and apply a defined attribution rule within its lookback window.

How Wallet-Based Tracking Transforms User Measurement

Wallet-based tracking uses a public account address as a durable, pseudonymous identifier. When a wallet appears in an observed application session, teams can analyze eligible onchain activity for that address without requiring the user to provide a name or email address.

That capability is useful, but it has clear boundaries:

• One person may control several wallets.

• A multisig or contract account may represent several people.

• Embedded wallets may be created separately for each app or device.

• Routers, aggregators, relayers, and smart accounts may obscure the initiating wallet.

• The same externally owned account address can appear across EVM-compatible chains, while non-EVM and chain-specific account systems use different identifiers.

A wallet connection is also different from wallet authentication. Connection means the application received an address from a wallet provider. A domain-bound signed challenge, such as a properly implemented Sign-In with Ethereum flow, can prove that the account authorized that specific authentication request. Neither event proves that the account belongs to one unique human or that the user consented to every possible analytics or marketing use.

Start with the shortest funnel that represents the actual product journey:

landing page view -> wallet connect -> confirmed transaction or decoded protocol event

A message signature or token approval belongs between connect and conversion only when that specific journey requires it. Do not make either step mandatory across every funnel. If the product exposes Formo’s SDK transaction lifecycle, analyze it separately:

transaction started -> transaction broadcasted -> transaction confirmed

A transaction can instead end as rejected before broadcast or reverted onchain. Keeping intent, submission, and success distinct reveals where users drop off and prevents a started or failed transaction from being counted as a successful conversion.

Wallet-level measurement can support:

• Smart contract interaction analysis: identify swaps, supplies, borrows, stakes, mints, claims, or governance actions from the relevant contracts and events.

• Token and NFT attribution: connect eligible campaigns to confirmed mints, purchases, or transfers when those events match the conversion definition.

• DeFi engagement analysis: measure repeat protocol actions, value ranges, and retained-wallet cohorts.

• Cross-chain analysis: compare activity across supported chains when the identity and execution path can be joined reliably.

Default to language such as “wallets,” “accounts,” or “observed users” unless the identity model justifies a stronger claim.

Use a consistent Web3 event-tracking plan so the wallet connection, optional signature, transaction lifecycle, and decoded protocol action retain distinct names and properties.

Key Benefits of Onchain Attribution for Marketing Teams

Onchain attribution connects acquisition reporting to protocol outcomes that browser analytics cannot decode on its own. Its primary benefits include:

Campaign ROI becomes more useful when spend is compared with confirmed, correctly valued outcomes rather than raw wallet connections or gross transaction volume.

• Outcome-based acquisition reporting: compare channels by confirmed protocol actions rather than stopping at landing-page or wallet-connect activity.

• Cost-per-acquisition analysis: calculate cost per connected wallet, cost per converted wallet, or customer acquisition cost (CAC) for a qualified account using the same conversion definition across campaigns.

• Unified funnel analysis: examine landing visits, wallet connections, transaction starts, confirmed transactions, value, and retention without treating them as interchangeable metrics.

• Value-based optimization: compare campaigns by attributed volume, fees, protocol revenue, or retained behavior, depending on the business goal.

• Cohort analysis: measure whether wallets acquired through a campaign return and complete another qualifying action within a defined period.

• Near-real-time campaign performance: where indexing latency and chain finality allow, identify changes in confirmed onchain outcomes soon enough to adjust active campaigns.

• Faster quality feedback: identify campaigns that generate many connects but few confirmed or economically meaningful actions.

First-touch attribution gives credit to the earliest eligible known touchpoint. Last-touch attribution gives credit to the latest eligible known touchpoint before conversion. Multi-touch attribution models can distribute credit across several touchpoints, but they require sufficient journey data and explicit platform support. More complex credit rules do not repair missing events or weak identity joins.

Attribution should be described as a model, not a causal result. If a team needs to know whether a campaign created conversions that would not otherwise have happened, it should complement attribution reporting with holdouts, geo tests, matched cohorts, or another incrementality method.

Building an Onchain Attribution System: Step-by-Step

A practical implementation combines technical instrumentation with clear business definitions.

Step 1: Understand the User Perspective

Map the actual path people take through the product before choosing a conversion event. A DEX journey may go from landing page to wallet connection, token approval, swap request, and confirmed swap. A lending flow may include wallet connection, collateral supply, and a later borrow. A vault may need to distinguish a deposit from a retained position.

Use the product yourself with representative test wallets before finalizing the event plan. Walk through the actions your audience actually performs, which may include joining a DAO, minting an NFT, or using a DeFi protocol. The goal is to identify real decision points and required steps, not to add every possible Web3 action to one funnel.

Define the business conversion in writing:

• The exact chain, contract, function, or emitted event that represents success.

• The wallet or account role that counts as the user.

• Any minimum value or qualification threshold.

• How reverted transactions, retries, partial fills, and duplicates are handled.

• Whether the reported outcome is a count, volume, fees, revenue, or retained activity.

Avoid treating every token transfer as a conversion. Transfers can result from routing, bridge movement, internal accounting, change, or other activity unrelated to the business action you intend to measure.

Step 2: Map Integration Architecture

Document how identifiers and events move from the campaign to the confirmed outcome:

campaign context -> first-party visitor/session -> observed wallet -> confirmed transaction or decoded protocol event -> normalized revenue or volume -> attribution model

Capture acquisition context on the landing event, including consistent UTM parameters, referral parameters, and supported click IDs. Referrers are useful supporting evidence, but browsers, redirects, in-app browsers, and privacy settings can shorten or suppress them.

Persist eligible first-touch and last-touch context separately so a later direct return does not erase a known acquisition source. The wallet link may occur several pages or sessions after the initial visit, so define the storage duration and lookback window deliberately.

For EVM outcomes, a practical join should include both chain_id and transaction_hash. A transaction hash without the chain is not a complete cross-chain key. Store receipt status, block time, contract address, decoded event, and the normalized economic fields required by the conversion definition.

Where an application appends an ERC-8021 builder code to transaction calldata, that code can provide an additional onchain source signal. Formo extracts supported builder codes from transaction calldata, but they complement rather than replace landing-page UTMs, referral codes, referrers, and ad click IDs.

Step 3: Implement Attribution

Instrument key lifecycle stages. Formo makes this simple with autocapture. For example, the Formo SDK captures key lifecycles of the transaction event:

started -> broadcasted -> confirmed

It also records rejected and reverted outcomes and other wallet events.

Treat wallet connection, signature confirmation, transaction start, and transaction broadcast as diagnostic milestones, not successful onchain conversions.

Use a confirmed transaction when transaction success itself is the conversion. Use a selected decoded contract event when the emitted event defines the semantic outcome, such as Swap, Deposit, or Mint.

If both records describe the same business action, choose one canonical conversion metric so the dashboard does not double-count it.

Apply a documented attribution rule:

• First touch: credit the earliest eligible known touchpoint inside the lookback window.

• Last touch: credit the latest eligible known touchpoint before the conversion.

• Direct or unattributed: keep these outcomes visible when no eligible campaign can be joined.

Choose the lookback window from observed time-to-conversion data. A same-session swap may justify a short window, while a considered lending or institutional journey may require a longer one. Compare results across reasonable windows before changing budget.

Step 4: Validate with Test Campaigns

Run known journeys before trusting ROI calculations:

• UTM visit to wallet connection to successful transaction.

• Referral visit followed by a later return and conversion.

• Direct visit with no known prior campaign.

• Wallet connection with no transaction.

• Transaction rejection, reversion, provider failure, and a replaced or dropped submission.

• Account switch or chain switch after connection.

• Router, aggregator, relayer, bridge, smart-account, and multisig paths.

• Duplicate client or indexer delivery.

• Conversion outside the attribution window.

For each test, reconcile the raw product event, wallet link, transaction receipt, decoded event, value calculation, attribution result, and dashboard total. A system that forces every transaction into a marketing channel can hide broken joins and missing data.

Technical components to plan include:

• Session-to-wallet association: preserve eligible first-party campaign context when a wallet appears in the observed product journey, with optional account linking only when the use case requires it.

• Onchain indexing and decoding: capture receipts and selected contract logs, apply the correct ABI, and account for duplicates, reorganizations, and the project’s confirmation policy.

• Consent and value exchange: explain any optional offchain identity link, provide a tangible product benefit where appropriate, and apply the required legal basis, retention limits, and access controls.

Essential Tools and Platforms for Onchain Attribution

An attribution system usually combines several capabilities:

• Campaign and product analytics: capture landing context, sessions, page views, wallet connections, and transaction lifecycle events.

• Onchain indexing and decoding: observe receipts and logs on supported chains, apply the correct ABI, and handle reorganizations or finality rules.

• Identity and session linking: associate eligible first-party acquisition context with the wallet observed in the same product journey.

• Warehouse or analytics layer: calculate funnels, cohorts, value, retention, and attributed outcomes using reproducible definitions.

• Quality and fraud controls: flag bots, self-referrals, wash activity, incentive farming, and other behavior that can inflate raw conversion counts.

Web3 CRMs can help teams activate unified wallet and account profiles. Query platforms such as Dune can support custom onchain analysis, while wallet-intelligence platforms such as Nansen can add labels and behavioral context. These tools do not automatically preserve campaign parameters or create the session-to-wallet join required for attribution. A dedicated Web3 analytics layer still needs to connect the acquisition, product, and onchain records.

When evaluating vendors, check supported chains and account types, SDK event coverage, contract decoding, attribution models, funnel and cohort analysis, DeFi-specific value fields, export access, privacy controls, and integrations with the existing data and marketing stack. A long feature list matters less than whether the platform can reproduce the project’s conversion and revenue definitions.

Sybil detection can improve reporting quality, but it does not prove that every remaining wallet is a unique or economically genuine person. Report raw wallets and qualified wallets separately and document the rules used to classify them.

Formo combines web, product, and onchain events in one analytics model. Its Web SDK can capture page views, campaign context, wallet connections, signatures, and transaction metadata. Teams can add contracts and select protocol events to ingest and decode. Formo currently documents first-touch and last-touch analysis across channels, referrers, referral codes, UTMs, and supported ad click IDs.

A practical Formo setup is:

1. Install the Formo SDK.

2. Standardize UTMs and referrals with the onchain attribution setup guide.

3. Review how Formo attribution works, including first-touch and last-touch behavior.

4. Add contracts and select conversion events using contract event tracking.

5. Build a funnel from landing page to wallet connection to a confirmed transaction or selected contract event. Add signature or approval steps only when the journey requires them.

6. Break down converted wallets, transactions, volume, or revenue by the relevant acquisition dimension.

The platform can automate capture and joining, but the team still owns the business definition of a conversion and the distinction between value moved and value earned.

Measuring Success with Onchain Data and Metrics

Web2 acquisition metrics and onchain outcomes belong in one funnel. One set should not be presented as a direct replacement for the other.

Define metrics precisely:

For ROAS and LTV, use protocol revenue or contribution margin according to the reporting policy. State whether incentives, rebates, refunds, and gas subsidies are deducted. If the available data measures only volume, label the result as volume rather than revenue.

Use wallet cohort analysis to compare retained behavior by campaign, but keep the acquisition date, qualifying action, return window, and retention denominator consistent across cohorts.

Protocol-specific supporting metrics can add context. Examples include smart contract interaction frequency and depth, DAO or governance participation, and NFT mint or holder retention. Correlate Discord or X engagement with onchain behavior only when an authorized data source and defensible identity link exist, and describe the result as an association rather than proof that community activity caused the transaction.

General analytics tools can receive custom events emitted by an application, including events about transaction attempts. They do not natively index and decode blockchain receipts and contract logs or resolve chain-specific transaction states. A specialized onchain data layer is still needed when the conversion must be verified from the chain rather than trusted from a browser event.

Overcoming Challenges in Web3 Attribution Implementation

Onchain attribution introduces technical, identity, economic, and privacy challenges.

Technical integration complexity

Campaign data, product events, wallet state, and blockchain data arrive from different systems. RPC providers and indexers may retry deliveries, chains can reorganize, and contract upgrades can change event decoding. Use chain-aware transaction keys, idempotent ingestion, ABI versioning, and an explicit confirmation or finality policy.

Identity and cross-chain gaps

Multiple wallets per person, shared wallets, embedded wallets, smart accounts, routers, bridges, and non-EVM identifiers make universal identity resolution unrealistic. Define which account represents the user for each product flow and state the level of confidence in every join.

Quantifiable metrics

A confirmed transaction proves that the action occurred, not that it reflects genuine demand. Bots, self-referrals, wash activity, and incentive farming can inflate conversion counts. Keep raw and qualified metrics, make qualification rules reproducible, and test how sensitive ROI is to those rules.

Attribution gaps

UTMs can be missing, referrers can be suppressed, users can return on another device, and the wallet may connect outside the lookback window. Preserve a visible direct or unattributed bucket and monitor attribution coverage rather than silently assigning every outcome to a campaign.

Causality

First-touch and last-touch models assign credit. They do not estimate what would have happened without the campaign. Use controlled experiments or credible quasi-experimental methods when the decision requires causal evidence.

Best Practices for Privacy and User Consent in Onchain Attribution

Privacy-friendly Web3 analytics starts from the fact that wallet addresses are pseudonymous, not automatically anonymous. When an address can be linked directly or indirectly to an individual, it may be treated as personal data under applicable privacy law.

Opt-in Wallet Linking

Link wallets to offchain accounts or contact information only for a defined purpose and with an appropriate legal basis. Explain what is collected, how it is used, how long it is retained, and which vendors receive it. Do not treat a wallet connection or signature as blanket consent for unrelated analytics or marketing.

Privacy Best Practices

• Collect only the campaign, session, wallet, and event fields required for defined analytics purposes.

• Limit retention of session-to-wallet and offchain identity mappings.

• Restrict access to wallet-level exports and linked identity data.

• Support deletion or unlinking of offchain profile data when required.

• Do not write personal data or marketing identifiers to a public blockchain to make attribution easier.

• Assess analytics, infrastructure, and indexing vendors that process wallet or campaign data.

• Keep privacy disclosures aligned with the events the product actually collects.

Regulatory Compliance and Data Minimization

Design the system so its notices, retention, access controls, and legal basis can be adapted to the data, purpose, and jurisdictions involved. Collect only the fields needed for defined measurement goals, and avoid creating offchain identity links simply because public wallet activity is available.

FAQs About Onchain Attribution

What is onchain attribution and why is it critical for Web3 marketing?

Onchain attribution joins an offchain marketing touchpoint to a wallet observed in a product journey and a confirmed blockchain outcome, then assigns conversion credit under a defined model and lookback window. It lets teams compare acquisition sources using outcomes such as successful swaps, supplies, borrows, mints, or retained protocol use.

How do I link off-chain marketing campaigns to on-chain user actions?

Capture UTMs, referral codes, referrers, and supported ad click IDs on the landing event. Preserve eligible first-touch and last-touch context, associate that context with a wallet observed in the product session, and join the wallet to a confirmed receipt or decoded contract event using the chain ID and transaction hash.

What key metrics should I track using onchain attribution?

Track the full funnel: landing sessions, wallet connect rate, transaction start rate when applicable, confirmed conversion rate, converted wallets, volume, protocol revenue, cost per converted wallet, ROAS, and retained-wallet rate. Define “new,” “active,” “qualified,” “retained,” and “revenue” before comparing campaigns.

Do I need to modify smart contracts to enable onchain attribution?

Not always. Existing transaction receipts and protocol events may already represent the conversion. Add or change contract events only when the current interface cannot expose the action or value needed, and weigh the engineering, upgrade, and security costs first.

How does onchain attribution maintain user privacy and pseudonymity?

It can operate at the wallet level without requiring a name or email address, but wallet addresses are pseudonymous rather than automatically anonymous. Use data minimization, purpose limitation, access controls, retention limits, accurate notices, and an appropriate legal basis for any offchain correlation.

Does a wallet connection prove wallet ownership?

No. A wallet connection exposes an account to the application. A verified, domain-bound authentication message can prove that the account authorized a specific request, but neither event proves that the wallet represents one unique person or that the person controls other associated wallets.

Can onchain attribution measure ad impressions?

Only when impression data is supplied by an ad platform or another authorized source and can be joined to the later journey. UTMs, referrers, referral codes, and click IDs normally begin at the visit or click. Landing-page data alone does not provide impression-to-wallet attribution.

Should I use first-touch or last-touch attribution?

Use first touch to compare the earliest known acquisition sources and last touch to compare the final known touchpoint before conversion. Evaluate both with the same conversion definition and lookback window. Neither model proves incremental lift.

How should revenue be calculated for onchain attribution?

Use the value the protocol economically retains, such as its retained share of fees after applicable incentives, rebates, refunds, or subsidies. Do not substitute transaction value, deposit volume, trading volume, total fees, or TVL for protocol revenue.

How does cross-chain attribution work?

Cross-chain attribution joins activity only when the analytics system can identify the relevant account and execution path on each chain. The same externally owned account may share an address across EVM-compatible chains, but smart accounts, bridges, relayers, exchanges, and non-EVM chains can introduce different or obscured identifiers.

What steps belong in an onchain attribution funnel?

Use the shortest sequence that matches the real product path. A useful baseline is page view -> wallet connect -> confirmed transaction or decoded contract event. Add a message signature, token approval, or other intermediate action only when that journey requires it. Use a separate diagnostic funnel for transaction started -> transaction broadcasted -> transaction confirmed so intent and submission are not confused with conversion.