Meta-Analysen und Metriken von Metriken

1) Was ist Meta Analytics

Meta Analytics ist die Steuerung der Messung selbst: Formeln, Quellen, Frische, Stabilität und die Kosten für die Gewinnung von Metriken. Ziel ist es, dass jede Metrik eine überprüfbare Wissenseinheit ist: reproduzierbar, zeitgerecht, teamübergreifend vergleichbar und wirtschaftlich.

2) Das Skelett der Metrik (Metrisches Entitätsmodell)

• Kennung: 'metric _ key', Besitzer (Product/Data Owner), Kritikalität (Gold/Silver/Bronze).
• Bedeutung: Definition, Einheiten, Aggregation, Fenster (day/wow/mom/rolling).
• Formel und Ebene: SQL/DSL, semantische Ebene (Dimensionen, Filter), gültige Segmente.
• Quellen und Lineage: Tabellen, Versionen, Abhängigkeiten (Fichi/Schaufenster/Modelle).
• SLO метрики: latency p95, freshness, coverage, accuracy, stability.
• Trust Signals: Neueste Prüfungen, DQ-Status, CI-Tests der Formel.
• Wirtschaft: bytes scanned, cost-per-chart (CPC), cost-per-insight (CPI).
• Zugangskontrolle: RLS/CLS, Empfindlichkeit.
• Versionierung: semver Formel ('ggr @ 2. 3. 0'), Änderungsprotokoll.

3) „Metriken von Metriken“: Was zu messen ist

Qualität und Vertrauen

Genauigkeit: Diskrepanz zur Benchmark/Buchhaltung (MAE/APE).
Consistency: Übereinstimmung zwischen Quellen/Dashboards (kanonische Formel).
Freshness: Alter der Daten vs SLO (sec/min).
Completeness: Anteil der ausgefüllten Segmente/Daten.
Stabilität: Varianz/Volatilität bei unveränderten Bedingungen (Levene/variance ratio).
Erklärbarkeit: das Vorhandensein einer Formel/Referenzen/CI/Bereiche in der Karte.

Leistung und Kosten

Latency p95/p99 Berechnung/Renderer.
Bytes gescannt/Anfrage.
CPC/CPI: Kosten für Grafik/Einblick.
Cache-Hit-Rate und Materialisierungen.

Risiko und Verwendung

Adoption: Anteil der Dashboards/Lösungen, die die Metrik verwenden.
Bruchrate: Häufigkeit von Testabfällen/Frischepausen.
Drift score: Verschiebung der Verteilungen nach Formel-/Quelländerungen.
Stützlast: Fälle/Vorfälle nach Metrik.

4) Semantische Schicht und „Metric Store“

Einheitliche Grammatik: Maße, Dimensionen, Filter, Aggregationsregeln und Kompatibilität.
API/Metrikverzeichnis: Suche, Karten, Versionierung, Lineage-Graph.
Zwischenberechnungen: Materialisierungen (täglich/wöchentlich), kanonische Finken.
Veröffentlichungsrichtlinie: nur von Metric Store zu Prod Dashboards/AI Visualisierung.

5) Versionierung und Kompatibilität

SemVer für Metriken: 'MAJOR' - brechende Bedeutungsänderung/Aggregationen; 'MINOR' - neuer Schnitt/Attribut; 'PATCH' - Optimierung ohne Wertänderung.
Deprecation flow: Warnung, Parallelmodus v1/v2, Abschaltdatum, Migrationshyde.
Vertragstests: Gleichheit/Inequalität, Invarianten (Summe der Teilsegmente = Ganzes).

6) Lineage und Audit von Metriken

Upstream: Quellen, DQ-Regeln, Versionen.
Transformieren: SQL/DBT/DAG-Knoten, Schemakompatibilitätsprüfungen.
Downstream: Dashboards/Modelle/Berichte, die die Metrik verbrauchen.
Audit: Wer die Formel wann geändert hat, welcher Vorfall oder welche Freigabe betroffen war.

7) Metrische Beobachtbarkeit (Metric Observability)

Zeitprofile: Saisonalität, Kalendereffekte, Promo.
Anomalien: STL/ESD/BOCPD; Alertas mit Kritikalitätsempfindlichkeit.
Check Gates: Vor der Veröffentlichung gibt es einen Vergleich der alten/neuen Formel auf dem „goldenen“ Schnitt.
Drift-Monitoring: PSI/JS nach Segmenten; Quelländerungs-Token.

8) Metrikökonomie und FinOps

Kontingente/Limits: max bytes gescannt, Laufzeit, off-peak rebuild.
Chargeback: Teams zahlen „virtuell“ für schwere Berichte.
Cache/Materialisierungen: Profile von Caches und TTLs.
Optimierung: Säulenformate, ZSTD, Sortierung/Clustering, Voraggregate.

9) Änderungsmanagement (Change Mgmt)

