What a Web3 Data Strategy Consultant Actually Does

TL;DR:

• If your dashboards disagree about basic numbers, you have a data strategy problem, not a tooling problem.
• At most protocols there is no data team. Reporting gets cobbled together by engineers and BD, and nothing reconciles.
• The job is connecting business goals to trusted metrics, so the board deck matches what the team uses internally.
• The hard part is rarely the SQL. It is deciding which numbers to trust.

If your growth dashboard says users are up, your onchain dashboard says activity is flat, and your product team is arguing over what counts as retention, you do not have a tooling problem first. You have a data strategy problem. That is exactly where a web3 data strategy consultant becomes valuable, not as an extra analyst, but as the person who turns fragmented reporting into a decision system.

In Web3, teams often collect plenty of data and still struggle to answer basic operating questions. Which wallets are actually valuable? Which acquisition channels bring funded users instead of empty signups? Where does activation break across onchain and offchain steps? Why do investor updates, internal dashboards, and product metrics all tell slightly different stories? A consultant focused on Web3 data strategy solves those gaps by connecting business goals, measurement design, technical architecture, and reporting discipline.

Why Web3 teams need a different kind of data strategy

Traditional SaaS analytics logic does not map cleanly onto crypto products. A wallet is not the same as a user. A transaction is not the same as engagement. Token incentives distort behavior. Multi-chain activity complicates identity. Offchain product actions and onchain outcomes often live in different systems, owned by different teams, with different definitions.

That creates a pattern many founders know well. Product wants activation metrics. Growth wants attribution. Finance wants trusted revenue reporting. Ops wants partner performance. Compliance wants transaction visibility. Leadership wants one source of truth. Everyone is asking reasonable questions, but the underlying data model was never designed to support them together.

There is also a structural reason this gets messy in crypto, and it is the thing generic breakdowns miss. At a centralized exchange, you usually sit inside a real data org. There is a data engineering team, an analytics team, business intelligence, sometimes data scientists. Roles are defined and someone owns the pipeline.

At a protocol, that is rarely true. Outside a handful of well-funded teams, you are often the only data person in the organization. You inherit reporting that engineers built on the side because they had to, or dashboards that BD and marketing put together themselves by vibe-coding Dune queries. Nobody set out to build a mess. It accumulated because there was no data function to own it. That gap is the actual reason the consultant role exists.

What a web3 data strategy consultant actually does

The role sits between strategy and execution. It is not just dashboard design, and it is not just data engineering. The work is to define the measurement framework, pressure-test the data model, and make sure the reporting stack answers business-critical questions without producing misleading numbers.

That typically begins with KPI design. Not vanity metrics, not a slide full of disconnected charts, but a real operating framework. The consultant identifies which metrics should guide executive decisions, which should support team-level optimization, and which should be monitored but not over-weighted. In crypto this distinction matters because many metrics are easy to inflate and hard to interpret.

From there, the consultant looks at instrumentation and source quality. Are wallet events tied to product events in a way that supports retention analysis? Is transaction data normalized across chains? Are campaign sources captured well enough to evaluate acquisition? Are internal definitions documented, or do different teams calculate the same number in different ways?

Then comes architecture. Sometimes the answer is a lightweight setup with a few reliable models and dashboards. Sometimes the team needs a more mature warehouse structure, custom onchain pipelines, identity resolution, and finance-grade reporting. It depends on stage, product complexity, and how expensive bad decisions have become.

The best consultants also force clarity around ownership. A metric without an owner turns into a debate. A dashboard without a use case becomes decoration.

A metric that looked fine until I looked underneath

Here is what this looks like in practice, from my own work leading the data function at Morpho.

Morpho shipped a feature in 2024 to migrate liquidity over from Aave and Compound. The onchain numbers looked great. Around $38M had migrated. If you stopped at the headline, it was a win, and the thread I posted with the Dune dashboard got the usual congratulations.

But the number was hiding the real story. Almost all of that volume was on Base, concentrated in a small set of addresses. On Ethereum, where the big positions actually live, there were 70 migration transactions. Seventy. The liquidity that mattered most was not moving.

The onchain data alone could not tell me why. So I did the thing the generic breakdown never mentions: I went offchain. I instrumented the frontend funnel, hover to click to convert, and the answer showed up immediately. The migrate button had near-zero engagement. It was dark-colored on a gray background, effectively invisible. The liquidity existed and users wanted it. They just could not see the path.

The fix was not a data engineering project. It started with changing a button color, then a popup prompt to guide users, then moving migrate into the app header in the V2 redesign instead of burying it. Over the months that followed, Ethereum migration went from roughly $6M to $32M, a 433% increase, while total migrated liquidity more than doubled to $86M.

The breakthrough came from holding both views at once. Read the full case study, or the detailed write-up (PDF).

That is the entire job in one example. The onchain metric was not wrong, it was just incomplete, and trusting it on its own would have sent the team chasing a problem that did not exist. Strong data work is holistic. You hold the onchain and the offchain view at the same time, because the decision lives in the gap between them.

I have written more about why headline onchain metrics mislead, TVL especially, in my guide for crypto data analysts. The short version: every onchain metric is a claim, and someone has to verify it before a decision gets built on top.

The mess usually looks the same

When a team realizes it needs help, the symptoms are predictable.

