JSON em Feeds de Produto: Integração Sem Erros em Redes de Varejo

Quando Um Campo Derruba 50.000 Produtos

O feed JSON é gerado pelo ERP às 23h, processado pelo Google Merchant Center às 00h30, e qualquer erro de sintaxe faz o Merchant Center rejeitar o arquivo inteiro — não o produto com erro, o arquivo inteiro. São 50.000 produtos fora do Google Shopping até o próximo ciclo de processamento, 24 horas depois.

Foi exatamente isso que aconteceu em uma das integrações que gerenciamos para um grande varejista brasileiro. O campo description de um produto de categoria "Decoração" continha uma aspa dupla literal não escapada — o nome do produto era algo como Espelho "Veneza" 60x80, e a pessoa que cadastrou no ERP usou aspas tipográficas que, ao serem exportadas como UTF-8, quebravam a estrutura JSON.

O feed ficou fora por 11 horas — das 00h30 até o time de desenvolvimento identificar e corrigir o problema às 11h40 do dia seguinte. Nenhum alerta automático foi disparado porque o sistema de monitoramento verificava apenas se o arquivo havia sido enviado, não se havia sido aceito. Aquelas 11 horas de invisibilidade custaram uma estimativa de 8.400 impressões perdidas no Google Shopping durante o horário de pico matinal.

Campos Obrigatórios do Google Shopping Feed

O Google Merchant Center tem requisitos específicos para feeds de produto. Os campos obrigatórios para feed estruturado em JSON ou XML:

• id — identificador único do produto. Use o SKU do ERP. Nunca use IDs sequenciais que podem se repetir após migração de sistema.
• title — nome do produto. Máximo 150 caracteres. Evite caracteres especiais, aspas e simbolos promocionais ("PROMOÇÃO!", "MELHOR PREÇO") — o Merchant Center penaliza títulos com linguagem promocional.
• description — descrição do produto. Máximo 5.000 caracteres. Texto plano — sem HTML, sem markdown. Aspas dentro da descrição devem ser escapadas (\") ou substituídas por aspas tipográficas Unicode.
• link — URL da página do produto. Deve corresponder exatamente à URL indexada, incluindo protocolo (https) e sem redirecionamentos.
• image_link — URL da imagem principal. Mínimo 100×100 px para produtos não-moda; mínimo 250×250 px recomendado. HTTPS obrigatório.
• price — preço no formato 99.90 BRL. Ponto como separador decimal, espaço antes da moeda. NUNCA vírgula como separador decimal.
• availability — in_stock, out_of_stock ou preorder. Produto marcado como in_stock com estoque zero causa penalidade de qualidade no Merchant Center.

Caracteres que Quebram JSON em Feeds de Varejo

Feeds gerados por ERPs de varejo têm padrões específicos de quebra. Os ofensores mais comuns em catálogos brasileiros:

• Aspas duplas não escapadas: produto com nome Perfil "T" 3m quebra qualquer parser JSON. Escape: Perfil \"T\" 3m ou substitua por aspas simples.
• Caracteres de controle: tabs (\t) e quebras de linha (\n, \r) inseridos em campos de texto pelo sistema de cadastro. Comum em campos de descrição copiados de PDF ou Word. Um \r\n literal dentro de uma string JSON é inválido e quebra silenciosamente em alguns parsers.
• BOM (Byte Order Mark): arquivos exportados pelo Excel com codificação UTF-8 com BOM incluem os bytes EF BB BF no início do arquivo. O parser JSON rejeita o arquivo por "caractere inesperado antes de {". Remova o BOM na exportação ou no pré-processamento.
• Barra invertida não escapada: campos de dimensão como "30cm × 20cm × 15cm" viram problemas quando o × é substituído por \x por algum sistema intermediário. Barra invertida em JSON é caractere de escape — precisa ser escapada como \\.
• Encoding misto: um campo em UTF-8 e outro em ISO-8859-1 no mesmo arquivo é o tipo de bug que só aparece em produtos com cedilha ou ã — e que se manifesta apenas para parte do catálogo, tornando o diagnóstico difícil.

Formatação de Preço: O Campo que Mais Causa Rejeição

O campo de preço no Google Shopping Feed tem formato rigoroso: 99.90 BRL. Ponto decimal, espaço, código ISO de moeda. Sem vírgula, sem R$, sem formatação de moeda local.

ERPs brasileiros exportam preço como 99,90 — com vírgula decimal, padrão local. O feed que usa esse formato é rejeitado. A transformação precisa acontecer no pipeline de exportação, não manualmente.

Outro problema comum: preços com 4 casas decimais por arredondamento de ponto flutuante. O ERP exporta 99.9000000000001 porque a representação interna de 99,90 em ponto flutuante tem esse comportamento. O Google Merchant Center aceita até 2 casas decimais — qualquer coisa além disso pode ser rejeitado dependendo da versão do parser.

Use o Formatador e Validador JSON para verificar a estrutura do seu feed antes de submetê-lo ao Merchant Center. Cole um exemplo do feed e o validador identifica imediatamente erros de sintaxe, campos malformados e caracteres inválidos.

Validação de Feed Antes do Envio ao Merchant Center

O processo de validação que implementamos para feeds de alto volume:

1. Validação sintática: parse completo do JSON antes de qualquer outra verificação. Se o JSON não é válido, nada mais adianta. Ferramentas: jq . no terminal, ou o validador online desta toolbox.
2. Validação de campos obrigatórios: verificar se todos os produtos têm os 7 campos obrigatórios presentes e não-nulos. Um produto com "price": null é tecnicamente JSON válido mas semanticamente inválido para o feed.
3. Validação de formato de preço: regex /^\d+\.\d{2} [A-Z]{3}$/ para verificar todos os valores de preço.
4. Validação de URL: amostra de 5% das URLs de produto e imagem para verificar se retornam 200. URLs que retornam 404 ou 301 causam penalidade de qualidade.
5. Alerta de tamanho: comparar o número de produtos no feed atual com a média dos últimos 7 feeds. Uma variação de mais de 5% para baixo é sinal de que produtos foram excluídos por erro.