メトリックアーキテクチャ

メトリクスアーキテクチャ

メトリックアーキテクチャは、明確な定義、再現可能な計算、透明なアクセス、組織全体の指標の信頼性の高い操作を提供するルール、アーティファクト、サービスのシステムです。目標は「MAU」、 「Retention D30」、または「ARPPU」がすべてのダッシュボード、実験、レポートで同じと見なされることです。

1）原則

1.数式と参考書のための単一の真実のソース。
2.実装からの意味論の分離：ビジネス定義は、すべてのSQL/ラップトップではなく、意味層に住んでいます。
3.管理履歴の移行を伴うメトリック、スキーマ、数式（v1→v2）のバージョニング。
4.再現性とテスト可能性：計算は決定論的であり、テストによってカバーされます。
5.観測性：新鮮さ、充満、一貫性とドリフト-SLOとアラート。
6.セキュリティとプライバシー：PII最小化、RLS/CLS、監査。
7.オペレーティングシステムをコードとして：定義、変換、ポリシー-CI/CD付きのリポジトリ内。

2）アーキテクチャ層

ソースデータ：イベント/トランザクション、リファレンスブック、モデルログ/infra。
統合とクリーニング：CDC/増分ロード、デダップ、タイムゾーンの統一。
データモデル（DWH）：星/雪片、ゆっくりと変化する測定（SCD）、サロゲートキー。
メトリクスのセマンティック層：均一な定義、集計、フィルタ、タイムグレイン、ロールアップロジック。
設計層：バッチ/microbatch/stream；窓、水痕、鍵。
カタログと辞書：「パスポートメトリクス」、系統、所有者、権利。
アクセスと消費：BI/ダッシュボード、 APIメトリック、アップロード、実験/AB。

3）データおよびメトリクス契約

ソース契約（イベント/テーブル）

スキーマ：フィールド、タイプ、無効、主キー。
SLA：新鮮さ（例えば「、≤ 10分ラグ」）、頻度、最大遅延到着。
品質：キーの一意性、有効な値ドメイン、タイムゾーン、idempotency。
変更点：スキーム進化政策（後方/前方）、偏差計画。

メトリックコントラクト

名前/ID： 'RET_D30_v2'

Domaine/オーナー： Product Analytics

定義（人間の言語で）

数式： SQL/擬似コード+入力ストアフロント/セマンティックオブジェクト

粒度/時間論理： 曜日/週；ポイントインタイムルール、タイムゾーン

デフォルトセグメント/フィルタ

単位と通貨（換算率/日付）

SLO： 鮮度≤ X、精度≥ Y、可用性≥ Z

バージョン/変更履歴/発効日

ガードレール： 有効範囲、Winzorizationルールp1/p99

4）指標のセマンティック層

• 要素：寸法（日付、国、プラットフォーム）、事実（イベント、収益）、指標（ARPU、保持D30）、計算フィールド、カレンダー（仕事/週末、休日）。
• 時間の挙動：カレンダーテーブル、ラグ、コホート、「スライド」ウィンドウ（7/30/90）。
• ロールアップと整合性：日単位=月、二重カウント（別個のユーザー）を除く。
• ミックス調整：正直なYoYのためのチャネル/国の一定のミックスへの正規化。
• マルチカレンシー/タイムゾーン：取引日に基準通貨に調整されます。ローカルと「正規」UTCスライス。

5）計算： バッチ、マイクロバッチ、ストリーム

バッチ：夜間/時間ジョブ、フル/インクリメンタル再計算、idempotencyコントロール。
Microbatch：操作ダッシュボードのウィンドウ1〜15分。
ストリーム：タイヤを介したイベント；ウィンドウ（タンブリング/スライド/セッション）、ウォーターマーク（後半データ）、正確に1回のセマンティクス（デッドロック+オフセットストア）。

• 'HOP 5m、 WINDOW 1h'は運用KPIのために。
• 'TUMBLE 1d'は毎日の指標のために。
• セッションのための'SESSION 30m'。

6）品質と検証可能性

データテスト：回路図、ドメイン（範囲）、参照リンク。
メトリクスのテスト：不変量（DAU ≤ MAU）、空でないセグメント、単調（累積）の期待。
和解：セマンティックレイヤーとリファレンスレポート/会計の間。
データの健康：新鮮さ、完全性、重複、NULL分数、異常ジャンプ。
ドリフトメトリクス：PSI/KL/JS、特にMLメトリクスの主な機能。

7）バージョン管理と移行

式のバージョンは'METRIC_NAME_vN'です。バージョンを変更せずに定義を「静かに」変更することは禁止されています。

• 横に並べて：v1とv2は並列にカウントされます。ユーザーの和解とトレーニングが行われます。
• カットオーバー：低負荷ウィンドウで消費者をv2に切り替えます。アーカイブv1。
• 履歴の再計算：履歴データに従ってバックフィル；差分プロトコル（差分レポート）
• コミュニケーション：changelog、エントリの日付、影響を受ける人、指示。

8）メトリックのデータモデル

