User-ID e vários domínios: limites de identidade entre sites e aplicativos

Com o consentimento registrado, a propriedade sabe quem deixou cookie. Falta decidir quando ela consegue reconhecer a mesma pessoa em lugares diferentes: o site, a loja Shopify em domínio próprio e o aplicativo do clube. Sem regra, cada lugar cria um usuário novo, e o relatório conta três onde pode existir uma pessoa só.

O custo se espalha sem barulho. Usuários novos inflam, a retenção encolhe, e a campanha que trouxe a pessoa perde o crédito quando a compra fecha em outro domínio. A promessa do capítulo é modesta e verificável: ligar as interações quando existem os identificadores e as condições para isso, e saber exatamente onde essa ligação se perde.

Três identificadores, e só um atravessa aparelhos

O identificador de cliente é o número que o cookie do Analytics guarda no navegador; ele reconhece um navegador num aparelho. O identificador da instância do app nasce na instalação do aplicativo. O User-ID é o código que a empresa envia quando a pessoa faz login. Entre esses três identificadores, ele permite ligar interações de navegador, aparelho e app quando a implementação e a análise são compatíveis.

A ordem em que a propriedade tenta reconhecer alguém é a identidade dos relatórios, uma configuração de leitura. A combinada usa User-ID, depois o identificador do aparelho e depois a modelagem; a observada para no identificador do aparelho; a baseada no dispositivo ignora o User-ID. A página oficial não inclui o Google signals nessa ordem.

Limiares de dados são a regra que esconde linhas de relatório quando poucas pessoas poderiam ser identificadas. A ajuda do Google avisa que as opções com User-ID estão sujeitas a eles e que a propriedade precisa de volume de usuários logados para não esconder demais. Nenhum número de limiar é publicado. Por isso Marina usa a combinada na leitura mensal e alterna para a baseada no dispositivo quando um relatório pequeno some, sabendo que a troca muda a lente e não os dados.

Primeira história: a assinante que entra no site e no app

A implementação do User-ID segue três regras. Enviar no login, em todo evento enquanto a pessoa estiver logada, com um código interno. Parar de enviar no logout, porque o código esquecido no navegador liga a próxima pessoa ao histórico da anterior. E nunca enviar num aparelho compartilhado sem login individual, como o tablet do balcão da loja física.

Código interno não deixa de ser dado pessoal. Ele é uma pseudonimização: troca o nome por um número que a empresa sabe ligar de volta à pessoa. Por isso o User-ID segue as mesmas regras de finalidade e acesso do resto, e e-mail ou documento nunca entram no lugar dele, nem em versão embaralhada por hash, que continua ligada à pessoa.

Caio encontrou o User-ID guardado numa variável global do site que sobrevivia ao logout: a pessoa saía, outra entrava no mesmo navegador e o Analytics juntava as duas. A correção foi apagar a variável no logout e ler o código só da sessão autenticada. Sem isso, o clube teria retenção inflada por pessoas que nunca voltaram.

Segunda história: o clique que sai do site e compra na loja

O cookie de um domínio não atravessa para outro. Subdomínios do mesmo endereço principal, como o blog, costumam compartilhar o cookie, porque a configuração padrão da tag grava o cookie no domínio principal; mudar essa configuração ou recusar os cookies quebra a ligação. A loja em outro domínio não compartilha. A medição entre domínios resolve isso: com os domínios listados na configuração da tag, cada link entre eles ganha o parâmetro _gl, que leva o identificador do navegador para o outro lado.

O pagamento por Pix ou boleto passa por um domínio de terceiro e devolve a pessoa à loja. Conforme a duração da visita e a configuração, o retorno pode iniciar uma sessão com o meio de pagamento como referência e alterar a leitura da origem. A lista de referências indesejadas, na configuração da tag, diz ao Analytics para não tratar esses domínios como origem de tráfego.

Autorreferência é o sinal de que a ligação falhou: o próprio site aparece como origem de sessões da loja. A causa pode ser domínio faltando na lista, link montado por JavaScript sem o _gl, redirecionamento que apaga o parâmetro ou visita de alguém que recusou cookies. O relatório mostra o sintoma; a causa se descobre testando cada caminho.

Redirecionamentos também apagam identificadores de anúncio. Desde 30 de julho de 2026, o Analytics traz um diagnóstico para propriedades em que os identificadores agregados do Google Ads, GBRAID e parâmetros gad_, somem do endereço, com as páginas problemáticas e o jeito de corrigir. Sem eles, o clique pago pode aparecer como orgânico ou sem origem.

Os limites que nenhuma configuração resolve

Quem nunca faz login fica no identificador do aparelho, e dois aparelhos são dois usuários. Um bloqueador pode impedir parte ou toda a coleta pelo navegador. Quem recusa os cookies de análise não deixa identificador persistente; quando não há identificador disponível e a propriedade atende aos requisitos, a identidade combinada pode usar a modelagem descrita em Consentimento e Consent Mode: respeitar a escolha e ler as lacunas para estimar parte desse comportamento. A configuração existe para não perder quem podia ser reconhecido.

O Google signals mudou de papel duas vezes. Em fevereiro de 2024 saiu da ordem de identidade dos relatórios. Desde 15 de junho de 2026, controla só a associação dos dados do Analytics a usuários logados no Google para relatórios de comportamento, e a coleta de dados de anúncio passou a obedecer ao modo de consentimento. Os dados do signals ficam guardados por no máximo 26 meses.

O que mudou na Verde Vivo

O inventário mostrou 9,8% das sessões da loja com o próprio site como origem, o meio de pagamento como origem de 6% das compras e 4.100 usuários ativos nas telas de assinante para 2.900 assinantes. Caio implementou o User-ID com o código interno do HubSpot no site, na loja e no app, com envio no login e limpeza no logout. Marina listou os dois domínios na configuração da tag e pôs os domínios de pagamento nas referências indesejadas.

Os 3.050 usuários ativos ainda passam dos 2.900 assinantes e a causa ainda é hipótese. Marina separou quatro candidatas para testar: instalações anteriores ao login obrigatório na primeira tela que nunca foram reabertas, aparelhos extras de uma mesma assinante, contas canceladas dentro do período e contas de teste da equipe. A distribuição de crédito entre canais mudou depois da correção, e a leitura dessa mudança fica para Atribuição entre canais: por que os painéis disputam a mesma venda, porque mistura o efeito da correção com o das próprias campanhas.

O que pedir à equipe

Peça os dois testes da tabela das duas histórias, com captura: a conta de teste reconhecida no celular e no notebook, e o clique do site para a loja com _gl no endereço de chegada. Peça também a porcentagem de autorreferência da loja no último mês e a lista de caminhos que ainda a produzem.

Com a identidade definida, falta provar que cada evento chega certo antes de confiar nos números. O capítulo Validação, filtros e qualidade: aprovar a coleta com evidências monta essa prova.