Diagnóstico de códigos de rastreamento de anúncios para ecommerce (2026)

Como usar este guia

Este guia foi criado para profissionais de marketing de performance, operadores de e-commerce, analistas, desenvolvedores e equipes que precisam auditar um rastreamento instalado por uma agência, plugin, aplicativo ou implementação interna. Execute os testes em um ambiente de staging ou com um pedido de teste que possa ser cancelado e reembolsado. Não repita os testes com pedidos reais de clientes.

Ao concluir este guia, você deverá ser capaz de

• Distinguir entre a presença do código, o disparo da tag, o envio da solicitação, o recebimento pela plataforma e a elegibilidade de uma conversão para lances.
• Validar campos críticos como ID de pedido, receita, moeda, ID de produto e ID de evento.
• Diagnosticar compras duplicadas ou ausentes, conversões com valor zero, perda de atribuição entre domínios e problemas de configuração do consentimento.
• Escolher a abordagem de diagnóstico adequada para Shopify, WordPress, WooCommerce ou uma plataforma de e-commerce personalizada.
• Produza um relatório de diagnóstico claro para equipes de marketing, desenvolvimento, análise ou gerenciamento.

Por que o rastreamento instalado ainda pode produzir dados não confiáveis

Quando uma loja de e-commerce independente começa a anunciar em Google Ads, Meta Ads, Microsoft Ads ou TikTok Ads, cada plataforma exige uma tag ou pixel de rastreamento. Localizar esse código no código-fonte da página não comprova que o rastreamento de conversões funciona corretamente.

• A plataforma de anúncios mostra a tag como não verificada, inativa ou sem atividade recente.
• GA4 registra pedidos, mas Google Ads não mostra conversões.
• A back-end da loja contém um pedido, enquanto a plataforma de anúncios relata duas compras.
• A contagem de conversão parece razoável, mas a receita, a moeda ou os dados do produto estão errados.
• O pixel é detectado na página inicial, mas desaparece durante o checkout ou na página de confirmação do pedido.
• Os eventos do navegador e do servidor são enviados, mas não são desduplicados corretamente.
• O rastreamento publicitário não está respeitando a escolha de consentimento do visitante: o armazenamento publicitário ainda é gravado ou lido, ou identificadores publicitários e dados do usuário continuam sendo enviados depois que o consentimento de marketing é denied. No modo de consentimento avançado, pings de consentimento sem cookies ainda podem ser enviados enquanto ad_storage ou analytics_storage está denied; esse comportamento, por si só, não indica falha de implementação.
• Tags não retomam após um visitante conceder consentimento.

Uma auditoria completa não pode se limitar à pergunta “O código está presente?”. Confirme que cada ação comercial real chega à plataforma correta com o nome do evento, os parâmetros, o valor, a moeda e o ID do pedido corretos, e que os envios pelo navegador e pelo servidor resultam em uma única conversão lógica após a deduplicação.

1. O que um diagnóstico de rastreamento de publicidade realmente verifica

O rastreamento publicitário pode ser avaliado em cinco camadas. Os dados só são adequados para análise de desempenho, cálculo de ROAS e lances automatizados quando todas as cinco camadas são aprovadas.

A mensagem “Tag Fired” no GTM comprova apenas que uma condição do gatilho foi atendida. Ela não comprova que a conversão esteja correta. Continue verificando a camada de dados, a solicitação de rede, as ferramentas de teste da plataforma e o pedido correspondente no back-end.

2. Construir um plano de rastreamento de eventos de comércio eletrônico

Antes de solucionar problemas, defina as ações dos clientes que o site realmente precisa medir. Uma implementação típica de e-commerce deve abranger, no mínimo, visualizações de produtos, adições ao carrinho, início do checkout e compras.

Na versão de agosto de 2026 deste guia, o TikTok usa Purchase como evento padrão de e-commerce purchase e Lead para envios de lead. CompletePayment e SubmitForm são nomes legados compatíveis, mapeados para Purchase e Lead; não renomeie uma implementação legada que funciona sem um plano de migração. Use Contact apenas para uma ação real de contato. GA4 usa purchase e recomenda parâmetros como transaction_id, value, currency e uma matriz items.

