DEX 新用户数据暴涨，往往是项目方和社区最兴奋的时刻。但这里有一个容易被忽略的陷阱：DEX 聚合器会把一笔用户交易拆分成多笔底层交易，如果你用"原始交易笔数"或"交互地址计数"来统计，一个真实用户很容易被数成三四个"新用户"。
先排除聚合器造成的重复计数，再判断增长是否真实。以下是 3 个步骤。
步骤 1：理解"聚合器一笔交易"和"底层多笔交易"的区别
DEX 聚合器的核心作用是帮助用户找到最优价格。为了实现这一点，它会把用户的一笔兑换请求拆成多笔在不同 DEX 上的交易。Dune 在官方文档中直接说明了这个区别：dex_aggregator.trades 表将用户的原始交易浓缩为一条记录，而 dex.trades 表则记录了这笔交易拆分后的每一个中间步骤。
做什么： 在查看 DEX 用户数据之前，先确认数据源是"用户级"还是"交易级"。
怎么做：
如果在 Dune 或类似平台上查询，优先使用
dex_aggregator.trades表，而不是dex.trades表。dex_aggregator.trades表的设计目的就是把聚合器交易压缩回用户视角。如果手头的数据源只有底层交易记录，需要手动按
tx_hash和tx_from（交易发起者地址）去重。同一个用户在同一个交易哈希里发起的多笔子交易，只能算作 1 笔用户交易。
做到什么程度算完成： 你确认了自己在看的"新增用户"数据，是基于"用户意图交易"统计的，而不是基于"底层子交易"统计的。
常见失败原因： 直接把 DEX 的"独立交易地址数"当作"独立用户数"。聚合器路由模式下，用户只签了一笔交易，但底层可能产生了三四笔交互，如果按"交易地址数"统计，同一个用户会被重复计数。
步骤 2：用"实体聚合"功能或 SQL 去重
即使使用了 dex_aggregator.trades 表，如果一个用户在同一天通过同一个聚合器做了两笔不同方向的交易，在"新地址"统计里他仍然会出现两次。需要按地址去重，才算真正的"新用户"。
做什么： 在统计"新增用户"时，按钱包地址分组取首次交互时间，而不是按交易笔数计数。
怎么做：
如果使用 Dune SQL，可以用
MIN(block_time)按wallet_address分组，找出每个地址的第一次交互时间。只有首次交互时间在统计周期内的地址，才计入"新用户"。使用支持"实体识别"的数据源（如 Nansen、Arkham 等地址标签系统）。这些系统能识别出同一个人控制的多个钱包，进一步避免"一人多号"造成的重复计数。聚合器本身也在向"看懂交易背后的人"这个方向发展——aPriori 的订单流识别系统就包含"钱包聚类"功能，用于判断哪些地址属于同一个操作实体。
做到什么程度算完成： 你统计出的"新用户"数量，已经是按钱包地址去重后的唯一地址数。如果有条件，再做了实体层面的合并。
风险提醒： 如果一个项目或协议的"新用户"数据在去掉聚合器重复计数后出现明显下滑，说明它的增长可能更多依赖聚合器的流量分发，而非用户主动发现和认可。聚合器的流量是可以被集成的——Stabull 的案例显示，聚合器集成后用户甚至不会知道自己用了哪个协议。
步骤 3：交叉验证"交易量"和"用户数"的比例
这是一个快速验证方法：如果"用户数"大幅增长，但"总交易量"或"平均单用户交易量"没有相应增长，说明"新用户"的含金量可能不高。
做什么： 计算"交易量 / 用户数"这个比值，看它的变化趋势。
怎么做：
情况A（健康增长）：新用户数上升，同时"交易量 / 用户数"保持稳定或上升。说明新用户是真实参与交易的，不是被聚合器路由"刷"出来的影子地址。
情况B（可疑增长）：新用户数暴涨，但"交易量 / 用户数"明显下降。可能意味着大量新地址只做了极小额的测试交易，这类"用户"往往来自空投刷量或脚本活动。
OKX DEX 的 Boost 产品在设计上做了一个区分：为了"防止刷量套利"，他们给不同交易对设置了不同的交易量倍数——稳定币对稳定币的交易只有 0.1 倍，而主流币对其他代币是 0.5 倍。这个逻辑说明，协议方本身也在防范把"低价值的兑换"当成真实活跃度来统计。
做到什么程度算完成： 你计算了去重后的新用户数和总交易量的比值，判断出当前的增长是"有质量的增长"还是"被放大后的假象"。
如何确认操作正确？
完成以上三步后，回答这三个问题：
你的数据源是否已经排除了聚合器的底层子交易？ （用了
dex_aggregator.trades还是dex.trades？）新地址是否经过了"按钱包地址去重"？ 同一个用户的多次交互只算 1 次了吗？
新用户数和交易量的比例是否合理？ 新增用户越多，平均交易量反而越低，这是一个危险信号。
如果三个问题都过关——数据源正确、地址已去重、比例合理——那看到的"新用户暴涨"大概率是真的。如果任何一个环节有问题，这个"暴涨"可能只是聚合器路由产生的数据泡沫。
