Architektur der Metriken

Die Metrik-Architektur ist ein System von Regeln, Artefakten und Diensten, die eindeutige Definitionen, reproduzierbare Berechnungen, transparenten Zugriff und zuverlässigen Betrieb von Metriken in der gesamten Organisation ermöglichen. Das Ziel ist, dass „MAU“, „Retention D30“ oder „ARPPU“ in allen Dashboards, Experimenten und Berichten gleich behandelt werden.

1) Grundsätze

1. Eine einzige Quelle der Wahrheit (Single Source of Truth) für Formeln und Nachschlagewerke.
2. Semantik von der Implementierung trennen: Die Geschäftsdefinition lebt in der semantischen Ebene und nicht in jedem SQL/Laptop.
3. Versionierung von Metriken, Schemata und Formeln (v1→v2) mit kontrollierter Geschichtsmigration.
4. Reproduzierbarkeit und Testbarkeit: Berechnungen sind deterministisch, werden durch Tests abgedeckt.
5. Beobachtbarkeit: Frische, Fülle, Konsistenz und Drift - mit SLO und Alert.
6. Sicherheit und Privatsphäre: Minimierung von PII, RLS/CLS, Audit.
7. Betriebssystem als Code: Definitionen, Transformationen, Richtlinien - im Repository mit CI/CD.

2) Schichten der Architektur

Quelldaten: Ereignisse/Transaktionen, Verzeichnisse, Modellprotokolle/Infra.
Integration und Bereinigung: CDC/inkrementelles Laden, Dedup, Vereinheitlichung von Zeitzonen.
Datenmodell (DWH): Stern/Schneeflocke, langsam wechselnde Messungen (SCD), Ersatzschlüssel.
Die semantische Schicht der Metriken: einheitliche Definitionen, Aggregationen, Filter, Zeitgrain, Rollup-Logik.
Berechnungsschicht: Batch/Microbatch/Stream; Fenster, Wasserzeichen, Dedup durch Schlüssel.
Verzeichnis und Wörterbuch: „Passport Metrics“, Lineage, Besitzer, Rechte.
Zugang und Verbrauch: BI/Dashboards, API-Metriken, Uploads, Experimente/AV.

3) Daten- und Metrikverträge

Quellvertrag (Ereignisse/Tabellen)

Schema: Felder, Typen, Nullwert, Primärschlüssel.
SLA: Frische (z.B. „≤10 Minuten lag“), Häufigkeit, maximale verspätete Ankunft.
Qualität: Eindeutigkeit des Schlüssels, gültige Wertedomänen, Timezone, Idempotenz.
Änderungen: Schema-Evolutionspolitik (backward/forward), deprecation-plan.

Metrikvertrag

Name/Code: „RET _ D30 _ v2“

Domaine/Eigentümer: Product Analytics

Definition (menschliche Sprache)

Formel: SQL/Pseudocode + Eingabevitrinen/semantische Objekte

Granularität/Zeitlogik: Tag/Woche; Point-in-Time-Regeln, Timezone

Standardsegmente/Filter

Einheiten und Währungen (Umrechnungskurs/Datum)

SLO: Frische ≤ X, Genauigkeit ≥ Y, Verfügbarkeit ≥ Z

Version/Änderungshistorie/Einstiegsdatum

Guardrails: zulässige Bereiche, p1/p99 Winzorisierungsregeln

4) Semantische Schicht von Metriken

Die Aufgabe der Schicht besteht darin, die Definitionen und Aggregationsregeln zentral zu speichern:

Elemente: Dimensionen (Datum, Land, Plattform), Fakten (Ereignisse, Revenue), Metriken (ARPU, Retention D30), berechnete Felder, Kalender (Sklave/Wochenende, Feiertage).
Zeitverhalten: Kalendertabellen, Lags, Kohorten, „gleitende“ Fenster (7/30/90).
Rollup und Konsistenz: Summe nach Tagen = Monat, während doppelte Buchführung (distinct users) ausgeschlossen ist.
Mix-Anpassung: Normalisierung unter einem konstanten Mix von Kanälen/Ländern für ein ehrliches YoY.
Multi-Währung/Zeitzone: Rückführung auf die Basiswährung am Transaktionsdatum; lokale und „kanonische“ UTC-Abschnitte.

5) Berechnung: Batch, Microbatch, Stream

Batch: Nacht-/Stundenjobs, vollständige/inkrementelle Neuberechnungen, Idempotenzkontrolle.
Microbatch: Fenster 1-15 Minuten für operative Dashboards.
Stream: Ereignisse über den Bus; Fenster (Tumbling/Sliding/Session), Wasserzeichen (Late Data), exactly-once Semantik (Dedup durch Schlüssel + Offset-Speicher).

Fenstermuster:

„HOP 5m, WINDOW 1h“ für betriebliche KPI;
„TUMBLE 1d“ für Tagesmetriken;
„SESSION 30m“ für Sitzungen.

6) Qualität und Überprüfbarkeit

Datentests: schematisch, Domäne (Bereiche), Referenzbeziehungen.
Metriktests: Invarianten (DAU≤MAU), nicht leere Segmente, Monotonie-Erwartungen (kumulativ).
Überleitungen (Reconciliation): zwischen semantischer Schicht und Referenzberichten/Buchhaltung.
Datengesundheit: Frische, Vollständigkeit, Duplikate, NULL-Anteil, abnormale Sprünge.
Drift-Metriken: PSI/KL/JS auf Schlüssel-Fics, insbesondere für ML-Metriken.

7) Versionierung und Migration

Version der Formel: 'METRIC _ NAME _ vN'. Es ist verboten, die Definition „leise“ zu ändern, ohne die Version zu ändern.

