Product data é o novo site lento

Um varejista de moda descobriu, depois de meses, que 38% dos seus SKUs de denim não tinham o atributo “fit” preenchido. Nada quebrou. A página carregava, o produto aparecia na vitrine, o checkout funcionava. Mas a busca interna não filtrava por caimento, o feed do Merchant Center rejeitava metade dos itens por atributo faltante, e o ChatGPT, quando perguntado por “jeans skinny masculino preto”, citava o concorrente. O board olhava o tempo de carregamento da home e dormia tranquilo. O problema não era a velocidade do site. Era a pobreza do dado de produto.

Essa é a tese deste guia, e ela é desconfortável: dado de produto pobre é o novo site lento. Há dez anos, um site que demorava a carregar perdia venda de um jeito visível, mensurável, com gráfico de bounce despencando. Hoje o equivalente acontece embaixo do radar. O catálogo incompleto não gera erro, não dispara alerta, não aparece no relatório semanal. Ele apenas faz você sumir, devagar, das respostas que importam, enquanto o board comemora um Core Web Vitals impecável.

Por que dado de produto ruim não aparece em nenhum dashboard?

Porque ele degrada resultado em vez de quebrar funcionalidade. Um bug derruba a página e alguém é acordado de madrugada. Um atributo faltante apenas reduz a probabilidade de aquele produto ser encontrado, filtrado, comparado ou citado. A perda é estatística, distribuída por milhares de SKUs, diluída em todos os canais ao mesmo tempo. Ninguém vê a venda que não aconteceu.

O mecanismo é simples de entender e brutal de corrigir. Cada canal de descoberta consome o mesmo dado de origem, mas penaliza a ausência de forma diferente. A busca interna não oferece o filtro. O Google rejeita o item no feed. A IA generativa, que precisa de atributos estruturados para responder com confiança, prefere o produto que tem o dado completo. O resultado é que a mesma lacuna de catálogo cobra um pedágio em sete frentes simultâneas, e nenhuma delas sozinha é grande o bastante para acionar um alarme.

Quando 71% das páginas citadas pelo ChatGPT carregam structured data, a pergunta deixa de ser “o nosso site tem schema?” e passa a ser “o nosso catálogo tem dado limpo o suficiente para gerar schema que não minta?”. Schema é a consequência. O dado de produto é a causa.

O que é a base de oferta, e por que PIM não basta sozinho?

A base de oferta é a camada única onde vive o dado de produto antes de virar qualquer experiência. Ela se sustenta sobre quatro disciplinas que costumam ser tratadas como ferramentas separadas, e é justamente essa separação que produz catálogo incoerente.

PIM (Product Information Management) é o coração: centraliza atributos, governa quem edita o quê, define obrigatoriedade por categoria. Akeneo virou referência nesse papel. Mas PIM sozinho organiza o texto e os números; não resolve a mídia nem a experiência. DAM (Digital Asset Management) versiona imagens, vídeos, tabelas de medida e documentos, garantindo que a foto certa na resolução certa chegue a cada canal. MDM (Master Data Management) mantém a integridade dos dados-mestre — SKU, GTIN, hierarquia de categoria — para que o mesmo produto seja o mesmo produto no ERP, no site, no marketplace e no feed. E PXM (Product Experience Management) é a camada que orquestra como esse dado vira narrativa adaptada a cada contexto: o texto do marketplace não é o texto da landing page, nem o texto que um agente de compra precisa ler.

Tratar essas quatro disciplinas como projetos isolados é o erro estrutural mais comum. O PIM fica num time, o DAM em outro, o MDM mora no TI e ninguém cuida da experiência. O resultado é dado tecnicamente presente e comercialmente inútil.

Disciplina	O que governa	Falha típica quando ausente
PIM	Atributos, regras de obrigatoriedade, fluxo editorial	Campos vazios, padrões divergentes por fornecedor
PXM	Adaptação do dado por canal e contexto	Texto genérico que não converte em nenhum canal
DAM	Mídia versionada e distribuída	Imagem errada, formato rejeitado pelo marketplace
MDM	Consistência de SKU, GTIN e hierarquia	Produto duplicado, GTIN trocado, feed rejeitado

Quantos canais bebem da mesma fonte de dado?

Pelo menos nove, e a lista só cresce. Cada um deles eleva a aposta sobre a qualidade do dado de origem, porque um único atributo errado se propaga por todos ao mesmo tempo.

