Dune Analytics setup: where manual data collection breaks
Manual collection of on-chain metrics holds up as long as we are talking about one wallet and one reporting period.
As soon as dozens of contracts, several networks, and daily snapshots enter reporting, manual work stops scaling: exports are made at different times, with different history depth, and with different assumptions about what even counts as a transaction.
What follows is not analytics but an investigation into why two departments' numbers for the same month do not match.
Update is the first thing to break. While the export catches up with the network, yesterday's picture lives in the report: data refresh lag accumulates, and decisions are made based on numbers that no longer describe what is happening.
On active contracts, where thousands of events pass in a day, manual recalculation cannot keep up with the network in principle — the analyst closes the previous period exactly when it has ceased to be relevant.
Second — discrepancies in reporting. Two snapshots for the same period do not reconcile because one includes failed transactions, while the other only includes confirmed ones; in one, transfers between own addresses are counted twice, in the other they are cut out.
The metric becomes overgrown with exceptions that live in someone's spreadsheet, and the argument is no longer about strategy but about the counting methodology.
Dune Analytics setup addresses exactly this part: SQL queries run on top of already indexed blockchain data, so a metric is calculated once and by a single definition. The network updates — and the query result updates too, without manual exports and reconciliations.
The dashboard and API return the same numbers that engineers see, and discrepancies remain only where expectations about methodology truly diverged, not where export dates diverged.
What changes after implementation: measurable effect
The effect of Dune is measured at the process level, not as "it became more convenient." Before implementation, a new question about blockchain data meant a separate export, manual reconciliation, and a day or two of waiting; after, it is a query on top of already indexed contracts that answers in minutes.
The analyst stops being a bottleneck, and the queue of requests from the product no longer piles up.
The share of manual operations drops predictably. Data mart updates are moved to a schedule, metric recalculation runs on the same query, and no one "tweaks" the numbers in a spreadsheet before a meeting. The freed-up time goes into defining metrics, not collecting them.
Reconciliation of numbers is a separate class of failure that is closed architecturally.
When dashboards and API read from the same data model, the discrepancy between the investor report and the internal snapshot disappears by design: both sides calculate the same value from the same source. A fix is made in one place, not in five spreadsheets.
The speed of obtaining metrics becomes a property of the system, not of one engineer's heroics. A new dashboard on indexed data is assembled in hours, and the API returns the same aggregates as the visual layer — without a second implementation of the logic. This is the verifiable result: fewer manual steps, faster answers, one version of the truth.
Approaches to metric collection: comparing options
The three levels of collection differ not in convenience but in who is responsible for the correctness of the numbers and how quickly a fix reaches the report: ready-made public queries, custom queries on an external platform, and fully in-house data collection.
Ready-made queries provide a quick start: the contract schema does not need to be described manually. But the filter logic is set by the author — you do not control the address list, thresholds, or aggregation window.
When a contract changes, such a dashboard silently shows an incomplete picture, and this can only be noticed by a discrepancy with an independent source.
Three options and their boundaries
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made public queries | A quick first snapshot is needed: volumes, active addresses, day-by-day dynamics | Filters and thresholds are set by the author, refresh lag, no guarantees after a contract change |
| Custom queries in Dune | Custom metrics and control over the formula are needed, and there is a person who writes SQL confidently | Source limitations: not all networks and events are indexed, history depth is dictated by the platform |
| In-house data collection | Data outside indexers and a custom view across internal systems are needed | Own team and infrastructure: nodes, storage, reindexing on every contract update |
In practice, teams take a hybrid: basic metrics live on the platform, while decision-critical ones are duplicated by in-house collection. Then the discrepancy between the two loops becomes a separate check — it is visible on the dashboard before the numbers go into the report.
Setup stages: from source audit to handover
We start with a source audit: we compare contracts and pools with what is already indexed in Dune and determine where ready-made tables are enough and where event log decoding is needed.
Already at this step, it is clear which metrics can realistically be collected and which will have to be calculated approximately.
- Source audit. A list of networks, addresses, and confirmed tables — the foundation for all subsequent queries.
- Data and metric schema. We agree on what "active address," "volume," and "cohort" mean: without unified definitions, the numbers on the dashboard will not match internal accounting.
- Query writing. SQL with parameters by periods and networks; we move reusable calculations into separate views so dashboards do not duplicate logic.
- Reconciliation check. We compare the samples with an independent source and investigate discrepancies until they are resolved — only then can the numbers be trusted.
- Dashboard assembly. A dashboard for specific decisions: dynamics, distribution, large participants, not charts for charts' sake.
- Access handover. Roles in the workspace, instructions on queries and metrics, and the procedure for edits without our involvement.
Each stage is closed with an artifact: a list of sources, a document with metric definitions, a verified set of queries, ready-made dashboards. Handover does not turn into an oral story — the result can be maintained by your own team.
Artifacts: queries, dashboards, policies, access
Analytics does not rest on charts but on the scaffolding around them — query code, field descriptions, and permissions. Without this, in a month no one will be able to explain where a number in the report came from, and any refinement will have to start from scratch. Therefore, we record the result of the work in artifacts that remain with your team.
- Query set — one per metric, broken down by contracts, pools, and periods. Each header states which tables and filters are used and why service operations are excluded.
- Dashboards and charts — a summary dashboard for management and detailed ones for analysts: volumes, active addresses, concentration among large holders. Periods and definitions are unified, so the numbers on different screens reconcile.
- Metric reference — a table "metric → formula → data source → owner." It removes arguments like "our volume is different": both teams count by the same definition.
- Access policies — roles for read, edit, and publish, binding to corporate accounts, and a separate perimeter for external contractors.
- Update policy — recalculation schedule, list of external dependencies, procedure for a source failure or schema change, as well as periodic reconciliation of key numbers with an independent source.
- Maintenance guide — how to add a new metric, where query versions are stored, whom to notify about a discrepancy. A new analyst can get up to speed without correspondence with us.
We hand over the set to the Dune workspace and to the client's repository with edit history: any metric can be rolled back to a previous version or show exactly what changed in it. We set up access under your accounts so that analytics does not remain tied to us.
Case study: reporting discrepancies reduced to zero
Initial picture: data for several contracts was collected manually — engineers exported operations from a network explorer into tables, consolidated them in a spreadsheet, and from there assembled a report for management.
This amounted to about 40 manual exports per month, preparation took two days, and discrepancies between the report and network data reached 6–8% — some transactions were lost during copying, and some were counted twice after internal transfers.
What we changed
The calculation logic was moved to Dune and broken into layers. Raw tables of blocks, event logs, and contract calls are normalized in intermediate SQL views: we bring addresses to a single case, mark internal transfers with a flag, and cut off reverted transactions.
On top are materialized aggregates by addresses, tokens, and pools with recalculation by block number, so any number is reproducible for any date, not "as of export time." The dashboard and API return the same aggregates, meaning internal reporting and external queries are calculated from a single source.
Result in metrics
Manual exports dropped from 40 to zero — only the monthly reconciliation of two control sums remained.
The discrepancy rate went to zero and has held across all reconciliations performed: a discrepancy now means an error in the model, not in manual work, and is caught by a test before publication.
A new report — for a new network, token, or period — is assembled in 2–4 hours instead of two days, because ready-made views are reused rather than rebuilding the export chain.
How does a ready-made dashboard differ from in-house data collection?
The ready-made dashboard of the Dune platform answers typical questions quickly: data is already indexed, metrics are calculated, and a snapshot by volumes and active addresses is visible the same day.
The limit comes where a custom view is needed — the share of wallets with repeat operations or a join between activity and product data. In someone else's data mart, such a view either will not appear or will be calculated by someone else's logic.
In-house data collection is a custom calculation layer: your own metric definitions, your own history depth, your own recalculation schedule.
The team itself is responsible for freshness and completeness, for recalculation when contracts update, and for ensuring a metric does not diverge after a schema change on the platform side. In return — control over the data and changes in days, not on someone else's release schedule.
The choice comes down to three modes:
| Option | When it fits | What limits it |
|---|---|---|
| Platform's ready-made dashboard | A quick overview is needed: volumes, active addresses, movement across large contracts | The set of metrics is set by the platform; a custom view and a join with product data are unavailable; edits follow the release schedule |
| In-house collection and storage | Custom metric definitions, deep history, and integration with internal systems are needed | An engineer is needed for support: index recalculation, freshness and gap control |
| Hybrid: dashboard plus in-house layer | The overview is taken ready-made, while critical metrics are calculated and stored in-house | Metric definitions need to be synchronized, otherwise the numbers in the dashboard and in the in-house layer will diverge |
The practical criterion is simple: if analytics is needed for market overview, a ready-made dashboard is enough.
If the numbers go into reporting, risk models, or product decisions, an in-house layer is needed; otherwise, a discrepancy in the metric definition will surface at the moment of a dispute about the numbers.
Common technical concerns before starting
We address the concerns most often raised before starting. They concern not Dune itself but the behavior of data in production: indexing speed, changes in contract logic, reliability of numbers, and access separation.
How far behind the latest block is the data?
Dune Analytics setup does not remove indexing lag: between block confirmation and its appearance in a query, anywhere from seconds to tens of minutes pass — it depends on the network and confirmation depth.
For operational control, we read state directly from the node, while we build analytical data marts on history, where lag is not critical.
The contract was updated — will the reports keep working?
A logic change breaks metrics silently: the address is the same, but the events and their parameters are different.
We pin addresses and signatures in the configuration, check for the appearance of new signatures, and version queries — after an update, it is visible which dashboards broke, instead of discovering a discrepancy in the report for management.
How can we make sure the numbers are correct?
Verification of numbers is not built on trust in the dashboard.
We compare aggregates with an independent source, check the reconciliation of sums by addresses and periods, add tests on known transactions and integrity control — a discrepancy surfaces at the assembly stage, not during a budget defense.
How do we expose data externally without opening up too much?
We grant API access to separate keys with a limited set of queries, not full workspace permissions. We store secrets in a secure vault, separate read and edit roles, and keep an access log — if a key leaks, it is revoked without rebuilding the entire analytics.
Let's discuss the task: what we need from you to start
For the first conversation, a finished requirements document is not needed — what you already have on hand is enough.
Below is a list that covers almost all questions about setting up analytics on Dune: with it, we come back not with clarifications but with a timeline estimate, a data layer schema, and a stage-by-stage plan.
- Data access: contract addresses by network, list of wallets, pools, or tokens, read permissions in internal systems — if part of the calculation uses your data, not only the network.
- List of questions the report must answer: capital distribution, movement across addresses, fund report, or risk monitoring. This determines the metric set and granularity.
- Report examples: current exports, spreadsheets, screenshots of old dashboards. Even an inconvenient format shows which snapshots and breakdowns you really need.
- Work plan: how often data must update and who views it — daily monitoring and a monthly summary for investors are assembled by different layers.
- Timeline estimate: the date by which the first result is needed, and whether there is a hard tie to an event — reporting, a deal, a product launch.
- Owner on your side who will confirm the metric calculation logic and accept the result at the end of the stage.
This is enough to start: we fill in the rest during the conversation. Describe the task — we will come back with an estimate, a work schema, and a plan where you will see the first working report long before the entire task is closed.