Erros de modelo de rastreamento e ValueTrack: correção

Cerca de 1 em cada 8 contas do Google Ads auditadas em 2026 tem pelo menos um modelo de monitorização que silenciosamente estraga os seus próprios URLs de clique — e o dano tem dois gumes: o anúncio é reprovado por "destino não funcional" enquanto o gclid que alimenta os seus dados de conversão escapa. Os erros de URL parecem um problema técnico de nicho, mas situam-se a montante de tudo o que mede, pelo que um único modelo defeituoso pode tanto interromper a publicação como corromper os números sobre os quais faz lances.

Este guia desfaz o emaranhado dos modelos de monitorização e parâmetros ValueTrack, explica exatamente porque é que os URLs finais falham na revisão e dá-lhe uma forma repetível de criar, testar e publicar URLs que passam na política e preservam os dados. Para analisar a sua conta em busca de destinos quebrados e lacunas de monitorização automaticamente, execute a nossa auditoria gratuita de 5 eixos do Google Ads.

Atualizado a 2026-05-25 com a validação atual de modelos de monitorização, o comportamento do ValueTrack e a interação com o Consent Mode observados em contas dos Estados Unidos, Reino Unido e Europa.

TL;DR — o que se estraga e como o corrigir :

Destino não funcional diz respeito ao URL de clique montado, não à página que vê — corrija o modelo, não a página. 2. Mantenha o token lpurl em primeiro lugar e deixe o tag automático adicionar o gclid. 3. Redirecionamentos e barras de consentimento são as principais causas de um gclid perdido. 4. O sufixo de URL final transporta os parâmetros UTM com mais segurança do que um monitorizador de cliques anteposto. 5. Teste duas vezes — o botão do produto mais um clique real ao vivo — antes de publicar para uma conta inteira.

O que são modelos de monitorização e parâmetros ValueTrack?

O Google Ads divide o endereço a que um utilizador chega em dois campos desacoplados, e compreender essa divisão é o jogo todo.

URL final: a página de destino real — o destino que um utilizador vê. Tem de resolver para uma página funcional no seu domínio apresentado.

Modelo de monitorização: um campo separado que indica à Google como montar o URL de clique envolvendo ou anexando monitorização em torno do URL final. Usa o token ValueTrack {lpurl} como marcador de posição para o URL final codificado.

Parâmetros ValueTrack: marcadores de posição dinâmicos que a Google substitui no momento do clique. O token {lpurl} torna-se o seu URL final; tokens como {campaignid}, {adgroupid}, {keyword} e {device} injetam detalhes do leilão para que possa atribuir cliques sem codificar valores manualmente.

O desacoplamento é o objetivo: define a monitorização de uma só vez ao nível da conta, campanha, grupo de anúncios ou palavra-chave, e cada URL final herda-a. Mude de fornecedor de medição e edita 1 campo, não 500 anúncios. Para os fundamentos da medição que isto alimenta, veja o nosso guia de monitorização de conversões.

Porque é que os URLs finais falham com "destino não funcional"?

"Destino não funcional" é uma reprovação de política, e quase nunca significa que a sua página de destino está em baixo. Significa que o rastreador da Google seguiu o URL de clique montado — modelo mais URL final codificado mais parâmetros — e não conseguiu chegar a uma página válida. Há cinco causas recorrentes.

Codificação quebrada — Quando {lpurl} não é mantido em primeiro lugar, ou um valor de parâmetro contém um espaço ou símbolo não codificado, o URL juntado fica malformado e resolve para nada.

Cadeias de redirecionamento — Um URL final que redireciona com 301 através de 2 ou 3 saltos pode eliminar parâmetros ou exceder a tolerância do rastreador, pelo que o destino "não funciona" mesmo que um humano acabe por chegar.

Incompatibilidade de domínio — A Google verifica que o URL final e o URL apresentado partilham um domínio. Encaminhe o clique através de um monitorizador noutro domínio sem o configurar corretamente e a verificação falha.

Tempos limite e erros — Um servidor lento, um 404 numa página desatualizada ou um 5xx durante o rastreio são todos interpretados como um destino quebrado.

Colisões de parâmetros — Definir o mesmo parâmetro duas vezes, ou anexar ? onde já existe um, produz um endereço que o servidor rejeita.

Para a taxonomia mais ampla de reprovações em que isto se enquadra, veja o nosso guia de anúncios reprovados e violações de política.

Como criar um modelo correto com lpurl e gclid

Um modelo correto é quase sempre aborrecido, e aborrecido é o objetivo. Construa-o por esta ordem.

Comece pelo token — Coloque {lpurl} em primeiro lugar, depois um ponto de interrogação e depois os seus parâmetros ligados por e comerciais. O token expande-se para o seu URL final codificado em URL, pelo que tudo o que vem depois do ? se torna parâmetros de query nesse destino.

Deixe o tag automático gerir o gclid — Não codifique manualmente um gclid no modelo. Ative o tag automático ao nível da conta e a Google anexa o gclid a cada clique. É isso que a importação de conversões e as Enhanced Conversions usam para associar, por isso deixe a Google geri-lo em vez de arriscar um valor desatualizado ou duplicado.

