A Crise do Perfil de Usuário: como não perder seus usuários no vazio de dados

Escrito por Facundo Piaggio (Solutions Architect)

É uma situação familiar. Você abre o dashboard e vê 10.000 “Usuários Ativos Mensais”, mas o banco de dados diz que só há 5.000. De onde vieram esses usuários fantasma? Em geral, é porque a estratégia de perfil de usuário funciona mais como uma “sugestão” do que como uma regra, e o stack inteiro está pagando o preço.

Definir bem o perfil de usuário entre Braze e Amplitude é uma das decisões de infraestrutura mais subestimadas que um time de crescimento pode tomar. Para orquestrar ciclos de vida no Braze e fazer análises de comportamento no Amplitude, é preciso falar o idioma deles. Esse idioma é escrito em IDs, e este guia explica como fazer isso da forma certa.

A Regra de Ouro: a política do “mesmo ID”

Para manter a sanidade, o user_id do Amplitude deve coincidir com o external_id do Braze, exatamente, sempre.

Quando esses dois valores estão alinhados, o stack se torna um ecossistema unificado. É possível ver um usuário abandonar um funil no Amplitude e, imediatamente, disparar uma notificação push de “carrinho abandonado” no Braze, porque ambas as ferramentas reconhecem User_123 como a mesma pessoa.

Como o Amplitude age como intermediário

O Amplitude não se limita ao ID do banco de dados; usa um sistema em camadas para garantir que a jornada de um usuário não fique fragmentada entre dispositivos.

A Trindade: O Amplitude rastreia cada usuário por meio de uma combinação de amplitude_id (interno), device_id e o user_id.

A Fusão: Se um usuário navega anonimamente pelo iPhone (device_A) e depois faz login como user_123, o Amplitude vincula esse device_id ao user_id. Se esse mesmo usuário fizer login em um iPad (device_B), o Amplitude reconhece user_123 e unifica toda a atividade em um único perfil.

Braze: o external_id ou nada

O Braze funciona de forma similar, mas com mais em jogo, porque gerencia a comunicação direta com os usuários. Embora o Braze rastreie muitos identificadores, o external_id é o único que realmente importa para identificar o perfil de usuário no Braze e Amplitude.

Os “outros” identificadores e por que ficam aquém

O requisito do changeUser()

O SDK do Braze se “prende” a um perfil assim que o carrega. Para passar de um perfil de visitante anônimo para um perfil de usuário conhecido, a aplicação deve chamar:

changeUser(external_id)

⚠️ O problema: A aplicação precisa ter acesso a esse ID antes de poder informar ao Braze quem é o usuário. Se o external_id não estiver disponível, a troca não pode acontecer.

Isso se torna ainda mais crítico em casos como dispositivos compartilhados. Sem o external_id, é impossível forçar o SDK do Braze a trocar o usuário que ele aponta internamente com atributos e eventos, e o SDK fica bloqueado no primeiro usuário que encontrou.

Nesses casos, restam duas opções pouco atraentes: a fusão de perfis (que arrisca sobrescrever dados críticos) ou chamar o método wipeData(). Vale o aviso: o wipeData() costuma trazer um novo conjunto de problemas relacionados à persistência de dados e ao rastreamento de sessões.

Por que a fusão manual é uma armadilha de manutenção

É possível ignorar o changeUser() e tentar resolver as coisas depois usando o endpoint /users/merge. Mas essa abordagem tem seus custos:

A armadilha do triplo fluxo: É preciso gerenciar perfeitamente a lógica para três cenários distintos: Login, Cadastro e Início do app. Se a lógica falhar em um único deles, perfis duplicados são gerados.

Limites de requisições: Em escala, fazer chamadas a uma API para fundir perfis manualmente vai atingir rapidamente os rate limits, gerando lacunas nos dados.

Atraso de sincronização: As fusões manuais nem sempre são instantâneas. O email de “Boas-vindas” pode ser enviado ao perfil duplicado antes que a fusão seja concluída.

O ideal é estabelecer um mecanismo para identificar os usuários anônimos, de modo que quando um perfil passe por qualquer um dos fluxos acima, seja feita uma requisição ao endpoint /users/merge.

Um ponto importante: esse endpoint deve ser executado a partir de um ambiente de back-end. Por razões de segurança, o Braze não permite chamadas à API diretamente do front-end, então os dados de fusão precisam ser transmitidos a um serviço interno primeiro. Isso significa que também é necessário considerar a escalabilidade desse serviço interno, especialmente ao lidar com alto volume de usuários ou sessões simultâneas.

TL;DR

Tentar corrigir o perfil de usuário quando os dados já estão bagunçados não é a solução.

1. Expor o ID — É necessário que a aplicação tenha acesso fácil ao ID único do banco de dados do usuário, ou a um valor com hash derivado de um campo como o email.
2. Inicializar cedo — Chamar setUserId no Amplitude e changeUser no Braze assim que o ID estiver disponível.
3. Manter a consistência — Usar exatamente a mesma string em ambas as ferramentas. Sem exceções.

Este é exatamente o tipo de problema em que o Minders vive.

Arquitetura de perfil de usuário no Braze e Amplitude, rastreamento de eventos, orquestação de ciclos de vida: ajudamos produtos digitais a resolver isso desde o início, para que os dados reflitam a realidade e as ferramentas trabalhem juntas em vez de contra si mesmas.

Se o stack está mais bagunçado do que deveria, vamos conversar.