SEO clássico depende de título, descrição e atributos para ranquear nas páginas de categoria. GEO — a visibilidade dentro de respostas de IA — exige dado estruturado e verificável, já que 65% das páginas citadas no Google AI Mode trazem structured data e o dado bem estruturado dá cerca de 3,1 vezes mais chance de exibição em AI Overviews. A busca interna do próprio site vive de facetas, que são atributos. Social commerce puxa imagem e preço do mesmo cadastro. Marketplaces rejeitam ou despriorizam itens com dado incompleto. Retail media precisa de catálogo limpo para segmentar e medir. Personalização recomenda com base em atributos. Comparadores de preço cruzam GTIN e disponibilidade. E os agentes de compra — o canal que mais cresce — leem o catálogo como API: se o atributo não estiver lá, de forma legível por máquina, o produto não entra na resposta.

A consequência prática é que melhorar o dado de origem não é uma iniciativa de SEO, nem de marketing, nem de TI, e sim uma alavanca de receita que rende em nove frentes de uma vez. Por isso o investimento em base de oferta tem ROI difícil de atribuir e fácil de subestimar: ele aparece pulverizado em todos os canais, e some quando você corta.

Como medir o que não dói: completeness score e time-to-market

Duas métricas conectam qualidade de catálogo a dinheiro. A primeira é o completeness score por categoria, ponderado pelos atributos que cada canal realmente consome. Não é contar campos preenchidos — é medir se os atributos que importam para descoberta e conversão naquela categoria estão presentes, corretos e atualizados. Um tênis de corrida precisa de drop, tipo de pisada e peso; um vinho precisa de safra, uva e país. Completeness genérico mente; completeness por categoria informa.

A segunda é time-to-market: quantos dias se passam entre receber um produto e tê-lo plenamente publicado, com dado completo, em todos os canais. Catálogo que demora a ficar pronto perde a janela de demanda. No varejo de moda, onde a coleção tem prazo de validade comercial curto, cada semana de atraso no enriquecimento é venda que vai para quem publicou primeiro.

Essas duas métricas têm uma virtude política: tornam visível o custo que hoje é invisível. Quando o board vê que 30% das categorias de alto giro estão abaixo de 80% de completeness, e que isso correlaciona com rejeição de feed e ausência em IA, a conversa muda de “quanto custa o PIM” para “quanto custa não ter”.

Por onde atacar primeiro sem tentar ferver o oceano?

Enriquecimento incremental por categorias de alto giro. A tentação de qualquer projeto de catálogo é tentar perfeição em todos os SKUs de uma vez — e morrer na praia, porque o catálogo é grande, mutável e nunca está pronto. A disciplina correta é o oposto: priorizar.

A URBN, casa que opera Anthropologie, Free People e Urban Outfitters, tratou o enriquecimento como esforço escalonado em vez de big bang. No denim, categoria de altíssimo giro, atacar primeiro os atributos que alimentam filtro de busca, feed e schema — fit, lavagem, cintura, comprimento, composição — destrava conversão na busca interna, recupera itens rejeitados no Merchant Center e dá ao schema dado suficiente para que a IA cite a peça certa. Só depois o esforço migra para categorias de cauda.

O passo a passo que sustenta esse retorno tem uma ordem que importa:

1. Medir o completeness atual por categoria e cruzar com receita e rejeições de feed.
2. Escolher as categorias de maior giro e margem cujo dado está abaixo do limiar útil.
3. Definir, por categoria, os atributos obrigatórios que alimentam SEO, GEO, busca, feed e agentes.
4. Enriquecer esses atributos primeiro, validar contra Merchant Center (corrigindo rejeições via plataformas de feed como Feedonomics) e medir o lift.
5. Só então avançar para a cauda do catálogo, com o processo já calibrado.

Feeds bem corrigidos importam tanto quanto o dado em si: o Merchant Center é implacável com atributo faltante, e ferramentas de gestão de feed existem justamente para traduzir a base de oferta em algo que cada destino aceite sem rejeição.

O que o board precisa entender antes de cortar

Que dado de produto pobre não é dívida técnica de TI — é erosão de receita disfarçada de planilha completa. A decisão executiva não é comprar uma ferramenta; é tratar a base de oferta como infraestrutura, com dono, métrica e orçamento recorrente, do mesmo jeito que ninguém mais questiona investir em performance de site.

O próximo passo é concreto e barato: rode um completeness score por categoria nas suas 20 categorias de maior receita esta semana, cruze com as rejeições do Merchant Center dos últimos 90 dias e com a presença ou ausência dos seus produtos nas respostas do ChatGPT e do Google AI Mode para as suas dez consultas mais valiosas. O diagnóstico vai doer. Mas é a primeira vez que o custo invisível vira número — e número, o board entende.