📚 课程目录第3章链上流量核心概念

3、链上流量核心概念：活跃地址、新增地址、唯一地址、交易笔数、Gas消耗、转账金额、合约调用次数等指标定义与口径

链上流量分析的第一步，不是急着打开Dune或Nansen看图表，而是先建立一套口径统一、定义清晰的指标体系。很多分析师在解读数据时出现“鸡同鸭讲”的尴尬，往往是因为对“活跃地址”的理解不一致——有人统计的是发起交易的地址，有人统计的是接收方地址，还有人把两者去重后合并计算。本章将系统拆解链上流量分析中最核心的七个指标，明确其定义边界、统计口径、适用场景与常见陷阱，帮助你建立一套可复用的分析框架。

上图展示了链上流量指标从原始数据到应用分析的完整链路。原始数据层是区块链上不可篡改的事实记录，指标加工层是我们基于分析目标对原始数据进行的聚合与计算，而应用分析层则是将加工后的指标用于回答具体的业务问题。理解这一分层逻辑，是避免指标误用的基础。

3.1 活跃地址：流量分析的第一入口

核心原理

活跃地址（Active Address）是链上流量分析中最基础、最常用的指标。其标准定义为：在特定时间窗口内（通常为24小时或30天），至少参与过一次有效交易的地址数量。这里的“参与”包括作为交易的发起方（Sender）或接收方（Receiver）。在以太坊等账户模型的链上，一个地址在一天内可能发起多笔交易，但只计为1个活跃地址；同样，一个地址可能收到来自多个地址的转账，也仅计为1个活跃地址。因此，活跃地址本质上是“去重后的用户数”，而非交易次数。

在实际操作中，不同数据平台对“有效交易”的定义存在细微差异。例如，某些平台将失败的交易也计入活跃地址统计，而另一些平台只统计成功的交易。此外，合约地址本身也可能成为活跃地址（当它作为交易的接收方时），这会导致统计口径的偏差。因此，在跨平台对比数据时，务必确认其底层SQL的过滤条件。

判断方法与操作流程

在Dune Analytics中，计算日活跃地址的标准SQL逻辑如下：

-- 以太坊日活跃地址（发送方+接收方去重）
SELECT 
  date_trunc('day', block_time) AS day,
  COUNT(DISTINCT address) AS active_addresses
FROM (
  SELECT "from" AS address, block_time FROM ethereum.transactions
  UNION ALL
  SELECT "to" AS address, block_time FROM ethereum.transactions
) t
WHERE block_time >= NOW() - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1

这段SQL的核心逻辑是：将交易的发送方和接收方字段合并到一个地址列中，然后按天进行去重计数。需要注意的是，UNION ALL会保留重复行（同一地址既发送又接收时会出现两次），但COUNT(DISTINCT)会将其合并为1。如果只想统计发送方活跃地址，则去掉UNION ALL中的接收方部分即可。

案例拆解：识别“刷量”假象

假设某Layer2项目方宣称其日活跃地址达到5万，但我们在Dune上验证时发现，其中约3万个地址是首次出现且只进行了一笔交易，且这些地址的Gas消耗集中在同一区块高度。进一步分析发现，这些地址的创建时间集中在项目方发布空投公告后的2小时内，且彼此之间存在资金关联（均由同一个地址批量转账0.001 ETH作为Gas费）。这明显是“女巫攻击”式的刷量行为。通过将活跃地址拆分为“新增地址”和“留存地址”两个子指标，并观察其分布特征，可以快速识别此类异常。

风险提示：活跃地址指标极易被刷量。在评估项目真实用户规模时，建议同时查看“活跃地址中非合约地址占比”、“平均交易间隔”以及“地址存活周期”等辅助指标。如果一个地址在一天内完成超过50笔交易，大概率是机器人或做市商，而非真实用户。

常见误区与复盘

误区一：将活跃地址等同于日活用户（DAU）。链上地址并不等于真实用户——一个用户可能控制多个地址（多账户策略），一个地址也可能被多个用户共享（如交易所热钱包）。
误区二：忽略时间窗口的选择。日活跃地址波动较大，周活跃和月活跃更能反映稳定的用户基础。对于新上线项目，建议同时观察7日移动平均线。
误区三：不区分交易类型。普通转账、合约调用、NFT铸造等不同类型的交易，其背后的用户意图完全不同。将合约调用与普通转账混在一起统计活跃地址，会掩盖协议的真实使用情况。