Mantenha-o minimalista — Adicione apenas os parâmetros que vai realmente ler. Cada token extra é mais uma coisa que pode quebrar a codificação ou colidir.

Use o sufixo para anexos — Se tudo o que precisa é adicionar etiquetas UTM, prefira o sufixo de URL final em vez de um modelo; ele anexa parâmetros sem envolver o endereço, pelo que sobrevive aos redirecionamentos de forma mais fiável. Reserve o modelo para encaminhar cliques através de um serviço de medição de terceiros.

Se está a integrar isto numa configuração do lado do servidor, o nosso guia de GTM do lado do servidor aborda como o gclid flui a jusante.

Como passar parâmetros UTM e personalizados de forma limpa

Parâmetros limpos são a diferença entre uma análise em que confia e um emaranhado de fontes incompatíveis. Quatro regras mantêm-nos arrumados.

Uma única fonte de verdade — Decida se as etiquetas UTM vivem no sufixo de URL final ou no modelo de monitorização, e nunca as divida entre ambos. Valores UTM duplicados são a causa mais comum do caos de origem/meio no GA4.

Faça corresponder o GA4 e o Ads — Mantenha o seu utm_source, utm_medium e utm_campaign consistentes com a forma como o clique recebe o tag automático, para que as conversões importadas se alinhem. O nosso guia de configuração do GA4 e importação de conversões mostra o mapeamento em detalhe.

Codifique cada valor — Um espaço, um e comercial ou um caractere acentuado dentro de um valor tem de ser codificado em URL ou irá truncar a query string. Construa as suas etiquetas com uma ferramenta em vez de manualmente — o nosso construtor de UTM codifica os valores por si.

Prefira ValueTrack a codificar manualmente — Use {campaignid} ou {keyword} em vez de escrever nomes de campanhas; o token dinâmico está sempre correto e nunca se desvia quando renomeia coisas.

Como testar URLs antes de entrarem em funcionamento

A maioria dos desastres de URL é apanhada em 5 minutos de testes e completamente ignorada sem eles. Execute duas verificações independentes.

O botão Testar do produto — Ao lado do campo do modelo de monitorização, o botão Testar expande cada token ValueTrack e abre o URL montado. Confirme que devolve uma página 200 no domínio correto com os seus parâmetros presentes. Isto apanha erros de codificação e sintaxe instantaneamente.

Um clique real ao vivo — O teste do produto não simula redirecionamentos nem barras de consentimento, por isso termine com um clique real. Ative o tag automático, clique num anúncio ao vivo num dispositivo de teste e observe a barra de endereço através de cada salto. Confirme que o gclid e os seus parâmetros UTM chegam à página final renderizada.

Confirmação na análise — Abra a vista em tempo real da sua análise e verifique que o clique se regista com a origem/meio corretos. Se o gclid estiver presente no URL mas a sessão aparecer como direta, tem um problema de tagging ou consentimento a jusante, não um problema de modelo.

Trate qualquer alteração de modelo como uma implementação: teste em 1 anúncio, confirme e depois implemente.

A tabela de correção de erros de URL

Trabalhe esta tabela de cima para baixo — está ordenada da correção mais rápida e comum até à mais profunda.

Nunca codifique manualmente um gclid no seu modelo :

Escrever um valor de gclid fixo, ou copiar um de um clique anterior, faz entrar todos os visitantes com o mesmo ID de clique — pelo que a importação de conversões associa-os todos a um único clique e os seus dados colapsam. Deixe o tag automático anexar um gclid novo e único no momento do clique. Se vir um gclid literal pousado no seu modelo de monitorização, remova-o antes de fazer qualquer outra coisa.

Como os modelos de monitorização interagem com redirecionamentos e consentimento

O último quilómetro — redirecionamentos e consentimento — é onde modelos corretamente construídos ainda assim perdem dados, por isso merece a sua própria lista de verificação.

Redirecionamentos — Cada 301 ou 302 entre o clique e a página final é uma oportunidade para eliminar a query string. Se tiver de encaminhar através de um redirecionamento, confirme que ele reencaminha todos os parâmetros e mantenha a cadeia em 1 salto. Um redirecionamento para um domínio diferente também arrisca a reprovação por "destino não funcional".

Consent Mode — Sob o Consent Mode v2, uma barra que recarrega ou reescreve o URL antes de o utilizador consentir pode eliminar o gclid do endereço. Configure a barra para preservar os parâmetros de query durante a interação de consentimento e confirme que o gclid continua presente depois de o utilizador aceitar.

Saltos de HTTP e www — Um redirecionamento silencioso de HTTP para HTTPS, ou de um domínio simples para www, conta como um salto. Defina o seu canónico para que o clique chegue diretamente à forma final.

Recuperação do lado do servidor — Se a perda no front-end for inevitável, capture o gclid do lado do servidor no primeiro pedido e persista-o. O mesmo padrão sustenta as importações de conversões offline, onde o gclid viaja com o lead de volta para o Google Ads.

