Saltar al contingut principal
Els esdeveniments són avaluats pel mateix motor que les transaccions. Hi ha un sol model de regla, un sol vocabulari de condicions i un sol conjunt d’accions: una regla només declara a quins tipus de registre s’aplica.

S’aplica a

scope.record_types determina en quins registres s’activa una regla.
Si l’omets, la regla continua sent només de transaccions. Totes les regles escrites abans que existissin els esdeveniments es comporten exactament com abans, i una regla mai no comença a coincidir amb inicis de sessió perquè el seu àmbit estava buit.
A la consola, això és el selector S’aplica a del pas Activador d’una regla. En triar Esdeveniments es mostra una llista de verificació Categories d’esdeveniments que restringeix la regla encara més; si la deixes tota desmarcada, la regla avalua totes les categories.
"__current__" vol dir «el mateix valor que l’esdeveniment avaluat», i així una regla expressa per subjecte, per dispositiu o per ronda sense haver-ne de nomenar cap. Els registres sense el valor agrupat mai no s’agrupen entre ells. Un esdeveniment sense empremta digital del dispositiu no és «el mateix dispositiu» que altres esdeveniments sense cap empremta digital, i un esdeveniment que no indica cap subjecte no és «el mateix subjecte» que altres esdeveniments anònims: quan l’esdeveniment avaluat no té valor per a un camp "__current__", aquesta agregació no coincideix, sigui quin sigui el seu operador.

Camps d’esdeveniments

Les condicions llegeixen rutes amb espai de noms. El vocabulari de transaccions que ja coneixes (action_type, subject_vendor_data, subject_ip_country, custom_values.<key>) també es resol en un esdeveniment. Els senyals del subjecte es guarden en memòria cau a l’usuari monitoritzat i no es recalculen per a cada esdeveniment, de manera que una regla els pot llegir a la velocitat de la ingestió.

Agregacions

Velocitat

Els reductors que ja fas servir amb les transaccions - count, sum, avg, min, max, distinct_count - sobre una window mòbil (30m, 24h, 7d, 30d).

Proporció

Dos reductors sobre la mateixa finestra. Així s’expressen les taxes d’aposta sobre dipòsit, de retirada sobre dipòsit, de bonificació sobre dipòsit i de contracàrrecs.
Dipositar 1.000, apostar 20 i sol·licitar una retirada: la proporció és 0,02, un clàssic blanqueig amb joc mínim.
Una proporció sense denominador mai no coincideix. Si no hi ha dipòsits, la proporció no és zero: no hi ha evidència, i activar-la marcaria tots els usuaris nous.

Seqüència

Predicats ordenats dins d’una finestra. Cada pas es basa en action_type, event_category o en un filtre match arbitrari, i pot requerir min_count ocurrències abans que la seqüència avanci.
Atac de farciment de credencials, després la presa de control amb MFA, després la redirecció del pagament i després el buidatge. La regla s’activa en l’esdeveniment que completa la cadena, i l’evidència coincident enumera els identificadors d’esdeveniment de cada pas. L’estat de la seqüència es guarda per regla i subjecte, de manera que avança a mesura que arriben els esdeveniments en lloc de tornar a recórrer la línia de temps. El progrés més antic que la finestra es descarta i no es compta.

Correlació

Una unió entre subjectes: aplicar una reducció a tots els esdeveniments que comparteixen el grup d’aquest esdeveniment.
"pair": true fa coincidir els dos extrems com a conjunt no ordenat, de manera que A→B i B→A cauen al mateix grup. Això permet que una sola regla vegi les dues parts d’una col·lusió. L’abocament de fitxes, les apostes oposades i l’autoderivació com a afiliat: tots tenen aquesta forma. Dona sempre a una regla de correlació filters que la restringeixin. Sense ells, considera tots els esdeveniments de la finestra.

Regles en temps real i asíncrones

Algunes regles poden respondre dins de la petició d’ingestió i altres no. Un esdeveniment amb regles pendents torna amb "correlation_pending": true. El seu estat i la seva puntuació s’actualitzen al mateix lloc quan acaba el procés asíncron. Tornar a executar-lo és idempotent, de manera que una regla mai aplica la seva puntuació dues vegades. Aquesta separació és intencionada: una consulta de xarxa entre subjectes no ha de fer esperar un inici de sessió.

Accions

El mateix vocabulari d’accions que les regles de transaccions: add_score, change_status, add_tags, add_note, add_to_list, open_case. Hi ha dues diferències en els esdeveniments:
  • change_status a AWAITING_USER és un resultat exclusiu de les transaccions (no hi ha flux de remediació per als esdeveniments) i s’aplica com a IN_REVIEW.
  • open_case enllaça el cas amb el subjecte en lloc d’una transacció, i registra l’identificador de l’esdeveniment coincident al cas.

Evidència

Cada coincidència emmagatzema el que ha vist: la finestra d’agregació, el valor calculat, el valor esperat, els identificadors d’esdeveniments mostrejats i la font de cada camp coincident. Així, un analista pot distingir una IP marcada pel servidor d’una pista subministrada pel client abans d’actuar sobre una coincidència. La consola mostra la font al costat de cada camp coincident al panell de l’esdeveniment.

Exemples pràctics

Dipòsit, joc amb tokens, retirada ràpida. Condició event.action_type eq withdrawal_requested, més la ràtio entre apostes i dipòsits en lte 0.1 durant 24h.
Ratio de count(chargeback_opened) respecte de count(deposit_completed) per subjecte durant 30d, gte 0.5. Agrupa per event.payment.payment_fingerprint en lloc del subjecte per detectar un mateix instrument de pagament en diversos comptes.
La seqüència ato_drain anterior, amb add_score 90 i change_status DECLINED.
La correlació de parells anterior. Augmenta value fins a l’import que sigui rellevant per a les teves taules, i afegeix event.gameplay.game_id a group_by per mantenir les partides separades.
Condicions sobre event.action_type eq bot_signal_observed, event.bot.timing_variance_ms lte 10 i event.device.bot_score gte 90, amb add_tags. Combina-ho amb un distinct_count de event.device.fingerprint per IP per detectar una granja en lloc d’un sol script.
Condició sobre event.action_type eq self_exclusion_match i event.payload.re_registration_attempt eq true, escalant-ho mitjançant open_case.

Següent

Ingestió d'esdeveniments

L’envolupant, les deu categories i el contracte de lots.

API de regles

Crea, actualitza i fes proves retrospectives de regles de manera programàtica.
Darrera modificació el 7 de novembre del 2026