Migrationsstrategien:

Side-by-side: v1 und v2 werden parallel gezählt; Abstimmung und Schulung der Nutzer.
Cut-over: Schalten der Verbraucher auf v2 im Low-Load-Fenster; Archiv v1.
Neuberechnung der Geschichte: Backfill nach historischen Daten; Differenzprotokoll (Diff-Report).
Mitteilungen: Changelog, Eintrittsdatum, Betroffene, Anweisungen.

8) Datenmodell für Metriken

Fakten: Korn (event_id, transaction_id, user_day), Ereigniszeit, Summe/Größen.
Maße: Benutzer, Gerät, Geographie, Kanal, Produkt, Kalender; SCD-Typ für Historizität.
Schlüssel: Surrogat-IDs, stabile Geschäftsschlüssel, Korrespondenztabellen (Mapping).
Anti-Takes: Identitätsregeln (User Merge), Fenster zum „Kleben“ von Sitzungen.

9) Einheiten, Währungen, Saisonalität

Einheiten/Format: explizite Maßeinheiten, Rundungen, Skalen (log/linear).
Multiwährung: Umrechnung zum Kurs am Datum der Transaktion; Lagern Sie sowohl den „rohen“ als auch den normalisierten Betrag.
Saisonalität: YoY und saisonale Indizes; bestimmte „Urlaub“ Effekte.

10) Sicherheit und Zugang

Row-Level Security (RLS): Zugriff auf Kennzahlen im Länder-/Marken-/Partnerschnitt.
Column-Level Security (CLS): Maskierung von PII/Finanzfeldern.
Audit: Wer hat nach der Metrik gefragt, welche Filter, welche Daten exportiert.
API-Differenzierung: „Aggregate nach Rollen“ gegen „detaillierte Uploads“.

11) Beobachtbarkeit und SLO

SLO Frische: z.B. „operative KPIs - lag ≤ 15 min, täglich - bis 06:00 Ortszeit“.
Verfügbarkeit SLO: ≥ 99. 9% für API/semantische Ebene.
Alerts: überfällige SLOs, metrische Sprünge, NULL/Duplikate Wachstum, Varianz v1 vs v2> X%.
Runbooks: Was tun bei Degradation - RCA-Schritte, Fallback (z.B. Umschalten auf die letzte gültige „Snepshot-Metrik“).

12) Experimente und Metriken

Guardrail-Metriken: Latenz, Fehlertoleranz, FPR/FNR für Scoring.
Einheitliche Definitionen für A/B: Conversions, Hold, NSM - über die gleiche semantische Ebene.
Minimal unterscheidbarer Effekt (MDE), Power-Analyse: Parameter in der Metrikkarte speichern.
Kausale Attribution: Richtlinien für Mix-Adjustment und Kontrollgruppen.

13) API-Metriken und Verbrauch

Запросы: `GET /metrics/{name}?from=2025-09-01&to=2025-10-01&dims=country,platform&filters=channel:paid`.
Richtlinien: Limits, Cache, Pagination, idempotente „Exporte“.
Versionen: Header 'X-Metric-Version: v2', Deprecation-Warnungen.

14) Muster und Artefakte

Metrikdatenblatt (Beispiel)

Code/Version: „ARPPU _ v3“

Definition: Durchschnittlicher Umsatz pro zahlendem Nutzer pro Periode

Формула: `sum(revenue_net) / count_distinct(user_id where paying_flag=1)`

Granularität: Tag; rollup: Woche/Monat = Summe des Zählers/Summe des Nenners

Quellen: 'fact _ payments _ v2', 'dim _ users _ scd'

Einheiten: Währung 'base _ ccy'; Umrechnung zum Kurs am Datum

Standardfilter: Aktive Märkte, Testtransaktionen ausschließen

SLO: Frische ≤ 1 h; API-Verfügbarkeit ≥ 99. 9%

Guardrails: ARPPU ∈ [0; 10 000]; Verzinkung p1/p99

Eigentümer: Monetization Analytics; Revisionsdatum: 2025-10-01

🚨 Check> Check-Liste der Metrik-Freigabe

Definition und Formel harmonisiert, durch Tests abgedeckt
Semantisches Objekt erstellt; lineage dokumentiert
Backfill und Abgleich mit Referenz abgeschlossen
SLO/Warnmeldungen konfiguriert; Das Runbook ist fertig
Rechte und RLS konfiguriert; PII versteckt
Alte Versionen in Dashboards/Experimenten ersetzt
Changelog/Mitteilung gesendet

SQL-Pseudo-Point-in-Time-Code (Beispiel 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) Häufige Fehler und wie man sie vermeidet

Stille Formeländerungen: immer über Version und Changelog.
Metriken „in jedem Laptop anders“: Erzwingen Sie eine semantische Schicht/API.
Inkonsistente Zeitzonen/Währungen: zentraler Kalender und FX-Tabelle.
Doppelte Benutzerabrechnung: Rollup-Regeln und einzigartige Schlüssel.
Undurchsichtige Frische: Zeigen Sie die Lag/Update-Zeit explizit an.
Abhängigkeit von einem Ingenieur: Alles ist wie Code, mit Revue und Oncoll.

Summe

Die Architektur der Metriken ist Wörterbuch + semantische Schicht + zuverlässige Berechnung + governance und SLO. Nach den beschriebenen Prinzipien (Verträge, Tests, Versionen, Beobachtbarkeit, Sicherheit) wandeln Sie die Metriken von „Zahlenstreitigkeiten“ in einen nachhaltigen Produkt- und Geschäftsmanagementmechanismus um.

Architektur der Metriken