O feed de produtos do Google é o envio que leva o catálogo ao Merchant Center, com cada item descrito por campos como título, descrição, link, imagem, preço e disponibilidade. O Google valida esses dados e decide onde e como o produto aparece. Num catálogo grande, a maior parte das reprovações começa no cadastro de origem.
Quem cuida de um catálogo pequeno resolve com o plugin da plataforma. Num catálogo com milhares de SKUs, variações e várias marcas, o feed vira um trabalho à parte.
Quais campos do feed de produtos pesam mais?
A especificação completa de dados de produto está publicada pelo Google na central de ajuda do Merchant Center, e muda de tempos em tempos. Na prática, alguns campos concentram a maior parte das reprovações e do desempenho:
- Título. É o que o comprador lê primeiro e o que o Google usa para entender a busca a que o item responde. Tipo de produto, marca e o atributo que diferencia (capacidade, cor, tamanho) costumam valer mais do que adjetivos.
- Descrição. Complementa o título com informação real do produto. Texto promocional e texto copiado de outro item não ajudam.
- Identificadores. GTIN, marca e código do fabricante dizem ao Google que produto é aquele. Variação sem código próprio é causa frequente de pendência.
- Imagem. A primeira foto mostra o produto sozinho, sem texto ou montagem por cima.
- Preço e disponibilidade. Precisam bater com o que a página do produto mostra. Divergência entre feed e página é motivo comum de reprovação.
- Categoria. Ajuda o Google a classificar o item; quando ela não vem, o próprio Google a infere.
Sobre identificadores, a regra do atributo GTIN diz que cada variante, de cor ou de tamanho, tem o próprio GTIN. Os casos difíceis estão no post sobre GTIN e EAN no e-commerce, e as regras de imagem, no de fotos de produto por canal.
Onde o feed de um catálogo grande quebra
Os problemas raramente são do formato do arquivo. Eles aparecem quando o dado de origem é irregular:
- Variações tratadas como um produto só. Cor e tamanho precisam virar itens com identificador próprio, agrupados pelo produto pai.
- Título montado sem padrão. Cada pessoa da equipe escreveu de um jeito, e o feed herda a bagunça.
- Preço que muda na loja e não no feed. Promoção ativada na loja, feed com o valor antigo.
- Imagem de uma variação na outra. A foto da cor errada vai para o item errado porque o vínculo foi feito à mão.
Cada um desses é um problema de cadastro. Corrigido na origem, ele some do feed e de todos os outros canais que leem o mesmo cadastro.
Arquivo, planilha ou API
O Merchant Center aceita o catálogo de mais de um jeito: arquivo agendado, planilha e envio por API. Para catálogos que mudam com frequência, o envio por API costuma ser o caminho mais controlável, porque cada atualização sai item a item e o retorno do Google fica associado ao produto. A visão geral da Merchant API descreve a API como forma de automatizar a gestão de produtos, ao lado de arquivos e de outros métodos de envio.
O AdCore Turbo no caminho do feed
O AdCore Turbo publica no Google pela Merchant API e leva o mesmo cadastro aos outros canais. Antes de publicar, o Feed Health aponta no SKU o campo obrigatório que falta para o canal, como título, descrição, link, imagem ou preço, e dá uma nota de 0 a 100 por feed; a correção acontece no cadastro, pela sua equipe. Quando o produto tem a versão da foto no tamanho do Google gerada pelo DAM, é essa versão que vai para o feed.
O detalhe de como os feeds funcionam está na página de gestão de feeds. O que vale acompanhar é quantos itens ficam parados em pendência no Merchant Center, semana a semana. Quando o problema já virou reprovação, o post sobre produto reprovado no Merchant Center mostra como atacar cada causa.