O catálogo da Meta não casa com as suas vendas
As campanhas de catálogo entregam, o site vende, e o Purchase nunca aparece atribuído ao produto. Quase sempre o identificador do item muda de valor no meio da jornada.
Atualizado em 8 de setembro de 2026 · por WYB Trackers
Por que o catálogo não faz match
Porque o content_ids precisa ser o mesmo identificador em toda a jornada, de ViewContent a Purchase. Qualquer troca de valor no caminho quebra o casamento com o catálogo, e junto com ele o Advantage+ Catalog Ads e o remarketing dinâmico.
A falha concreta e recorrente em checkout externo: os eventos de topo usam o ID de variante da loja e o Purchase troca para o ID interno do checkout. São dois números diferentes para o mesmo produto, e o Purchase deixa de casar com qualquer item do catálogo.
A troca de ID no meio da jornada
O padrão observado em auditoria tem esta cara. O mesmo produto, dois identificadores diferentes, dependendo de quem disparou o evento:
| Evento | Quem dispara | Identificador enviado |
|---|---|---|
| ViewContent | Loja | 53616896278712 (ID de variante) |
| AddToCart | Loja | 53616896278712 (ID de variante) |
| InitiateCheckout | Loja | 53616896278712 (ID de variante) |
| Purchase | Checkout externo | 251498732 (ID interno do checkout) |
O efeito é específico e fácil de confundir com problema de mídia: a campanha de catálogo entrega, gera visualização e carrinho, e reporta zero conversão. O anunciante conclui que a campanha não funciona e desliga uma estrutura que estava vendendo.
Qual fonte da camada de dados usar
O catálogo da Shopify é variant-level
O catálogo gerado pelo Product Catalog nativo trabalha em nível de variante: o content ID é o ID de variante puro. Portanto content_ids e contents[].id devem usar item_variant, não item_id.
A armadilha que faz a implementação parecer certa
item_id e item_variant nem sempre são a mesma coisa
ecommerce.items, frequentemente item_id é igual a item_variant, e a implementação passa no teste. Mas em cart_state.lines o item_id é o ID de produto, diferente do de variante. Uma tag que lê a fonte errada quebra o match só em parte dos eventos. Isso é pior que quebrar inteiro, porque o relatório parcial passa a impressão de que está tudo funcionando.Divergência de tipo entre fontes
Há ainda uma diferença de formato que engana. No GA4, item_variant costuma vir como rótulo de texto, algo como "Azul / M", enquanto no payload do checkout ele vem como identificador numérico. Um agregador de itens que lê a fonte errada entrega content_ids vazio ou preenchido com texto, que não casa com catálogo nenhum.
content_type ausente é falha silenciosa
Sem content_type, a Meta não sabe se os valores em content_ids são product ou product_group. O alvo é content_type: "product" em todos os eventos, com o mesmo nível de identificador em toda a jornada.
Dois detalhes de especificação que passam batidos
contents[], a especificação da Meta usa item_price, não price. E o campo name dentro de contents é ignorado, porque é redundante com content_name. Enviar no nome errado não gera erro visível, só deixa de ser lido.Como diagnosticar
- 1No Gerenciador de Eventos, abra um ViewContent recente e anote o valor de content_ids.
- 2Abra um Purchase recente do mesmo produto e compare o valor. Se forem diferentes, a troca de ID está confirmada.
- 3Verifique se content_type está presente e igual a product nos dois eventos.
- 4No catálogo, confira o formato do ID dos itens: ele precisa ser o mesmo nível usado nos eventos.
- 5Inspecione a camada de dados no checkout e confirme de qual objeto a tag está lendo o identificador.
- 6Confira se o valor enviado é numérico e não um rótulo de texto de variante.
O que corrigir o ID não resolve
- A Conversions API não conserta
content_idserrado. Ela entrega o mesmo erro mais rápido e com mais confiabilidade de transporte. - Casar o catálogo não recupera o histórico. As conversões que já foram registradas sem casamento continuam sem casamento.
- Identificador correto não corrige catálogo desatualizado, com produto fora de estoque ou preço divergente.
Perguntas relacionadas
Por que minhas campanhas de catálogo não recebem conversão?
Na causa mais comum, o content_ids do Purchase não é o mesmo dos eventos de topo do funil. Os eventos de visualização e carrinho usam o ID de variante da plataforma, e o Purchase, disparado pelo checkout, troca para o ID interno daquele checkout. Como os dois valores são diferentes, o Purchase nunca casa com nenhum item do catálogo, e a campanha fica sem sinal de conversão mesmo com vendas acontecendo.
Qual ID devo usar no content_ids de uma loja Shopify?
O catálogo gerado pelo Product Catalog nativo da Shopify é variant-level, ou seja, o content ID é o ID de variante puro. Então content_ids e contents[].id devem usar item_variant, não item_id. Usar o ID de produto faz o match falhar em qualquer loja que tenha mais de uma variante por produto.
Meu item_id e item_variant são iguais. Posso usar qualquer um?
Não. Em ecommerce.items eles frequentemente coincidem, o que faz a implementação parecer correta. Mas em outras fontes da camada de dados, como cart_state.lines, o item_id é o ID de produto, diferente do variant. Se a tag lê a fonte errada em parte dos eventos, o match quebra só em parte da jornada, o que é pior que quebrar inteiro porque parece funcionar.
O que acontece se content_type estiver ausente?
É uma falha silenciosa. Sem content_type, a Meta não sabe se os valores em content_ids são product ou product_group, e o casamento com o catálogo fica indefinido. O alvo é content_type igual a product em todos os eventos, com o mesmo nível de ID em toda a jornada.
A Conversions API corrige um content_ids errado?
Não. A CAPI entrega o mesmo erro por um caminho mais confiável, e mais rápido. Se o identificador do produto está errado no payload, ele chega errado ao destino independentemente de ter saído do navegador ou do servidor. Corrigir o ID é um trabalho de camada de dados, não de transporte.
Documentacao de referencia
Continuar lendo
Tracking para Facebook Ads
_fbc, _fbp, Conversions API e deduplicação por event_id.
Advanced Matching e normalização
Telefone, cidade e e-mail. Normalizar antes de hashear.
Meta e a loja mostram números diferentes
As dez causas reais da divergência, em ordem de frequência.
Pix e boleto: conversão perdida
Pagamento assíncrono e a conversão que chega sem identificador.
Campanha de catálogo entregando e sem conversão atribuída?
No diagnóstico gratuito comparamos o identificador enviado em cada evento da jornada e mostramos onde ele troca.
Agendar diagnostico gratuito