On-Chain Analytics Metrics: Activity, Cohorts and Financial Context
Build dashboards whose activity counts, financial aggregates and labels preserve the calculation choices behind each result.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
On-chain analytics turns observations into metrics: active accounts, transaction counts, retained cohorts, market volumes or financial aggregates. A dashboard can make these numbers easy to compare even when their populations and calculation rules differ.
A useful metric explains its unit before showing a trend. Who or what was counted, over which interval, and under which inclusion policy? Retain those choices with the result. This allows readers to distinguish real observed change from expanded coverage, revised labels or an updated interpretation that changes the meaning of the chart.
Choose the counting unit before aggregation
A transaction, event, asset movement, address and application session describe different units. Counting one as another can produce a technically valid query with a misleading label. A single transaction may contain several relevant movements and involve several accounts.
Write the intended grain in the metric definition. A sample data can contain two transactions, five movements and three distinct qualified account references. Each count can be useful, but none should be presented as the others. Preserve stable record identities through joins and enrichment. If descriptive metadata creates extra rows, the aggregate should retain the intended grain rather than treating every joined row as a new network event or user action.
Distinguish addresses from people and organizations
An active address count is an observation over included address relationships. One person can control several accounts, and one account can represent many participants. A familiar dashboard label such as users needs an explicit application definition and supporting relationship evidence.
If the analysis groups accounts into entities, retain the mapping, confidence and effective period. Keep ungrouped observations available for review. A later label revision should be identifiable as a methodology change rather than silently altering an adoption trend. Test one grouped entity with several addresses and a custody-like fixture representing several synthetic participants. The dashboard should explain which level it measures instead of implying that address count proves a real-world population.
Keep time windows and observed populations compatible
A daily metric needs a timezone, boundary convention and observation-selection policy. A cohort calculation also needs a definition of entry, return and the population eligible to be measured. Retain those rules with the query or calculation version.
Newly inspected ranges can change a historical chart without new network activity occurring. Preserve coverage context so the change can be explained. Test a record at an interval boundary and an earlier unresolved range that becomes available. The result should distinguish changed evidence from changed behavior. A consistent label across networks is not enough if each network contributes a different record type or historical period to the combined aggregate.
Separate quantity aggregates from valued metrics
Financial measures require compatible units and explicit treatment of claims, liabilities and price inputs. Summing differently identified token quantities does not produce a meaningful common financial value. Counting both a claim and its represented underlying assets can also duplicate included value.
Retain the component observations and valuation method under any total. A synthetic dashboard can include two priced assets and one unresolved position component. The visible aggregate should identify what is included and what cannot yet be valued. A metric called total value needs a stated population and method rather than relying on a familiar name to hide assumptions about asset grouping, conversion timestamps or overlapping protocol relationships.
Version entity labels and quality filters
An address label, spam indicator or action classification adds an interpretation to technical records. Retain the rule or evidence behind it, along with the interpretation version and unresolved state. A filter should not silently remove observations from every future analysis without a documented policy.
Offer enough methodology for readers to understand a raw included series and any policy-filtered view. Test a label change and conflicting classifications. The analytical result should explain which rule applied and whether the change affects earlier periods. This supports reproducibility and avoids treating an improved classification as proof that the underlying transaction or account observation changed at the same time as the dashboard label.
Publish a methodology that supports comparison
A compact metric definition can identify the population, grain, time window, relevant units, inclusion rules, coverage boundary and calculation version. Keep it available beside the chart or export rather than requiring readers to infer it from a title.
The PostgreSQL aggregate-function documentation is a primary implementation reference for one query environment, but calculation meaning remains the application's responsibility. Test duplicate observations, many-to-many joins, changed labels and missing valuation inputs. Useful analytics lets a reviewer reproduce the included result and compare compatible definitions, while keeping unsupported causal explanations or real-world identity conclusions separate from what the underlying network observations actually establish.
Questions about the topic
Frequently asked questions
Are active addresses the same as active people?
No. Address relationships and real-world entities have different meanings. Retain any explicit grouping policy and its evidence before presenting a metric as a count of people or organizations.
Why can a historical dashboard change without new activity?
Coverage can expand, records can be corrected and interpretation rules can change. Preserve the relevant versions so the dashboard can explain which input or method changed.
What should a metric definition include?
State population, counting grain, interval, units, filters, coverage and calculation version. Financial metrics also need their valuation and overlap policies to remain reproducible.
Standards & technical documentation
