测量栈

这是一个人独立搭建起来的东西，用来为一款小众配送类应用做埋点——每一项都可以在仓库里核实，也可以直接跑一遍工具来验证：

• 两个 GA4 属性（web 486642492，app 493986654），并且严格把两边的数据主张分开，不互相混淆。
• Flutter 应用里 70 多个类型化埋点事件（analytics_service.dart）——覆盖新手引导、鉴权、路线、相机权限授予的阶梯流程、OCR 子步骤、配送结果、推荐相关的钩子（invite_driver、join_community）——在还没有用户可测之前就已经埋好了。
• 失败侧的一层（2026-07 → 09）： AUTO 门只声明一次，埋点由装饰器承担（gate-spec-and-telemetry-decorator）；门超时事件带上检测器自己的判定和 ML Kit 看到了什么（gate-events-carry-the-verdict）；应用发送的每个参数都在同一次改动里注册成 GA4 维度（ga4-schema-completion）。读数据也有自己的规则：先减掉开发者自己的手机和商店的测试机器人（subtract-your-own-phone-and-the-robots）。
• 一套整合过的分析 CLI（tools/ga4.mjs）：一个工具、十三个子命令（dashboard / funnel / churn / ocr / gate / firstrun / activation / versions / paths / attribution / retention / cta / who），默认排除模拟器流量——从一堆零散的一次性脚本重构成了一件真正的仪器。2026-07-10 一次跑通；gate 按应用版本拆分，因为门的条件本身在版本之间变过。
• 竞品情报抓取器（LinkedIn/X，配置驱动，支持多家公司），覆盖 Circuit、Route4Me、OptimoRoute、Routerra 等对手。
• 有分量的分析（funnel-analysis-2026-07-07.txt）：一份完整的从获客到激活的漏斗拆解，其中第 8 节推翻了自己第 7 节的结论——按版本切片后发现，"用户打开相机却不扫描"这一现象大部分其实是旧版 iOS 相机的一个 bug，而不是用户行为本身，文档如实写明了这一点，并改写了自己的结论。文档收尾时把这条方法论定成了规则：在把任何现象归因于用户行为之前，先按 appVersion 切片。一份会自我修正的分析、并且把修正过程原原本本写下来，是这个文件夹里最罕见的东西。

摆在这里要说清楚的一点是：不管增长问题的答案最终是什么（growth），测量从来都不是短板——这里的埋点程度，已经超过了大多数拿到融资的团队实际在做的水平。