Dados mínimos necessários para um evento purchase

3. Prepare o teste diagnóstico

Não use um pedido real de cliente como teste principal. Crie um pedido de teste que possa ser cancelado ou reembolsado e registre os dados abaixo antes de começar.

Desative as extensões de bloqueio de anúncios do navegador no teste principal da implementação, mas não desative o banner de consentimento do site. Execute separadamente os testes de bloqueio de anúncios e de consentimento; caso contrário, não será possível saber se a extensão do navegador ou a configuração de consentimento bloqueou a tag.

Teste pelo menos três cenários consentimento

• Um novo visitante que ainda não fez uma escolha de cookies.
• Um visitante que aceita todos os cookies relevantes.
• Um visitante que rejeita cookies de marketing.

No modo de consentimento do Google, defina o estado padrão de consentimento antes do disparo das tags relevantes e atualize-o imediatamente, na mesma página, depois que o visitante fizer uma escolha. Verifique ad_storage, analytics_storage, ad_user_data e ad_personalization separadamente. O modo de consentimento avançado pode enviar pings sem cookies enquanto o armazenamento está denied; confirme que nenhum armazenamento publicitário, identificador publicitário ou dado do usuário seja enviado em desacordo com a escolha do visitante.

Conjunto de ferramentas de diagnóstico

1. Google Tag Assistant e GTM Preview

Google Tag Manager A visualização mostra eventos de página, tags que dispararam, tags que não dispararam, condições de gatilho, variáveis e estado consentimento. Ele responde a duas perguntas essenciais: o que aconteceu no site, e por que GTM disparou ou não disparou uma tag?

2. GA4 DebugView

GA4 DebugView confirma se o GA4 realmente recebeu o evento e mostra seus parâmetros. Ele ajuda a separar um problema de implementação GTM de um problema de entrega ou coleção GA4.

3. Chrome DevTools Network painel

O painel Network mostra as solicitações que o navegador realmente envia. Você pode filtrar por domínio de plataforma, tipo de solances, nome do arquivo, tag ID ou ID de medição. É a ferramenta chave para responder, “O navegador enviou os dados?”

4. Ferramentas de teste específicas da plataforma

Use Test Events e diagnóstico em Meta Events Manager; Pixel Helper, Test Events, e diagnóstico para TikTok; UET Tag Helper para Microsoft Advertising; e Shopify Pixel Helper para Shopify pixels personalizados.

4. Fluxo de trabalho completo para diagnosticar o rastreamento publicitário

Etapa 1: Faça o inventário de todas as implementações de rastreamento

Conversões duplicadas geralmente são causadas por várias instalações da mesma plataforma, e não por uma única tag com defeito.

• GTM é instalado uma vez no tema e novamente através de um plugin.
• O aplicativo oficial da Meta para Shopify instala um pixel, mas também existe um Meta pixel personalizado separado.
• Um plugin WordPress envia Purchase enquanto GTM envia o mesmo Purchase novamente.
• Uma ação de compra Google Ads nativa e uma ação de compra GA4 importada são ambas definidas como objetivos primários.
• Meta Pixel e Conversions API enviam a mesma compra sem deduplicação correta.
• Um aplicativo do TikTok, o GTM e o código do tema instalam, cada um, o mesmo pixel.

Crie um inventário da implementação. Para facilitar a leitura, reúna o método de instalação, o local da tag base, a origem do evento de compra e o status do evento do servidor em um único campo de observações.

Procure cada ID no código-fonte da página, na lista de tags do GTM, nos plugins do WordPress, nas áreas de código personalizado do tema, no Shopify Customer Events, nos aplicativos do Shopify, no Cloudflare Zaraz, no GTM do servidor e em integrações personalizadas do back-end.

