Anônimo no site, logado no app, outro perfil no CRM: o mesmo cliente vira três pessoas. Veja como escolher o identificador certo e enviá-lo em cada ferramenta sem duplicar perfis.
Índice do artigo
- Por que a identificação quebra
- As 4 regras de um bom User ID
- Anônimo x identificado: o momento da ligação
- Como cada ferramenta recebe a identidade
- Unidade de experimento: sessão ou usuário?
- Privacidade: identidade não é dado pessoal
- Os erros que mais aparecem
- Perguntas frequentes
Por que a identificação quebra
Toda ferramenta cria um identificador próprio para o visitante: cookie no navegador, Install ID no app. Esse identificador se perde quando o cookie expira, o usuário troca de dispositivo, reinstala o app ou limpa o navegador. O único identificador que sobrevive a tudo isso é o que você controla: o ID do usuário no seu banco de dados.
Em uma frase: o User ID é a ponte entre o visitante anônimo que as ferramentas enxergam e o cliente que o seu negócio conhece.
As 4 regras de um bom User ID
- Único: um ID por pessoa.
- Estável: nunca muda. O Hotjar trata um ID alterado como outra pessoa, e isso vale para praticamente todas as ferramentas.
- Sem dado pessoal: não use e-mail, CPF ou telefone. E-mail, inclusive, muda com frequência.
- Igual em todas as ferramentas: o mesmo valor no GA4, no replay, no teste A/B e no CRM.
A chave primária do cliente no seu banco (ou um hash estável dela) atende às quatro.
Anônimo x identificado: o momento da ligação
A identificação acontece no login, no cadastro ou em qualquer autenticação silenciosa (link mágico, token de deep link). Nesse momento, a ferramenta liga o histórico anônimo daquele dispositivo ao User ID.
O Hotjar documenta bem esse comportamento: sessões anteriores no mesmo dispositivo, feitas antes do login, passam a ser associadas ao User ID quando a identificação acontece. A UXCam faz o mesmo com o Install ID, e o vínculo persiste depois de criado.
Boa prática: chame a identificação a cada carregamento de página (ou a cada sessão, em app) enquanto o usuário estiver logado, não só no momento do login. Em single-page apps, repita após mudança de rota.
Como cada ferramenta recebe a identidade
- Microsoft Clarity: window.clarity(“identify”, “custom-id”), com sessão, página e nome amigável opcionais.
- Hotjar: hj(‘identify’, userId, { atributos }), ou null quando o usuário não é conhecido; disponível nos planos Business e Scale.
- Fullstory: FS(‘setIdentity’, { uid, properties }); use a versão assíncrona para garantir a ordem antes de eventos.
- UXCam: UXCam.setUserIdentity(id), uma vez por sessão, depois da inicialização do SDK.
- CleverTap: clevertap.onUserLogin.push({ Site: { Identity } }). Nunca profile.push no login, para não misturar perfis em aparelho compartilhado.
- SAP Emarsys: setCustomerId ou setEmail no Web Extend, só quando há usuário identificado.
- Croct: ligação do perfil ao ID da aplicação nas áreas logadas.
- ABsmartly e VWO FME: o ID entra como unidade do contexto (context.units ou context.id) e define a variação.
Centralize isso na camada de dados: um push com user_id após o login, lido pelo GTM, que dispara a identificação em cada ferramenta.
Unidade de experimento: sessão ou usuário?
Em testes A/B, a unidade define quem é “a mesma pessoa”. Com unidade de sessão, o mesmo usuário pode cair em variantes diferentes em visitas diferentes. Com unidade de usuário, a experiência é consistente, mas só vale para quem está logado.
Regra prática: testes de aquisição e primeira visita usam ID anônimo estável (cookie first-party); testes de produto em área logada usam o User ID. No ABsmartly, várias unidades (session_id, user_id) podem coexistir no mesmo context.
Privacidade: identidade não é dado pessoal
O User ID existe justamente para que você não precise enviar dado pessoal às ferramentas. Quando uma ferramenta precisa de e-mail (CRM, por exemplo), use o campo reservado para isso e só com base legal definida pelo jurídico. No Hotjar, e-mail só é aceito no atributo reservado email; em qualquer outro atributo de texto, é rejeitado.
Mantenha também um processo para atender pedidos de exclusão: com o User ID, é possível localizar e apagar os dados do titular nas ferramentas que oferecem consulta e exclusão por ID.
Os erros que mais aparecem
- E-mail como User ID.
- Identificação chamada só no login, e nunca de novo.
- IDs diferentes para a mesma pessoa em ferramentas diferentes.
- Uso de profile.push no login da CleverTap.
- Evento disparado antes da identidade estar aplicada.
Perguntas frequentes
O que é User ID em analytics?
É o identificador do cliente no seu próprio sistema, enviado às ferramentas para ligar sessões e dispositivos à mesma pessoa.
Posso usar o e-mail como User ID?
Não é recomendado: e-mail é dado pessoal e muda com frequência, o que fragmenta o histórico.
Quando devo enviar o User ID?
No login, no cadastro e em cada carregamento de página ou sessão enquanto o usuário estiver autenticado.
O que acontece com o histórico anônimo quando o usuário faz login?
Em ferramentas como Hotjar e UXCam, as sessões anteriores do mesmo dispositivo passam a ser associadas ao User ID.
Qual unidade usar em testes A/B?
ID anônimo estável para testes de aquisição; User ID para testes em área logada.
User ID é dado pessoal pela LGPD?
Pode ser considerado dado pessoal quando permite identificar o titular combinado a outras informações. Por isso, trate-o com as mesmas regras de governança e consulte o jurídico.