Pular para o conteúdo principal
Eventos são avaliados pelo mesmo mecanismo que as transações. Há um único modelo de regra, um único vocabulário de condições e um único conjunto de ações: a regra apenas declara a quais tipos de registro se aplica.

Aplica-se a

scope.record_types define a quais registros uma regra se aplica.
Omiti-lo mantém a regra restrita a transações. Toda regra criada antes da existência dos eventos se comporta exatamente como antes, e uma regra nunca passa a corresponder a logins só porque seu escopo estava vazio.
No console, isso corresponde ao seletor Aplica-se a na etapa de gatilho da regra. Escolher Eventos exibe uma lista de verificação Categorias de eventos que restringe ainda mais a regra; deixe tudo desmarcado para avaliar todas as categorias.
"__current__" significa “o mesmo valor do evento que está sendo avaliado”. É assim que uma regra expressa por titular, por dispositivo ou por rodada sem nomear nenhum deles.

Campos de eventos

As condições leem caminhos com namespace. O vocabulário de transações que você já conhece (action_type, subject_vendor_data, subject_ip_country, custom_values.<key>) também pode ser usado em um evento. Os sinais do titular ficam em cache no usuário monitorado e não são recalculados a cada evento, então uma regra pode lê-los durante a ingestão.

Agregações

Velocidade

Os redutores que você já usa em transações (count, sum, avg, min, max, distinct_count) aplicados a uma janela móvel window (30m, 24h, 7d, 30d).

Razão

Dois redutores sobre a mesma janela. É assim que se expressam as razões entre apostas e depósitos, saques e depósitos, bônus e depósitos e as taxas de chargeback.
Deposite 1.000, aposte 20, solicite um saque, e a razão será 0,02: o clássico caso de lavagem com jogo mínimo.
Uma razão sem denominador nunca corresponde. Nenhum depósito não é uma razão igual a zero, é ausência de evidência, e disparar nesse caso sinalizaria todo usuário recém-criado.

Sequência

Predicados ordenados dentro de uma janela. Cada etapa é correspondida com base em action_type, event_category ou por um filtro match arbitrário, e pode exigir min_count ocorrências antes que a sequência avance.
Credential stuffing, depois a tomada de controle do MFA, depois o redirecionamento do pagamento e, por fim, o esvaziamento da conta. A regra é disparada no evento que completa a cadeia, e a evidência correspondente lista os ids de evento de cada etapa. O estado da sequência é mantido por regra e por titular, então ele avança à medida que os eventos chegam, sem reprocessar toda a linha do tempo. O progresso anterior à janela é descartado em vez de contabilizado.

Correlação

Uma junção entre titulares: aplica um redutor a todos os eventos que compartilham o grupo deste evento.
"pair": true corresponde às duas pontas como um conjunto não ordenado, de modo que A→B e B→A caem no mesmo grupo. É isso que permite que uma única regra enxergue as duas metades de um conluio. Chip dumping, apostas opostas e autoindicação de afiliados têm todos esse formato. Sempre defina filters restritivos para uma regra de correlação. Sem eles, ela considera todos os eventos da janela.

Regras em tempo real e assíncronas

Algumas regras podem retornar um resultado na própria requisição de ingestão, enquanto outras não. Um evento cujas regras ainda estão pendentes retorna com "correlation_pending": true. Seu status e sua pontuação são atualizados no próprio evento quando a etapa assíncrona é concluída; a reexecução é idempotente, então uma regra nunca aplica sua pontuação duas vezes. Essa divisão é intencional: uma consulta de rede entre titulares não deve fazer um login esperar.

Ações

O vocabulário de ações é o mesmo das regras de transação: add_score, change_status, add_tags, add_note, add_to_list, open_case. Há duas diferenças nos eventos:
  • change_status para AWAITING_USER é um resultado exclusivo de transações (não existe fluxo de remediação para eventos) e é aplicado como IN_REVIEW.
  • open_case vincula o caso ao sujeito em vez de a uma transação e registra no caso o ID do evento correspondente.

Evidências

Cada correspondência armazena o que foi observado: a janela de agregação, o valor calculado, o valor esperado, IDs de eventos amostrados e a origem de cada campo correspondente. Assim, um analista consegue distinguir um IP registrado pelo servidor de uma indicação fornecida pelo cliente antes de agir sobre uma correspondência. O console mostra a origem ao lado de cada campo correspondente no painel lateral do evento.

Exemplos práticos

Depósito, jogo simbólico, saque rápido. Condição event.action_type eq withdrawal_requested, mais a razão entre apostas e depósitos mostrada acima em lte 0.1 ao longo de 24h.
Razão entre count(chargeback_opened) e count(deposit_completed) por sujeito ao longo de 30d, gte 0.5. Agrupe por event.payment.payment_fingerprint em vez do sujeito para detectar um mesmo meio de pagamento usado em várias contas.
A sequência ato_drain mostrada acima, com add_score 90 e change_status DECLINED.
A correlação entre pares mostrada acima. Aumente value para o valor que for relevante para as suas mesas e adicione event.gameplay.game_id a group_by para manter os jogos separados.
Condições sobre event.action_type eq bot_signal_observed, event.bot.timing_variance_ms lte 10 e event.device.bot_score gte 90, com add_tags. Combine com um distinct_count de event.device.fingerprint por IP para encontrar uma fazenda de bots, e não apenas um script.
Condição sobre event.action_type eq self_exclusion_match e event.payload.re_registration_attempt eq true, escalando com open_case.

Próximos passos

Ingestão de eventos

O envelope, as dez categorias e o contrato de lote.

API de regras

Crie, atualize e faça testes retrospectivos de regras de forma programática.
Última modificação em 1 de novembro de 2026