Identidades e formação de perfis
Uma mesma pessoa pode aparecer de várias formas durante sua relação com uma empresa. Ela pode acessar o site sem fazer login, voltar mais tarde autenticada, usar outro aparelho e também conversar por outros canais, como um chat de suporte ou o WhatsApp.
A resolução de identidades é o que permite ao PrismaFlow reconhecer essas conexões e transformar eventos inicialmente separados em uma visão da mesma pessoa. Com ela, o histórico não fica preso a uma sessão, aparelho ou estado de autenticação.
Imagine alguém que acessa um site pela manhã sem fazer login e visualiza um produto. À noite, essa pessoa volta autenticada e tenta concluir a compra. Quando a aplicação envia as identidades que conectam os dois momentos, o PrismaFlow consegue manter a visualização e a tentativa de compra no mesmo perfil.
Esse é um diferencial importante para segmentos, computed traits e jornadas. Em vez de tratar cada sessão como uma pessoa nova, o PrismaFlow pode usar o histórico conectado para entender o contexto e continuar a comunicação.
Este guia explica como essa conexão acontece, quando um evento apenas completa um perfil existente e quando pode acontecer um merge.
Identidade, trait e propriedade não são a mesma coisa
Um identificador é um valor usado para reconhecer uma pessoa. Ele deve ser enviado dentro de identifiers.
Exemplos comuns são o ID do cliente no sistema de origem, email, telefone e um ID anônimo criado pela aplicação.
Informações usadas para contato ou reconhecimento direto também pertencem a identifiers. Essa área recebe o tratamento protegido do PrismaFlow. Não coloque email, telefone ou CPF em properties.
Traits descrevem o perfil, mas não são usados como identidade. O primeiro nome, por exemplo, pode ser um trait quando será usado para personalizar uma mensagem. As propriedades descrevem o acontecimento enviado pelo evento.
Como um perfil começa
Quando um evento chega, o PrismaFlow compara seus identificadores com os perfis existentes.
- Se nenhum perfil é encontrado, um perfil é criado.
- Se um perfil é encontrado, o evento passa a fazer parte de seu histórico.
- Se o evento traz um identificador novo junto de outro já conhecido, o novo valor é ligado ao perfil encontrado.
- Se os identificadores encontram perfis diferentes, existe um conflito de identidade. O PrismaFlow pode fazer um merge ou enviar o evento para a quarentena, conforme a configuração.
Um perfil não precisa nascer completo. Ele pode começar com uma identidade anônima e receber uma identidade conhecida mais tarde.
Exemplo 1: reconhecer o mesmo perfil
Uma fintech recebe dois eventos com o mesmo customer_id:
O primeiro evento cria ou encontra o perfil. No segundo, o PrismaFlow reconhece o mesmo customer_id e relaciona o PIX ao perfil já conhecido.
Isso não é um merge. Existe apenas um perfil durante todo o exemplo.
Exemplo 2: completar um perfil anônimo
Uma pessoa acessa o site pela manhã sem fazer login e visualiza um produto. Nesse momento, a aplicação conhece somente o identificador anônimo:
À noite, ela volta ao site, faz login e tenta concluir a compra. A aplicação envia o identificador anônimo junto do ID conhecido:
Como anonymous_id: device_123 já encontra um perfil, o PrismaFlow liga customer_id: customer_456 a esse mesmo perfil. A visualização da manhã e a tentativa de compra da noite passam a fazer parte da visão da mesma pessoa.
Esse caso também não precisa de merge. O evento apenas completou um perfil existente com uma identidade nova.
Exemplo 3: quando existe um merge
Agora imagine que os dados chegaram por caminhos separados:
- Uma integração criou um perfil usando
customer_id: customer_456. - Outra integração criou um perfil usando
email: cliente@example.com. - Mais tarde, um evento trouxe os dois valores juntos.
O PrismaFlow encontra dois perfis para o mesmo evento. Se customer_id e email estiverem configurados para permitir merge, os perfis são unidos.
Um perfil é mantido como principal. O outro não é apagado: ele fica registrado como incorporado ao principal. O histórico, as identidades e os dados relacionados passam a ser considerados em conjunto.
O merge também pode afetar segmentos e jornadas em andamento. Por isso, ele deve ser permitido somente para identidades confiáveis.
Exemplo 4: conflito enviado para a quarentena
Use o mesmo cenário anterior, mas considere que o tipo email não permite merge.
O evento encontra dois perfis, porém o PrismaFlow não pode uni-los automaticamente. Nesse caso, o evento segue para a quarentena como um conflito de identidade. Os dois perfis permanecem separados.
Isso protege a operação contra uma união que não foi autorizada pela configuração. Veja Quarentena de eventos [blocked] para entender como investigar eventos separados do fluxo normal.
Como configurar um tipo de identidade
Cada tipo possui decisões que mudam sua participação na formação dos perfis.
Força
A força representa quanto aquela identidade pesa quando mais de um perfil é encontrado. O valor vai de 1 a 5.
Um ID estável do cliente pode ter uma força maior. Uma identidade anônima ligada a um navegador ou aparelho costuma ter força menor.
A força não transforma um dado incerto em confiável. Ela serve para comparar identidades cuja origem e significado já são conhecidos.
Identidade única
Marque um tipo como único quando o mesmo valor só puder pertencer a uma pessoa dentro da aplicação.
Um customer_id gerado pelo sistema de origem costuma ser único. Um valor compartilhado por uma família, empresa ou aparelho precisa ser analisado antes de receber essa configuração.
Somente identidades únicas são usadas para escolher entre perfis candidatos. Uma identidade não única pode trazer contexto, mas não deve decidir sozinha quem é a pessoa.
Permissão de merge
Essa permissão autoriza o PrismaFlow a unir perfis quando uma identidade daquele tipo participa de um conflito.
O merge automático só acontece quando todos os tipos que encontraram os perfis permitem essa operação. Se um deles não permitir, o evento segue para a quarentena.
Ative essa opção apenas quando uma correspondência for confiável o bastante para reunir históricos. O produto não oferece uma operação comum para desfazer o merge depois.
Normalização
A normalização deixa valores equivalentes no mesmo formato antes da comparação.
Ela pode, por exemplo:
- remover espaços e converter um email para letras minúsculas;
- manter apenas os números de um documento;
- remover a formatação de um telefone.
Normalizar não confirma que o dado pertence à pessoa certa. Também não substitui a validação feita pela integração de origem.
Envie valores de identidade como texto, mesmo quando eles possuem apenas números:
Antes de mudar uma configuração
Uma alteração afeta as próximas resoluções, mas não reorganiza automaticamente todo o histórico já processado.
Antes de mudar força, unicidade, permissão de merge ou normalização:
- confirme o significado daquele identificador na origem;
- verifique se o valor pode ser compartilhado por pessoas diferentes;
- avalie os perfis que poderão se encontrar depois da mudança;
- trate a permissão de merge como uma decisão difícil de desfazer;
- normalize a integração para enviar o mesmo formato em todos os canais.
Uma configuração segura começa na origem
O PrismaFlow consegue relacionar apenas as evidências que recebe. Um customer_id reutilizado, um email preenchido com valor genérico ou um aparelho compartilhado podem representar pessoas diferentes.
Uma boa configuração não é a que transforma todos os campos em identidades. É a que usa poucos identificadores, com significado conhecido e comportamento consistente entre as integrações.
Revisão editorial
- Estado: Aprovado
- Fatos confirmados em: implementação atual dos serviços de ingestão, identidade, segmentos, jornadas e Customer 360
- Walkthrough: análise técnica da PF-1365 em 15/08/2026
- Aprovação: GREEN confirmado em 15/08/2026 na PF-1365
- Lacunas conhecidas: conciliação do comportamento técnico de conflitos, identidades não únicas, valores numéricos, mudanças de normalização e concorrência