Web3 campaign analytics is the practice of connecting marketing activity to actions that matter in a blockchain-based product. A campaign may attract wallet connections or transactions, but neither figure alone establishes that it has acquired loyal customers. The useful question is whether people take a meaningful action and return when the initial promotion is no longer the main attraction.
That question is difficult because a person can use several wallets, a wallet can interact with more than one product, and incentives can temporarily change behavior. A practical measurement process combines campaign reports, product events and, where appropriate, on-chain records while making the limits of each source explicit.
Define adoption before analysing campaign exports
Start with the product outcome the campaign is meant to support. For a payment gateway, that might be a merchant completing a first payment and then processing another one. For a wallet application, it could be a user completing a core action and returning to use the application again. Define the action, the observation period and the conditions that qualify it before reviewing the results.
Once those definitions are set, a marketing workspace such as https://www.ohlas.uk/ can be used to review prepared campaign exports, spreadsheets and reports for performance issues and possible tests. That is analysis of the material supplied by the operator, not independent verification of blockchain activity or identification of real users.
Build a small funnel around the outcome: campaign exposure or click, landing-page visit, wallet connection if relevant, first meaningful product action, and a return action. Record the number eligible to reach each stage as well as the number completing it. This makes it possible to distinguish a traffic problem from a product onboarding problem.
Choose a primary outcome and a few diagnostic measures rather than treating every transaction as a success. If a campaign offers rewards for an initial action, report rewarded and non-rewarded activity separately when the data allows. A strong launch count followed by little subsequent use may be a useful finding, not a reason to redefine success after the fact.
Why wallet counts are not customer counts
An address identifies an account, not a verified individual. Ethereum’s guide, How to create an Ethereum account, distinguishes accounts from wallet applications: one wallet can access several accounts, and one account can be accessed through multiple wallets. These distinctions matter when a report labels every active address a new user.
One person can control multiple accounts; an application or other contract can also generate activity that does not map neatly to a person. Conversely, a shared or organisational account may represent activity by more than one person. Wallet connections are not necessarily unique customers either, especially when a visitor reconnects or uses another device.
Incentives add another source of uncertainty. An airdrop, fee rebate or trading reward may encourage users to complete an action mainly to qualify for a benefit. Repeated activity across addresses can be consistent with incentive-seeking, but a transaction pattern by itself does not prove that the same person controls those addresses. Do not label a cohort fraudulent without stronger evidence and an appropriate review process.
Use precise names in reports: “unique addresses interacting with the contract,” “wallet connections” or “accounts completing onboarding” rather than “customers,” unless a separate, defensible customer measure exists. Put the time window and chain or chains covered next to the number. If addresses cannot be reliably linked across networks or to product accounts, describe the resulting overlap as unknown.
Build a minimal dataset without exposing wallet-level histories
Prepare an analysis table at the lowest level needed to answer the question. For many campaign decisions, an aggregate row per campaign, channel, reporting period and incentive status is sufficient. It can contain spend, impressions, clicks, eligible visits, first product actions and qualifying return actions. Include the event definitions and data source alongside the export, so an analyst or AI tool can interpret the columns correctly.
Keep campaign and product periods aligned. If the retention measure is a return within 30 days, recent acquisition cohorts have not yet had a full 30-day opportunity to return. Compare mature cohorts with the same follow-up window, or clearly mark incomplete cohorts. Note missing campaign tags, changes to event instrumentation and gaps in chain coverage rather than silently treating them as zero activity.
Avoid uploading seed phrases, private keys, credentials, customer contact details or raw wallet histories into a marketing analysis tool. Aggregate or remove identifiers before export, restrict access to the source records, and follow the organisation’s privacy and retention requirements. Hashing an address does not automatically make a dataset anonymous: it may still be linkable to other information.
If a question genuinely requires record-level linkage, handle it in an approved environment with a documented purpose, appropriate controls and only the fields needed. Establish how the connection between a campaign touchpoint, product account and address is made, and report unmatched records. Consent, browser restrictions and incomplete tagging can all leave gaps; the matched subset should not automatically be assumed representative of everyone.
Use AI to investigate funnel drop-offs, not invent attribution
With a prepared export, ask specific questions. Which channels show a large decline between a landing-page visit and a first product action? Did cost per qualifying action change after a creative or landing-page update? How does the return-action rate differ between campaigns with and without incentives? Request the calculations, denominators and assumptions behind each observation, not just a ranked list of recommendations.
A useful rate must have a consistent denominator. For example, divide the number of accounts that completed the defined return action within the observation window by the number of accounts that completed the first qualifying action and had enough time to return. Describe it as an account-level rate if accounts, rather than verified people, are being counted. Do not mix address counts in the numerator with product-account counts in the denominator.
Attribution adds a separate layer of uncertainty. Google Analytics’ Get started with attribution documentation explains how rules or data-driven models assign conversion credit and how settings such as eligible channels and lookback windows affect reporting. A conversion credited to a campaign is therefore a measurement result under selected rules, not proof that the campaign caused the outcome.
Ask the analysis to flag alternative explanations: a reward launch, a product release, a tracking change, organic coverage or a shift in audience mix. If an export lacks cost data or cannot link campaign visits to later activity, an AI-generated answer cannot repair that missing evidence. Treat its explanation as a hypothesis to investigate, and check the underlying arithmetic against the original reports.
Verify recommendations against product and on-chain evidence
Before changing a budget, compare the proposed explanation with records outside the campaign summary. OhlasAi’s stated approach at https://www.ohlas.uk/about is that users review and adjust AI recommendations and make the final decision. That principle is especially important when the uploaded report captures only part of a Web3 customer journey.
Use a short operator check before acting on a suggested change:
- Tracking: Check whether tags, event definitions, consent settings or reporting coverage changed during the comparison period.
- Incentives: Confirm who was eligible for rewards, when they were available and whether the reported actions were required to claim them.
- Product events: Verify that the events labelled as successful reflect the intended user action, and check for failed or duplicated events where possible.
- On-chain records: Where relevant records are available, compare contract, network and transaction timing with the report. A transaction can corroborate an account-level action without identifying its controller or explaining the campaign’s influence.
Document what was checked, what remains unknown and who approved the decision. If a recommendation depends on a link between a product event and an address, confirm how that link was established and how many records could not be matched. A discrepancy may reflect timing or coverage rather than misconduct or an analysis error; resolve it before making a confident claim.
Run one campaign test and measure retained use
Turn the strongest supported hypothesis into a bounded test. For example: “A landing page that explains the first payment workflow more clearly will increase the share of eligible campaign visitors who complete a first payment.” Decide the audience, creative, destination, budget cap and test period in advance. Keep the incentive terms consistent if the aim is to isolate the landing-page change.
Where feasible, randomly assign comparable eligible visitors to the existing and revised pages during the same period. Check that assignment and event tracking work in both groups, and predefine the primary measure and the minimum evidence needed to make a decision. A simultaneous comparison helps limit some time-related differences, but missing tracking, small samples and users crossing between groups can still weaken the result.
Measure the immediate outcome and a later return outcome separately. If the product’s meaningful repeat action takes 30 days, allow each cohort the full window before comparing retention. Also report spend, sample size, failures or reversals where relevant, and any material changes to rewards or product availability. An apparent lift in first actions may be less valuable if subsequent use does not follow.
If randomisation is not practical, a before-and-after comparison can still inform the next question, but label it observational. Seasonality, market conditions and simultaneous launches may explain part of the difference. Use the result to decide whether to continue, revise or stop the campaign—not to claim a causal effect that the design cannot establish.
The most defensible Web3 campaign report is not the one with the largest wallet count. It is the one that defines meaningful use, separates account activity from people, shows how credit was assigned and makes the next decision proportionate to the evidence.