Etapa 2: Confirme que a tag base é carregada corretamente

No GTM, não comece abrindo diretamente a página de confirmação do pedido. Conecte o Preview a partir da página inicial ou da landing page do anúncio e siga a jornada real do cliente: visualização do produto, carrinho, checkout e pagamento.

• Confirme que o Preview está conectado ao domínio correto.
• Confirme que o contêiner GTM esperado aparece quando a página é carregada.
• Verifique se o ID do contêiner corresponde à conta e ao ambiente ativos.
• Confirme que a base Google tag carrega em todas as páginas necessárias.
• Verifique se a página de sucesso de pagamento permanece na mesma sessão de depuração.
• Verifique se a sessão quebra após uma transição de redirecionamento ou domínio cruzado.
• Revise o Consent Initialization e qualquer estado de consentimento que bloqueie a tag.

Ao mesmo tempo, abra Chrome DevTools e procure no painel Network o ID do contêiner GTM, o ID de medição GA4, o ID de conversão Google Ads, o ID Meta pixel, o ID do pixel do TikTok ou o ID da tag Microsoft UET. Buscar o ID real é mais confiável do que depender de um endpoint fixo, pois os caminhos das solicitações podem mudar.

Quando nenhuma solicitação aparecer, verifique primeiro

• Falta o código ou o ID configurado está errado.
• O contêiner GTM não foi publicado ou o ambiente errado está carregado.
• As configurações de consentimento impedem a execução da tag.
• A Política de Segurança de Conteúdo bloqueia o script ou endpoint externo.
• Um bloqueador de anúncios ou configuração de privacidade do navegador bloqueia a solances.
• Ocorre um erro de JavaScript antes que o código de rastreamento seja executado.
• Um cache ou CDN ainda serve uma versão mais antiga do código do site.

Passo 3: Validar a camada de dados ou evento do cliente

A camada de dados é a ponte entre a atividade de e-commerce e as tags publicitárias. Google Tag Manager e gtag.js leem eventos e variáveis dessa camada estruturada. Use dados previsíveis e estruturados, em vez de obrigar as tags a extrair valores de elementos não relacionados da página.

Um evento purchase simplificado no estilo GA4 pode ser assim:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-10086",
    value: 129.90,
    currency: "USD",
    tax: 8.20,
    shipping: 0,
    items: [
      {
        item_id: "SKU-001",
        item_name: "Portable Coffee Grinder",
        price: 64.95,
        quantity: 2
      }
    ]
  }
});
</script>

No e-commerce do GA4, o valor no nível do evento normalmente deve ser igual à soma de preço multiplicado pela quantidade da matriz items. Ele não deve incluir frete nem impostos, salvo quando a definição documentada do relatório e a plataforma de destino exigirem explicitamente outro valor.

Use o seguinte comando no Chrome Console para uma inspeção inicial:

window.dataLayer

Para mostrar apenas os eventos purchase:

window.dataLayer?.filter(item => item.event === "purchase")

Validar estes seis pontos

1. O evento ocorre no momento correto: Purchase deve ser gerado somente depois que o pedido for realmente concluído, e não quando o cliente apenas clicar em Pagar agora ou Enviar pedido.
2. O ID do pedido é exclusivo: o mesmo pedido deve manter o mesmo ID após uma atualização, enquanto pedidos diferentes nunca podem compartilhar um ID.

3 O valor é numérico: Use 129,90, não “$129,90”, “USD 129,90”, ou uma string contendo um separador de milhares.

1. A moeda corresponde ao pedido: em lojas multimoeda, compare a moeda exibida, a moeda de liquidação e a moeda enviada à plataforma.
2. A matriz items está completa: IDs, preços, quantidades e descontos dos produtos devem corresponder ao pedido no back-end.
3. Valores antigos não são mantidos: aplicativos de página única, carrinhos laterais e checkouts do AJAX podem reutilizar, por engano, dados de um evento anterior.

Passo 4: Inspecione gatilhos e variáveis GTM