事実：穀物（event_id、 transaction_id、 user_day)、イベント時間、合計/値。
次元：ユーザー、装置、地理、チャネル、プロダクト、カレンダー；歴史性のためのSCDタイプ。
キー：代理ID、安定したビジネスキー、マッピングテーブル。
重複防止：IDルール（ユーザーのマージ）、セッション「接着」ウィンドウ。

9）単位、通貨、季節性

単位/形式：明示的な単位、丸め、尺度（log/linear）。
多通貨：取引日の為替レートでの変換。「生」と「正規化された量」の両方を保存します。
季節性：YoYと季節指数；別々の「休日」効果。

10）セキュリティとアクセス

行レベルのセキュリティ（RLS）：国/ブランド/パートナー別の指標へのアクセス。
Column-Level Security （CLS）-PII/金融分野のマスキング。
監査：誰がメトリックを要求しましたか、フィルターします。、データをエクスポートしました。
APIの差別化：「役割ごとに集計」と「詳細なアップロード」。

11）観察可能性およびSLO

SLOの新鮮さ：例えば、「動作KPI-遅延≤ 15分、毎日-06：00現地時間まで」。
空室状況SLO： ≥ 99。API/セマンティックレイヤーの9％。
アラート：SLO非行、メトリックジャンプ、NULL/重複成長、分散v1 vs v2> X％。
Runbooks：劣化したときに何をすべきか-RCAステップ、フォールバック（たとえば、最後に有効な「スナップショットメトリック」に切り替えます）。

12）実験と指標

ガードレールのメトリクス：レイテンシ、回復力、スコアリングのためのFPR/FNR。
A/Bのユニフォーム定義：変換、保持、NSM-同じセマンティックレイヤーを介して。
最小識別可能効果（MDE）、電力分析：メトリックカードにパラメータを保存します。
因果アトリビューション：ミックス調整とコントロールグループによるポリシー。

13） APIの指標と消費

'GET/metrics/{ name}？ from=2025-09-01&to=2025-10-01&dims=country、 platform&filters=channel： paid'。
ポリシー：制限、キャッシュ、ページネーション、idempotent「エクスポート」。
バージョン：'X-Metric-Version： v2'ヘッダー、非推奨の警告。

14）パターンとアーティファクト

メトリックパスポート（例）

コード/バージョン： 'ARPPU_v3'

定義： 期間の支払うユーザーあたりの平均収益

Формула： 'sum （revenue_net）/count_distinct （user_id paying_flag=1）'

粒度： 日；ロールアップ：週/月=分子の合計/分母の合計

ソース： 'fact_payments_v2'、 'dim_users_scd'

単位： 通貨'base_ccy'；現在の為替レートでの変換

デフォルトのフィルタ： アクティブなマーケット、テストトランザクションを除外

SLO： 鮮度≤ 1時間；API ≥ 99の可用性。9%

ガードレール： ARPPU ∈ ［0；10 000];vinzorization p1/p99

所有者： 収益化アナリティクス；リビジョンの日付：2025-10-01

チェックリストメトリックリリース

• テストで覆われた、合意された定義と式
• 作成されたセマンティックオブジェクト；文書化された系統
• バックフィルと参照が完了しました
• SLO/アラートが設定されています。runbookの準備完了
• 設定された権利とRLS；PII隠された
• ダッシュボード/実験で置き換えられた古いバージョン
• changelog/コミュニケーション送信

ポイントインタイムSQL擬似コード（Retention D30例）

sql
WITH cohort AS (
SELECT user_id, MIN(event_date) AS signup_date
FROM fact_events
WHERE event_type = 'signup'
GROUP BY 1
),
activity AS (
SELECT user_id, event_date
FROM fact_events
WHERE event_type = 'app_open'
),
ret AS (
SELECT c. signup_date,
COUNT(DISTINCT CASE WHEN a. event_date = c. signup_date + INTERVAL '30 day' THEN a. user_id END) AS returned,
COUNT(DISTINCT c. user_id) AS cohort_size
FROM cohort c
LEFT JOIN activity a
ON a. user_id = c. user_id
AND a. event_date BETWEEN c. signup_date AND c. signup_date + INTERVAL '30 day'
GROUP BY 1
)
SELECT signup_date, returned / cohort_size AS retention_d30
FROM ret;

15）頻繁な間違いとそれらを回避する方法

静かな数式の編集：常にバージョンと変更履歴を介して。
「すべてのラップトップで異なる」メトリック：セマンティックレイヤー/APIを強制します。
一貫性のないタイムゾーン/通貨：集中カレンダーとFXテーブル。
ダブルユーザー会計：ロールアップルールとユニークなキー。
不透明な新鮮さ：明らかに遅れ/更新時間を示します。
1つのエンジニアへの依存：すべてがコードのようなもので、レビューとオンコールがあります。

合計

メトリックアーキテクチャは、辞書+セマンティックレイヤ+堅牢な計算+ガバナンスとSLOです。記載されている原則（契約、テスト、バージョン、観測可能性、安全性）に従うことで、「数値紛争」からの指標を持続可能な製品およびビジネス管理メカニズムに変えます。