GH GambleHub

Feature Engineering und Merkmalsauswahl

1) Zweck und Grundsätze

Das Ziel: nachhaltige, interpretierbare und wirtschaftliche Merkmale zu konstruieren, die zwischen offline und online abgestimmt sind.

Grundsätze:
  • Point-in-Time: Die Fiches werden aus den zum Zeitpunkt der Entscheidung verfügbaren Daten ohne Zukunft (Anti-Leakage) berechnet.
  • Domain-first: Die Fiches spiegeln die Geschäftsmechaniken (Einzahlungen, Sessions, Spielgenres, RG/AML) wider.
  • Reuse & Contracts: fichy - Versionen, Besitzer, Formeln und SLOs im Feature Store.
  • Cost-aware: Wir betrachten die Latenz und die Kosten der Berechnung/Speicherung → materialisieren nur das, was sich auszahlt.
  • Observability: Überwachung Drift/Stabilität/Kalibrierung; Äquivalenztest online/offline.

2) Feature-Taxonomie für iGaming

RFM/behavioral: recency/frequency/monetary by windows (10m/1h/1d/7d/30d).
Session: Dauer, Pausen, Gerätewechsel/ASN, Aktionsgeschwindigkeit.
Finanziell: Ein-/Auszahlungen/Charjbacks, Anteile der Zahlungsmethoden, FX-Normalisierung.
Gaming: Genreprofile, Volatilität der Anbieter, RTP-Cluster, Win-Streak.
Marketing: Kanäle/UTM, Kampagnenantworten, Saturation/Cooldown.
RG/AML: Limits, Selbstausschlussflags, Velocity-Muster, Wiederverwendung von BIN/IP.
Geo/Zeit: lokale Kalender/Feiertage, Stunde der Gürtel, Abend/Nacht.
Graphisch: User-Card-Device-IP-Verbindungen, Zentralität/Komponenten, „Ringe“ des Betrugs.
NLP/Texte: Themen und Tonalität der Tickets/Chats; Die wichtigsten Beschwerden.
Operativ: Fehler der Anbieter, Stabilität der Sitzungen (für SRE-Modelle).


3) Fenster und Aggregate (Point-in-Time)

Typische Fenster: 10m/1h/24h/7d/30d. Für jedes Fenster gibt es count/sum/mean/std/last/max/min, ratio und rate.

SQL-Vorlage (30d Einlagen, keine Zukunft):
sql
SELECT u.user_pseudo_id, t.asof,
SUM(CASE WHEN e.type='deposit'
AND e.event_time>=t.asof - INTERVAL '30' DAY
AND e.event_time< t.asof THEN e.amount_base ELSE 0 END) AS dep_30d,
COUNT(CASE WHEN e.type='bet'
AND e.event_time>=t.asof - INTERVAL '7' DAY
AND e.event_time< t.asof THEN 1 END) AS bets_7d
FROM silver.fact_events e
JOIN (SELECT user_pseudo_id, DATE(event_time) AS asof
FROM silver.fact_events GROUP BY 1,2) t USING(user_pseudo_id)
JOIN dim.users_scd u ON u.user_pseudo_id=t.user_pseudo_id
AND t.asof >= u.valid_from AND (u.valid_to IS NULL OR t.asof < u.valid_to)
GROUP BY 1,2;

4) Kategoriale Kodierungen

One-Hot/Hashing: für seltene/hoch-kardinale Kategorien (Spiele, Anbieter).
Target Encoding (TE): Zieldurchschnitte mit k-fold/leave-one-out und time-aware anti-leakage.
WOE/IV (Risk Scoring): monotone Behälter mit IV- und Stabilitätskontrolle.

TE (Pseudocode, Time-Aware):
python for fold in time_folds:
train_idx, val_idx = split_by_time(fold)
te_map = target_mean(train[["provider_id","label"]])
val["provider_te"] = val["provider_id"].map(te_map).fillna(global_mean)

5) Normalisierung und Skaling

Min-max/Robust/Z-score - durch das Trainingsfenster; Parameter in Artefakten speichern.
Log-Konvertierungen für lange Schwänze von Beträgen/Wetten.
Box-Cox/Yeo-Johnson - wenn Symmetrierung erforderlich ist.