3.2 新增地址与唯一地址：用户增长的真相

核心原理

新增地址（New Address）指在统计时间窗口内首次出现在链上的地址。其核心判断依据是：该地址在历史数据中从未有过任何交易记录。新增地址是衡量项目“拉新能力”和市场渗透率的关键指标。而唯一地址（Unique Address）则是一个更宽泛的概念，指在特定时间范围内（如项目上线以来）所有出现过的去重地址总数。唯一地址是存量概念，新增地址是流量概念。

需要特别注意的是，新增地址并不等于“新用户”。一个用户可能通过交易所提现到新生成的地址，该地址虽然是链上的“新增地址”，但背后对应的却是老用户。因此，新增地址更适合作为“新资金入场”的代理指标，而非严格的用户增长指标。

判断方法与操作流程

在Dune中计算新增地址的常用方法是：先获取所有地址的首次交易时间，再按天统计首次出现的地址数量。

-- 以太坊每日新增地址
WITH first_tx AS (
  SELECT "from" AS address, MIN(block_time) AS first_seen
  FROM ethereum.transactions
  GROUP BY 1
)
SELECT 
  date_trunc('day', first_seen) AS day,
  COUNT(DISTINCT address) AS new_addresses
FROM first_tx
GROUP BY 1
ORDER BY 1

这里的关键在于MIN(block_time)——它提取了每个地址最早的一笔交易时间。如果某个地址在2023年1月1日首次交易，那么它会被计入当天的“新增地址”中，之后无论该地址多么活跃，都不会再被计为新增。

案例拆解：新地址与真实用户增长的背离

我们曾分析某DeFi协议的用户增长情况。数据显示，该协议的新增地址数在三个月内增长了300%，看似用户规模在快速扩张。但当我们进一步分析这些新增地址的资金来源时发现，超过70%的新增地址在首次交易前24小时内，都从同一个中心化交易所（CEX）地址收到了等额的ETH。这意味着这些地址很可能是同一批用户为了参与该协议的流动性挖矿而批量创建的新钱包，并非真正的新用户涌入。通过将新增地址与“首次交易金额分布”、“资金来源集中度”等维度交叉分析，我们得以还原用户增长的真实质量。

经验提醒：在分析新增地址时，建议同时计算“新增地址的留存率”——即这些地址在首次交易后的第7天、第30天是否仍有交易行为。如果新增地址的30日留存率低于5%，说明项目虽然吸引了大量新地址，但缺乏有效的用户留存机制。

常见误区与复盘

误区一：将唯一地址总数当作“累计用户数”。唯一地址包含大量废弃地址、合约地址和一次性地址，其数值通常远大于真实用户数。
误区二：忽略地址的“首次交易”定义。有些平台将“首次收到资金”作为新增地址的判断标准，而另一些平台则使用“首次发起交易”。对于空投领取场景，用户可能先收到代币（作为接收方），之后再发起交易，两种口径的结果差异巨大。
误区三：不区分EOA地址与合约地址。合约地址在部署时也会产生交易记录，如果将其计入新增地址，会严重高估用户增长。建议在SQL中过滤掉is_contract字段。

3.3 交易笔数、Gas消耗与转账金额：流量质量的三个维度

核心原理

交易笔数（Transaction Count）是链上最直观的流量指标，反映了链上活动的总频次。Gas消耗（Gas Used）则衡量了为执行这些交易而消耗的计算资源总量，其计算公式为：Gas消耗 = GasUsed × GasPrice。Gas消耗越高，说明链上计算越密集，网络越拥堵。转账金额（Transfer Value）指在交易中转移的代币总价值，通常以原生代币（如ETH）或稳定币（如USDC）计价。

这三个指标从不同维度刻画了链上流量的“质量”：交易笔数反映“频次”，Gas消耗反映“复杂度”，转账金额反映“资金规模”。一个健康的链上生态，三者应呈现正相关关系。如果交易笔数激增但Gas消耗和转账金额均未同步增长，则可能存在大量低价值的“垃圾交易”或刷量行为。

判断方法与操作流程

在分析这三个指标时，建议采用“分层聚合”的方法：先按小时粒度计算原始值，再聚合到日/周/月粒度，同时计算均值、中位数和P95分位数，以观察分布特征。

-- 以太坊每日交易笔数、Gas消耗与转账金额
SELECT 
  date_trunc('day', block_time) AS day,
  COUNT(*) AS tx_count,
  SUM(gas_used * gas_price / 1e18) AS total_gas_eth,
  SUM(value / 1e18) AS total_transfer_eth
