Zum Hauptinhalt springen
Ereignisse werden von derselben Engine ausgewertet wie Transaktionen. Es gibt ein Regelmodell, ein Bedingungsvokabular und einen Satz von Aktionen. Eine Regel legt lediglich fest, auf welche Datensatztypen sie angewendet wird.

Gilt für

scope.record_types bestimmt, bei welchen Datensatztypen eine Regel ausgelöst wird.
Wird der Eintrag weggelassen, bleibt eine Regel auf Transaktionen beschränkt. Jede Regel, die vor der Einführung von Ereignissen geschrieben wurde, verhält sich weiterhin genauso wie zuvor. Eine Regel beginnt nie, Logins zu erfassen, nur weil ihr Scope zufällig leer war.
In der Konsole ist dies der Selektor Gilt für im Trigger-Schritt einer Regel. Wenn Sie Ereignisse wählen, erscheint eine Checkliste Ereigniskategorien, die die Regel weiter eingrenzt. Lassen Sie alle Kategorien unmarkiert, um jede Kategorie auszuwerten.
"__current__" bedeutet „derselbe Wert wie das gerade ausgewertete Ereignis“. Damit gibt eine Regel pro Subjekt, pro Gerät oder pro Runde an, ohne einen konkreten Wert zu nennen. Datensätze ohne den gruppierten Wert werden nie zusammengefasst. Ein Ereignis ohne Geräte-Fingerprint ist nicht „dasselbe Gerät“ wie andere Ereignisse ohne Fingerprint, und ein Ereignis ohne Subjektangabe ist nicht „dasselbe Subjekt“ wie andere anonyme Ereignisse. Hat das ausgewertete Ereignis für ein "__current__"-Feld keinen Wert, greift diese Aggregation unabhängig vom Operator nicht.

Ereignisfelder

Bedingungen lesen Pfade mit Namensraum. Das Transaktionsvokabular, das Sie bereits kennen (action_type, subject_vendor_data, subject_ip_country, custom_values.<key>), wird auch bei einem Ereignis aufgelöst. Subjektsignale werden beim überwachten Benutzer zwischengespeichert und nicht pro Ereignis neu berechnet. So kann eine Regel sie mit der Geschwindigkeit der Ereigniserfassung auswerten.

Aggregationen

Geschwindigkeit

Die Reducer, die Sie bereits bei Transaktionen verwenden (count, sum, avg, min, max, distinct_count), über ein rollierendes window (30m, 24h, 7d, 30d).

Verhältnis

Zwei Reducer über dasselbe Zeitfenster. So werden Wett-zu-Einzahlungs-, Auszahlungs-zu-Einzahlungs-, Bonus-zu-Einzahlungs- und Chargeback-Raten ausgedrückt.
Einzahlung 1.000, Wette 20, Auszahlung angefordert, und das Verhältnis beträgt 0,02 – klassische Geldwäsche durch minimales Spielen.
Ein Verhältnis ohne Nenner greift nie. Keine Einzahlungen ergeben kein Verhältnis von null, sondern keinen Nachweis. Ein Treffer an dieser Stelle würde jeden neuen Benutzer markieren.

Sequenz

Geordnete Prädikate innerhalb eines Zeitfensters. Jeder Schritt wird anhand von action_type, event_category oder einem beliebigen match-Filter abgeglichen und kann min_count Vorkommen verlangen, bevor die Sequenz fortschreitet.
Credential-Stuffing, dann die MFA-Übernahme, dann die Umleitung der Auszahlung, dann das Leeren des Kontos. Die Regel löst bei dem Ereignis aus, das die Kette abschließt. Die zugehörigen Nachweise listen die Ereignis-IDs jedes Schritts auf. Der Sequenzstatus wird pro Regel und Subjekt gehalten. So schreitet er mit eintreffenden Ereignissen voran, statt die Zeitleiste erneut zu durchsuchen. Fortschritt, der älter als das Zeitfenster ist, wird verworfen und nicht mitgezählt.