RFC-Metriken: Ziel, Risiko, erwartete Verschiebung, Rollback-Plan.
Formel A/B: parallele Berechnung und Vergleich der Metriken v1 vs v2.
Kommunikation: changelog in der Karte, Banner auf gebundenen Dashboards.
Rollback: Schneller Wechsel zur vorherigen Materialisierung.

10) Rollen

Metric Owner: Bedeutung, Formel, Releases, Kommunikation.
Data Engineer: Zuverlässigkeit der Pipeline, Leistung.
Analyst/Wissenschaftler: Gültigkeit und kausale Interpretation.
FinOps: Kosten und Quoten.
Compliance/Privacy: Zugriffe, Maskierung, Reporting.

11) Antipatterns

SELECT in der Metrikformel.
Zwei „offizielle“ Formeln derselben Metrik.
Manuelle Änderungen im Dashboard statt Änderungen im Metric Store.
Ohne Angabe des Fensters/der Vergleichsbasis.
Null Lineage und kein Besitzer.
Versteckte Filter (verschiedene Länder/Währungen) → nicht vergleichbare Zahlen.

12) Fahrplan für die Umsetzung

1. Inventar: Liste der Top-50-Metriken, Besitzer, Kritikalität, aktuelle Formeln.
2. Metric Store MVP: Karten, SemVer, API, Lineage, CI-Tests.
3. Beobachtbarkeit: freshness/latency/bytes scanned/Anomalien, SLO-Panels.
4. FinOps: Limits, Cache, Materialisierungen, Wertberichte.
5. Governance: RFC/degradation/rollbacks, deprecation-policy.
6. Maßstab: automatische „Metriken der Metriken“, Integration mit KI-Visualisierung/Kontext.

13) Metrik Checkliste (vor der Veröffentlichung)

• Die Metrikkarte ist ausgefüllt (Definition, Einheiten, Segmente, Fenster).
• Die Formel ist versioniert; Konsistenz-/Invariantentests grün.
• Freshness/Latency SLOs werden gesetzt und überwacht.
• DQ-Quellen sind grün; lineage ist transparent.
• Kosten der Anfrage innerhalb der Grenzen; Cache/Materialisierung konfiguriert.
• Zugriffsrichtlinien (RLS/CLS) und Maskierung angewendet.
• Die Mitteilung über die Änderungen ist vorbereitet. Es gibt einen Rollback-Plan.

14) Mini-Vorlagen

14. 1 Metrikkarte (YAML)

yaml metric:
key: ggr version: 2. 3. 0 owner: "product-data@company"
definition: "Bet amount minus win amount"
unit: "currency"
aggregation: "sum"
window: ["day","wow","mom"]
dims_allowed: ["country","device_os","provider","game"]
lineage:
sources: ["fact_bets","fact_payouts"]
transforms: ["ggr_daily. sql"]
slo:
freshness_s: 600 latency_p95_ms: 1500 accuracy_mae_pct: <=0. 5 finops:
max_bytes_scanned_mb: 2048 cache_ttl_min: 60 access:
sensitivity: "internal"
rls: ["tenant","region"]

14. 2 Formeltests (dbt-Stil)

sql
-- invariant: GGR = bets - wins select count () as violations from (
select bets - payouts as ggr_calc, ggr from mart_daily
) t where abs(ggr_calc - ggr) > 1e-6;

14. 3 Alert Metrics Policy

yaml alerts:
- name: ggr_freshness when: freshness_s > 600 severity: high action: [page:oncall-data, degrade:use_last_materialization]
- name: ggr_stability when: variance_ratio_week > 2. 5 severity: medium action: [open:investigation, add:banner_on_dashboards]

14. 4 Vergleich der Formelversionen

sql select dt, country,
ggr_v1, ggr_v2,
(ggr_v2 - ggr_v1) as delta,
100(ggr_v2 - ggr_v1)/nullif(ggr_v1,0) as delta_pct from compare_ggr_v1_v2 order by dt desc, abs(delta_pct) desc limit 100;

14. 5 „Metric Metrics“ -Bericht für Dashboards

yaml meta_dashboard:
tiles:
- metric: freshness_s target: <=600
- metric: latency_p95_ms target: <=1500
- metric: bytes_scanned_mb target: <=2048
- metric: anomaly_rate_7d target: <=0. 5%
- metric: adoption_rate target: >=80%

15) Das Ergebnis

Meta Analytics macht Metriken zu zuverlässigen Engineering-Objekten: Sie haben Eigentümer, Versionen, SLOs, Tests und Kosten. Wenn Metrikkarten, semantische Schicht, Beobachtbarkeit und FinOps zusammenarbeiten, erhält die Organisation vergleichbare, überprüfbare und kostengünstige Zahlen und nicht „unterschiedliche Wahrheiten“. Es ist die Grundlage für schnelle Analysen, korrekte Entscheidungen und skalierbares Wachstum.