Google Shopping e Merchant Center 2026 no PrestaShop: feed de produtos, GTIN, Performance Max

Google Shopping em 2026: a camada de aquisição mais mal explorada pelas lojas PrestaShop

Nas lojas PrestaShop de média dimensão que auditamos, o Google Shopping representa em média 18 % da faturação adquirida. Quando o feed está bem feito. Quando não está, e é a situação por defeito, são 3 % ou menos, com um custo de aquisição a disparar e produtos reprovados pelo Merchant Center sem que ninguém dê por isso.

A diferença joga-se em três níveis: a qualidade do feed (atributos exigidos, GTIN, identificadores únicos), a estratégia de campanha (Performance Max ou Standard Shopping), e a conformidade Merchant Center (políticas 2024-2026, Comparison Shopping Services, preços de referência). Os três são temas distintos e técnicos. Este artigo cobre-os pela ordem em que aparecem no pipeline de um comerciante que arranca ou refaz o seu canal Shopping em 2026.

O que mudou no Merchant Center em 2024-2026

Três evoluções maiores redefinem o terreno de jogo:

O Merchant Center Next substitui a antiga interface

Desde 2024, a Google migrou todas as contas para o Merchant Center Next: uma remodelação que aplana a hierarquia, simplifica a criação de feeds e impõe mais estritamente as políticas. Consequência prática: feeds que passavam em silêncio há 18 meses são hoje reprovados em bloco, nomeadamente na ausência de shipping e de tax para os comerciantes fora da UE.

O fim da exclusividade dos Comparison Shopping Services do lado da UE

Na sequência da decisão europeia e dos seus ajustes de 2023-2024, os comerciantes da UE podem passar pela Google diretamente ou por um CSS parceiro com um desconto efetivo de 20 % no CPC. Em orçamentos Shopping acima de 5 000 €/mês, a passagem por um CSS parceiro (Adwise, KelKoo Group, Productsup, etc.) é rentável. É uma otimização que não custa nada a ativar mas que 80 % dos comerciantes PrestaShop não ativam.

Os atributos de devolução e entrega tornaram-se quase obrigatórios

Desde o final de 2024, a Google exige shipping e return_policy explícitos na grande maioria das fichas Shopping. Sem isso, os anúncios correm mas com uma visibilidade degradada e um Quality Score em queda. Está alinhado com as propriedades Schema.org Product 2026 (hasMerchantReturnPolicy, shippingDetails) que a Google já impôs nos rich results.

Anatomia de um feed de produtos conforme em 2026

O feed Google Shopping é um ficheiro (XML, CSV, ou via Content API) que descreve cada produto para a Google. Vinte e cinco atributos são possíveis, dez são obrigatórios, e o seu tratamento correto faz a diferença entre uma conta Merchant Center saudável e uma conta sob aviso permanente.

Os dez atributos obrigatórios, e as armadilhas no PrestaShop

Os atributos « opcionais mas críticos »

Quatro atributos não estão marcados como obrigatórios mas a sua ausência degrada fortemente o desempenho:

• shipping: tabela de tarifas de entrega por país/região. Sem isto, a Google aplica regras por defeito muitas vezes erradas. A preencher com detalhe, sobretudo nas lojas multipaís.
• tax: imposto aplicável. Obrigatório para os comerciantes dos EUA. Para a UE, o preço com IVA vai em price e o IVA fica implícito mas pode ser declarado.
• google_product_category: categoria Google (3 a 5 níveis). Sem ela, a Google adivinha, muitas vezes mal. A mapear a partir da taxonomia oficial Google (5 600 categorias).
• product_type: a sua própria taxonomia, útil para a segmentação das campanhas.

Variantes e variações: a complexidade PrestaShop

No PrestaShop, uma ficha de produto com variações (tamanho × cor) é um produto com vários id_product_attribute. No Google Shopping, cada variação deve ser uma linha distinta do feed, com:

• id único por variação (tipicamente {id_product}-{id_product_attribute}).
• item_group_id comum a todas as variações do mesmo produto pai (tipicamente id_product). É o que permite à Google agrupar as variantes na interface do comprador.
• Atributos de variação: color, size, material, pattern, gender, age_group, consoante a categoria.
• GTIN por variação (muitas vezes um EAN diferente por tamanho ou cor).
• Stock por variação.