Completar uma jornada de teste real em GTM Preview, selecionar o evento purchase, e inspecionar Tags Fired, Tags Not Fired, Variables, Data Layer e consentimento.

O gatilho é muito largo.

Uma regra como “Page URL contains thank-you” pode disparar novamente sempre que o visitante atualizar, salvar nos favoritos ou revisitar a página de confirmação. As compras de e-commerce devem, de preferência, usar um evento real de conclusão do pedido e um ID exclusivo.

O gatilho é demasiado restritivo.

A URL real pode ser /en/checkout/success, enquanto o gatilho permite apenas /checkout/success. Pastas de idioma, strings de consulta e caminhos alternativos de checkout podem invalidar uma regra excessivamente restritiva.

Os nomes dos eventos personalizados não correspondem

A camada de dados envia event: “checkout_completed”, mas GTM escuta purchase. Os nomes dos eventos devem coincidir exatamente, inclusive em maiúsculas, minúsculas e sublinhados.

A tag dispara antes dos dados chegarem

A tag é executada durante o carregamento da página, mas o valor, a moeda e o ID do pedido só entram na camada de dados algumas centenas de milissegundos depois. A tag parece disparar corretamente, porém envia parâmetros vazios.

AJAX ou uma aplicação de uma única página não produz nenhuma carga de página tradicional

Carrinhos laterais, checkouts modais e aplicativos React ou Vue podem não gerar uma visualização de página tradicional. Acione o rastreamento por eventos comerciais, em vez de depender apenas do carregamento de páginas ou de alterações na URL.

Etapa 5: Use Network para confirmar que uma solicitação foi enviada

Abra Chrome DevTools -> Network, ative Preserve log e repita todo o teste. Filtre pelo ID ou domínio da plataforma. Abra a solicitação correspondente e examine Headers e Payload.

• Verifique a plataforma de destino e tag ou pixel ID.
• Verifique o nome do evento, valor, moeda e ID de pedido.
• Confirme que os IDs do produto, as quantidades e a matriz items estão presentes.
• Confirme que os eventos do navegador e servidor compartilham os identificadores de deduplicação específicos da plataforma: Meta e TikTok exigem um nome ou tipo de evento correspondente mais event_id, enquanto as compras GA4 e Google Ads usam transaction_id.
• Verifique se a solances foi cancelada, bloqueada ou devolvida um erro.
• Verifique se a solances ocorreu antes ou após o redirecionamento da página.

Uma solances observada com uma carga útil plausível prova apenas que o navegador tentou entregar ou que um endpoint aceitou uma solances. Ele não prova processamento de plataforma, atribuição, elegibilidade de lances ou precisão de dados de negócios. Uma solances Purchase com um valor de 0 ainda pode ser transmitida com sucesso.

GTM informa que a tag disparou, mas Network não mostra nenhuma solicitação

• Estado de consentimento e verificações internas de consentimento.
• Bloqueio de anúncios ou configurações de privacidade do navegador.
• Restrições da Política de Segurança de Conteúdo.
• Modelo de tag com defeito ou erro de execução do JavaScript.
• Solicitação cancelada por uma navegação imediata.
• Limitações do Pixel Sandbox do Shopify.

Etapa 6: Confirme o recebimento em cada plataforma publicitária

GA4

Abra o DebugView, selecione o dispositivo de teste e confirme que a sequência de eventos é razoável:

page_view
view_item
add_to_cart
begin_checkout
purchase

Abra a compra e verifique transaction_id, valor, moeda e itens.

Google Ads

Abra Goals -> Conversions -> Summary e revise o status de rastreamento da ação relevante. Para Unverified, Tag inactive ou Needs attention, inicie Tag Assistant a partir da ação de conversão. O status da conta pode demorar para atualizar após uma correção; use Tag Assistant e a solicitação real como camada de validação imediata.

Meta Ads

