Purchase), atualize o trait last_purchase_amount com o valor da compra.
A aba Computed Traits
As regras ficam na aba Computed Traits, dentro de Eventos.
Cada regra mostra o nome, se está ativa, a prioridade e o trait que ela alimenta. Ações: ativar/desativar, reprocessar, editar e excluir.
Como uma regra é montada
Uma regra é um fluxo de nós, da esquerda para a direita: Evento gatilho → (Filtro opcional) → Operação → Trait alvo.
O fluxo de uma regra: o evento que dispara, como o valor é calculado e qual trait recebe o resultado.
Criar uma regra
Clique em Nova regra e monte o fluxo, nó por nó:Evento gatilho — o que dispara a regra
Purchase@1. Toda
vez que esse evento chega e é atribuído a um perfil, a regra roda para aquele perfil; eventos de
outros tipos ou versões são ignorados por ela. Só aparecem eventos que já têm
definição ativa.
Escolha o evento e a versão que disparam a regra.
(Opcional) Filtro — quando aplicar

Após cada nó, escolha adicionar um Filtro ou uma Operação.
properties.payment_method), um
operador (é, não é, maior/menor que, está em, contém, existe) e um
valor. Todas as condições precisam ser verdadeiras (um “E”). Deixe o filtro vazio
para a regra valer para todos os eventos do gatilho.Exemplo: para contar só as compras pagas, filtre properties.status é paid.
Cada condição é um campo, um operador e um valor. Adicione quantas precisar.
Operação — como calcular o valor
1 a cada compra) ou um Caminho do evento (um valor de dentro do evento,
ex.: $.properties.amount).
Escolha a operação e diga de onde vem o valor: uma constante fixa ou um caminho do evento.
$.properties.amount (combina com somas, médias e máximos). As
operações que acumulam (Incrementar e Média) contam cada evento uma única vez — mesmo
em reprocessamento, sem dupla contagem.Trait alvo — qual trait recebe o valor
snake_case, ex.: total_compras). O tipo
(texto, número, booleano, data ou lista) é sugerido pela operação, mas você pode trocar — por
exemplo, forçar número se o valor chegar como texto. Se o valor não couber no tipo, a regra
é pulada para aquele evento, sem erro.Mais de uma regra pode alimentar o mesmo trait; nesse caso, a prioridade decide quem
vence (veja abaixo).
O trait que recebe o resultado: a chave (snake_case) e o tipo do valor.
Criar regra
Cuidado: o filtro não escreve false
Esse é o detalhe que mais pega as pessoas. Um filtro não devolve “verdadeiro ou falso” — ele
funciona como uma portaria: se o evento passa na condição, o fluxo continua e a operação
roda; se não passa, a regra inteira é ignorada e o trait fica exatamente como estava.
A consequência: uma regra com filtro que define um valor cria uma flag “grudenta” — uma
vez escrita, ela não volta atrás sozinha.
Exemplo: “o cliente pagou com PIX?”
Imagine esta regra:- Gatilho:
Purchase - Filtro:
payment_methodépix - Operação: Definir valor
true - Trait alvo:
paid_with_pix
true e fica true para sempre —
mesmo que todas as compras seguintes sejam no cartão. Se a sua intenção era “já pagou com PIX
alguma vez?”, está perfeito. Mas se você queria “o último pagamento foi via PIX?”, está
errado.
Como corrigir: uma segunda regra que faz o oposto
Para um flag que reflete o último evento, crie duas regras apontando para o mesmo trait — uma para cada caso:true, qualquer outro método vira
false. O trait passa a refletir sempre o último pagamento.
Prioridade: quando duas regras disputam o mesmo trait
Várias regras podem alimentar o mesmo trait. Se, no mesmo evento, mais de uma regra quiser escrever no mesmo trait, vence a de maior prioridade (número maior = mais importante). Em empate, o desempate é automático e sempre dá o mesmo resultado. A prioridade aparece como um selo no cartão da regra.Reprocessar (aplicar ao histórico)
Uma regra nova ou alterada vale só dos próximos eventos em diante — ela não recalcula o passado sozinha. Para aplicar a eventos antigos, clique em Reprocessar (↻) na regra.
Reprocessar: escolha a janela de tempo (ou um atalho) e inicie. A engine relê os eventos do período e reaplica a regra.