开源工具最容易定错价：第一批用户愿意买 license，作者就把长期维护、托管 API、邮件支持和企业需求都压进一个一次性价格里。半年后问题才出现：GitHub star 涨了，边际成本也涨了，但老客户没有续费路径。
Polar 用量计费的价值不是「多一个收款按钮」。它逼你把产品拆成 4 类收入：固定订阅、按事件计费、预付 credits、平台外服务。拆完以后，哪些能进 MoR，哪些不该进 MoR，会比价格数字更清楚。
Polar 用量计费到底由哪 4 个零件组成？
Polar usage-based billing 的链路很短：你的应用发送 events，meter 过滤并聚合这些 events，subscription product 里的 metered price 按 meter 计费，credits 先抵扣客户的可用额度。
| 零件 | 在产品设计里的含义 | 典型例子 | 设计风险 |
|---|---|---|---|
| Event | 应用产生的原始用量记录 | api_call、build_finished、image_generated | 事件名太细，月底无法对账 |
| Meter | 过滤和聚合规则 | 只统计 status=success 的构建次数 | 聚合方式选错，收费口径变形 |
| Metered price | 绑定 meter 的订阅价格 | 每 1,000 次 API 调用 $X | 和固定订阅价职责混在一起 |
| Credits | 客户先消耗的额度 | Pro 每月 10,000 credits | 余额、overage、退款解释不清 |
这里最关键的是顺序。不要先问「每次调用收多少钱」，问「哪类事件代表客户真正消耗了我的成本」。如果事件定义错，后面的 meter、price、credits 都会一起错。
哪些收入按 seat 收，哪些按 event/meter 收？
开源项目做 SaaS 化时，固定订阅价应该承载「账户和权限」，metered price 承载「资源消耗」。两者不要互相替代。
| 收入项 | 推荐计费方式 | 为什么 |
|---|---|---|
| 个人 Pro 账户 | 固定月费或年费 | 账户、同步、基础支持成本稳定 |
| 团队 seat | 按 seat 固定订阅 | 权限、审计、团队成员数容易理解 |
| API 调用 | Event + meter + metered price | 成本随调用量线性增长 |
| AI 生成次数 | Credits + meter | 用户更愿意看额度，不愿意看 token |
| 构建分钟数 | Metered price | CI、容器和队列成本随时长增长 |
| 私有项目数 | 固定阶梯或 seat 附带 | 不一定每个项目都产生成本 |
| 企业 SSO | 固定 add-on | 价值来自权限和合规，不是事件量 |
| 顾问实施 | Polar 外合同 | 属于 human services，不能当普通数字商品塞入 MoR |
一个可执行的定价草图是：Starter $9/月，含 1 seat 和 1,000 credits；Team $29/月，含 3 seats 和 10,000 credits；超出 credits 后按 meter 计算 overage。这样客户买的是订阅关系，平台成本由用量补回来。
meter 事件要怎么定义才不坑自己？
Polar meters 文档里的重点是两个动作：filter 和 aggregate。filter 决定哪些 events 进入 meter，aggregate 决定这些 events 怎样变成一个数字。
过滤条件可以用事件字段和 metadata 字段；metadata 字段可以直接引用，不需要加 metadata. 前缀。操作符包括 equals、not equals、大于、小于、contains 等，多个条件可以用 and 或 or 组合。
聚合方式包括 Count、Sum、Average、Minimum、Maximum、Unique。单位只影响展示，不改变计费数学；scalar、token、自定义单位都只是让客户看懂账单。
| 产品事件 | filter 示例 | aggregation | 适合的前台单位 |
|---|---|---|---|
| API 请求 | event=api_call 且 status=success | Count | requests |
| LLM 消耗 | event=model_call 且 plan=pro | Sum tokens | credits 或 tokens |
| 图片生成 | event=image_generated 且 quality=hd | Count | images |
| 构建任务 | event=build_finished | Sum duration_seconds | build minutes |
| 团队活跃用户 | event=member_active | Unique user_id | active users |
生产前最好保留一张内部 usage ledger。Polar 的 meter 是账单入口，不是你唯一的审计流水。客户质疑「为什么多收 37 次」时，你要能回到原始 event id、内部用户 id、请求时间和业务动作。
credits 适合解决什么定价心理？
credits 不是优惠券，它更像「预付用量账户」。Polar credits 文档说明，订阅 offer 可以在每个 billing cycle 开始发放 units；一次性 offer 则在购买时发放一次。客户使用时先扣 credits，余额为零后，继续使用会变成 billable overage。
credits 适合 3 类产品：AI 生成工具、开发者 API、批处理任务。它们的共同点是客户不想每次看到费用跳动，但作者又不能无限包量。
| 方案 | 客户感受 | 作者风险 | 适合场景 |
|---|---|---|---|
| 纯固定订阅 | 简单 | 重度用户吃掉毛利 | 成本极低的工具 |
| 纯按量计费 | 公平 | 新用户害怕账单失控 | 成熟 API 平台 |
| 订阅 + credits | 可预期 | 要设计 overage 文案 | AI SaaS、构建工具 |
| credits-only | 像充值包 | 收入不够稳定 | 插件、短期任务、低频使用 |
如果你只想让客户消耗 credits，不想触发 meter billing，Polar 文档也给了限制：不要创建对应的 Metered price。这个细节对「预付包」很重要，否则客户可能既买了 credits，又在超额后被自动计费。
MoR acceptable use 会怎样反推产品限制？
Polar 是 Merchant of Record，但 MoR 不等于什么都能卖。acceptable use 文档允许的方向集中在 Software & SaaS、数字产品、模板、代码、字体、设计资产、课程、订阅内容，以及通过 license key、下载、邀请、私有链接或 API 交付的数字访问。
不该放进 Polar 的类别也很清楚：physical goods、human services/consulting、marketplaces、adult content and services 等都在禁止或高风险范围内。文档还保留了平台自行拒绝产品的权利。
把这条规则翻译成产品设计语言，就是：
- 开源项目的付费 license、SaaS 订阅、API access，可以考虑 Polar。
- 模板、代码包、私有 GitHub access，可以考虑 Polar。
- 纯捐赠、众筹、赞助位和社区会费，不要当成软件订阅混进 MoR。
- 企业顾问、定制开发、上线实施、小时费，不要包装成「订阅权益」硬塞进去。
- 帮别人卖插件、主题、数据包并抽佣，已经接近 marketplace，先别用 Polar 当分账系统。
- 实体周边、硬件、线下课程和人工交付，不属于这个工具最舒服的限制。
这个限制会影响你的官网文案。不要把 Team plan 写成「每月 5 小时专家顾问」。更干净的写法是「Team plan 包含团队权限、私有项目、API credits 和优先邮件支持」；真正的实施服务另签合同。
多价格和多 items 对订阅设计有什么影响？
Polar API changelog 在 2025-03-14 提到，schema 调整是为了 usage-based billing 和 one subscription/order with multiple prices/items 做准备。旧的单一 price 字段逐步让位给 Subscription.prices，订单侧则使用 Order.items；金额字段也从单一 Order.amount 变成 net、subtotal、discount、total 等更细的结构。
这对开源 SaaS 很实际：一个订阅不再只能表达「Pro $19/月」。它可以更像一张账单：基础订阅价、seat、metered usage、discount、税费和总额分开出现。
| 账单组成 | 建议放在哪里 | 对账字段思路 |
|---|---|---|
| Pro 基础订阅 | subscription fixed price | plan、price id、周期 |
| Team seat | subscription price 或内部 seat 表 | seat 数、成员变更时间 |
| API overage | metered price | meter id、period usage |
| Credits grant | credits offer | grant amount、cycle start |
| 折扣 | discount amount | campaign、coupon、有效期 |
| 税费与总额 | order totals | net、subtotal、discount、total |
后台表结构也要跟着改。不要只在 subscriptions 表里存一个 price_id。至少预留 subscription items、order items、meter id、credit balance 和 period usage。等客户从 Starter 升 Team、加 seat、超 credits 后，你会感谢这次预留。
后台、银行、税务账号环境怎么管？
用量计费上线后，后台不只一个 Polar。你还会同时打开 GitHub、Cloudflare、数据库、银行、会计软件和客服邮箱。出问题时，最怕多人在不同设备改 price、meter、webhook、payout 材料，最后没人说得清哪次改动影响了账单。
如果团队分布在不同城市，建议把 Polar、银行、税务和部署后台纳入同一套登录规范：固定负责人、固定设备、固定 2FA、变更记录、月度导出。核心财务与产品后台可以用海外银行 + Stripe + AI 工具全场景承载，减少后台安全提醒和登录环境漂移带来的追查成本。
这不是技术洁癖。用量计费的事故通常不是「少写一行代码」，而是产品、财务和客服看到的数字不一致。登录环境稳定、变更记录完整，才能把事故从「猜」变成「查」。
第一版上线清单怎么排？
第一版不要追求 Paddle、Stripe Billing 那种复杂度。Polar 适合开发者产品快速开卖，复杂度应该按客户需求增长。
| 阶段 | 只做什么 | 暂时不做什么 |
|---|---|---|
| v0 | 一个固定订阅价 + 一个核心 meter | 多地区价格、复杂阶梯 |
| v1 | 每周期 credits + overage 文案 | 企业采购、PO、定制发票 |
| v2 | 客户用量页 + 内部 usage ledger | 自动迁移所有老 license |
| v3 | seat、团队权限、发票导出 | marketplace 分账 |
| v4 | 企业合同外置 | 把咨询服务伪装成 SaaS |
上线前跑 6 个测试订单：新订阅、取消、续费失败、credits 用完、overage、退款。每个订单都要能在内部 ledger、Polar 账单、客户页面和会计材料里对上。
最后再检查 MoR 限制。只要收入来自软件访问、license、数字下载和 API，Polar 很可能是轻量路径；只要收入来自人、实体、撮合交易或代卖别人产品，就该从 Polar 设计图里拿掉。