No Events Manager, selecione a fonte de dados correta e revise Overview, Test Events, diagnóstico, Event Deduplication e Event Match Quality. Test Events confirma o envio pelo navegador e pelo servidor; diagnóstico identifica eventos duplicados, parâmetros inválidos e problemas de qualidade dos dados.

TikTok Ads

Use TikTok Pixel Helper para inspecionar tags, eventos e parâmetros do navegador; Gerenciador de eventos -> Test Events para recebimento em tempo real; e Gerenciador de eventos -> diagnóstico para erros de implementação persistentes.

Microsoft Advertising

Use UET Tag Helper para validar o ID da tag UET, o evento de carregamento da página, os eventos personalizados, a receita variável, a moeda e as condições da meta de conversão. O status UET no Microsoft Advertising pode levar mais tempo para atualizar. Se Microsoft Advertising Conversions API também for usado, verifique seu event_id e confirme que os envios pelo navegador e pelo servidor não geram relatórios duplicados. Para receita variável, preserve revenue_value e currency exatamente como exigido pelo destino.

5. Diagnostique Conversions e Event Deduplication duplicados

Compras duplicadas inflam o ROAS informado e fornecem sinais incorretos aos lances automatizados. Revise em conjunto navegador, servidor, plugins, aplicativos, GTM e metas importadas, em vez de auditar apenas uma camada.

Google Ads deduplicação

Google Ads recomenda enviar um ID de transação exclusivo com cada compra. Se a página de confirmação for atualizada e o mesmo pedido for enviado novamente à mesma ação de conversão, Google Ads poderá usar o ID correspondente para identificar a duplicação. Um ID de transação não deduplica automaticamente ações de conversão Purchase distintas.

• Pedidos diferentes não devem compartilhar o mesmo ID de transação.
• O ID da transação não deve estar vazio.
• Não use um endereço de e-mail do cliente ou número de telefone como o ID do pedido.
• As tags do navegador e os uploads do back-end devem usar o mesmo ID de pedido para a mesma transação.

Meta Pixel e Conversions API deduplicação

Quando o mesmo Purchase é enviado por Meta Pixel e Conversions API, os eventos do navegador e do servidor devem compartilhar os mesmos event_name e event_id. Pedidos diferentes devem usar valores event_id diferentes. Caso contrário, um único pedido poderá ser contabilizado como dois eventos.

• Os eventos do navegador e do servidor usam o mesmo event_name?
• Ambas as versões da mesma pedido usam o mesmo event_id?
• Cada pedido diferente recebe um ID de evento diferente?
• Uma nova tentativa do servidor cria outro ID de evento e gera acidentalmente um segundo evento?
• Um aplicativo Shopify e uma implementação personalizada CAPI estão enviando a mesma compra?

TikTok Pixel e Events API deduplicação

Quando o TikTok Pixel e Events API enviam o mesmo evento, ambos devem usar o mesmo nome ou tipo de evento e o mesmo event_id, para que o TikTok reconheça o par e mantenha uma única ocorrência lógica.

Atualizações da página de confirmação de pedidos

Usar apenas uma visualização da página de confirmação para acionar Purchase é arriscado. Atualizar, salvar nos favoritos ou reabrir a página pode disparar o evento novamente. Use um ID de pedido exclusivo e, sempre que possível, acione o rastreamento por um evento real de conclusão do pedido, não por um carregamento de página comum.

6. Revise Goals de conversão, checkout entre domínios e atribuição

Primary versus ações secundárias de conversão

No Google Ads, as ações de conversão primárias normalmente aparecem na coluna Conversions e podem ser usadas nos lances quando a campanha utiliza a meta relevante. As ações Secondary são usadas principalmente para observação e geralmente aparecem em All conversions. Ainda assim, uma ação secundária pode ser usada nos lances quando fizer parte de uma meta personalizada usada ativamente pela campanha.

Quando o evento aparece na conta, mas a campanha não otimiza para ele, verificar que a ação é primária e que a campanha está usando o objetivo correspondente.

Every versus One

