Setup de tracking para e-commerce em 2026: GA4, CAPI e Merchant Center

Tracking quebrado não aparece como erro. Aparece como decisão errada tomada com confiança. O gestor abre o gerenciador, vê ROAS 4x, aumenta o orçamento, e o caixa não mexe. A campanha não piorou. A medição nunca esteve certa.

Este pilar cobre o setup de ponta a ponta que uma operação de e-commerce precisa em 2026: GA4 com comércio eletrônico completo, Pixel Meta com Conversions API deduplicada, Google Merchant Center com feed que sobrevive à revisão, e Enhanced Conversions no Google Ads. O foco não é reproduzir a documentação do Google e do Meta. O foco é o que o setup padrão esconde, distorce ou quebra quando a operação escala.

Antes de qualquer tag, existem três pré-requisitos que nenhuma documentação de plataforma pede.

Os pré-requisitos que nenhuma documentação lista

Pré-requisito 1: uma fonte de verdade financeira fora das plataformas. Receita de plataforma é estimativa modelada. Receita de ERP ou de gateway é dinheiro reconhecido. Se você não tem uma tabela com pedido, valor líquido, custo do produto e status de cancelamento, o tracking mais preciso do mundo vai medir a coisa errada com precisão de três casas decimais. A conversa sobre qual número manda está detalhada no pilar ROAS versus unit economics em e-commerce.

Pré-requisito 2: acesso ao código do checkout. Não ao tema da loja. Ao checkout. Deduplicação entre Pixel e Conversions API depende de um identificador gerado no mesmo evento de compra, e esse identificador precisa existir nos dois lados. Plataforma de e-commerce que expõe apenas um campo de "scripts de conversão" na página de obrigado não permite setup correto. Isso muda a lista de plataformas viáveis, e é melhor descobrir antes de assinar o contrato anual.

Pré-requisito 3: uma definição de conversão que corresponde a dinheiro. Compra com boleto emitido não é compra. Compra com pagamento aprovado é. Operações que disparam purchase na emissão do boleto inflam o volume de conversão em uma fatia que varia conforme o mix de meios de pagamento, e o algoritmo de leilão passa a otimizar para gente que emite boleto e não paga.

A ressalva que vem antes do tutorial

Esse setup completo não vale para toda operação. Abaixo de 50 conversões por mês por conta de anúncio, a maior parte do ganho vem de ter o evento de compra disparando com valor correto, e nada mais. Enhanced Conversions, feeds suplementares e modelagem de consentimento entregam ganho marginal em cima de um volume que não sustenta significância estatística. O custo de manutenção é real: cada camada adicional é mais um ponto que quebra silenciosamente em uma atualização de tema.

A Moyker viu isso na LR Joias. O tráfego de busca por marca chegou com CPC abaixo de R$ 0,10, e a taxa de conversão continuou baixa. O diagnóstico não veio de uma camada nova de tracking. Veio de olhar a razão entre sessão de produto e carrinho, que já estava medida. A correção foi trocar o tipo de carrinho dentro da plataforma. A taxa de conversão triplicou. Nenhum evento novo foi instalado.

A regra prática: instale a camada seguinte quando a camada anterior já estiver conciliada com o financeiro dentro de 5% de erro. Antes disso, você está empilhando complexidade em cima de um número que ninguém confere.

Passo a passo: as quatro camadas na ordem certa

A ordem importa. Cada camada depende da anterior estar estável, e inverter a sequência produz um setup que parece completo e mede errado.

Camada 1: GA4 como leitura de comportamento, não como fonte de faturamento

GA4 é a única das quatro camadas que não otimiza campanha. Ele descreve comportamento. Tratá-lo como fonte de faturamento é o erro mais comum em operação de e-commerce, porque o relatório de Monetização mostra um número em reais e o número parece oficial.