O erro mais frequente: enviar uma única linha por produto pai com um preço médio e um stock agregado. A Google bloqueia imediatamente. O módulo Google Shopping PrestaShop gere esta explosão por variação nativamente, com mapeamento dos atributos PrestaShop para os atributos Google.

GTIN: a fricção n.º 1 e a solução

O GTIN (Global Trade Item Number) é o identificador universal de um produto. EAN-13 na Europa, UPC-A nos EUA, ISBN para os livros. A Google pede o GTIN para todos os produtos que o têm nativamente (marcas conhecidas, produtos manufaturados). Para os produtos sem GTIN (criação artesanal, marca própria exclusiva, serviços), é preciso marcar explicitamente identifier_exists: false.

Duas armadilhas frequentes:

1. Os EAN-13 inválidos

O décimo terceiro dígito é um check digit, calculado sobre os doze primeiros segundo o algoritmo Módulo 10. Muitas lojas importam referências de fabricante com EAN truncados ou inventados. A Google rejeita-os em massa. A validação deveria ser feita no momento da importação, não descoberta três semanas depois quando o Merchant Center reprova 800 fichas.

2. O GTIN partilhado entre variações

Erro clássico no PrestaShop: o EAN está guardado no produto pai (ps_product.ean13) em vez da variação (ps_product_attribute.ean13). Resultado: todas as variantes têm o mesmo GTIN, a Google deteta a duplicação e reprova.

O bom padrão: guardar o EAN ao nível da variação quando ela tem a sua própria referência (caso típico: tamanhos diferentes do mesmo modelo), e ao nível do produto pai apenas para as fichas de variação única.

Performance Max ou Standard Shopping em 2026

Desde 2022, a Google empurra o Performance Max (PMax) como campanha por defeito. É uma campanha automatizada que combina Shopping, Display, YouTube, Discover e Search numa única lógica de otimização. O algoritmo decide onde colocar os anúncios e a quem. O anunciante fornece os asset groups (textos, imagens, sinais de audiência) e o orçamento.

Quando o PMax é rentável

• Catálogo amplo (1 000+ referências) com uma cobertura de categorias variada.
• Dados de conversão sólidos (50+ conversões / 30 dias por campanha, idealmente 100+).
• Margens que suportam um CPA otimizado pelo algoritmo (entre +15 e +30 % de CPA face ao Standard, mas volume × 2 a × 5).
• Capacidade de analisar os segmentos pelos relatórios de asset groups e de sinais de audiência (relatórios limitados mas em melhoria desde 2024).

Quando o Standard Shopping continua preferível

• Catálogo especializado (menos de 200 referências) em que o controlo granular por grupo de produtos é crítico.
• Margens apertadas que exigem um CPA estrito e um ROAS estável.
• Categorias reguladas (CBD, vape, alguns suplementos) em que o PMax pode alargar a segmentação de forma não conforme.
• Fase de aprendizagem: mais vale estruturar em Standard Shopping durante 3 meses para medir o desempenho por segmento, antes de passar a PMax com essas aprendizagens.

A stack híbrida 2026

O padrão que funciona hoje: Standard Shopping nos 20 % do catálogo que fazem 80 % da faturação, PMax na cauda longa. Combina o controlo (produtos estratégicos de topo) e a automatização à escala (cauda longa em que o custo de otimização manual não é rentável).

A exportação do feed PrestaShop: três arquiteturas

Arquitetura 1: feed estático XML/CSV regenerado

Um cron PHP (de hora a hora, ou todas as noites consoante o ritmo do catálogo) regenera um ficheiro XML ou CSV exposto numa URL fixa. O Merchant Center vai buscar esse ficheiro na frequência configurada. Simples, robusto, mas com uma latência de várias horas entre uma mudança e o seu reflexo no Shopping.

Arquitetura 2: push pela Content API

O módulo empurra as mudanças em tempo real pela Google Content API. Ideal para as lojas em que os preços mexem com frequência (vendas relâmpago, dynamic pricing) ou para os inventários limitados. Mais complexo de implementar, exige uma quota de Content API e uma gestão fina dos erros.