As ações Purchase geralmente precisam contabilizar todas as transações. Formulários Lead costumam usar One porque envios repetidos do mesmo clique no anúncio podem não representar vários leads válidos. Para vendas, use um ID de transação exclusivo para eliminar pedidos duplicados.

Duplicar metas de compra primária

Uma conta pode conter uma Google Ads Purchase nativa, uma GA4 Purchase importada e uma Purchase criada por um aplicativo Shopify. Se as três forem primárias e usadas pela campanha, a coluna Conversions poderá conter vários sinais de compra para um único pedido.

Conversions

Depois de ativar Conversions avançado, confirme que os dados próprios elegíveis do cliente realmente são enviados no formato exigido. Uma tag base Purchase funcionando não comprova que Conversions avançado esteja íntegro.

Checkout entre domínios e redirecionamentos de pagamento

Algumas lojas transferem os visitantes do domínio principal para um domínio de checkout separado, provedor de pagamento terceirizado, sistema de reservas, serviço de formulários, subdomínio ou site regional. Uma configuração incorreta entre domínios pode causar:

• A divisão de uma única sessão do cliente em várias sessões.
• O desaparecimento da origem publicitária original.
• O provedor de pagamento passar a ser informado como origem de referência.
• A perda do ID de clique antes do checkout.
• Eventos na loja, mas nenhum evento após a aprovação do pagamento.

Use a medição entre domínios GA4 apenas entre domínios que você controla e nos quais a mesma tag GA4 pode ser implantada. Em domínios de pagamento terceirizados onde não seja possível implantar essa tag, revise List unwanted referrals para impedir que o provedor substitua a origem original; isso não substitui a medição entre domínios. Teste todo o redirecionamento a partir de uma landing page, em vez de abrir diretamente a página de sucesso.

7. diagnóstico de rastreamento específico do Shopify

Os pixels Shopify Customer Events são executados em ambientes sandbox. Pixels de aplicativos usam um sandbox Strict, enquanto pixels personalizados usam um sandbox Lax; os recursos não são idênticos. Ambos devem usar Shopify Customer Events e Web Pixels API, em vez de extrair dados pelo DOM tradicional.

1. Não confie no Google Tag Assistant sozinho

Google Tag Assistant não é compatível com pixels personalizados GTM no Shopify. Use Shopify Pixel Helper para confirmar que os eventos do cliente entram no sandbox e depois valide a solicitação Network resultante e a ferramenta Test Events ou de diagnóstico da plataforma de destino.

Shopify Pixel Helper
-> Custom Pixel dataLayer
-> Tag GTM
-> Solicitação Network
-> Test Events da plataforma publicitária

2. Evite extrair dados do DOM dentro do sandbox

Os Web Pixels do Shopify operam em um sandbox. Implementações que leem ou alteram o DOM da loja podem falhar ou se comportar de maneira inconsistente. Prefira os dados fornecidos por Shopify Customer Events e Web Pixels API, em vez de extrair preços, botões ou dados do pedido com seletores CSS.

• Um gatilho de clique que escuta diretamente um botão de tema.
• Uma variável do elemento DOM que raspa o preço do produto exibido.
• Uso direto do document.querySelector.
• Usando o URL sandbox como se fosse o URL storefront.
• Assumindo que a medição aprimorada do GA4 pode descobrir cada interação em sandbox automaticamente.

3. Verifique se o pixel está aguardando consentimento

Abra Configurações do Shopify -> Eventos do cliente -> Pixels personalizados e inicie um teste. Se o Pixel Helper informar “Pixel is awaiting consentimento”, revise:

• As permissões de privacidade do cliente atribuídas ao pixel personalizado.
• Configuração do banner de cookies para o mercado ativo.
• Se o visitante granted consentimento de Analytics ou Marketing.
• Se a plataforma de gerenciamento de consentimento está integrada à Customer Privacy API do Shopify.

4. Use checkout_completed corretamente