The most common one is that marketing, BD, and growth have all started doing their own reporting. Someone vibe-codes a Dune query, someone else builds a spreadsheet, an engineer wires up an event tool on the side. None of it is coordinated. So you end up with tons of dashboards and metrics and almost nothing an exec can actually run the company from.

That is the real failure mode. Not too little data. Too much data, calculated too many different ways, with no shared definitions underneath it. When product, growth, and leadership each report a different version of user activity, the problem is not communication. It is missing metric governance.

A close cousin is tooling sprawl. Teams add dashboards, event tools, onchain query platforms, reverse ETL, and spreadsheets, then assume more software will fix reporting quality. It usually does not. Without a clear data strategy, more tools just produce more inconsistency.

And then there is slow decision-making. Teams wait too long to answer simple questions because every analysis requires manually joining product data, CRM data, and blockchain activity. That cost compounds. It slows experiments, weakens accountability, and makes planning more political than analytical.

There is also a hiring signal. If you are about to hire a head of data, staff analyst, or analytics engineer but cannot define what success looks like, bringing someone in part-time first can save time and money. This is exactly why fractional data leadership makes sense at this stage: you get the framework and the trusted numbers in place before you commit to a full-time hire, so the eventual role is built on the right foundation instead of inheriting the same undefined mess.

Where the framework comes in

The piece that ties all of this together for leadership is a real measurement framework. This is the part I find most underrated.

Most crypto teams track what is easy to count, token price, TVL, raw transaction volume, social metrics, and then wonder why none of it tells them whether the business is healthy. A framework like OKRs adapted for onchain reality forces a different question: which outcomes actually matter, and which numbers are leading indicators of those outcomes versus vanity noise.

That work is less about charts and more about connecting strategy to measurement. Retention over raw wallet counts. Revenue growth over price. Developer adoption over GitHub stars. The framework is what lets a founder walk into a board meeting and defend the numbers, because every metric in the deck traces back to a strategic objective and a definition the whole team agreed on. That is the difference between a dashboard you inspect and a system you operate from.

What good consulting looks like in practice

A serious engagement should produce more than recommendations. Strategy without implementation detail dies in the backlog.

Good work usually includes a current-state audit, a target KPI framework, prioritized gaps, and an execution roadmap tied to business outcomes. It often also includes dashboard redesign, event taxonomy cleanup, onchain and offchain identity logic, reporting governance, and support for team rituals like weekly growth reviews or monthly executive reporting.

The practical output matters. A founder should know which numbers to trust. A growth lead should know how channel performance is measured. A product lead should see the activation funnel with both app events and wallet-level outcomes. A finance or ops lead should not need a custom pull every time leadership asks for a board metric.

In stronger engagements, the consultant also helps set operating cadence. That sounds less technical, but it is often where value compounds. Data strategy is not complete when dashboards ship. It is complete when the company uses them to make sharper decisions, consistently.

What to look for before you hire one

Domain knowledge matters here more than in many other data roles. A consultant can be excellent in traditional analytics and still miss core Web3 realities like wallet fragmentation, chain-specific quirks, token-driven behavior, smart contract event complexity, and the difference between speculative activity and durable product usage.

You want someone who can talk comfortably about KPI design, SQL models, attribution limits, retention frameworks, and executive reporting in the same conversation. And ideally someone who has actually held the onchain and offchain views together on a real product, because that is exactly where the hard decisions live. That combination is rare, which is why broad analytics consultants often underperform in crypto environments.

You should also look for judgment. Not every team needs a full warehouse rebuild. Not every metric needs to be real time. Not every reporting issue is a data engineering issue. Sometimes the fastest fix is a simpler definition, a narrower dashboard, a clearer owner, or as I learned at Morpho, a more visible button.

The right consultant reduces complexity where possible and adds sophistication only where it pays off.

The real outcome is not better charts

Better charts are easy to buy. What teams actually need is better confidence. Confidence that the KPI in the board deck matches the metric the team uses internally. Confidence that growth spend is judged against real value, not surface activity. Confidence that onchain reporting reflects how users behave, not just how transactions are logged.

That is the job. A web3 data strategy consultant gives teams a measurement system they can operate from, not just inspect.

For Web3 teams that need both strategic clarity and implementation depth, this is the gap I work in through Unchain Data, whether as a fractional head of data or a focused strategy engagement. The point is to understand the business layer and the mechanics underneath it at the same time, which is what most crypto teams actually need.

If your company is scaling faster than its reporting discipline, fix that before the next product launch, fundraising cycle, or hiring wave forces the issue. Data strategy is not overhead when the business runs on numbers people trust.

Key Takeaways

• A web3 data strategy consultant turns fragmented reporting into a decision system. The deliverable is trusted numbers, not more dashboards.
• The role exists because most protocols have no data function. You inherit reporting from engineers and BD people, never designed to work together.
• Onchain metrics are claims, not facts. At Morpho, $38M migrated looked like a win until the offchain funnel showed an invisible button was blocking the biggest positions on Ethereum. Fixing it grew Ethereum migration from about $6M to $32M, a 433% jump, and total migrated liquidity more than doubled to $86M.
• The mess is almost never too little data. It is too much, calculated too many ways, with no shared definitions and nothing an exec can run the company from.
• A real measurement framework, OKRs adapted for onchain reality, is what connects strategy to the numbers in the board deck.