6) Temporäre und saisonale Fici

Kalender: Wochentag, Stunde, Marktfest (Ref. calendar), pay-day.
Periodizität: gleitende Durchschnitte/Belichtung. Anti-Aliasing (EMA), deltas (t − t-1).
Event-basiert: Zeit seit der letzten Einzahlung/Gewinn/Verlust, „Abkühlung“.


7) Graphische Merkmale (Betrug/AML)

Top: user/card/device/ip. Kanten: Transaktionen/Sitzungen/gemeinsame Merkmale.
Fichy: Komponentengröße, Grad, betweenness, pagerank, triads, Wiederauftreten.
Vorlage: Nightly Batch erstellt einen Graph → Embedding/Zentralität → Online-Cache.


8) NLP-fichi (sapport/chats/revue)

Basis: TF-IDF/NMF Themen, Sentiment, Länge, Reklamationshäufigkeit.
Fortgeschritten: Embedding (Sentence-BERT) → Mittelung über Tickets pro Fenster.
PII: Vor- und Nachmaskierung (E-Mail, PAN, Telefone) nach Politik.


9) Geo/ASN und Geräte

IP→Geo/ASN: Zwischenspeichern und aktualisieren; keine synchronen Abfragen online ohne Timeout/Cache.
Fichy: ASN/DeviceID Stabilität, Schaltfrequenz, Abstand zwischen den Logins.


10) Anti-Leakage und Online/Offline-Verhandlung

Point-in-time join, keine zukünftigen Ereignisse in den Fenstern/Labels.
Ein Transformationscode (library) für offline und online.
Äquivalenztest: In der T-Stichprobe vergleichen wir die Online-Werte von fich mit Offline (MAE/MAPE).

YAML-speca fichi:
yaml name: deposits_sum_10m owner: ml-risk slo: {latency_ms_p95: 20, availability: 0.999}
offline:
source: silver.payments transform: "SUM(amount_base) OVER 10m BY user_pseudo_id"
online:
compute: "streaming_window: 10m"
tests:
- compare_online_offline_max_abs_diff: 0.5

11) Merkmalsauswahl (feature selection)

11. 1 Filter

Variation/Korrelation: Konstanten entfernen,ρ>0. 95 Duplikate.
Mutual Information (MI): Rangfolge nichtlinearer Verbindungen.
IV/KS (Risiko): für binäre Targets in AML/RG.

11. 2 Wrapper

RFE/Sequential FS: auf kleinen Sätzen/logistischer Regression.
Stability Selection: Nachhaltigkeit im Bootstrap-Sampling.

11. 3 Embedded

L1/Lasso/ElasticNet: Verdünnung.
Trees/GBDT: importance/SHAP für Auswahl und geschäftliche Interpretation.
Group Lasso: Gruppenselektion (Bin-Fich-Sätze einer Variablen).

Pipeline (Skizze):
python
X = preprocess(raw)        # one-hot/TE/scale
X = drop_const_and_corr(X, thr=0.95)
rank_mi = mutual_info_rank(X, y)
keep1 = topk(rank_mi, k=200)
model = LGBMClassifier(...)
model.fit(X[keep1], y)
shap_vals = shap.TreeExplainer(model).shap_values(X[keep1])
keep2 = stable_topk_by_shap(shap_vals, k=60, bootstrap=20)
final = keep2

12) Stabilität, Drift und Kalibrierung

Drift: PSI/KS für Fics und Score; alert, wenn Schwellenwerte überschritten werden.
Stabilität: Achten Sie auf „fragile“ TE/WOE (Kardinalität/Verschiebungen).
Kalibrierung: Platt/Isotonic; Zuverlässigkeitsberichte.
Slice-Analyse: Märkte/Anbieter/Geräte - Benchmarks für Metriken und erwartete Fehlerkosten.


13) Kosten-Engineering und Produktivität

Cost per Feature (CPF): CPU/IO/Netzwerk/Speicher → Budget pro Modell.
Materialisierung: schwer offline, leicht online; TTL/Cache für heiße Fich.
Gelöschte Lookups: nur async + Cache; p95 <20-30 ms auf fichi online.
Chargeback: Berücksichtigung der Kosten von Fich/Inference durch Teams.