Shopify checkout_completed normalmente dispara uma vez por checkout e costuma ser observado na página Thank You. Com um upsell pós-compra, pode disparar na primeira página do upsell, e não novamente na página Thank You. Também pode não disparar se a página esperada não carregar corretamente.

Teste o checkout de cartão padrão, Shop Pay ou checkout acelerado, pedidos com desconto, pedidos gratuitos, upsells pós-compra, pedidos de multi-moeda, e casos em que a página Obrigado não carrega totalmente.

8. Problemas comuns de diagnóstico no WordPress e no WooCommerce

O problema mais comum no WordPress não é a impossibilidade de instalar o rastreamento, mas instalá-lo em locais demais. Revise os locais abaixo na ordem:

• Plugins de instalação GTM.
• GA4 ou plugins de conversão de publicidade.
• Separar os plugins Meta, TikTok ou Microsoft Advertising.
• Áreas de código personalizado no cabeçalho e no rodapé do tema.
• Código personalizado do construtor de páginas.
• Personalizações da página Thank You do WooCommerce.
• CDN, cache, combinação de script e configurações de atraso JavaScript.

Os fluxos de adição ao carrinho, checkout e pagamento do WooCommerce são frequentemente alterados por AJAX ou plugins de terceiros. Não pressuponha que um gatilho padrão de clique no botão ou uma regra padrão da página de confirmação ainda funcione. Use a camada de dados real e o evento de conclusão do pedido como fonte confiável.

Verificações extras para plugins de desempenho e cache

• Atrasam o GTM ou o carregamento de pixels?
• Os scripts combinados alteram a ordem de execução?
• Uma página de confirmação com dados do pedido está sendo armazenada em cache?
• A atualização do consentimento ocorre após as tags de publicidade já terem sido executadas?
• As solicitações de rastreamento de terceiros estão bloqueadas ou encaminhadas por proxy de forma incorreta?
• O problema ocorre apenas quando o administrador não está conectado?

9. Matriz de solução de problemas

10. Critérios de aceitação de uma implementação confiável

Uma compra de teste bem sucedida deve satisfazer todas as seguintes condições:

• Purchase dispara somente depois que o pedido é realmente concluído.
• O pedido de teste One resulta em uma única conversão lógica após a deduplicação.
• O ID do pedido corresponde ao back-end da loja.
• O valor de conversão segue a definição acordada e a moeda está correta.
• IDs de produto, preços e quantidades são precisas.
• GTM Preview mostra o evento completo e as variáveis preenchidas.
• A solances correspondente existe em Network.
• A plataforma de destino reconhece o evento em sua ferramenta de teste.
• Os eventos do navegador e do servidor são desduplicados.
• Os estados consentimento aceitos e rejeitados produzem o comportamento pretendido.
• As configurações Google Ads Primary, Secondary e Count estão corretas.
• O checkout entre domínios preserva a origem original.
• Atualizar a página de confirmação não cria outra conversão independente.

Padrão final de aceitação
Um pedido comercial real One -> uma única conversão publicitária lógica após a deduplicação -> ID do pedido, valor, moeda e dados dos produtos corretos -> verificado na plataforma -> conciliável com o back-end da loja.

11. Modelo de relatório de diagnóstico do rastreamento publicitário

Use a estrutura abaixo para registrar a auditoria. Salve capturas de tela do caminho de teste, da carga útil Network, da ferramenta Test Events da plataforma e do pedido no back-end como evidências anexas.

1. Site e ambiente

2. Inventário das instalações de rastreamento

3. Pedido de teste

4. Resultados do diagnóstico

5. Problema e correção

6. Teste de regressão

Cadeia completa de evidências

Ação comercial
-> Evento do cliente / Data Layer
-> Gatilho GTM
-> Tag publicitária
-> Solicitação Network
-> Evento de teste da plataforma
-> Meta de conversão
-> Conciliação com o back-end

Somente quando todas as camadas dessa cadeia estiverem corretas, os dados de conversão poderão ser usados na avaliação de campanhas, nos relatórios ROAS e nos lances automatizados.