Implemente o conjunto de eventos de comércio eletrônico recomendado pelo Google, e não apenas purchase. A lista mínima que sustenta diagnóstico de funil é view_item, add_to_cart, begin_checkout, add_payment_info, purchase e refund. Cada um deles carrega o array items com item_id, item_name, price e quantity, mais value e currency no nível do evento. A especificação completa dos parâmetros está na documentação de comércio eletrônico do GA4.

Três detalhes decidem se esses dados servem para alguma coisa:

1. transaction_id obrigatório em purchase e em refund. Sem ele, GA4 não deduplica compras recarregadas na página de obrigado, e a receita infla. Use o identificador de pedido do ERP, não um número gerado no navegador.
2. value sem frete e sem imposto, ou com frete e imposto, mas igual em todas as plataformas. A escolha importa menos que a consistência. Se GA4 manda valor com frete e o Pixel manda sem, o ROAS de Google e o de Meta ficam permanentemente incomparáveis.
3. user_id populado quando o cliente está logado. É o que permite unificar dispositivos no relatório e é o insumo de identidade que sustenta Enhanced Conversions depois.

Onde conferir: Administrador, Fluxos de dados, seu fluxo web, e depois DebugView com a extensão de depuração ativa. Compre um produto de teste e acompanhe o evento chegando com o array items completo. Se items vier vazio, o restante da configuração é decorativo.

Consent Mode v2 é a parte que a maioria das operações brasileiras ignora e que muda o comportamento da coleta. A documentação de consentimento do Google define quatro parâmetros: ad_storage, analytics_storage, ad_user_data e ad_personalization. Cada um aceita granted ou denied. Com ad_storage negado, novos cookies de publicidade não são gravados, e o Google passa a depender de modelagem para reconstruir conversão. Existe ainda url_passthrough, que carrega o identificador de clique via parâmetro de URL entre páginas quando o cookie está bloqueado, e ads_data_redaction, que remove identificadores de clique das requisições quando ad_storage está negado.

O detalhe operacional: banner de consentimento instalado sem integração com Consent Mode não reduz coleta, apenas exibe um aviso. E banner integrado em modo básico bloqueia a tag inteira antes da escolha do usuário, o que elimina o sinal cookieless que alimenta a modelagem. Modo avançado dispara a tag com consentimento negado e envia ping sem cookie. A diferença entre os dois modos aparece direto no volume de conversão reportada, não na conformidade.

O detalhamento de cada evento e dos parâmetros de item está no satélite GA4 para e-commerce: setup, eventos e enhanced ecommerce. A definição curta do que GA4 é e do que ele não é está no glossário GA4.

Camada 2: Pixel Meta com Conversions API deduplicada

Pixel sozinho perde eventos. Bloqueador de anúncio, restrição de cookie de terceiro no Safari e limites de rastreamento em iOS derrubam uma fatia da coleta que varia por mix de dispositivo. Conversions API resolve isso enviando o mesmo evento do servidor. O problema é que resolver mal produz contagem dobrada, que é pior que contagem incompleta, porque o ROAS aparente sobe e a decisão de escala vem em cima de um número inflado.

A deduplicação do Meta funciona por dois métodos, e só o primeiro é confiável. O método recomendado pelo Meta compara event_id da Conversions API com eventID do Pixel, e event_name com event. Os dois precisam ser idênticos. A janela de deduplicação é de 48 horas a partir do primeiro evento recebido. O segundo método compara event_name mais fbp e/ou external_id, e traz uma limitação que a documentação declara de forma explícita: eventos de servidor não serão descartados se nenhum evento de navegador tiver chegado nas últimas 48 horas, mesmo que um evento idêntico de navegador chegue depois. Traduzindo para operação: se o seu servidor é mais rápido que o navegador do cliente, o método 2 duplica.

Portanto, gere o event_id uma vez, no servidor, no momento em que o pedido é criado, e injete o mesmo valor nos dois envios. Não gere no navegador. Não use timestamp. Use o identificador de pedido concatenado com o nome do evento.

