Keep funding acquisition only when a defined cohort reaches a meaningful protocol action, returns within a stated observation window, and does so at a cost the team accepts. If one of those links is missing, pause expansion or redirect the test. A token generation event changes the context, but it does not prove product demand.
A launch can bring attention, liquidity and wallet activity at once. Those signals describe different things. A useful budget decision starts with the protocol behavior it aims to create, then traces what can be connected to the acquisition source. If the data cannot connect those points, report the gap instead of treating activity as proof. This guide sets out a simple evidence path for founders and growth leads.
Primary evidence: define the cohort before measuring it
Write down who entered the acquisition cohort, when they entered, and which campaign or touchpoint is being evaluated. Use a stable rule. It could be wallets exposed to a campaign, accounts that completed signup, or users linked to a referral code. State the rule and its limits. If a wallet cannot be tied to a channel touchpoint, channel attribution is incomplete.
Next define the first meaningful action. Choose an event that shows the user experienced the protocol’s intended value. For a lending app, that might be a completed deposit or borrow, subject to the product’s own definition. A wallet connection, token transfer or page visit may be a step in the journey, but none should be silently substituted for product use. Record the event name, chain, contract or data source, and any exclusions. Dune’s query documentation describes how analysts can run and inspect queries over on-chain datasets. It supports reproducible analysis, but the analyst still has to validate the table, event decoding and query logic for the protocol being studied.
Measure repeat use with an explicit window
A first action indicates activation. Repeat use asks whether the same cohort completed another qualifying action during a stated period. Pick the observation window before reading the result, based on how often the protocol’s value should recur. A weekly trading product and an infrequent governance tool do not share a natural cadence.
Show the cohort size, eligible users, repeat-action rule, observation dates and missing coverage. Do not call the result retention if the event history is incomplete or user identity changes across addresses. Wallets are addresses, not automatically people. A user may control several wallets, and one address can be shared or automated. The measure therefore describes the cohort under the stated identity rule. It does not reveal more than that. If repeat use cannot be observed, report it as unknown and keep the spend decision provisional.
Separate on-chain behavior from channel credit
On-chain data can show protocol events under a defined query. Analytics systems can assign credit to channels under a selected attribution model. These records answer different questions. Google Analytics explains that attribution models distribute credit across touchpoints according to model rules. That allocation is not proof that a channel caused the event.
Keep the views side by side. The on-chain panel can report qualifying actions and repeat behavior. The channel panel can report the selected model, date range and credited conversions. Add a third status for links between them: verified, partial or unknown. When a user’s channel touchpoint cannot be linked to a wallet or account under a lawful, documented method, do not join the records by guesswork. The honest answer may be that the campaign generated measurable visits while protocol adoption remains unattributed.
Patterns and common mistakes that distort the decision
Wallet totals can rise because one person uses several addresses, bots interact, or an incentive attracts one-time activity. TVL can change with asset prices, deposits, withdrawals and market conditions. Token movement can reflect transfers or trading rather than use of the protocol. Each measure can still be useful, but only for the question it actually answers.
A second shortcut is comparing cohorts with different exposure periods or rules. Align the start date, eligibility criteria and observation window before comparing. A third is treating a campaign-level correlation as causal lift. Without a credible comparison or identification method, say the result is associated with the campaign, not caused by it. Avoid a composite score that hides these differences. A short table with separate definitions is more useful than one blended “growth” number.
Strategic interpretation: continue, pause or redirect spend
Continue when the cohort meets the protocol-defined meaningful-action and repeat-use tests, the acquisition cost falls within a threshold the team set in advance, and the result is sufficiently attributable for the decision at hand. The threshold is a management choice, not a universal benchmark. Document who chose it and why.
Pause expansion when a required event is uninstrumented, the observation window is not complete, or the cohort cannot be distinguished from other traffic. A pause can mean holding new spend while preserving the test and fixing measurement. Redirect when the current source produces low-quality actions under the same cohort rules but another hypothesis can be tested. Do not keep spending simply because a dashboard is busy.
Use the related launch, retention and acquisition guides below to compare adjacent growth questions.
Set the decision rule before the next campaign launches. Write down the acceptable acquisition cost, the event that counts as meaningful use, and the observation window. If those definitions change after the result is visible, preserve the old rule and explain the revision. This protects the team from moving its own standard to fit a preferred outcome.
Growth framework: a post-TGE acquisition decision record
Preserve the query version and event definition used for every cohort. If the contract or event changes, record the date and split the comparison. Otherwise, the team may mistake a measurement change for a behavior change. Note whether incentives were active during the observation window and whether every acquisition source used the same eligibility rule. These controls do not prove that a campaign caused repeat use. They make the observation easier to reproduce and show where the conclusion may fail. Keep a separate count for records whose identity could not be linked. Excluding them without disclosure can make the measured cohort look more complete than it is.
I would rather leave a gap visible than claim a return the data cannot support.
Use the related protocol launch guide, user retention guide and acquisition channel overview for adjacent questions.
FAQ
What counts as a meaningful action after TGE?
A protocol-defined event that reflects the value a user came to experience. Wallet connection or a token transfer alone may not qualify.
How long should a protocol measure repeat use?
Choose a period that matches how often the protocol value should recur. State it before reading the result.
Can wallet growth prove a campaign worked?
No. Wallet totals count addresses and do not establish unique people, repeat use or channel causation.
When should a protocol pause acquisition spend?
Pause expansion when key events are untracked, the observation window is incomplete or cohort linkage is unknown.
Closing: set the rule before the next campaign
The next useful signal is whether the same event and cohort rules still hold through the next observation window. If your team needs an outside review of its acquisition measurement, I can help identify the evidence gaps and decisions it supports.
Need a clearer view of your protocol’s growth gaps?
I assess evidence across six growth dimensions and provide concrete actions for your team.
Run the Growth Audit →
| Question | Evidence to inspect | What it supports |
|---|---|---|
| Who entered the cohort? | Protocol-defined acquisition cohort | Membership under the stated rule |
| What counts as a first action? | A protocol-defined event or transaction | Observed product behavior |
| Did users return? | Repeat event in a stated observation window | Repeat behavior, not channel causation |
References
- Dune query engine documentation, checked 2026-10-15.
- Google Analytics attribution documentation, checked 2026-10-15.