# All metrics are imperfect, but many are useful. Let's make them more available
**URL:** https://forum.polkadot.network/t/all-metrics-are-imperfect-but-many-are-useful-lets-make-them-more-available/1858
**Category:** Ecosystem
**Created:** [January 29, 2023, 10:44pm UTC](https://forum.polkadot.network/t/all-metrics-are-imperfect-but-many-are-useful-lets-make-them-more-available/1858 "2023-01-29T22:44:47Z")
**Posts on this page:** 1
**Showing post:** 12
### Author:  [@sourabhniyogi](https://forum.polkadot.network/u/sourabhniyogi)
#### Post date: [February 18, 2023, 2:39pm UTC](https://forum.polkadot.network/t/all-metrics-are-imperfect-but-many-are-useful-lets-make-them-more-available/1858/12 "2023-02-18T14:39:01Z")
As marketing people, “investors”, competing ecosystems, govts monitoring Web2, etc. use DAU and MAU vocabulary, I strongly believe that it’s important to retain the notion of “active” and not abandon it because it’s difficult to define otherwise. In particular, I think we should arrive at a definition that conforms to human intuition for “active” - something like “clicked the sign button on a wallet” with only one private key, or a bot doing so via equivalent code (which we can’t distinguish), and corresponds to **signed extrinsics** (or signed EVM Transactions). I don’t think it’s healthy to attempt to include accounts that haven’t passed the “is there a signature?” test as “active.”
Let’s consider four cases:
- If P is a proxy account for X, and there is an extrinsic signed by P to transfer Assets from Account X to Account Y, only P is _active_, while both X and Y are _passive_.
- If there is a 2-of-3 multisig account with S\_1+S\_2+S\_3 controlling X, and there are two extrinsics from S\_1 and S\_2 to transfer Asset from Account X to Account Y, only S\_1 and S\_2 are _active_, while Y are passive and S\_3 has not performed any action onchain to be considered _active_ nor _passive_.
- If there is an XCM transfer from an origination chain C1 of account S\_4 with an amount A to a destination chain C2 with a beneficiary Y, only S\_4 is _active_, while Y on destination chain is _passive_.
- If there is remote execution from an origination chain C1 of account S\_5 causing some Transact operation with a destination chain C2 with some keyless derivative account Y who does a transfer of some amount A to account Z, only S\_5 is _active_, while Y and Z are _passive_.
The border between active and passive is guided by the simple “is there a signature?” test, where signing is the fundamental operation that drives our human intuition of “active”. I recommend refining (or coming to consensus) by explicitly considering these 4 cases, and adding additional cases to refine further. If we wanted to artificially inflate the number of accounts, we could consider X + Y + S\_3 + Z as “active” accounts. However, this would be overzealous and potentially misleading, and it goes against human intuition. These accounts should remain “passive.” I understand the marketer within us may want to claim bigger numbers of active accounts, but honest analytics should not be driven by these insecurities.
The Polkadot ecosystem is led by people who consistently do the right thing and take the long-term view. We shouldn’t twist “active” based on any other psychology. I would like the industry to conduct cross-ecosystem analytics in a multichain objective way, with Polkadot doing the right thing. We should not suddenly go against human intuition unless CeFi entities (Coinbase, Binance, OpenSea, etc.) publicly start using “active” in this manner.
Therefore, we keep the “active” definition simple and adhering to human intuition:
Active Accounts: (Substrate)
Accounts that have signed an extrinsic
Passive Accounts: (Substrate)
Accounts that aren’t active but have any balance changes for any asset (native or non-native asset, within chain or cross-chain). This can include proxy and multisig (X, Y, S\_3 in the above examples), remote execution triggered by other accounts, transfer recipients (including crowdloan and staking rewards distribution), and balance deductions (e.g., pre-authorized transferFrom/proxy called by other active accounts).
We have mechanized the above definitions with exact [substrate-etl](https://github.com/colorfulnotion/substrate-etl) BigQuery here:
>
The 4 cases active/passive distinctions are covered perfectly with the above definition, but we imagine being able to refine both definitions precisely with open source transparent code as new forms of active/passive evolve.
The open source approach taken here is of _transparency_ and _reproducibility_: with exact BigQuery computations, anyone can reproduce any datapoint and improve any definition with simple code adjustments to the query form.
---
_[View the full topic](https://forum.polkadot.network/t/all-metrics-are-imperfect-but-many-are-useful-lets-make-them-more-available/1858)._