Como o PrismaFlow decide a qual pessoa cada evento pertence — e como configurar seus identificadores (ID de login, e-mail, telefone, aparelho).
Toda vez que um evento chega, o PrismaFlow precisa responder uma pergunta: de quem é esse
evento? As identidades são as regras que respondem isso. Esse processo de descobrir o
dono do evento se chama resolução de identidade.Uma identidade (ou tipo de identidade) é a configuração de um tipo de identificador
que aparece nos seus eventos — por exemplo external_id (ID de login), email, phone ou
device_id. Ela não é o valor em si; é a regra de como aquele identificador se comporta na
hora de ligar um evento a uma pessoa (um perfil).
Pense nas identidades como chaves que ligam um evento a uma pessoa. Algumas chaves são
fortes e exclusivas (um ID de login); outras são fracas e compartilhadas (um aparelho que a
família inteira usa). Configurar bem essas chaves é o que mantém os perfis certos.
Não existe lista fixa de identificadores. Você não está preso a external_id, email,
phone ou device_id — esses são só exemplos comuns que usamos ao longo da página. Qualquer
chave que você enviar nos seus eventos vira um tipo de identidade: cpf, matricula,
id_assinatura, loyalty_card… o que fizer sentido pro seu negócio. O que importa não é o
nome, e sim configurar bem cada um (é único? qual a força? permite merge?).
Você não cria identidades na mão. Quando os primeiros eventos chegam, o PrismaFlow
detecta automaticamente cada tipo de identificador e cria um card para ele — só que ainda
como rascunho (não configurado). O nome do card é exatamente a chave que veio no evento, seja
ela qual for — você decide o que enviar.Enquanto um tipo está como rascunho, todo evento que depende dele vai para a
Quarentena de propósito — até você abrir o card e salvar a
configuração. É o jeito do PrismaFlow dizer “me diga como tratar essa chave antes de eu usar
de verdade”.
Depois dos primeiros eventos, abra cada card e salve — mesmo sem mudar nada. Isso marca o
tipo como configurado e libera os eventos da quarentena.
Clique em um card para abrir a configuração. Ela tem três seções:
1
Básico — nome e liga/desliga
O nome vem dos eventos e não pode ser alterado. O toggle Habilitado liga ou
desliga o processamento desse tipo — desabilitar não apaga nada, só faz o resolver
deixar de processar novos valores desse tipo.
Seção Básico: nome (vem dos eventos) e o toggle Habilitado.
2
Normalização — padronizar o valor
A normalização padroniza o valor antes de comparar, pra que o mesmo dado escrito de
formas diferentes seja tratado como igual. Há um campo de teste pra você digitar um valor e
ver como ele fica.
Seção Normalização: escolha o formato e teste o resultado.
Normalização
O que faz
Exemplo
Nenhuma
Usa o valor como veio
u_42 → u_42
E-mail (minúsculo)
Deixa minúsculo e tira espaços
Ana@X.com → ana@x.com
Telefone (E.164)
Só dígitos, com + na frente
(11) 99999-0000 → +5511999990000
Só dígitos
Remove tudo que não é número
123.456-7 → 1234567
Texto (minúsculo)
Minúsculo e sem espaços nas pontas
ABC → abc
3
Resolução & Unicidade — o coração da regra
Aqui você define como esse identificador participa de ligar eventos a perfis.
Seção Resolução & Unicidade: força, único e permitir merge.
Strength (força, 1–5)
O peso desse identificador. Quando mais de um perfil disputa um evento, vence o de
maior soma de força. Dê força alta aos identificadores mais confiáveis.
Único
Se ligado, cada valor desse tipo pertence a no máximo um perfil. Só identificadores
únicos servem de âncora para casar um evento a um perfil que já existe.
Permitir merge
Se ligado, um conflito (o mesmo evento apontando para 2+ perfis) funde os perfis
automaticamente. Se desligado, o evento vai para a Quarentena.
Ao salvar, o tipo passa a ser considerado configurado (e sai da quarentena).
Para cada evento, o PrismaFlow normaliza os identificadores e procura o perfil dono. A regra
central é simples:
Só identidades marcadas como “Único” casam um evento a um perfil existente. Um
identificador não-único (um device_id compartilhado) nunca casa sozinho.
Se mais de um perfil casar, a força (strength) decide o vencedor.
O resultado cai em um de três caminhos:
Nenhum perfil casa
O PrismaFlow cria um perfil novo e liga todos os identificadores a ele.
Um perfil casa
Usa o perfil existente e anexa os identificadores novos do evento.
Dois ou mais casam
Conflito. Aí entram as regras de merge — funde os perfis ou manda para a quarentena.
Esse é o lado mais dinâmico das identidades. Um merge acontece quando o mesmo evento
casa, via identificadores únicos, com dois ou mais perfis que hoje existem separados.A trava de segurança: o merge só dispara se todos os tipos envolvidos no casamento tiverem
“Permitir merge” ligado. Basta um deles não permitir para o evento ir à quarentena em vez de
fundir.
Imagine um e-commerce. A mesma pessoa apareceu fragmentada em vários perfis ao longo do tempo,
e um dia ela faz login autenticado — e o evento traz todos os identificadores juntos.Identidades configuradas:
Tipo
Força
Único
Permitir merge
external_id (ID de login)
5
Sim
Sim
email
4
Sim
Sim
phone
4
Sim
Sim
device_id (aparelho)
1
Não
Não
Como estavam os perfis antes do evento:
Perfil A — visto no app, conhecido pelo phone.
Perfil B — visto no site, conhecido pelo email.
Perfil C — cadastro antigo, conhecido pelo external_id.
Aí chega o evento de login, trazendo tudo de uma vez:
external_id aponta para o Perfil C, email para o B, phone para o A. O device_id é
não-único, então é ignorado nessa disputa.
3
Soma a força para escolher o vencedor
C = 5, B = 4, A = 4. Vence o Perfil C (external_id, força 5).
4
Confere a permissão de merge
Os tipos que casaram (external_id, email, phone) todos permitem merge → o merge
dispara.
5
Funde tudo no vencedor
Os perfis A e B são fundidos no C: os identificadores são repontados para o C e os traits
são consolidados. O device_id novo é anexado ao C.
6
Resultado
Um único Perfil C com external_id, email, phone, device_id e os dados
consolidados. A e B deixam de existir como perfis separados.
Se um dos tipos que casaram tivesse “Permitir merge” desligado (por exemplo o
email), nada seria fundido: o evento iria para a Quarentena como conflito, e os perfis
ficariam separados até você revisar. É uma trava proposital pra você não fundir perfis sem
querer.
Um roteiro prático, na ordem que costuma funcionar:
1
Deixe os primeiros eventos chegarem
Os tipos aparecem sozinhos como rascunho e os eventos vão para a quarentena — isso é o
“aquecimento” esperado, não um erro.
2
Abra cada card e salve
Isso marca o tipo como configurado e libera a quarentena. Depois, reprocesse os eventos que
ficaram parados.
3
Marque 'Único' com cuidado
Ligue Único nos identificadores que apontam para uma pessoa (external_id, email,
phone). Deixe não-único o que é compartilhável (device_id, cookie) — senão você
juntaria pessoas diferentes que usaram o mesmo aparelho.
4
Defina a força por confiabilidade
O identificador mais estável (ID de login) recebe força 5; e-mail e telefone, 3–4; sinais
fracos, 1–2. É o que decide o vencedor num conflito.
5
Escolha 'Permitir merge' com critério
Ligue só nos identificadores em que você confia para fundir perfis automaticamente. Deixar
um tipo conservador sem merge força a revisão manual via quarentena.
6
Ajuste a normalização e desabilite o que não usa
E-mail → minúsculo; telefone → E.164; documento → só dígitos. Tipos que você não quer
resolver podem ficar desabilitados (não apaga dados, só ignora).