FROM ethereum.transactions
WHERE block_time >= NOW() - INTERVAL '30 days'
  AND success = true  -- 只统计成功交易
GROUP BY 1
ORDER BY 1

这里将gas_used与gas_price相乘并除以1e18，将结果转换为ETH单位。同时，通过success = true过滤掉失败交易，避免失败交易对Gas消耗的虚高影响。

案例拆解：Gas消耗异常飙升的排查

某公链在2024年3月12日出现Gas消耗异常飙升，日Gas消耗较前7日均值增长了450%。初步排查发现，交易笔数仅增长了30%，但平均GasPrice从20 Gwei飙升至120 Gwei。进一步分析交易详情发现，大量交易在调用同一个NFT铸造合约，且该合约的mint函数存在高Gas消耗的逻辑（如复杂的链上随机数生成）。这导致网络拥堵，普通用户的转账Gas费被迫抬高。通过分析Gas消耗的构成（按合约地址分组），我们快速定位到了导致拥堵的“罪魁祸首”——一个热门的NFT项目。这个案例说明，Gas消耗指标不仅是流量指标，更是网络健康度的“晴雨表”。

  分析要点：当Gas消耗与交易笔数出现背离时，优先检查以下三个维度：① 平均GasPrice是否异常波动；② 是否有特定合约地址消耗了超过30%的Gas；③ 失败交易占比是否上升（失败交易同样消耗Gas但不产生有效状态变更）。

常见误区与复盘

误区一：忽略GasPrice的波动。Gas消耗的短期飙升可能仅仅是因为GasPrice上涨，而非交易量增加。建议同时观察GasUsed（不含价格因素）和GasPrice两个子指标。
误区二：将转账金额与“链上总锁仓量（TVL）”混淆。转账金额是流量概念，TVL是存量概念。一笔1亿美元的转账可能只是交易所内部钱包整理，并不代表新资金流入。
误区三：不区分原生代币与ERC-20代币。上述SQL中的value字段仅统计原生代币（ETH）的转账。如果要统计USDC、USDT等ERC-20代币的转账金额，需要额外解析Transfer事件的日志数据。

3.4 合约调用次数：协议活跃度的核心度量

核心原理

合约调用次数（Contract Call Count）指在特定时间窗口内，智能合约被外部账户（EOA）或其他合约调用的总次数。与普通转账不同，合约调用通常涉及更复杂的业务逻辑，如DEX兑换、借贷、质押等。合约调用次数是衡量一个协议真实使用频率的核心指标，其重要性远高于单纯的转账笔数。

在以太坊中，判断一笔交易是否为合约调用，主要看交易的to地址是否为合约地址。如果to地址是EOA，则为普通转账；如果是合约地址，则为合约调用。此外，合约内部还可以调用其他合约（内部交易），但这类调用通常不体现在交易记录中，需要通过解析trace数据获取。

判断方法与操作流程

在Dune中统计特定协议的合约调用次数，通常需要结合协议地址和函数选择器（Function Selector）进行过滤：

-- 统计Uniswap V3 Router的每日调用次数
SELECT 
  date_trunc('day', block_time) AS day,
  COUNT(*) AS call_count,
  COUNT(DISTINCT "from") AS unique_callers
FROM ethereum.transactions
WHERE "to" = 0xE592427A0AEce92De3Edee1F18E0157C05861564  -- Uniswap V3 Router地址
  AND block_time >= NOW() - INTERVAL '30 days'
  AND success = true
GROUP BY 1
ORDER BY 1

这里通过指定to地址为Uniswap V3 Router合约，统计了所有直接调用该合约的交易。但需要注意，用户也可能通过其他聚合器（如1inch）间接调用Uniswap，这部分调用不会体现在上述SQL中。因此，合约调用次数的统计口径需要明确是“直接调用”还是“包含间接调用”。

案例拆解：通过合约调用次数评估协议真实使用情况

我们曾对比两个借贷协议A和B的链上数据。协议A的日活跃地址为2,000，协议B的日活跃地址为1,500，表面上看A更活跃。但当我们统计合约调用次数时发现，协议A的日合约调用次数仅为3,000次（平均每个活跃地址调用1.5次），而协议B的日合约调用次数高达8,000次（平均每个活跃地址调用5.3次）。进一步分析发现，协议A的大量活跃地址仅进行了“授权”操作（Approval），并未实际借贷；而协议B的地址则频繁进行“存入-借出-还款”等核心操作。这说明协议B的用户参与深度远高于协议A。合约调用次数帮助我们识别了“虚假繁荣”的协议。

