活跃地址：先定义活动，再统计增长
统计活跃地址前，先定义什么行为算活跃。发送交易、接收代币、调用应用或签署链下消息，属于不同的测量范围。地址增长不能随意改名为人数增长或付费客户增长。
Ethereum 区块浏览器文档介绍浏览器呈现的链上资料。底层观察可以帮助核验活动，但统计人口、合格行为、去重规则和区间仍需研究者自己写清楚。
写出活动口径
选择与研究问题对应的主要行为。假设要研究应用使用，指定合约的成功用户交互，可能比所有收到转账的地址更相关。记录合约范围、交易状态、网络，以及通过路由器间接访问是否纳入。
画图前确认计数单位。每日唯一发送地址、月度唯一地址和每日唯一数的合计不是同一个指标。同一地址连续三十天活动，月度唯一数只算一次，每日数合计则可能算三十次。
| 定义项目 | 必须写出的决定 |
|---|---|
| 统计范围 | 网络及应用合约集合 |
| 合格行为 | 成功调用、转账或具体事件 |
| 身份单位 | 地址、拟议地址簇或已核实用户 |
| 时间窗口 | 精确边界和时区 |
| 排除项目 | 系统地址、运维活动、测试事件 |
| 敏感性 | 含有及排除不确定活动的结果 |
不要为了让增长线好看而悄悄采用过滤规则。过滤必须服务于问题，并在笔记中披露。
假设案例：活动领取与持续使用
假设虚构应用第一周有一千个合格地址，第二周一千八百个，其中九百个只进行一次激励领取。在全部合格动作口径下，地址增长确实发生；但研究持续使用时，领取活动应作为单独群组观察。
按明确规则拆分回访地址、新增非活动地址和仅领取地址，不要没有证据就把最后一组称为机器人。一个人可以控制多个地址，多个人也可能经由同一服务地址活动，单数标识无法解开这两种关系。
后续可观察第二周地址中，有多少在明确的后续窗口再次执行指定动作。这测量地址层面的重复使用；没有经过核实的用户映射，就不能把它称作客户留存。以上数量均为假设，不代表真实应用。
检查分母与覆盖
先从底层事件复现一天的数量，再信任汇总序列。查失败交易是否被纳入，合约生成的动作归给用户还是中介。对突然出现的峰值，优先检查是否新增合约覆盖，以及是否存在重复运维模式。
再比较窄口径和宽口径，例如只统计指定成功动作与统计全部交互。如果两个定义下结论相反，就应突出说明依赖关系，而不是只选择有利的一条线。这样读者才能知道增长究竟指什么。
分群研究还要保存可用历史中的首次观察日期，并注明历史截断。数据集中第一次出现，不代表该地址此前从未使用应用。将所有首次观察地址称为新用户，会超过证据范围。
边界与常见错误
地址数不能独立证明人数、经济价值、满意度或自然需求。识别自动化尤其依赖方法，缺少公开且经过检验的规则时，应报告模式与敏感性，不做确定身份判断。没有用户映射时，本方法不适合精确人数采用率主张。
常见错误包括把每日唯一数相加得到月度唯一数、将被动收款地址当成主动用户、把活动增长全称为自然增长，以及把所有异常模式认定为欺诈。最终记录必须同时保留数字及产生它的定义。
常见问题
活跃地址等于活跃用户吗？
不等于。它是满足指定规则的标识，映射到个人或客户需要另外的证据。
激励活动地址应该直接排除吗？
通常应保留为独立群组。针对特定问题可以排除，但要披露规则，并展示排除对结果的影响。