spending-analysis

要求

• 在 pollinations 仓库根目录运行。
• 安装 jq 和 sops。
• 使用 enter.pollinations.ai/observability/scripts/tb-prod.sh "<sql>" 查询（下文简称 tb-prod.sh）。它会从 SOPS 读取生产环境的读取令牌；预发布工作区没有实际收入。
• 在通过管道传递查询输出前启用 set -o pipefail，以确保查询失败时整个管道都失败。

收入查询必须筛选成功的 Stripe 结账事件，确保异步支付方式只统计一次。

每周套餐收入

tb-prod.sh "SELECT toStartOfWeek(timestamp) AS week, round(sum(amount_cents) / 100, 2) AS revenue_usd, count() AS purchases FROM stripe_event WHERE payment_status = 'paid' AND event_type IN ('checkout.session.completed', 'checkout.session.async_payment_succeeded') AND timestamp >= now() - INTERVAL 90 DAY GROUP BY week ORDER BY week DESC FORMAT JSON" | jq '.data'

最近的套餐购买

tb-prod.sh "SELECT timestamp, user_id, session_id, amount_cents / 100 AS amount, currency, payment_method FROM stripe_event WHERE payment_status = 'paid' AND event_type IN ('checkout.session.completed', 'checkout.session.async_payment_succeeded') ORDER BY timestamp DESC LIMIT 100 FORMAT JSON" | jq '.data'

按客户统计收入

tb-prod.sh "SELECT user_id, round(sum(amount_cents) / 100, 2) AS revenue_usd, count() AS purchases FROM stripe_event WHERE payment_status = 'paid' AND event_type IN ('checkout.session.completed', 'checkout.session.async_payment_succeeded') AND timestamp >= now() - INTERVAL 30 DAY GROUP BY user_id ORDER BY revenue_usd DESC LIMIT 50 FORMAT JSON" | jq '.data'

按余额类别统计每周支出

tb-prod.sh "SELECT toStartOfWeek(start_time) AS week, splitByChar(':', selected_meter_slug)[-1] AS meter_source, sum(total_price) AS total_spend, count() AS requests FROM generation_event_v2 WHERE start_time >= now() - INTERVAL 60 DAY AND environment = 'production' GROUP BY week, meter_source ORDER BY week DESC FORMAT JSON" | jq '.data'

资金来源与支出去向

generation_event_v2 支出（pack_spend、selected_meter_slug）表示消耗了哪个类别的余额，而不是余额的资金来源。Stripe 购买和自动充值会给 pack_balance 充值，但 BYOP 加价和社区模型奖励（记入付款方的余额类别，shared/billing/track-helpers.ts）以及部分任务奖励也会充值。因此，套餐支出 ≠ 现金。仅查看 Stripe 结账行也会遗漏自动充值，因为自动充值不会生成 checkout.session.* 事件。要区分现金与赚取的余额，请分别核对每种来源，不要相加计价基础不同的数字：

• Stripe 结账 pollen_credited（stripe_event，payment_status = 'paid'）
• 自动充值 amount_usd（充值的本金——见下文）
• 历史 Polar 余额（2025 年 11 月至 2026 年 1 月）
• 按类别统计的已领取社区/BYOP 奖励

没有现金购买 ≠ 未付款或滥用；套餐支出 ≠ 现金支付的证明。

自动充值：本金与付款总额

D1 中的自动充值 amount_usd 是充值的 Pollen 本金；Stripe 手续费和税费另计。现金付款总额记录在 Tinybird 的 stripe_event 中，表现为 user_id 为空的 payment_intent.succeeded 行（自动充值在此处不会关联到用户）；对每位用户，通过 stripe_invoice_id 获取发票并使用 amount_paid。本金、付款总额、税费、退款和净收入应分别记录。

历史定价变更

应根据当时部署的代码来定义过去的价格变更，而不是 PR 标题或公告——“便宜 X%”的公告可能与同日抵消这一优惠的乘数变更同时发生。请在 generation_event_v2 中确认计费单价：

tb-prod.sh "SELECT toDate(start_time) AS day, round(avg(total_price), 6) AS avg_unit_price, count() AS requests FROM generation_event_v2 WHERE model_used = '<model>' AND start_time BETWEEN '<before>' AND '<after>' GROUP BY day ORDER BY day FORMAT JSON" | jq '.data'

Provider 成本、priceMultiplier 加价和套餐余额促销会分别变动；请逐一核查。现金支付金额与充值的 Pollen 应分别记录——Pollen 折扣不会改变现金的购买力。说明在你要解释的付款事件发生前，哪些用户受到了影响，以及当时是否发生了其他变更。

转化队列分析

对于“这些用户付费更多”或“X 导致转化”等说法，请先定义比较方式：

• 在查看结果前确定队列。 不要按付款情况或需要付款才能获得的奖励来筛选。贡献类奖励（PR/任务合并）可以纳入；付款触发的奖励不可以。
• 为队列成员资格和付款检查确定统一的截止日期。
• 匹配观察窗口。 最近 7 天的队列有 0–7 天的转化时间；只能与采用相同观察方式的其他队列比较，或使用固定的用户观察窗口（例如“注册后前 7 天”）。
• 检查时间顺序。 对于与奖励相关的队列，统计哪些用户在奖励前付款、哪些在奖励后付款。如果大多数用户先付款，那么奖励并未推动转化。
• 每位用户只统计一次。
• 在报告百分比时注明各组人数和注意事项。

备注

• stripe_event 是礼包购买收入分析的唯一可信来源。
• generation_event_v2 记录的是 Pollen 消耗量，而非现金收入。
• 两个数据集都使用 user_id，因此可以直接联结收入和用量。
• 仪表板的 daily_stripe_revenue 数据管道应用了相同的付费事件筛选条件。
• 对于迁移前的收入历史，请注意 Polar 是 Stripe 之前的登记商户（2025 年 11 月至 2026 年 1 月），目前已停用。未核实截止时间是否存在重叠前，不要合并 Polar 和 Stripe 的历史总额。
• 请求量占比（例如 BYOP 占比）受免费流量影响很大，且变化很快。务必注明日期范围；对于战略性结论，优先使用收入占比（total_price 的占比）。