O segundo bloco que decide a qualidade do CAPI é o user_data. Os parâmetros de informação do cliente são enviados com hash SHA-256, com exceção de fbc, fbp, client_ip_address e client_user_agent, que vão em texto. Quanto mais campos preenchidos, maior a nota de Qualidade da Correspondência de Eventos, que o Meta exibe em escala de 0 a 10. E-mail e telefone normalizados antes do hash são os que mais movem essa nota. Telefone precisa de código de país sem sinal de mais e sem separador.

Onde conferir: Gerenciador de Eventos, sua fonte de dados, aba Visão Geral. Filtre pelo evento Purchase e veja duas coisas na mesma tela. A primeira é a nota de Qualidade da Correspondência. Abaixo de 6, faltam parâmetros de identidade. A segunda é o card de eventos redundantes, que aponta quantos eventos chegaram pelos dois canais sem deduplicar. Acima de 5% de eventos não deduplicados, o event_id está inconsistente e todo número de conversão do Meta está inflado.

O setup completo, com exemplo de payload e ordem de implementação, está no satélite Como configurar CAPI Meta em e-commerce.

Um terceiro campo decide como o Meta interpreta o evento e quase nunca recebe atenção: action_source. Ele declara onde a conversão aconteceu, e aceita valores como website, app, phone_call, chat e system_generated. Enviar compra de site como system_generated porque o disparo veio de uma rotina do servidor faz o evento sair do conjunto que alimenta otimização de conversão no site. O evento aparece no gerenciador, a contagem bate, e a campanha continua sem sinal. Para e-commerce com checkout próprio, action_source é website mesmo quando o envio parte do backend, porque o que o campo descreve é onde o cliente agiu, não de onde saiu a requisição.

Há ainda a decisão de arquitetura entre integração por parceiro e envio direto. Integração nativa de plataforma de e-commerce resolve em minutos e é a escolha certa para a maior parte das operações. Ela cobra o preço de não permitir controle sobre event_id nem sobre quais campos de user_data são enviados, que são exatamente as duas variáveis de qualidade descritas acima. O corte que a Moyker usa em campo: operação que depende do leilão do Meta para escalar e já roda acima de R$ 100 mil por mês em investimento de mídia ganha mais controlando o envio. Abaixo desse patamar, a integração nativa entrega a maior parte do resultado com uma fração do trabalho de manutenção.

Camada 3: Google Merchant Center e o feed que sobrevive à revisão

Merchant Center não é tracking. É catálogo. Mas ele entra neste pilar porque em e-commerce ele determina o que pode ser anunciado, e feed reprovado é a causa mais silenciosa de campanha de Shopping e Performance Max com entrega travada.

A especificação de dados de produto define os atributos obrigatórios: id, title, description, link, image_link, availability, price, e depois os identificadores únicos de produto, brand, gtin e mpn, com regras que variam por categoria e por país. Preencher os obrigatórios aprova o produto. Não é o mesmo que fazer o produto competir.

Três decisões separam feed que aprova de feed que vende:

Título construído por regra, não copiado do nome do produto no site. O nome comercial da loja costuma ser otimizado para a página, não para a consulta. Um padrão que funciona em varejo é marca mais tipo de produto mais atributo diferenciador mais variação, dentro dos 150 caracteres do atributo.

Feed suplementar para o que a plataforma de e-commerce não exporta. Feed suplementar sobrescreve ou complementa campos do feed primário sem exigir mudança no sistema de origem. É o instrumento certo quando a plataforma não permite editar o campo diretamente, e é a solução que a Moyker usou na Shop.com, operação da Market America em sete países, onde os feeds do Merchant Center chegaram com desafios de aprovação de produto que não podiam ser corrigidos na origem.

