Event & Award Automation: Regeln und Webhooks

Gamification beruht auf zwei „Motoren“: Ereignisse (was der Benutzer getan hat) und Regeln (was dafür fällig ist). Damit das im großen Stil und fehlerfrei funktioniert, braucht es einen zuverlässigen Eventbus, eine Regelengine, einen Liefer-/Vergabemechanismus und einen strikten Betrugsschutz. Im Folgenden finden Sie praktische Architektur, Vorlagen und Checklisten.

1) Flow-Architektur „Ereignis → Regel → Belohnung“

1. Ingest (Event Login): SDK/Web, Server-Webhooks vom Zahlungs-/Spieleanbieter → API Gateway → Queue/Bus (Kafka/Rabbit/Cloud Pub/Sub).

2. Normalizer: Validierung, Anreicherung (geo, device, payer_flag), Schemaversion.

3. Rules Engine: Punkte-/CR-Scoring, Missions-/Quest-Check, Belohnungs-/Benachrichtigungsauslöser.

4. Reward Orchestrator: Berechnung der Belohnung, Budget-Check, RG/KYC-Gates, Erstellung einer „Ausgabeaufgabe“, Protokollierung.

5. Payout/Bonus Service: Cash/Bonus Cash/Freespins/Coupons, externe Webhooks (Wallet, Anbieter).

6. Notifier: Push/in-App/Email/Messenger mit Frequenzlimits.

7. Storage/Analytics: Rohveranstaltungen, Schaufenster, A/B, Alerts.

8. Anti-Fraud/RG: Mundschutz, Heuristiken/ML, Hold-and-Review von großen Preisen.

2) Ereignismodell (Mindestsatz)

json
{
"event_id": "d9e8-...-5c2",  "event_name": "bet",  "version": "1. 2. 0",  "ts": "2025-10-24T11:37:21Z",  "user": {
"id": "u_123",   "geo": "TR",   "platform": "android",   "payer_flag": true,   "risk_flags": ["vp_nightly"]
},  "context": {
"session_id": "s_789",   "device_fp": "fp_...",   "ip": "203. 0. 113. 24"
},  "payload": {
"game_id": "slot_wolf",   "bet": 0. 5,   "win": 1. 25,   "currency": "EUR",   "provider": "GameCo"
}
}

Базовые типы: `login`, `session_start/end`, `bet/spin`, `win`, `deposit`, `withdraw_request`, `kyc_status_changed`, `mission_view/join/progress/complete`, `tournament_join/score/update/reward`, `reward_issued`, `rg_event`.

3) Regelwerk: Wie man Logik beschreibt

Konzepte: Regeln (wenn/dann), Segmente, Zeitfenster, Mundschutz, Prioritäten, Versionierung.

Beispiel für eine deklarative Regel (YAML-Stil):

yaml rule_id: r_points_winmult_v2 when:
event_name: bet filters:
- payload. bet >= 0. 2
- user. geo in ["TR","BR","PE"]
- now between "2025-11-01" and "2025-11-30"
score:
formula: "floor((payload. win / payload. bet) 3)"
caps:
per_bet: 50 per_minute: 200 per_day: 1500 reward_trigger:
on_progress:
threshold: [100, 300, 800]
reward: [{type: "fs", value: 10}, {type: "bonus_cash", value: 2}, {type: "loot", rarity: "rare"}]
guardrails:
kyc_min_level: 2 rg_limits_ok: true budget_pool: "nov_season"
budget_soft_cap: 80000 meta:
version: "2. 0"
experiment: "scoring_ab_2025w45"

4) Webhooks: Server-Server-Integration

4. 1. Ausgehende Webhooks (von Ihnen zu den Anbietern/Wallet)

Methode: 'POST https ://partner. example/payouts`

Подпись: `X-Signature: HMAC-SHA256(secret, body)` + `X-Request-Id` (idempotency).

Retrays: exponentieller Backoff, 'max _ retries = 8', jitter, DLQ.

Idempotency: Wiederholung der gleichen 'X-Request-Id' → der Partner muss mit der gleichen 'payout _ id/status' antworten.

Beispiel für payload:

json
{
"request_id": "rid_7f5...",  "user_id": "u_123",  "reward": {"type":"cash","amount":10. 00,"currency":"EUR"},  "reason": "milestone_300_points",  "kyc_level": 2,  "constraints": {"wagering": 0, "expiry_at": "2025-12-01T00:00:00Z"}
}

4. 2. Eingehende Webhooks (zu Ihnen)

Erlauben Sie nur IP/MTLS-Listen, überprüfen Sie HMAC und Signaturlebensdauer ('X-Timestamp', ± 5 Minuten).

