GBRAID e gad_ no GA4 podem desaparecer entre o clique no anúncio e a abertura da landing page. Quando isso acontece, o Analytics perde parte da informação usada para atribuir o tráfego pago e pode mostrar sessões como “(not set)” ou orgânicas. O novo diagnóstico do GA4 aponta URLs problemáticas; a correção exige descobrir em qual salto os parâmetros foram removidos.
Resumo rápido
- GBRAID e parâmetros gad_ carregam informações agregadas de campanha quando GCLID ou DCLID não bastam.
- Você não deve inventar esses valores: deve preservar os parâmetros adicionados pelo Google.
- O teste precisa acompanhar a URL por redirecionamentos, WordPress, cache, segurança e consentimento.
- Depois da correção, o aviso pode levar de 24 a 48 horas para refletir a mudança.
- Nem todo “(not set)” nasce deste erro; trate o alerta como pista, não como diagnóstico universal.
Fonte e revisão: conteúdo revisado em 20 de agosto de 2026 com a documentação oficial do Google Analytics. O diagnóstico de parâmetros agregados foi anunciado em 30 de julho de 2026.
GBRAID e gad_ no GA4: por que esses parâmetros importam?
O Google chama GBRAID e gad_ de identificadores agregados. Eles ajudam a recuperar dimensões de origem, mídia, plataforma de origem e campanha quando o identificador de clique padrão não consegue fornecer essas informações.
Isso pode ocorrer, por exemplo, quando o usuário nega o consentimento de ad_user_data. O GBRAID preserva informação de campanha de forma não exclusiva. Entre os parâmetros gad_, o gad_source identifica a origem do tráfego de anúncios, enquanto o gad_campaignid identifica a campanha.
O papel do site é não remover nem bloquear esses parâmetros. Eles chegam anexados à URL e precisam sobreviver até a página em que as tags do Google Ads e do Analytics são carregadas. Se uma regra de redirecionamento descarta a query string, a medição perde o contexto antes mesmo de a tag executar.
Cuidado: preservar parâmetros não significa guardá-los em banco, exibi-los ao usuário ou criar valores manualmente. O teste serve para confirmar que a infraestrutura não elimina os identificadores legítimos anexados pelo Google.
O que o alerta de parâmetros ausentes realmente mostra?
O diagnóstico de remoção de parâmetros aparece no indicador de qualidade de dados. O alerta informa que a precisão dos dados de campanha foi afetada e oferece a ação “Ver URLs” para listar os caminhos em que GBRAID ou gad_ não chegaram como esperado.
A lista é o ponto de partida. Ela não diz automaticamente se a causa está no servidor, no plugin de redirecionamento, no template, no cache, no gerenciador de consentimento ou em um salto externo. Também não prova que toda discrepância de atribuição vem do mesmo defeito.
Quando os parâmetros são removidos, o tráfego pago pode aparecer como “(not set)” ou orgânico. Isso altera leitura de campanha, CPA e ROAS. Antes de mexer em verba, confira a base do guia de Google Ads e separe problema de atribuição de problema de entrega.
Árvore de diagnóstico para encontrar o ponto de perda
Não comece trocando plugins ao acaso. Pegue uma URL afetada no GA4 e siga o caminho do clique até a página final. A pergunta em cada etapa é simples: a query string entrou e saiu deste salto completa?
| Sinal observado | Suspeita principal | Próximo teste |
|---|---|---|
| Parâmetros somem no primeiro 301/302 | Regra no servidor, CDN ou encurtador | Comparar cabeçalhos Location de cada salto |
| Chegam ao domínio, mas somem ao normalizar a URL | Plugin de redirect, permalink ou canonicalização | Desativar a regra em staging e repetir a mesma URL |
| A barra do navegador mantém a query, mas a tag não lê | Ordem de tags, consentimento ou script que reescreve history | Comparar antes e depois do carregamento e do consentimento |
| Só algumas landing pages falham | Template, construtor ou regra por caminho | Comparar uma URL afetada com uma saudável no mesmo domínio |
Regra prática
Se os parâmetros somem antes do HTML, investigue servidor, CDN e redirecionamentos. Se continuam na URL mas não chegam à medição, investigue consentimento, ordem das tags e scripts que mudam o endereço depois do carregamento.
Como testar uma URL sem esperar outro clique pago?
Use uma página de teste ou ambiente de staging sempre que possível. Acrescente valores fictícios e identificáveis à URL, apenas para observar se a infraestrutura preserva as chaves. Não reutilize o teste para analisar campanha e não trate esses valores como conversão real.
- Escolha uma landing page mostrada em “Ver URLs” e registre a URL original.
- Acrescente uma query de teste, como
?gbraid=teste-redirecionamento&gad_source=1&gad_campaignid=teste-campanha. - Abra as ferramentas do navegador, marque “Preserve log” na aba de rede e carregue a URL.
- Leia cada resposta 301, 302, 307 ou 308 e confira se o cabeçalho
Locationconserva todas as chaves. - Na página final, confirme a query visível e execute
window.location.searchno console. - Repita com consentimento aceito e recusado, em janela limpa, sem extensões que alterem tracking.
- Teste também uma landing page saudável para saber se a falha é global ou específica do template.
Se não houver redirecionamento visível no navegador, ainda pode existir uma reescrita interna no servidor. Nesse caso, use o inspetor de rede e os logs do host. Guarde horário, URL, status e destino de cada salto; sem esse registro, a equipe tende a corrigir uma camada e quebrar outra.
Onde o WordPress costuma remover a query string?
No WordPress, a perda costuma aparecer em regras criadas para forçar HTTPS, adicionar ou remover www, padronizar barra final, migrar slugs, encaminhar campanhas ou esconder parâmetros. Plugins de cache e segurança também podem normalizar URLs ou responder com um destino que não reaproveita a query original.
Construtores de landing page podem executar redirecionamentos em JavaScript. Temas e plugins podem chamar history.replaceState para limpar o endereço. Isso não é necessariamente errado, mas precisa acontecer depois que a medição apropriada leu os parâmetros — e deve ser validado nos cenários de consentimento aplicáveis.
Ao revisar o banner e a ordem das tags, use o checklist de Consent Mode no WordPress. O objetivo não é contornar a escolha do usuário; é preservar a URL e permitir que a implementação do Google opere conforme o consentimento concedido.
Evite a correção perigosa: não crie uma allowlist tão estreita que descarte todo parâmetro desconhecido. Novos identificadores podem surgir. Prefira repassar a query string por padrão e bloquear apenas o que tiver motivo técnico, de privacidade ou segurança documentado.
O que comparar antes e depois da correção?
A primeira validação é técnica: a mesma URL de teste atravessa todos os saltos e chega intacta à página final. A segunda é operacional: o diagnóstico do GA4 deixa de listar as URLs corrigidas depois do prazo de processamento informado pelo Google.
Depois, acompanhe a proporção de sessões pagas, “(not set)” e orgânicas nas páginas afetadas. Não prometa que o orgânico vai cair na mesma medida em que o pago sobe; consentimento, janela de atribuição, modelagem e outros defeitos continuam influenciando os relatórios.
Se a empresa importa vendas do CRM, verifique também a cadeia de identificadores e o processo descrito no guia de conversões offline do Google Ads. Corrigir a landing page não conserta sozinho um identificador perdido na captura do lead.
Checklist de encerramento
- URLs do alerta foram exportadas e priorizadas por investimento ou tráfego;
- cada redirecionamento preserva GBRAID e parâmetros gad_;
- o teste foi repetido com estados de consentimento relevantes;
- WordPress, CDN, cache, segurança e template foram avaliados separadamente;
- a alteração foi registrada com horário e possibilidade de reversão;
- o GA4 será revisado após 24 a 48 horas, sem atribuir toda variação à correção.
Diferenças entre GCLID, GBRAID e gad_
| Identificador | Papel resumido | Ação no site |
|---|---|---|
| GCLID / DCLID | Identificadores padrão de clique usados na medição de anúncios | Preservar durante navegação e captura aplicável |
| GBRAID | Informação agregada de campanha com proteção de privacidade | Não remover nem bloquear na landing page |
| gad_source / gad_campaignid | Origem do anúncio e campanha em formato agregado | Repassar a query completa em todos os saltos |
Para entender o GA4 além deste alerta, o roteiro gratuito de GA4 organiza configuração, relatórios e validação sem misturar conceitos.
Perguntas frequentes
Preciso adicionar GBRAID e gad_ manualmente aos anúncios?
Não. O Google adiciona os parâmetros quando eles são necessários. Sua responsabilidade é evitar que redirecionamentos, templates e scripts removam os valores legítimos antes que as tags os leiam.
Todo “(not set)” no GA4 é causado por parâmetros removidos?
Não. O alerta confirma um problema específico de cobertura de atribuição, mas “(not set)” também pode ter outras causas. Use as URLs listadas pelo diagnóstico para delimitar a investigação.
Quanto tempo o GA4 leva para reconhecer a correção?
A documentação informa que a mudança pode levar até 48 horas para aparecer no diagnóstico. Faça o readback técnico imediatamente e agende a conferência do GA4 para depois desse intervalo.
Posso limpar os parâmetros da barra depois do carregamento?
Só depois de validar que a medição os leu no momento correto e em todos os estados de consentimento aplicáveis. Uma limpeza antecipada pode recriar exatamente o defeito que o alerta identifica.
Conclusão
GBRAID e gad_ no GA4 são um problema de percurso, não apenas de configuração dentro do Analytics. A correção começa na URL listada pelo diagnóstico e termina quando cada redirecionamento, template e camada de consentimento preserva os identificadores até a leitura das tags.
Registre o caminho, teste uma variável por vez e aguarde o prazo de processamento antes de concluir o efeito. Isso transforma um alerta genérico em uma auditoria verificável — e evita decidir orçamento com atribuição incompleta.
Você encontrou a perda no servidor, no WordPress ou na camada de consentimento? Compartilhe nos comentários qual salto removeu os parâmetros.
