modeling-revenue-metrics

收入指标建模

将支付和订阅数据转化为持久可靠的收入模型。请先阅读 modeling-warehouse-foundations，了解视图与 dbt 的选择、view-* 工作流以及 convertCurrency()；本技能是在此基础上针对收入的扩展层。指标定义见 references/revenue-metric-definitions.md；可直接复制粘贴的方案见 references/posthog/ 和 references/dbt/。

第 1 步 — 找到收入数据所在位置

收入数据通过两种方式进入 PostHog；两者都会进入同一组托管收入视图：

• 将支付平台用作数据仓库数据源 — 目前支持 Stripe（即将支持 Chargebee/Polar/RevenueCat）。适用于业务依托计费平台运营的情况。通过 setting-up-a-data-warehouse-source 进行连接。
• 自定义收入事件 — 发送带有收入属性的事件（例如 purchase_completed）。适用于没有受支持的平台，或已在产品中跟踪收入的情况。

如果这两种方式目前都不可用，请使用 suggesting-data-imports 推荐数据源。在 dbt 中，对应的做法是对已载入数据仓库的计费表进行暂存处理。

第 2 步 — 基于托管视图建模，而非原始表

PostHog 会为每个数据源自动生成一组精选视图。不要从原始 Stripe 表重新推导收入——托管视图已经处理了递延收入确认、货币和稳定的架构。

每个数据源都有自己的视图，不存在跨数据源视图。视图名称取决于数据源类型：

• 数仓数据源：<source>.<prefix>.<kind>_revenue_view，例如 stripe.prod.mrr_revenue_view。如果数据源没有前缀，则省略 <prefix>. 部分。
• 自定义收入事件：revenue_analytics.events.<event_name>.<kind>_events_revenue_view，事件名称中的所有非字母数字字符都会替换为 _。

<kind> 是下表中的一种托管视图。请发现准确的名称。不要搜索 revenue_analytics，因为它与数仓数据源视图不匹配：

SELECT table_name FROM system.information_schema.tables
WHERE position(table_name, 'revenue_view') > 0 ORDER BY table_name

如果没有返回结果，则项目尚未配置收入数据源。请检查受治理的 mrr 指标（metric-list），或发现数仓中的计费表，并在建模前读取其列。不要猜测视图名称。

托管视图	粒度	用途
revenue_item（从这里开始）	1 / 发票行项目	总收入、月度经常性收入、按产品／客户／期间划分的收入。处理递延收入 + 货币。
mrr	1 /（客户、订阅）	当前 MRR 的实时快照——不是时间序列。
customer	1 / 客户	dim_customer：电子邮件、国家／地区、群组、元数据。
subscription	1 / 订阅	用于流失／扩张逻辑的订阅状态。
charge	1 / 扣款	原始扣款；除非明确需要扣款数据，否则优先使用 revenue_item。
product	1 / 产品	产品维度。

revenue_item 的关键列：amount（已转换为项目的基础货币）、currency（该基础货币）、original_amount / original_currency（扣款时的金额和货币）、is_recurring、customer_id、subscription_id、product_id、group_0_key…group_4_key（B2B 账户键）、timestamp。

建模前须知（收入陷阱）

1. 没有订阅配置，MRR 就是空的。 对于基于事件的收入，只有在配置了订阅属性后，才会填充 MRR。MRR 为空但总收入有值是预期行为，不是 Bug——应说明这一点，而不是试图“修复”它。
2. 托管视图 mrr 是当前快照，而非历史数据（“当前时刻的 MRR”）。要查看随时间变化的 MRR，可按月汇总 revenue_item 中的经常性 amount（参见配方），或按计划定期对 mrr 视图生成月度快照。
3. amount 已使用基础货币。 报表中可直接使用。只有在需要转换为_其他_目标货币，或处理原始事件时，才调用 convertCurrency(original_currency, 'XXX', original_amount, timestamp)。
4. 通过元数据将收入关联到人员。 要获取个人或群组级收入，需要在 Stripe 客户（或人员关联）上设置 posthog_person_distinct_id 元数据。没有该元数据，收入数据就只能关联到客户级别。
5. 不要基于收入仪表板构建模型——它即将停用（约 2026-06-30）。请基于托管收入视图以及个人／群组收入属性进行建模。
6. 排除测试账户。 确认 filter_test_accounts 的行为，避免 QA／内部费用抬高收入。

步骤 3 — 构建模型

PostHog： 编写 HogQL（为每一列设置别名），执行 view-create，用 view-get 验证，然后对开销较大的月度汇总执行 view-materialize（对于收入数据，通常每日一次的 sync_frequency 就合适）。配方：references/posthog/ — mrr_and_arr.sql、gross_revenue_by_month.sql、revenue_by_customer.sql。

dbt： 对账单来源数据进行分层处理，构建 fct_revenue_item、fct_mrr、dim_customer 数据集市，并添加测试。配方：references/dbt/。注意，dbt 没有 convertCurrency()——请提供汇率种子数据。

然后注册模型（基础知识中的 references/governance.md）：为列添加注释；如果 MRR／ARR 是关键指标，可将其提议纳入语义层。

文件索引

文件	阅读时机
references/revenue-metric-definitions.md	查看精确定义：MRR、ARR、总收入、新增／扩张／收缩／流失、ARPU、LTV。
references/posthog/	查看托管视图的 HogQL 视图配方。
references/dbt/	查看 dbt 分层处理、fct_*／dim_* 数据集市及 schema.yml 测试。

配套内容

modeling-warehouse-foundations（操作机制）、setting-up-a-data-warehouse-source + suggesting-data-imports（导入 Stripe／收入数据）、modeling-dimension-tables（货币／计划维度）、querying-posthog-data（HogQL + 语义层指标检查）。