Divergência de preço entre feed e página de destino derruba o produto. O rastreador do Google compara os dois. Loja com preço promocional renderizado por JavaScript depois do carregamento inicial é a causa mais comum de reprovação em massa que aparece do nada.

Onde conferir: Merchant Center, menu Produtos, aba Diagnóstico. Ordene por número de itens afetados, não por severidade. Um erro de severidade média que atinge 4.000 produtos custa mais que um erro crítico em 3 produtos. Defina o gatilho antes de olhar: acima de 10% do catálogo com o mesmo motivo de reprovação, o problema é de regra de feed e não de produto individual.

A definição do que o Merchant Center faz na estrutura de mídia está no glossário Google Merchant Center. O movimento do Google em direção a um protocolo aberto de dados de produto, que muda o horizonte dessa camada, está analisado no quick take sobre o Universal Commerce Protocol.

Camada 4: Enhanced Conversions no Google Ads

Enhanced Conversions recupera conversão que o cookie perdeu, usando dados fornecidos pelo próprio cliente. A loja envia e-mail, telefone ou endereço com hash SHA-256, e o Google casa esse dado com contas logadas para atribuir a conversão ao clique, conforme a documentação de conversões aprimoradas.

A camada só funciona se a anterior estiver pronta, e essa é a razão de ela ser a quarta. Enhanced Conversions consome o mesmo campo de identidade que você já precisou normalizar para o user_data do CAPI. Operação que fez o dever de casa no Meta implementa Enhanced Conversions em uma tarde. Operação que não fez descobre nessa hora que o campo de e-mail do checkout aceita espaço em branco no final.

Duas formas de implementar. Via Google Tag com variáveis da camada de dados, que é mais rápido e depende de o dado estar disponível na página de conversão. Via API, que é mais estável e é obrigatório quando a conversão acontece fora do navegador. Para e-commerce com checkout próprio, a primeira resolve. Para operação com pagamento assíncrono, a segunda.

Onde conferir: Google Ads, Objetivos, Conversões, Resumo, clique na ação de compra, aba de diagnóstico de Enhanced Conversions. A tela mostra taxa de correspondência dos dados enviados. Abaixo de 60%, o problema é normalização, não volume.

Erros comuns que matam o resultado

Estes seis erros aparecem em quase toda auditoria de tracking de e-commerce que a Moyker fez. Nenhum deles gera mensagem de erro em plataforma nenhuma.

Erro 1: event_id gerado no navegador. O navegador gera um valor, o servidor gera outro, e a deduplicação nunca acontece. O sintoma é aritmético e fácil de conferir: a contagem de compras no Gerenciador de Eventos se aproxima do dobro da contagem de pedidos pagos do ERP no mesmo intervalo. Quanto mais perto de 2 vezes, mais completo é o vazamento.

Erro 2: purchase na página de obrigado sem trava de recarregamento. Cliente recarrega a página de agradecimento, ou volta nela pelo histórico, e o evento dispara de novo. Sintoma: pedidos com valor duplicado exatamente, sempre nos mesmos identificadores. A trava é o transaction_id no GA4 e o event_id no Meta, mais gravação no armazenamento de sessão.

Erro 3: valor inconsistente entre plataformas. GA4 com frete incluso, Meta sem, Google Ads com imposto. Os três ROAS ficam diferentes, ninguém sabe qual está certo, e a discussão vira opinião. Escolha um critério, documente em um arquivo, e aplique nos três.

Erro 4: Consent Mode em modo básico com banner que bloqueia tudo. A operação acredita que está em conformidade e perdeu o sinal modelado inteiro. Sintoma: queda em degrau no volume de conversão reportada na data exata em que o banner subiu, sem queda equivalente no faturamento do ERP.

Erro 5: GA4 tratado como fonte de faturamento em reunião de resultado. GA4 usa modelo de atribuição próprio e janela própria. Comparar a receita do relatório de Monetização com a receita do ERP e chamar a diferença de "erro de tracking" desperdiça reunião. Os dois números medem coisas diferentes por construção.