Arquitetura 3: feed em tempo real via Merchant Center Next

Desde 2024, o Merchant Center Next suporta as real-time inventory updates para os atributos críticos (preço, stock, disponibilidade). É um endpoint dedicado, independente do feed principal. O padrão recomendado em 2026 é combinar: um feed estático para os dados estáveis (título, imagem, descrição) e um push em tempo real para preço e stock.

O módulo DataFirefly implementa a arquitetura estática com uma opção de push preço/stock, cobrindo 95 % dos casos de comerciantes sem complexidade de API gateway.

Conformidade Merchant Center: as políticas 2024-2026 que reprovam

Quatro políticas estão na origem de 80 % das reprovações em 2026:

1. Preço de referência: diretiva Omnibus e política Google alinhada

Se mostra um preço riscado (« 99 € em vez de 149 € »), o preço de referência deve estar conforme à diretiva Omnibus, transposta em Portugal pelo Decreto-Lei n.º 109-G/2021: preço mais baixo praticado nos últimos 30 dias. A Google alinhou a sua política: um preço de referência não conforme = reprovação, e fica registado em toda a conta.

2. Produtos restringidos e proibidos

Tabaco, armas, conteúdos para adultos, medicamentos sujeitos a receita: proibidos. Suplementos alimentares, vape (sem nicotina), CBD: restringidos, com regras por país. A reprovação de um único produto restringido pode levar a uma suspensão de conta se repetida: filtrar sempre do lado do feed PrestaShop para excluir estas categorias da exportação.

3. Disponibilidade incoerente

O feed diz in_stock, a ficha mostra « Esgotado » ou um botão desativado. A Google compara e reprova. A solução: sincronizar o feed com o stock real por variação, com um limiar (por exemplo availability = out_of_stock se quantity ≤ 0 e allow_oosp = false).

4. Política de devolução e entrega não declarada

Desde 2025, a Google pede explicitamente as políticas de devolução e de entrega. Ou pelos parâmetros de conta do Merchant Center (políticas globais por país), ou pelos atributos shipping e return_policy no feed. Sem isso: aviso permanente e degradação do Quality Score.

Medir o desempenho: para lá do ROAS do Merchant Center

O ROAS mostrado pelo Google Ads é a métrica de superfície. Para pilotar corretamente, três outras leituras:

• ROAS líquido = (faturação bruta × taxa de margem) / custo publicitário. O ROAS da Google não considera a margem do produto. Um ROAS de 8 em produtos com 15 % de margem é menos rentável do que um ROAS de 4 em produtos com 45 % de margem.
• Incrementalidade: quantas destas vendas teriam acontecido sem o Shopping (via SEO orgânico, retorno de marca, outro canal)? Teste: pausar o PMax durante 14 dias num segmento e medir o delta de faturação. Difícil de fazer com rigor, mas crítico para os orçamentos acima de 20 mil €/mês.
• Custo de aquisição new vs returning. O Shopping converte massivamente em novos clientes (aquisição). Para medir o LTV, cruzar com o CRM/back-office PrestaShop em 6 a 12 meses.

A implementação do server-side tracking GA4 tornou-se indispensável em 2026 para fiabilizar estas medições, com a erosão dos cookies de terceiros e o Consent Mode v2.

Articulação com os outros sinais SEO/AEO

O Google Shopping não vive isolado. Os agentes de IA, Google AI Overviews, ChatGPT Shopping, Perplexity, leem ao mesmo tempo o feed Shopping (via Merchant Center API), os dados estruturados Schema.org da ficha, e o conteúdo semântico do site. Três otimizações que se reforçam mutuamente:

• O ficheiro llms.txt que serve de índice para os LLM.
• Schema.org Product completo (com hasMerchantReturnPolicy, shippingDetails, aggregateRating) para o matching orgânico.
• Feed Shopping conforme com atributos ricos (GTIN, brand, gender, material, age_group).

Nas lojas que investem nos três, observa-se uma correlação forte entre a qualidade do feed Shopping e as citações de IA nos agentes de compras por IA.

Orçamento realista para arrancar em 2026