14) Feature Store (Konsistenzkern)

Registry: Name, Formel, Besitzer, SLO, Tests, Versionen.
Online-/Offline-Synchronisation: ein Transformationscode, Gleichheitstest.
Protokolle/Audit: wer hat die Formel geändert; Auswirkungen der Version auf die Modellmetriken.


15) Beispiele

ClickHouse: Minuten-Wettaggregate:
sql
CREATE MATERIALIZED VIEW mv_bets_1m
ENGINE = SummingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), user_pseudo_id)
AS
SELECT toStartOfMinute(event_time) AS ts_min,
user_pseudo_id,
sum(stake_base) AS stake_sum_1m,
count() AS bets_1m
FROM stream.game_events
GROUP BY ts_min, user_pseudo_id;
Anti-correlation drop (SQL-Idee):
sql
-- вычислить корреляции и удалить пары с     ρ    >0.95, сохранив более «дешевую» фичу
WOE Binning (Skizze):
python bins = monotonic_binning(x, y, max_bins=10)
woe = compute_woe(bins)
iv = compute_iv(bins)

16) Prozesse und RACI

R (Responsible): Data Eng (Pipelines/Feature Store), Data Science (Fich Design/Selektion/Metriken).
A (Accountable): Head of Data / CDO.
C (konsultiert): Compliance/DPO (PII, residency), Risk/AML/RG (rules), SRE (SLO/cost), Security.
I (Informed): Produkt/Marketing/Betrieb/Support.


17) Fahrplan

MVP (3-5 Wochen):

1. Verzeichnis der Top-50-Fitch (Zahlungen/Gameplay) mit Point-in-Time-Formeln.

2. Feature Store v1 (online/offline) + Äquivalenztest.

3. Grundauswahl: Konstanten/Korrelationen → MI → L1/SHAP Shortlist (bis zu 60 Fich).

4. Überwachung von Drift-Fitch und Cost-Dashboard.

Phase 2 (5-10 Wochen):
  • TE/WOE mit Time-Aware-Validierung, Graphen und Kalender-Fiches.
  • Slice-Analyse und Fairness, Kalibrierung von Wahrscheinlichkeiten.
  • Materialisierung von schweren Offline-Fich, Online-Cache, Quoten.
Phase 3 (10-16 Wochen):
  • Auto-Generierung der Dokumentation fich, stability-selection in CI.
  • Auto-Deaktivierung von „teuren und nutzlosen“ Fitch (CPF↑, vklad↓).
  • A/B Vergleich der Sätze von Fich, Expected-Cost-Berichte.

18) Checkliste vor dem Verkauf

  • Alle Fiches haben Spezifikationen (Eigentümer, Formel, Versionen, SLO).
  • Point-in-Time und Online/Offline Äquivalenztests bestanden.
  • Auswahl: Filter → embedded (SHAP/L1) → Stabilität.
  • Drift- und Zuverlässigkeitsüberwachung eingerichtet; Es gibt Schwellen und Alerts.
  • CPF/Latency passen in den Haushalt; schweres Fici materialisiert.
  • PII-Richtlinien werden eingehalten (CLS/RLS, Tokenisierung, Residency).
  • Dokumentation und Anwendungsbeispiele wurden dem Katalog hinzugefügt.

19) Anti-Muster und Risiken

Leukej (zukünftige Ereignisse/Auswirkungen promo).
Inkonsistente Online-/Offline-Formeln.
Wiedergewonnene One-Hot aus den hochdramatischen Kategorien ohne Hashing/TE.
„Teure“ Fiches ohne messbaren Qualitätsgewinn.
Fehlende Slice/Fairness Analyse - versteckte Degradation.
TE/WOE ohne Time-Aware-Cross-Validierung → Umschulung.


20) Das Ergebnis

Feature Engineering ist eine überschaubare Disziplin: Point-in-Time, Geschäftssinn, Reproduzierbarkeit, Monitoring und Ökonomie. Starke Fici + rigorose Selektion (Filter/Wrapper/Embedded) und ein einheitlicher Feature Store ergeben nachhaltige, interpretierbare und günstige Modelle, die Net Revenue aufwerten, Missstände reduzieren und RG unterstützen - transparent und konform.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.