Assim que o caminho estiver limpo, fixe-o: volte a testar após qualquer alteração de página de destino ou de CMS e audite os URLs antes de cada grande lançamento. Para encontrar destinos quebrados e parâmetros perdidos numa conta inteira de uma só vez, execute a auditoria gratuita de 5 eixos da SteerAds.

Fontes

Fontes oficiais consultadas para este guia:

FAQ

O que significa 'destino não funcional' no Google Ads?

Significa que o rastreador da Google seguiu o URL produzido pelo seu modelo de monitorização e não conseguiu chegar a uma página de destino funcional — esgotou o tempo limite, devolveu um erro 4xx ou 5xx, entrou num ciclo de redirecionamentos ou chegou a um domínio que não corresponde ao seu URL apresentado. A reprovação diz respeito ao URL de clique montado, não à página que vê no seu navegador, pelo que a causa mais comum é um modelo que constrói um endereço malformado depois de o token lpurl e os parâmetros serem juntados. Corrija o modelo, volte a submeter e a revisão costuma ficar resolvida no espaço de um dia útil.

O que é o token lpurl num modelo de monitorização?

O token lpurl é um marcador de posição ValueTrack que a Google substitui pelo seu URL final no momento do clique, codificado em URL para que possa ser transportado em segurança como parâmetro. Um modelo de monitorização começa normalmente por esse token seguido dos seus parâmetros de monitorização, por exemplo o token lpurl, depois um ponto de interrogação e depois as suas etiquetas UTM. Como a página de destino é injetada dinamicamente, pode alterar a monitorização de uma só vez ao nível da conta em vez de editar todos os anúncios. Mantenha sempre o token lpurl em primeiro lugar, a menos que esteja a encaminhar intencionalmente através de um monitorizador de cliques que espera um destino codificado.

Porque é que o meu gclid não está a passar para a minha página de destino?

Um gclid perdido deve-se quase sempre a um redirecionamento ou a um modelo que sobrescreve a query string. Se o seu URL final redirecionar com 301 para outro endereço, muitas configurações eliminam os parâmetros originais, a menos que o redirecionamento os reencaminhe explicitamente. As barras de consentimento que recarregam a página, o JavaScript que reescreve o URL e os saltos de HTTP para HTTPS ou para www são os culpados habituais. Teste o caminho completo do clique de ponta a ponta: clique num anúncio real, observe a barra de endereço e confirme que o gclid sobrevive a cada salto, desde o primeiro pedido até à página final renderizada.

Qual é a diferença entre um URL final e um modelo de monitorização?

O URL final é a página real onde o utilizador chega — o destino. O modelo de monitorização é um campo separado que indica à Google como montar o URL de clique envolvendo ou anexando informações de monitorização em torno desse URL final através do token lpurl. Os dois estão desacoplados de propósito: pode atualizar a monitorização ao nível da conta, campanha, grupo de anúncios ou palavra-chave sem tocar num único URL final. A Google valida que o modelo mais o URL final resolvem para o mesmo domínio de destino, razão pela qual uma incompatibilidade desencadeia 'destino não funcional'.

Os modelos de monitorização afetam a monitorização de conversões e o Smart Bidding?

Sim, diretamente. Se o modelo eliminar o gclid, as conversões importadas e as Enhanced Conversions não podem ser associadas de volta ao clique, pelo que as suas contagens de conversões caem e o Smart Bidding perde o sinal que otimiza. Mesmo uma perda parcial — digamos, um salto de redirecionamento que elimina parâmetros apenas em dispositivos móveis — distorce silenciosamente os seus dados e os seus lances. É por isto que os erros de URL não são apenas um aborrecimento de política: um modelo quebrado deixa o algoritmo sem alimento. Valide que o gclid sobrevive antes de confiar em qualquer número de ROAS ou CPA dessa campanha.

Posso usar um modelo de monitorização e um sufixo de URL final em conjunto?

Sim, e para a maioria das contas o sufixo de URL final é a ferramenta mais limpa para anexar parâmetros. O sufixo anexa os seus parâmetros de monitorização ao URL final sem o envolver, pelo que sobrevive melhor aos redirecionamentos do que um modelo que antecede um monitorizador de cliques. Use o modelo de monitorização quando tiver de encaminhar cliques através de um serviço de medição ou redirecionamento de terceiros, e use o sufixo de URL final quando apenas quiser transportar parâmetros UTM ou personalizados. Podem coexistir; apenas certifique-se de que o mesmo parâmetro não é definido duas vezes com valores conflituosos.

Como testo um modelo de monitorização antes de os anúncios entrarem em funcionamento?

Use o botão Testar incorporado, ao lado do campo do modelo de monitorização — ele expande os tokens ValueTrack e abre o URL montado para que possa confirmar que resolve. Depois faça uma verificação no mundo real: ative o tag automático, clique num anúncio ativo num dispositivo de teste e verifique se o gclid e os seus parâmetros UTM chegam todos à página de destino renderizada. Combine o teste do produto com um inspetor de parâmetros ou a vista em tempo real da sua análise. Nunca publique um novo modelo para uma conta inteira sem ambas as verificações, porque o teste do produto não deteta a perda de parâmetros na fase de redirecionamento.