Speichern Sie den „rohen“ Body + Header im Audit-Repository (WORM).

Jede Doppel/Wiederholung → überprüfen Sie die idempotency Schlüssel gegen das Protokoll.

5) Zuverlässigkeit: „gleichmäßiger“ Fluss ohne doppelte Auszahlungen

At-least-once auf ingest + idempotent Handler → den Goldstandard.

Idempotency-Schlüssel: 'hash (event_id + user_id + rule_id)', um Punkte zu sammeln; separater Schlüssel für die Vergabe der Auszeichnung 'reward _ task _ id'.

Exactly-once Semantik ist nur logisch (durch Idempotenz) realistisch, nicht durch Transport.

Reihenfolge der Ereignisse: Speichern Sie' event _ ts' und 'ingest _ ts'; Verwenden Sie ein Reordering-Fenster (z. B. 60 Sekunden) und Replay aus der Warteschlange mit dem Schlüssel 'user _ id'.

Dead Letter Queue (DLQ):

Wir schreiben dort Nachrichten mit einem permanenten Fehler (das Zeitschema ist nicht bestanden, die Unterschrift ist ungültig, das Budget ist geschlossen).
DLQ-Revue-Service mit Reprocess/Drop/Fix-Schema-Buttons.

6) Budgets und Margenschutz

Budgetpools: „nov _ season“, „daily _ sprint“, „vip _ weekend“.

Quoten: Soft/Hard Cap, „Circuit Breaker“ - bei Erreichen von 90% des Budgets große Preise in Hold-State übertragen.

Einzelkosten: „Preis & Bonuskosten per Active/Payor“, Net Uplift.

Prioritäten: RG und Compliance wichtiger als Promo - bei einem Konflikt wird die Vergabe verschoben.

Beispiel Budgetprüfung (SQL-Sketch):

sql
SELECT pool_id,    SUM(amount) AS spent,    budget AS limit,    SUM(amount)/budget AS fill
FROM reward_ledger
WHERE pool_id =:pool AND date(ts) = current_date
GROUP BY pool_id, budget;

7) RG/KYC/Geo-Gates (Spielersicherheit und Compliance)

KYC: Minimum L2 für Cache/große Preise; Freispiele sind mit L1 zulässig.

RG: Überprüfung der Einzahlungslimits, Selbstausschluss, „Cool-Off“ → Belohnungen werden „eingefroren“, bis die Beschränkungen aufgehoben werden.

Geo: Liste der erlaubten Länder für jede Regel/Belohnungspool.

Schwellen-Alerts: Starker Anstieg „fast erreicht“ bei einzelnen Konten = Grund für Hold & Review.

8) Anti-Fraud-Regeln und Telemetrie

Punkte zu einem Satz/min/Stunde/Tag, minimale Varianz der Einsätze, Verbot von „idealen“ Mustern.

Technische Signale: Headless, wiederkehrende device_fp, Proxy-Subnetze.

Anomalien: „Punkte/Einsätze“ und „Punkte/min“ - lange „Schwänze“ auf 99-Perzentil.

Hold-and-Review für Top-Preisträger: automatischer KYC-Check + manuelle Überprüfung.

9) Überwachung, Metriken und Alerts

SLO/SLA:

Ingest p95 ≤ 250 ms Behandlung der Regel p95 ≤ 150 ms; Aktualisierung des Leaderboards ≤ 2 s; Belohnung ≤ 60s.
Error budget < 0. 1% Ereignisse/Tag.

Alerts:

SRM auf Experimenten (Verkehrsverzerrung), DLQ-Wachstum, Rückgang der HMAC-Validierungsunterschrift, Budgetüberschreitung, Anstieg der Idempotent-Takes.

Dashboard (täglich):

Ereignisse/s, Lag, Fehlertoleranz;
Der Trichter: das Ereignis → die Regel → reward_task → reward_issued;
Kosten: Preis/Bonus per Active, Net Uplift;
Qualität: Betrugsflaggen, KYC-Einheiten, RG-Betätigungen.

10) Versionierung und Migrationen

Jede Regel ist versioned ('rules. version`).

Sie können die aktive Regel nicht ohne eine neue Version bearbeiten; Verwenden Sie ficheflag und „sanftes Aufwärmen“ (10% → 50% → 100%).

Schema der Ereignisse über schema registry; inkompatible Änderungen - nur die Hauptversion.

11) A/B-Automatisierungstests (kurz)

Einheit - Benutzer; sticky-assignment; Schichtung (payer/geo/platform).

