modeling-revenue-metrics

収益指標のモデリング

決済／サブスクリプションデータを、長期的に使える収益モデルに変換します。ビューと dbt のどちらを選ぶか、view-* ワークフロー、convertCurrency() については、まず modeling-warehouse-foundations をお読みください。このスキルは、その上に重ねる収益に特化したレイヤーです。指標の定義は references/revenue-metric-definitions.md に、コピーして使えるレシピは references/posthog/ と references/dbt/ にあります。

ステップ 1 — 収益データの所在を確認する

収益データは 2 つの方法で 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 が空で総収益が入力されている状態は想定どおりの動作であり、バグではありません。「修正」するのではなく、その旨を説明してください。
2. 管理ビュー mrr は現在のスナップショットであり、履歴（「現在時点の MRR」）ではありません。時間経過に伴う MRR を求める場合は、レシピを参照して revenue_item の月ごとに定期的な amount を合計するか、スケジュールに従って mrr ビューの月次スナップショットを具体化してください。
3. amount はすでに基準通貨で表されています。 レポートではそのまま使用してください。別の目標通貨が必要な場合や、生イベントを使用する場合に限り、convertCurrency(original_currency, 'XXX', original_amount, timestamp) を呼び出してください。
4. メタデータを使って収益を個人に関連付けてください。 個人／グループ単位の収益には、Stripe の顧客（または個人との結合）に posthog_person_distinct_id メタデータが必要です。これがないと、収益は顧客単位のみになります。
5. Revenue ダッシュボードを基盤にしないでください — 廃止予定です（~2026-06-30）。管理収益ビューと個人／グループ収益プロパティに基づいてモデル化してください。
6. テストアカウントを除外してください。 QA／内部の請求によって収益が水増しされないよう、filter_test_accounts の動作を確認してください。

ステップ 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() がない点に注意してください。レートシードを用意してください。

次に、モデルを登録します（foundations の 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 とセマンティックレイヤーの指標チェック）。