这篇复盘来自 9 月底一次数据工具改造（素材日期 2026-09-29）。当时我做的小程序「宝可问答助手」增长卡在一个说不清的地方：日新增稳定在 30~55，看起来没断崖，但留存就是上不去。我想用数据把"瓶颈到底在哪"讲清楚，结果发现微信官方根本没有一套现成好用的数据接口——两套接口并存、口径互异、文档 404，逼得我自己搭了一个周报脚本 wxstats。
问题背景：两套接口并存，且是互补关系
微信有两套官方数据接口。一套是后台「数据助手」里的 wedata（接口 wedata_get_data，用 chart_id 拉图表），另一套是老的 datacube（我们 npm run retention 一直在用）。两者是互补关系：
wedata= 核心指标总账，趋势 + 流失/回流/添加，支持区间拉取；datacube= 结构与明细，来源、页面进出、停留时长、用户画像。
但 datacube 的文档页已经 404，不能抄网上的清单，只能打接口实测。最终结论是要两张都接，合成一个 npm run wxstats 才是完整周报。
技术方案：一个归一化的周报脚本
脚本 pokemon-back/scripts/wxstats.ts 默认拉取最近 7 天、截止前天（留存需 T+2），支持 --days/--since/--until/--json，输出八段：核心指标总账、访问来源、新用户引流来源、留存分来源、页面漏斗、设备平台、页面概况、分享量。
接口返回的数字是字符串，留存是小数（"0.3645"），第一步就是显式 Number() 归一化，别把字符串当数字比大小。
踩坑记录：五个解析坑
这五个坑我都写进了脚本注释，下次接手的人不会再犯：
- 取列只能取「第一个命中」。列名
日打开次数也会匹配日打开次数(新用户)，如果继续遍历会被后者覆盖。我实测 09-21 的打开次数被打印成 108，真值是 169——一个不报错但数错的静默 bug。 - 列名跨图不一致。同一件事在
1000102006叫"活跃日留存"，在1000401002叫"活跃用户留存"。取值统一用colLike关键词匹配，失配就告警，而不是静默打印一条"—"。 - 退出率别自己算。官方"页面退出率（访问人数维度）"和自算对不上：首页官方 54.7%，自算 79%，甚至一度算成 89%。直接取官方列，别自己除。
- 留存表是「一天一行 × 场景」，必须跨天聚合，直接罗列会打印一堆同名行。
- datacube 概况返回紧凑日期
20260921（没有斜杠），率类指标返回小数（0.09 就是 9%），解析时要专门处理。
还有两个更隐蔽的雷：
- 返回码
9900030一码两用：既可能是"指标数据全为 0"，也可能是"超过并发限制"。客户端必须带重试，不能一见它就判定无数据。 - 留存数据要 T+2，查询 T+1 会整条失败；
time_unit只支持 0；target_id空表示拉全图。
另外 target_id 语义只在"同一张图内"唯一：1000102006 的 T001 是累计用户数，而 1000301002 的 T001 是打开次数。所以解析必须读 chart_header，禁止硬编码 target_id 的语义。
时段分布：官方没接口，用自建库补
微信两套接口都没有"24 小时时段分布"这张图。我改用自建库 Record.attempts[].ts（每次猜测的真实时刻）来算活跃时段。这里又踩了一个坑：一开始拿 updatedAt 算，得出 22 点占 67% 的假峰，原因是任何批量写入都会刷新它。换成真实游玩时刻 ts 后，主峰落在上午 10 点到下午 2 点，13 点最高，19 点及以后只有 18.9%——和此前推测的"19 点后仅 18%"互相印证。
数据驱动的产出
这套 wxstats 第一次跑出来的结论很能指导行动：搜索贡献了 62% 的新用户；固定场景（任务栏/最近使用）的留存 51%，远高于全站 32.7%，说明"让用户把小程序存进我的小程序"是当前最强的留存杠杆；首页退出率 61% 仍是最大的漏斗口；7 天分享合计仅 77 次，分享裂变不值得做。这些数字直接支撑了后续"首日体验"的前端改造决策——而找到这个方向，正是当初搭这套工具的初衷。
方法论沉淀
做内部数据工具，是 full-stack 工程师很日常但很能见功力的活：接口是别人家的、文档不全、口径漂移，你要做的是把混乱归一化成自己能信任的数据。 four 条经验最值得带走——列名用关键词而非全等匹配、错误码区分后带重试、官方口径优先于自算、日期与数值类型显式归一化。把坑固化进注释，数据工具的价值才真正落地：不止一次性出数，而是任何人接手都能稳定出数。
（项目：宝可猜谜挑战 / 宝可问答助手；相关文章与工具见博客 https://blog.alleria.cn）