Erro 6: catálogo do Meta e feed do Google alimentados por exportações diferentes. Produto com preço atualizado no Google e desatualizado no Meta gera reprovação de anúncio dinâmico e distorce o remarketing de catálogo. Uma origem, duas saídas.

A leitura mais ampla sobre onde procurar gargalo antes de mexer em campanha está no satélite Diagnóstico técnico de tráfego pago em 5 dimensões.

Quando não aplicar este setup

Quatro situações em que a recomendação muda.

Operação abaixo de 50 conversões por mês por conta. Instale purchase com valor correto e transaction_id, integre o feed, e pare. As camadas de recuperação de sinal entregam ganho que você não consegue medir nesse volume, e cada camada é mais superfície de falha.

Checkout de terceiro sem acesso ao código. Marketplace, link de pagamento externo, plataforma fechada. Sem controle sobre o momento da compra, não existe deduplicação confiável. Nesse cenário, a decisão certa é medir conversão intermediária que você controla e reconciliar com o financeiro por período, aceitando atribuição pior de forma consciente.

Migração de plataforma em andamento. Reimplementar tracking em uma plataforma que vai ser trocada em três meses é trabalho jogado fora duas vezes. A exceção é o evento de compra, que precisa continuar de pé durante toda a migração para você conseguir comparar antes e depois.

Operação de canal único com margem apertada. Se 90% da receita vem de um canal, o valor de atribuição multicanal é baixo e o custo de manutenção continua igual. Investir as mesmas horas em conversão de página de produto costuma pagar mais rápido.

Como medir se o setup funcionou

Tracking não se valida por sensação de que "agora está certo". Valida por número, com gatilho definido antes de olhar. Cinco checagens, todas executáveis em menos de 48 horas.

Checagem 1: conciliação de volume. Compare o número de compras do Gerenciador de Eventos do Meta, do relatório de Monetização do GA4 e do ERP, no mesmo intervalo de 7 dias fechados. Gatilho: divergência acima de 10% em qualquer par exige investigação antes de qualquer mudança de orçamento.

Checagem 2: taxa de deduplicação. Gerenciador de Eventos, aba Visão Geral, card de eventos redundantes no evento Purchase. Gatilho: acima de 5% de eventos não deduplicados, o event_id está inconsistente.

Checagem 3: Qualidade da Correspondência de Eventos. Mesma tela, escala de 0 a 10. Gatilho: abaixo de 6, adicione parâmetros de identidade ao user_data antes de mexer em criativo ou em público.

Checagem 4: cobertura do feed. Merchant Center, Diagnóstico. Divida produtos ativos por produtos enviados. Gatilho: abaixo de 90% de aprovação, corrija a regra de feed antes de aumentar orçamento de Shopping ou Performance Max.

Checagem 5: taxa de correspondência de Enhanced Conversions. Google Ads, Conversões, diagnóstico da ação de compra. Gatilho: abaixo de 60%, o problema está na normalização do dado enviado.

Rode as cinco no mesmo dia, anote os valores em uma planilha com a data, e repita mensalmente. O valor da série histórica é detectar o dia em que uma atualização de tema quebrou um evento, o que nenhuma plataforma avisa.

O que continua aberto

O setup descrito aqui é o que sustenta decisão de mídia em 2026. Ele não sobrevive intacto a 2027. O identificador de clique perde alcance a cada restrição nova de navegador, a modelagem de conversão ganha peso sobre a observação direta, e a discussão de catálogo caminha para protocolos abertos em vez de feeds proprietários por plataforma.

O que não muda é a pergunta que decide tudo: o número que você usa para escalar corresponde a dinheiro que entrou na conta? Se a resposta depende de qual aba está aberta, o problema nunca foi de campanha.

Quantos dos cinco gatilhos acima a sua operação passaria hoje, sem ajustar nada antes de medir?