Getrennte Leaderboards oder Normalisierung der Brille, um Interferenzen auszuschließen.

Primary: participation_net, completion, Net ARPPU; Guardrails: Beschwerden/1k, Betrugsflaggen, RG-Trigger.

CUPEDs und Kovariaten zur Reduzierung der Dispersion.

12) Beispiele: von der Regel bis zur Auslieferung

12. 1. Auslöser „Mikro-Belohnung für Fortschritt“

json
{
"type": "reward_task. created",  "reward_task_id": "rt_456",  "user_id": "u_123",  "origin": {"rule_id":"r_points_winmult_v2","threshold":300},  "reward": {"type": "bonus_cash", "amount": 2, "currency":"EUR", "wagering": 15},  "pool_id": "nov_season",  "status": "pending",  "created_at": "2025-10-24T11:38:30Z"
}

12. 2. Ausgehende Webhooks auf der Brieftasche


POST /wallet/credit
X-Request-Id: rid_7f5...
X-Timestamp: 1730061700
X-Signature: sha256=7b9a...

{ "user_id":"u_123", "amount":2. 00, "currency":"EUR", "reason":"rule:r_points_winmult_v2" }

Der Erfolg → 'reward _ task' = 'succeeded' und der Eintrag in 'reward _ ledger'.

Flop (5xx/Timeout) → Retrait mit der gleichen 'X-Request-Id'.

Failure (4xx) → DLQ + manuelle Analyse.

13) Tresore und Tabellen (Sketch)

sql
-- Zeitschrift für Auszeichnungen
CREATE TABLE reward_ledger (
id BIGSERIAL PRIMARY KEY,  reward_task_id TEXT UNIQUE,  user_id TEXT,  pool_id TEXT,  type TEXT,  value NUMERIC(18,2),  currency TEXT,  cost NUMERIC(18,2) DEFAULT 0, -- реальная стоимость для P&L status TEXT, -- succeeded/failed/held created_at TIMESTAMPTZ,  updated_at TIMESTAMPTZ
);

-- Indempotenz
CREATE UNIQUE INDEX uniq_reward_task ON reward_ledger (reward_task_id);

-- Budget
CREATE TABLE reward_budget (
pool_id TEXT PRIMARY KEY,  budget NUMERIC(18,2),  spent NUMERIC(18,2),  period DATE
);

14) Sicherheit und Privatsphäre

HMAC-Signaturen, MTLS, allow-list IP.

Verschlüsselung im Transit/Rest, Schlüsselrotation, Geheimnisse im Tresor.

Datenminimierung im Payload (PII separat, per Link-Token, TTL).

Prüfprotokolle sind unveränderlich (WORM).

Aufbewahrungs- und Löschpolitik (Recht auf Vergessenwerden, Deduplizierung-sicher).

15) Start-Checkliste

Ereignis- und Registrierungsdiagramme, Webhook-Verträge (Signaturen, TTL).
Warteschlangen, Retrays, DLQs, idempotente Verarbeiter.
Caps/Guardrail-s in den Regeln, KYC/RG-Gates.
Budget-Pools, Circuit-Breakers, Überlaufalerts.
SLO Dashboards + Reward Trichter.
A/B-Ficheflag und SRM-Überwachung.
Runbook Vorfälle (Wiederholung, Einfrieren, manuelle Ausgabe).

16) Mini-Fall (synthetisch)

Veranstaltungen von Spieleanbietern und Wallet sind verbunden; inklusive „win/bet“ Scoring mit Mundschutz.

Webhooks signiert von HMAC, Retrays bis zu 8 Versuchen, DLQ mit Revue alle 2 Stunden.

Für 4 Wochen: Behandlungs-Lag p95 180 ms; DLQ < 0,06%; doppelte Auszahlungen 0; Betrugsflaggen − 0,4 pp; ΔParticipation_net +6,3 п.п.; ΔARPPU (net) +€2,1 при Prize&Bonus/Active +€0,7.

Fazit: Skalierung der Regeln auf neue Geos mit lokalen Budget-Pools.

Bei der Automatisierung von Belohnungen geht es nicht darum, „einen Push mit Freispielen zu senden“. Es ist ein Engineering-System: zuverlässige Lieferung von Ereignissen, strenge Versionierung von Regeln, idempotency und Signaturen, Budget-Capers, KYC/RG-Gates, Betrugsbekämpfung und Überwachung. Bauen Sie diesen Rahmen eines Tages auf - und alle Missionen, Turniere und „Loot-Momente“ funktionieren vorhersehbar, pünktlich und mit einem positiven Nettoeffekt.