surendrapandar/minilytics

如果你运营自己的网站，最想知道的是“哪个流量来源真的付了钱”，而不是“今天有多少访问”，Minilytics 值得花时间看看。它是一个自托管、跑在 Cloudflare 上的分析系统，把访问、目标和 Dodo Payments 交易记录放在同一处。

解决什么问题

多数轻量分析面板只回答流量问题：你能看到一条发布推文带来 400 个访客，却不知道其中有没有人真正购买。要回答这个问题，独立开发者通常得把网站分析工具、支付后台和一张电子表格拼在一起，再靠时间戳或客户邮箱手动匹配。Minilytics 改变的是这一步：它把访客和会话标识与支付 webhook 存在一起，从而在面板里按渠道、活动甚至单个客户旅程展示收入。最终你得到的是一个统一视图，推文、文章或来自 ChatGPT 的引荐各自带着自己的收入数字。

有什么不同

核心机制是一对第一方 cookie（ml_vid 和 ml_sid），由 9 KB 的追踪脚本写在你的根域上。Dodo Payments 的 webhook 在服务端记录，应用按文档写明的优先级把每笔支付归到之前的某次访问：最后非直接来源优先，然后是结账返回页（?payment_id=）、同一客户的更早支付、通过 identify() 传入的邮箱，最后才是“过去 3 小时内恰好只有一个访客点击了 Dodo 结账链接”的结账时间匹配。这个顺序有意义，因为最简单的归因信号——直接回访——被有意限制，不能覆盖最初的来源。README 也明确说明退款会从收入中扣除，并且每笔支付的匹配方式会显示在 Journey 标签页里，让归因决定可以被检查，而不是藏在黑盒里。重要的取舍是：它不是通用归因引擎，文档中深度集成的是 Dodo Payments；其他支付提供商需要向通用支付 API 提交访客 cookie，而且只有 Dodo 提供以网站币种结算的金额时才会做币种换算。

谁值得试

合适的用户是通过 Dodo Payments 收款的独立开发者，正在用内容或社交发布做推广，并且愿意部署一个 Cloudflare Worker。他们能拿到来源级别的收入归因和 Journey 视图，而不必按事件量向 SaaS 付费。不合适的是需要开箱即用支持多家支付渠道归因的团队，或者合规和营销技术栈要求使用有成熟集成目录的托管厂商的团队。文档给出的安装方式是完整的自部署：克隆仓库、创建 D1 数据库、设置管理密码和会话密钥，再用 Wrangler 部署。README 还提到一个“Copy AI prompt”按钮，让 Claude Code 或 Cursor 在你的代码库里帮你装站点脚本；这降低了追踪脚本本身的集成工作量，但 Cloudflare 部署那部分并没有省掉。

使用条件与边界

最重要的限制在运维层面。你需要 Cloudflare 账号、Node.js 20+ 和 Git，并自行维护数据库和部署；更新时要先把改过 wrangler.jsonc 的改动 stash 起来，拉取后再恢复并重新部署。免费计划的文档限制大致是每天 10 万次 Worker 请求、每天约 1 万次页面浏览对应的 D1 写入、每月 1 万访客时每天几百次面板加载，以及 5 GB 的 D1 存储；README 说副业项目流量只会用掉几个百分点，超出后 Cloudflare Workers Paid 是每月 5 美元。准确性方面文档列出了几个缺口：广告拦截器可能挡住脚本，Safari 对 JavaScript 设置的 cookie 最多保留 7 天，因此超过一周的回访会被算作新访客，机器人靠 user agent 和 navigator.webdriver 过滤，X、Medium、LinkedIn 会隐藏具体帖子，所以想看到单条推文或文章带来的访问必须给链接打标记。即使用户浏览器屏蔽了脚本，支付仍会通过 webhook 记录下来。

HotRepo 点评

HotRepo 目前只有一次带日期的记录：2026-10-25 在 TypeScript 新项目榜上看到 135 个总 star、第 9 名。这不是单日增长数据，也没有可比的每日榜单历史，因此还无法判断热度能否持续。README 对归因顺序和准确性缺口的说明相当具体，这是采用前最该查看的地方：确认你的支付流程确实在支付服务商期望的位置带上了访客 cookie，因为元数据缺失时，那套兜底匹配顺序会真正影响结果。

项目源码与说明