Korrelation

Eine Verknüpfung über Subjekte hinweg: Reduziert wird über jedes Ereignis, das dieselbe Gruppe wie dieses Ereignis teilt.
"pair": true gleicht die beiden Enden als ungeordnete Menge ab, sodass A→B und B→A in dieselbe Gruppe fallen. So kann eine Regel beide Hälften einer Absprache sehen. Chip-Dumping, Gegenwetten und Selbstempfehlung über Affiliates haben alle diese Form. Geben Sie einer Korrelationsregel immer einschränkende filters an. Ohne sie berücksichtigt sie jedes Ereignis im Zeitfenster.

Echtzeit- und asynchrone Regeln

Manche Regeln können innerhalb der Ingestion-Anfrage antworten, andere nicht. Ein Ereignis, dessen Regeln noch ausstehen, wird mit "correlation_pending": true zurückgegeben. Status und Score werden im bestehenden Ereignis aktualisiert, sobald der asynchrone Durchlauf abgeschlossen ist. Erneutes Ausführen ist idempotent, daher wendet eine Regel ihren Score nie zweimal an. Diese Trennung ist bewusst so gewählt: Eine subjektübergreifende Ringabfrage darf keinen Login verzögern.

Aktionen

Es gilt dasselbe Aktionsvokabular wie bei Transaktionsregeln: add_score, change_status, add_tags, add_note, add_to_list, open_case. Bei Ereignissen gibt es zwei Unterschiede:
  • change_status auf AWAITING_USER ist ein reines Transaktionsergebnis (es gibt keinen Behebungs-Workflow für Ereignisse) und wird als IN_REVIEW angewendet.
  • open_case verknüpft den Fall mit dem Subjekt statt mit einer Transaktion und speichert die Ereignis-ID des Treffers im Fall.

Belege

Jeder Treffer speichert, was er gesehen hat: das Aggregationsfenster, den berechneten Wert, den erwarteten Wert, stichprobenartig ausgewählte Ereignis-IDs und die Quelle jedes übereinstimmenden Felds. So kann ein Analyst eine serverseitig erfasste IP von einem clientseitigen Hinweis unterscheiden, bevor er einen Treffer bearbeitet. Die Konsole zeigt in der Ereignisseitenleiste neben jedem gematchten Feld dessen Quelle an.

Praxisbeispiele

Einzahlung, Token-Spiel, schnelle Auszahlung. Bedingung event.action_type eq withdrawal_requested sowie das oben beschriebene Verhältnis von Einsatz zu Einzahlung bei lte 0.1 über 24h.
Verhältnis von count(chargeback_opened) zu count(deposit_completed) pro Subjekt über 30d, gte 0.5. Gruppieren Sie nach event.payment.payment_fingerprint statt nach dem Subjekt, um ein Zahlungsmittel über mehrere Konten hinweg zu erkennen.
Die oben beschriebene Sequenz ato_drain mit add_score 90 und change_status DECLINED.
Die oben beschriebene Paarkorrelation. Erhöhen Sie value auf den Betrag, der für Ihre Tische wesentlich ist, und fügen Sie event.gameplay.game_id zu group_by hinzu, damit Spiele getrennt bleiben.
Bedingungen für event.action_type eq bot_signal_observed, event.bot.timing_variance_ms lte 10 und event.device.bot_score gte 90, mit add_tags. Kombinieren Sie dies mit einem distinct_count von event.device.fingerprint pro IP, um eine Farm statt eines einzelnen Skripts zu finden.
Bedingung für event.action_type eq self_exclusion_match und event.payload.re_registration_attempt eq true, mit Eskalation über open_case.

Weiter

Ereigniserfassung

Die Nachrichtenhülle, die zehn Kategorien und der Batch-Vertrag.

Regel-API

Regeln programmatisch erstellen, aktualisieren und rückwirkend testen.
Zuletzt geändert am 7. November 2026