经验提醒：在分析合约调用次数时，建议按函数类型进行拆分。例如，将swap、deposit、withdraw等核心函数与approve、transfer等辅助函数分开统计。核心函数的调用次数更能反映协议的真实业务活跃度。

常见误区与复盘

误区一：将合约调用次数与交易笔数等同。一笔交易可能包含多次合约调用（如通过聚合器交易），也可能包含0次合约调用（如普通ETH转账）。
误区二：忽略合约地址的“代理合约”问题。很多协议使用代理合约（Proxy）模式，用户调用的地址是代理合约，而实际执行逻辑的是实现合约。如果只统计实现合约的调用次数，会漏掉大量数据。
误区三：不关注调用失败率。合约调用失败率过高（如超过10%），可能说明协议存在bug或用户体验不佳，需要进一步排查。

3.5 指标联动分析：构建流量质量评估框架

核心原理

单一指标往往具有局限性，将多个指标组合使用可以构建更全面的流量质量评估框架。我们推荐使用“活跃地址-交易笔数-合约调用次数”三维矩阵来评估一个协议的流量质量。具体而言：

高活跃地址 + 高交易笔数 + 高合约调用次数：健康的流量生态，用户参与度高，协议使用频繁。
高活跃地址 + 低交易笔数 + 低合约调用次数：可能存在大量“一次性”用户，或用户仅进行简单的转账操作，协议的核心功能未被充分使用。
低活跃地址 + 高交易笔数 + 高合约调用次数：少数地址（可能是做市商或机器人）贡献了大部分流量，真实用户规模有限。
低活跃地址 + 低交易笔数 + 高合约调用次数：协议被少数重度用户高频使用，可能是专业交易者或机构用户，但缺乏广泛的用户基础。

判断方法与操作流程

在实际分析中，建议按以下步骤操作：

确定分析目标：是评估协议整体健康度、竞品对比，还是监控异常活动？
选择时间窗口：日、周、月粒度分别适用于不同场景。日粒度适合监控异常，周/月粒度适合评估趋势。
计算核心指标：至少计算活跃地址、交易笔数、合约调用次数、Gas消耗四个指标。
计算衍生指标：如“人均交易笔数”（交易笔数/活跃地址）、“人均合约调用次数”（合约调用次数/活跃地址）、“单笔交易Gas消耗”（Gas消耗/交易笔数）。
横向对比：与同类协议、自身历史数据、大盘均值进行对比，识别异常。

案例拆解：多指标联动识别“僵尸协议”

某NFT交易市场在2024年Q1的日活跃地址稳定在3,000左右，交易笔数约5,000笔，看似运营正常。但当我们计算“人均交易笔数”时发现，该指标仅为1.67，远低于行业均值（约3.5）。进一步分析合约调用次数发现，该协议的核心函数buy（购买NFT）的日调用次数仅为200次，而list（挂单）的调用次数高达4,500次。这意味着大量用户仅挂单不购买，市场流动性极差。通过多指标联动分析，我们判断该协议已沦为“僵尸市场”——表面活跃，实际交易深度严重不足。这一结论在后续的TVL和成交量数据中得到了验证。

风险提示：在跨链对比时，不同链的Gas机制和交易模型差异巨大。例如，Solana的低Gas费会导致交易笔数虚高，而以太坊Layer2的批量交易机制会使得交易笔数被低估。跨链对比时，建议使用“活跃地址”和“合约调用次数”作为主要对比指标，而非交易笔数。

常见误区与复盘

误区一：只看单一指标做决策。链上流量分析必须多维度交叉验证，单一指标极易被操纵或误读。
误区二：忽略时间序列的平滑处理。链上数据存在明显的周期性波动（如周末交易量下降），建议使用7日移动平均或同比/环比分析。
误区三：不记录分析口径。在团队协作中，务必记录每个指标的SQL定义、时间窗口和过滤条件，避免因口径不一致导致结论冲突。

通过本章的学习，你应该已经掌握了链上流量核心指标的定义、口径、计算方法和应用场景。在实际分析中，建议从“活跃地址”入手，逐步深入到“合约调用次数”和“Gas消耗”等深层指标，并结合多维度交叉验证，才能得出可靠的分析结论。记住：链上数据是透明的，但解读数据的方式决定了分析的价值。