用途：把支付与订阅数据转化为可长期复用的收入指标体系，适用于需要 MRR、ARR、毛收入、新增/扩展/收缩/流失、ARPU、LTV 及按客户或 B2B 账户维度统计收入的场景。建议先阅读 modeling-warehouse-foundations，了解视图与 dbt 的取舍、view-* 工作流及 convertCurrency()，本技能是其上的收入专属层。
数据来源：收入可通过两种方式进入 PostHog，二者都汇入同一组托管视图 revenue_analytics_*。一是以支付平台作为数仓源，目前支持 Stripe（Chargebee/Polar/RevenueCat 即将支持）；二是自定义收入事件（如 purchase_completed，带 revenue 属性）。两者都不存在时，可用 suggesting-data-imports 推荐来源。
建模要点：应在托管视图而非原始表上建模，避免从 Stripe 原始表重新推导收入。可查询 system.information_schema.tables 中匹配 %revenue_analytics% 的表名确认名称。核心视图包括 revenue_item（按发票行项目，覆盖毛收入、MRR、按产品/客户/周期的收入，已处理递延收入与币种）、mrr（按客户与订阅的当前快照）、customer、subscription、charge、product。revenue_item 列含 amount（已换算为基础币种）、currency、original_amount/original_currency、is_recurring、customer_id、subscription_id、product_id、group_0_key…group_4_key、timestamp。
注意事项：事件型收入只有在配置了 subscription 属性后 MRR 才有值，MRR 为空而毛收入有值是预期行为；mrr 视图是当前快照而非历史，需要时间序列时应按月对 recurring amount 求和或定期物化快照；amount 已为基础币种，仅在需要其他目标币种或处理原始事件时才用 convertCurrency()；要关联到人或账户，需要 Stripe 客户上的 posthog_person_distinct_id 元数据；不要基于即将退役的 Revenue 仪表盘构建；应排除测试账户。
构建方式：PostHog 中用 HogQL 编写查询并对列取别名，经 view-create 创建、view-get 校验，再对昂贵的月度汇总执行 view-materialize（收入通常用每日 sync_frequency）。dbt 中先暂存计费源，再构建 fct_revenue_item、fct_mrr、dim_customer mart 并配测试；dbt 无 convertCurrency()，需提供汇率种子表。完成后按治理说明注册模型并标注列，若 MRR/ARR 是核心指标可提议加入语义层。
限制：具体价格与收费资料暂未提供；配方文件位于 references/posthog/ 与 references/dbt/，需按需查阅。