Paridade entre o Feed de Merchant e a Página

O feed e a página de produto são duas representações do mesmo item, mantidas por equipas diferentes, por isso divergem. A discrepância suprime o item sem tocar no posicionamento orgânico, razão pela qual passa meses despercebida. O instinto é despachar as reprovações na interface uma a uma, mas quase sempre são produzidas por um punhado de regras do feed ou por campos em falta no catálogo de origem.

O ficheiro da competência

---
name: merchant-feed-and-page-parity
description: Use quando as fichas de produto gratuitas mostram muito menos itens do que o catálogo tem, ou quando há itens reprovados enquanto as próprias páginas de produto parecem estar bem.
---

# Paridade entre o Feed de Merchant e a Página

O feed e a página de produto são duas representações do mesmo item, mantidas por equipas diferentes, por isso divergem. A discrepância suprime o item sem tocar no posicionamento orgânico, razão pela qual passa meses despercebida. O instinto é despachar as reprovações na interface uma a uma, mas quase sempre são produzidas por um punhado de regras do feed ou por campos em falta no catálogo de origem.

## O que precisa primeiro

- a exportação actual do feed mais os diagnósticos ao nível do item com os motivos de reprovação
- páginas de produto renderizadas para uma amostra transversal às categorias, a mostrar preço e disponibilidade tal como um crawler os vê
- valores de cobertura de GTIN, MPN e marca por categoria, tirados do catálogo de origem e não do feed
- as definições de impostos e de envio configuradas na conta de merchant

## Método

1. Conte os itens reprovados e pendentes por motivo antes de abrir um único item. Dois ou três motivos costumam explicar a maior parte do volume e são falhas de configuração ou de cobertura, e não falhas item a item.
2. Reconcilie primeiro as contagens: linhas do feed contra SKU vendáveis na base de dados. Um feed a que falta um terço do catálogo tem uma falha de geração, e nenhum trabalho de atributos importa enquanto isso não estiver resolvido.
3. Compare preço e disponibilidade entre o feed e a página renderizada em toda a amostra, olhando aos timestamps e não apenas aos valores. Caches diferentes nos dois caminhos são a origem mais comum de discrepância.
4. Corrija a cobertura de identificadores na origem do catálogo e não numa regra do feed. Um identificador inventado durante uma transformação do feed chumba na validação e corrompe o registo de que vai precisar mais tarde.
5. Construa os títulos do feed pela sua própria ordem de atributos, marca depois produto depois o atributo pelo qual os compradores pesquisam, em vez de reutilizar o title da página. Os títulos do feed são comparados com as pesquisas e cortados sem dó, por isso a ordem do title da página raramente serve.
6. Escreva quais são os campos em que o feed pode divergir. Envio e impostos pertencem às definições da conta e não aos dados do item, e as descrições podem legitimamente ser mais curtas do que as da página.
7. Volte a ver os diagnósticos aos 14 dias e observe a composição dos motivos e não o número de destaque, já que resolver um motivo expõe rotineiramente um segundo que estava escondido por trás dele.

## O que isto produz

Um feed reconciliado com uma regra declarada de paridade de campos, reprovações resolvidas na causa, e cobertura de identificadores reparada no catálogo de origem.

## Onde isto corre mal

- remendar discrepâncias com regras do feed enquanto o catálogo de origem continua errado, de modo que os mesmos erros voltam na reconstrução completa seguinte
- gerar identificadores de preenchimento para satisfazer um campo obrigatório, o que produz reprovações mais difíceis de diagnosticar do que era o campo em falta
- ler uma taxa de aprovação ao nível da conta como sinal de saúde quando as reprovações estão nas poucas linhas de maior receita
- comparar o feed com o HTML de origem quando o preço e o stock são injectados do lado do cliente, de modo que a discrepância nunca aparece nos testes

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/merchant-feed-and-page-parity

O que precisa primeiro

• a exportação actual do feed mais os diagnósticos ao nível do item com os motivos de reprovação
• páginas de produto renderizadas para uma amostra transversal às categorias, a mostrar preço e disponibilidade tal como um crawler os vê
• valores de cobertura de GTIN, MPN e marca por categoria, tirados do catálogo de origem e não do feed
• as definições de impostos e de envio configuradas na conta de merchant

Método

1. 01 Conte os itens reprovados e pendentes por motivo antes de abrir um único item. Dois ou três motivos costumam explicar a maior parte do volume e são falhas de configuração ou de cobertura, e não falhas item a item.
2. 02 Reconcilie primeiro as contagens: linhas do feed contra SKU vendáveis na base de dados. Um feed a que falta um terço do catálogo tem uma falha de geração, e nenhum trabalho de atributos importa enquanto isso não estiver resolvido.
3. 03 Compare preço e disponibilidade entre o feed e a página renderizada em toda a amostra, olhando aos timestamps e não apenas aos valores. Caches diferentes nos dois caminhos são a origem mais comum de discrepância.
4. 04 Corrija a cobertura de identificadores na origem do catálogo e não numa regra do feed. Um identificador inventado durante uma transformação do feed chumba na validação e corrompe o registo de que vai precisar mais tarde.
5. 05 Construa os títulos do feed pela sua própria ordem de atributos, marca depois produto depois o atributo pelo qual os compradores pesquisam, em vez de reutilizar o title da página. Os títulos do feed são comparados com as pesquisas e cortados sem dó, por isso a ordem do title da página raramente serve.
6. 06 Escreva quais são os campos em que o feed pode divergir. Envio e impostos pertencem às definições da conta e não aos dados do item, e as descrições podem legitimamente ser mais curtas do que as da página.
7. 07 Volte a ver os diagnósticos aos 14 dias e observe a composição dos motivos e não o número de destaque, já que resolver um motivo expõe rotineiramente um segundo que estava escondido por trás dele.

O que isto produz

Um feed reconciliado com uma regra declarada de paridade de campos, reprovações resolvidas na causa, e cobertura de identificadores reparada no catálogo de origem.

Onde isto corre mal

• remendar discrepâncias com regras do feed enquanto o catálogo de origem continua errado, de modo que os mesmos erros voltam na reconstrução completa seguinte
• gerar identificadores de preenchimento para satisfazer um campo obrigatório, o que produz reprovações mais difíceis de diagnosticar do que era o campo em falta
• ler uma taxa de aprovação ao nível da conta como sinal de saúde quando as reprovações estão nas poucas linhas de maior receita
• comparar o feed com o HTML de origem quando o preço e o stock são injectados do lado do cliente, de modo que a discrepância nunca aparece nos testes

Use esta skill na sua própria IA

O ficheiro é markdown simples, com o nome e o gatilho no frontmatter. Quando um assistente consegue carregar skills sozinho, é esse frontmatter que lê para decidir que esta se aplica.

Mais em SEO para e-commerce