Para uma loja PrestaShop de média dimensão que lança o Google Shopping:

• Módulo de feed: 149 € de licença perpétua, ou 30 a 80 €/mês para as alternativas em SaaS.
• Configuração inicial: 1 a 3 dias de trabalho (mapeamento da taxonomia Google, validação dos GTIN, parametrização shipping/tax). O módulo DataFirefly automatiza 80 % desta configuração.
• Orçamento Ads: começar com 30-50 €/dia, subir para 200-500 €/dia à medida que o ROAS estabiliza. O ponto ideal de aprendizagem do PMax ronda as 50 conversões / 30 dias.
• CSS parceiro: menos 20 % no CPC efetivo, gratuito de ativar depois da abertura da conta. Rentável a partir de 5 000 €/mês de orçamento.

Com esta configuração, o ROAS-alvo a 12 meses é de 4 a 8 com margens de 30-40 %, com um payback da implementação nos dois primeiros meses.

FAQ

É preciso uma conta Google Ads para usar o Merchant Center?

Para fazer anúncios Shopping pagos, sim. Mas o Merchant Center sozinho também permite os free listings (anúncios gratuitos no separador Shopping e no Search). Estes listings não convertem tanto como os pagos mas é tráfego gratuito que nenhuma loja deveria deixar em cima da mesa.

Podem fazer-se anúncios Shopping em B2B?

Oficialmente, o Shopping destina-se ao B2C. Mas lojas B2B no PrestaShop expõem o seu catálogo público no Shopping para gerar leads: funciona desde que a ficha permita a compra direta. Os preços devem aparecer com IVA (ou com menção « sem impostos »); as lojas 100 % sem IVA com validação profissional não são elegíveis.

O que causa a suspensão de uma conta Merchant Center?

Três causas principais: multiplicação das reprovações sem correção (a Google considera que não respeita a política), criação repetida de contas para contornar uma suspensão anterior (a suspensão fica registada por domínio, IBAN, identidade fiscal), ou presença de um produto proibido (armas, medicamentos sujeitos a receita). Em caso de suspensão, o procedimento de recurso pede um corretivo documentado, não uma desculpa.

Como gerir as promoções e os saldos via Shopping?

O Google Merchant Promotions permite associar códigos promocionais aos anúncios. O código deve ser válido, aplicável ao carrinho mínimo, e conforme à diretiva Omnibus para o preço riscado. Para os saldos de calendário (Black Friday, saldos de verão), preparam-se os anúncios 7 a 14 dias antes pelo feed, e planeia-se a campanha PMax com um orçamento × 2 ou × 3 no período. Ver também a nossa checklist Black Friday.

O feed deve ser bilingue/multipaís?

Sim, mas com um feed distinto por país/língua visado. Um mesmo produto em Portugal e em Espanha declara-se com duas entradas no Merchant Center: uma com language=pt, feed_country=PT, preço em EUR, entrega PT; outra com language=es, feed_country=ES, preço em EUR (ou diferente se a estratégia o justificar), entrega ES. Nunca declarar um produto em vários países com um mesmo feed: quebra o matching e reprova.

Em síntese

O Google Shopping em 2026 não é um canal que se ativa em 30 minutos. É uma infraestrutura de dados de produto que exige rigor nos GTIN, limpeza no mapeamento de taxonomia, conformidade regulamentar (Omnibus, devolução, entrega) e alinhamento com os sinais SEO/AEO do resto do site. Para as lojas PrestaShop que fazem este investimento, são tipicamente 15 a 25 % da faturação adquirida com um ROAS de 4 a 8 e um payback da implementação em 60 dias.

O módulo Google Shopping PrestaShop da DataFirefly automatiza os elementos mais consumidores de tempo: extração por variação, validação dos GTIN, mapeamento da taxonomia Google, exportação XML/CSV, integração Content API. Para as lojas que querem ir mais longe, a auditoria completa do canal Shopping identifica as fugas de conformidade e os ganhos rápidos.

A não esquecer em paralelo: a integração Google Search Console para seguir o desempenho orgânico a par do pago, e as ligações internas semânticas para reforçar a autoridade temática do catálogo independentemente do orçamento Ads.