Especificações: product_detail e additionalProperty

Para levar a ficha técnica de um eletrônico a um assistente de IA, use o atributo product_detail no feed do Merchant Center e a propriedade additionalProperty no schema da página, ambos gerados da mesma tabela de especificações. Assim o feed e a página dizem a mesma coisa, e cada valor é um campo com nome, em vez de uma frase solta.

Por que dividir a ficha técnica em campos?

Texto corrido é uma carta; um campo é um formulário. Uma carta que diz "notebook leve, com tela nítida e bastante memória" é agradável de ler e ruim de extrair. Um formulário com "Memória: 16 GB" e "Peso: 1,2 kg" entrega o dado sem exigir interpretação. Quando um assistente precisa comparar três modelos por peso e memória, ele se beneficia de ter os valores em campos nomeados, e não de deduzi-los de adjetivos.

Isso não garante que a IA vá usar o campo. Nós não afirmamos isso. O que dá para afirmar é que um dado em campo tem menos caminhos para dar errado do que um dado escondido em parágrafo. Se você quer o raciocínio completo sobre completude de atributos, ele está em outro post; aqui o assunto é a técnica.

Como funciona o product_detail no Merchant Center?

Segundo a Central de Ajuda do Google, product_detail é um atributo opcional e repetível, usado para fornecer especificações técnicas ou outros detalhes adicionais que os outros atributos não cobrem. Cada detalhe é composto por três partes:

• section_name (opcional, mas recomendado): agrupa detalhes relacionados, como "Conectividade" ou "Memória".
• attribute_name (obrigatório): o nome da especificação.
• attribute_value (obrigatório): o valor.

As regras de formato merecem atenção. Cada detalhe tem de 1 a 150 caracteres, e cada produto aceita até 100 detalhes. Em feeds de texto, as três partes são separadas por dois-pontos, como em Garantia:1 ano do fabricante; se você omite a seção, mantém os dois-pontos iniciais. Em XML, usa-se <g:product_detail> com os três elementos aninhados. Valores que contêm vírgulas, aspas ou dois-pontos precisam estar entre aspas duplas.

A página também lista o que não entra ali: preço, datas de promoção, frete, prazo de entrega e nomes de empresa têm atributos próprios. Inclua um nome e um valor apenas quando o valor estiver confirmado, e não coloque palavras-chave ou termos de busca.

E o additionalProperty no schema?

No vocabulário do schema.org, additionalProperty é um par propriedade-valor que descreve uma característica adicional de uma entidade, como um recurso do produto, quando o vocabulário não tem uma propriedade própria. O tipo esperado é PropertyValue, e o schema.org o lista como utilizável em Product, Offer e outros tipos.

O mesmo texto traz um aviso que vale ouro: se existe uma propriedade específica, como width, color ou gtin13, as aplicações normalmente esperam que o dado venha por ela. Ou seja, additionalProperty é para o que sobra, não para tudo. Dentro de um PropertyValue, os exemplos do próprio schema.org usam name para o rótulo, value para o valor, unitCode para um código de unidade (por exemplo, "GRM" para grama) e unitText para a unidade escrita. Há ainda propertyID, um identificador que esclarece o significado da propriedade.

Um limite que precisamos registrar: a página de dados estruturados de Product do Google que consultamos não menciona additionalProperty. Portanto não podemos dizer que o Google a use para um recurso de busca específico. Ela continua sendo um formato legível por máquina e válido no vocabulário, o que já é útil para qualquer consumidor de dados que o leia. Para o quadro geral das regras, veja dados estruturados Product.

Como montar a ficha de um produto de exemplo?

Usaremos o produto fictício Aurora Pro 14, o exemplo público do site, com valores inventados só para ilustrar. Comece por uma tabela única, a fonte da verdade:

1. Liste cada especificação com seção, nome, valor e, quando houver, unidade. Exemplo: seção "Memória", nome "Capacidade", valor "16", unidade "GB".
2. Separe o que já tem propriedade própria (marca, cor, identificador) do que não tem. O primeiro grupo vai para os campos específicos; o segundo vai para product_detail e additionalProperty.
3. Gere o feed a partir da tabela, no formato Memória:Capacidade:16 GB.
4. Gere o JSON-LD da página a partir da mesma tabela, com um PropertyValue por linha, usando name e value e, se o valor for numérico, unitText.
5. Compare os dois no final. Se o feed diz 16 GB e a página diz 8 GB, a IA não saberá em qual confiar, e o problema é seu, não dela. O post sobre como a IA reconcilia feed e schema mostra esse cenário.

Onde essa ficha costuma quebrar?

Em eletrônicos, os erros se repetem. Unidades misturadas, como "1,2 kg" numa linha e "1200 g" noutra, impedem comparação limpa. Valores promocionais ou comerciais ("o mais leve da categoria") escorregam para o campo de especificação. Variantes de memória ou cor compartilham uma única ficha, e o valor descreve só uma delas. Para esse último caso, a entidade de produto e as variantes são o ponto de partida.

Há ainda a questão do idioma. A Central de Ajuda diz que, se você envia feeds em vários idiomas, deve localizar os nomes de seção, os nomes de atributo e os valores em cada feed. Um feed em português com "Memory" como nome de atributo é um feed pela metade.

O que levar daqui

• Um campo nomeado tem menos caminhos para dar errado do que uma especificação escondida em parágrafo.
• product_detail aceita de 1 a 150 caracteres por detalhe e até 100 detalhes por produto, no formato seção, nome e valor.
• Use additionalProperty só para o que não tem propriedade própria no schema.org, e não conte com ele como garantia de nenhum recurso de busca.
• Gere feed e schema da mesma tabela, e compare os dois antes de publicar.
• Padronize unidades e localize os nomes dos campos em cada idioma.

Perguntas frequentes

Posso colocar preço e frete no product_detail?

Não. A orientação do Google é usar os atributos próprios de preço, frete e prazo, deixando o product_detail para especificações confirmadas.

additionalProperty substitui as propriedades específicas do schema?

Não. O schema.org avisa que, havendo propriedade específica para o dado, as aplicações esperam encontrá-lo nela. Use additionalProperty para o resto.

Preencher esses campos garante que a IA recomende meu produto?

Não. Preencher bem torna a ficha legível e consistente, mas ser recomendado depende de modelo, prompt e dia. A medição é outra etapa, descrita em /methodology.

Quer saber se a ficha técnica da sua página aparece como esperado numa leitura automatizada? O diagnóstico gratuito mostra uma primeira leitura de prontidão, com a ressalva de que prontidão não é o mesmo que ser recomendado.