コモンイベント契約書
これらのクエリを再利用可能に保つフィールド
- timestamp_utc、account_id、event_name、プラン、および通貨
- amount_usd、billable_units、included_units、MRR フィールド、および invoice_id
- payment_attempt、failure_type、acquisition_source、およびコホート
SQL より前の定義
クエリでは決定できないこと
- 1ソース金額を破棄せずに、お金を 1 つの報告通貨に正規化します。
- 2アップグレード、ダウングレード、チャーン、および再アクティベーションを相互に排他的な動きとして定義します。
- 3収益を集計する前にプロバイダー イベントの重複を排除します。
推奨される順序
最初にビルド検出、次に診断
分析パターン
結果で決定を説明する
動きを調和させる
新規、拡大、縮小、チャーン、および再活性化の動きを分類して、MRR の開始と動きの合計が MRR の終了と同じになるようにします。
コホートを観察可能な状態に保つ
各コホートに同じ変換または更新の機会が与えられた後にのみ、取得、計画、サインアップのコホートを比較します。
ソースマネーフィールドを保持する
財務合計を追跡できるように、正規化されたレポート値の横に元の金額と通貨を保存します。
完全なレシピ
クエリをコピーし、仮定を検証します
試用版から有料版への変換を計算する
一定のコンバージョン期間内にどれだけの試用アカウントが有料顧客になったかを測定します。
どのトライアル コホートと取得元が有料アカウントに変換されますか?
SQL と結果を参照してください。支払い失敗時の回復を測定する
失敗した請求書が、その後の支払いの試みによって回復される頻度を計算します。
どの支払い失敗が回復し、どのくらいの収益が依然としてリスクにさらされているのでしょうか?
SQL と結果を参照してください。毎月の経常収益の動きを計算する
新規、拡張、縮小、チャーン、再アクティブ化の MRR を請求ライフサイクル イベントから分離します。
経常収益が毎月増加または減少した原因は何ですか?
SQL と結果を参照してください。純収益および総収益保持率の計算
総保持率から拡大を抑えながら、アカウントレベルの毎月の経常収益スナップショットから NRR と GRR を計算します。
拡張前後で当初の経常収益はどのくらい維持されましたか?
SQL と結果を参照してください。アカウントごとの使用量クォータの消費量を計算する
各アカウントに含まれる月次割り当てに対して請求可能単位を測定し、超過に近づいているアカウントをランク付けします。
今月、含まれている使用量を最も早く消費しているアカウントはどれですか?
SQL と結果を参照してください。しきい値の前にイベント コントラクトを適応させる
分析パターンを維持しますが、テーブル名、フィールド タイプ、ビジネス定義、時間枠、および最小ボリューム ルールを独自のイベントに対して検証します。パブリッシュされたすべてのクエリも計画され、ピン留めされたエンジンを使用して空の型付きテーブルに対して実行されます。