Parâmetros padrão de feeds de produtos em XML
A maioria dos artigos sobre feeds XML parte do princípio de que você vende camisetas.
Essa suposição fazia sentido há uma década, quando "feed de produtos" significava um arquivo do Google Shopping e nada mais. Hoje ela não se sustenta. Uma concessionária de veículos, um site de vagas, uma rede hoteleira, um portal imobiliário e uma plataforma de apostas fazem publicidade baseada em feeds, e nenhum deles envia size ou gtin. Eles enviam VINs, códigos IATA, número de quartos, tipos de contratação e horários de início das partidas.
A mecânica de base é idêntica. Os parâmetros não são.
Este guia cobre as duas coisas: as regras estruturais que valem para todo feed XML, independentemente do segmento, e os conjuntos específicos de atributos de cada um dos principais tipos de feed — varejo, estoque local, veículos, turismo, imóveis, vagas de emprego e estoque com prazo, como partidas, eventos e sessões de cinema. Com XML funcional para cada um.
1. O que é, de fato, um feed XML
Um feed XML é um arquivo estruturado que descreve um estoque de forma que as máquinas possam consumi-lo sem que uma pessoa precise interpretá-lo. Uma plataforma busca o arquivo em um cronograma, processa o conteúdo e cria anúncios, listagens ou resultados de busca a partir do que encontra.
O formato importa menos do que a maioria das pessoas pensa. O que importa é o contrato: cada destino publica uma especificação dizendo quais campos exige, quais valores são válidos e como vai se comportar quando estiverem errados. O feed é a sua parte desse contrato.
Daí decorrem duas consequências, e elas são o motivo pelo qual os feeds são mais difíceis do que parecem:
O contrato é por destino. A especificação de produtos do Google, a especificação de catálogo da Meta e o XML de vagas do Indeed quase não compartilham nomes de campos. Um único catálogo de origem precisa ser transformado de forma diferente para cada um.
As violações costumam falhar em silêncio. Um campo malformado raramente quebra o arquivo. Ele reprova um item, rebaixa um anúncio ou remove um atributo do anúncio — e nada no painel da sua campanha avisa isso.
2. A anatomia do arquivo
A maioria dos feeds XML de publicidade usa RSS 2.0 com uma extensão de namespace. A estrutura é sempre a mesma, em três camadas:
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
<channel>
<title>Example Store — Product Feed</title>
<link>https://example.com</link>
<description>Full catalogue, updated hourly</description>
<item>
<!-- one inventory item -->
</item>
</channel>
</rss>
- A declaração XML define a codificação. Na prática, ela precisa ser
UTF-8; qualquer outra causa corrupção de caracteres em catálogos que não estão em inglês e é, sozinha, a causa mais comum de títulos de produtos deformados em turco, alemão e tcheco. - A declaração de namespace (
xmlns:g="...") é o que torna<g:price>válido. Se você a omitir, todos os elementos com prefixo serão ignorados em silêncio — o feed é processado, e quase nada é importado. <channel>contém os metadados do feed.<item>é uma unidade do estoque. O que "uma unidade" significa é uma decisão, e não algo dado: um SKU, uma variante, um veículo, uma vaga, um hotel, uma partida.
Nem todo segmento usa esse formato. Os feeds de vagas usam <source><job>, e alguns marketplaces definem elementos raiz totalmente próprios. A lógica de três camadas — documento, contêiner, item repetido — vale em qualquer caso.
3. O núcleo universal
Sete parâmetros aparecem em praticamente todas as especificações de feed já escritas, com nomes diferentes. Se você entender esses sete, consegue ler qualquer especificação.
| Conceito | Google Shopping | Catálogo da Meta | Vagas do Indeed | Finalidade |
|---|---|---|---|---|
| ID único | id | id / vehicle_id / home_listing_id | referencenumber | Identidade entre sincronizações |
| Nome | title | title / name | title | O que é |
| Detalhe | description | description | description | Por que importa |
| URL de destino | link | url | url | Onde converte |
| Imagem | image_link | image[0].url | — | Como é |
| Preço | price | price | salary | Quanto custa |
| Estado | availability | availability | (presença no feed) | Se está ativo |
Três regras sobre o ID que valem universalmente e causam mais estragos do que qualquer outro campo isolado:
- Ele precisa ser estável. Se o seu ID é regenerado na exportação — derivado da ordem das linhas, de um timestamp ou de um hash de conteúdo que muda —, cada sincronização apaga o histórico de desempenho acumulado do item, que recomeça do zero.
- Ele precisa ser único. IDs duplicados fazem com que as linhas posteriores sejam descartadas sem nenhuma mensagem de erro. Os itens simplesmente somem.
- Ele precisa corresponder ao que o seu pixel ou tag envia. A correspondência de catálogo da Meta, o remarketing dinâmico do Google e todos os produtos de retargeting dependem de o ID do feed e o ID do evento do site serem a mesma string. Esse é o motivo mais comum para o retargeting dinâmico "não funcionar".
4. Parâmetros de varejo / e-commerce
Esta é a especificação mais bem documentada e a base da qual a maioria dos outros segmentos empresta elementos.
Obrigatórios
| Atributo | Observações |
|---|---|
id | Máx. 50 caracteres. Estável, único e correspondente aos eventos do pixel. |
title | Máx. 150 caracteres. Coloque no início a marca e os termos que as pessoas realmente buscam. |
description | Máx. 5.000 caracteres. Texto simples; sem textos promocionais nem HTML. |
link | A página do produto, e não uma categoria ou um resultado de busca. Precisa ser rastreável. |
image_link | Imagem principal. Mínimo de 500x500 pela especificação de 2026 (veja abaixo). |
availability | in_stock, out_of_stock, preorder, backorder. |
price | Valor mais a moeda ISO: 899.90 TRY. Precisa corresponder exatamente à landing page. |
Identificadores
brand, gtin, mpn e identifier_exists. O GTIN é o campo que determina se o seu produto será associado ao grafo de conhecimento de produtos do Google — e, portanto, se ele aparece ou não em superfícies de comparação e de compras com IA. Na prática, ele não é opcional, diga a especificação o que disser.
Variantes
item_group_id, item_group_title, color, size, size_type, size_system, material, pattern, gender, age_group.
Variantes são um assunto à parte; em resumo, o item_group_id precisa ser idêntico em todo o grupo e derivado de dados de origem estáveis, e gender e age_group são constantes no grupo, enquanto color e size não são.
Categorização
google_product_category (a taxonomia do Google, por ID ou caminho completo), product_type (a sua própria taxonomia — é o campo que torna possível estruturar as campanhas e é de formato livre, então use-o).
Comercial
sale_price, sale_price_effective_date, unit_pricing_measure, unit_pricing_base_measure, installment, subscription_cost, loyalty_program.
Logística
shipping, shipping_weight, shipping_length / _width / _height, shipping_label, transit_time_label, min_handling_time, max_handling_time, tax.
Controle de campanhas
excluded_destination, included_destination, ads_redirect, custom_label_0 a custom_label_4.
Os cinco custom labels são os campos mais subutilizados de toda a especificação. Eles não têm significado nenhum para o Google — existem apenas para que você possa segmentar. Faixas de margem, profundidade de estoque, sazonalidade, idade do produto, nível de desempenho no GA4. Se a estrutura da sua campanha não consegue expressar uma regra de negócio, geralmente o motivo é este.
Mídia
additional_image_link, lifestyle_image_link, virtual_model_link, video_link.
Um item de varejo mínimo, mas completo
<item>
<g:id>KRC-4210-BLK</g:id>
<g:title>Karaca Fine Pearl 6-Person Dinner Set — Black</g:title>
<g:description>26-piece porcelain dinner set for six. Dishwasher and microwave safe.</g:description>
<g:link>https://example.com/urun/fine-pearl-6-kisilik</g:link>
<g:image_link>https://cdn.example.com/krc-4210-blk-01.jpg</g:image_link>
<g:additional_image_link>https://cdn.example.com/krc-4210-blk-02.jpg</g:additional_image_link>
<g:video_link>https://cdn.example.com/video/krc-4210.mp4</g:video_link>
<g:availability>in_stock</g:availability>
<g:price>4299.00 TRY</g:price>
<g:sale_price>3499.00 TRY</g:sale_price>
<g:sale_price_effective_date>2026-11-24T00:00+0300/2026-12-01T23:59+0300</g:sale_price_effective_date>
<g:brand>Karaca</g:brand>
<g:gtin>8680150042109</g:gtin>
<g:condition>new</g:condition>
<g:google_product_category>672</g:google_product_category>
<g:product_type>Home & Kitchen > Dinnerware > Dinner Sets</g:product_type>
<g:custom_label_0>high-margin</g:custom_label_0>
<g:custom_label_1>bf-2026</g:custom_label_1>
</item>
Observe o & e o > em product_type. Caracteres & sem escape em URLs e caminhos de categoria são a causa mais frequente de arquivos XML que não podem ser processados de forma alguma.
5. O que mudou em 2026
Vale a pena agir agora, e não no prazo final, em relação a três mudanças na especificação de dados de produtos do Google.
A resolução mínima de imagem agora é de 500x500 px para image_link e additional_image_link, em todas as categorias e métodos de marketing. Os avisos começaram a aparecer no Merchant Center em abril de 2026; a aplicação começa em 31 de janeiro de 2027. O Google pode ampliar algumas imagens menores automaticamente, mas tratar isso como solução é um erro — imagens ampliadas parecem ampliadas, e a qualidade da imagem é uma variável da taxa de cliques.
O video_link está ativo e sendo veiculado. Os vídeos enviados por esse atributo passaram a poder ser veiculados a partir de 30 de junho de 2026, com validação de políticas e de qualidade. Os erros bloqueiam o vídeo, mas não a oferta, o que faz deste um campo de baixo risco para preencher. A maioria dos catálogos não tem vídeo para a maior parte dos SKUs, e é justamente por isso que gerá-los em escala a partir dos dados do feed se tornou uma lacuna competitiva, e não um diferencial opcional.
Os controles de frete no nível do produto foram ampliados. O handling_cutoff_time define um horário limite diário para o processamento dos pedidos, e o minimum_order_value especifica o valor mínimo de compra para a entrega. O atributo shipping também ganhou os subatributos loyalty_program_label e loyalty_tier_label para benefícios de entrega específicos de programas de fidelidade.
A direção é consistente: o Google continua levando para o nível do item detalhes que antes ficavam no nível da conta. Tudo o que é expresso por item é algo que uma camada de feed consegue automatizar e um processo manual não.
6. O mapa dos segmentos
O varejo é uma linha desta tabela, e não a tabela inteira.
| Segmento | Destino no Google | Tipo de catálogo da Meta | Outros canais comuns |
|---|---|---|---|
| Varejo / e-commerce | Anúncios do Shopping, listagens gratuitas | Produtos (e-commerce) | Marketplaces, comparadores de preços, redes de afiliados |
| Varejo em loja física | Anúncios de inventário local | Produtos com disponibilidade local | Plataformas de busca local |
| Automotivo | Anúncios de veículos, listagens de veículos | Veículos / ofertas de veículos | Portais de classificados, marketplaces automotivos |
| Hotéis e hospedagem | Anúncios de hotéis (Hotel Center) | Hotéis | OTAs, metabuscadores |
| Voos | Google Flights | Voos | Metabuscadores |
| Destinos e pacotes | — | Destinos | Afiliados de turismo |
| Imóveis | — | Anúncios de imóveis | Portais imobiliários, agregadores de imóveis |
| Recrutamento | Dados estruturados de vagas (JobPosting) | — | Sites de vagas, distribuição via ATS, agregadores de vagas |
| Eventos, partidas, sessões | Produtos (modelados) | Produtos (modelados) | Plataformas de ingressos, DSPs |
Duas regras estruturais que vale a pena assimilar antes de construir qualquer coisa:
Um catálogo da Meta comporta exatamente um tipo de estoque. Não é possível misturar hotéis e produtos. Se você vende os dois, precisa de dois catálogos.
O Google separa os segmentos no nível da fonte de dados. Uma fonte de dados de veículos deve ser direcionada apenas a anúncios de veículos. Enviar veículos para uma fonte de dados do Shopping gera reprovações, e não anúncios — e as fontes de veículos não devem conter peças de reposição nem acessórios, que pertencem a um feed de produtos normal.
7. Feeds de veículos
O automotivo é o segmento em que "é só usar a especificação de varejo" falha de forma mais evidente. Um carro é um objeto físico único com um identificador legal, e não um SKU com profundidade de estoque.
Os atributos de veículos do Google ficam por cima do núcleo comum:
| Atributo | Observações |
|---|---|
vin | A identidade legal do veículo. VINs malformados e divergências entre VIN e ano são a reprovação mais comum. |
year, model, trim | A versão (trim) é o que diferencia um anúncio dos concorrentes do mesmo modelo. |
body_style | Valores enumerados. |
mileage | Valor mais a unidade (miles ou km). Precisa corresponder à landing page. Valores fora da faixa plausível para o ano do modelo são sinalizados. |
condition | Novo, usado, seminovo certificado. |
certified_pre-owned | Indicador separado. |
engine, fuel_consumption, energy_consumption, co2_emissions, emissions_standard | Cada vez mais relevantes nos mercados da UE. |
electric_range, fuel_consumption_discharged_battery | Específicos de elétricos e híbridos. |
date_first_registered | Mês e ano do primeiro emplacamento. |
vehicle_msrp, vehicle_price_type | Preço de tabela versus preço de oferta. |
vehicle_fulfillment | Se o veículo está na loja, se pode ser transferido ou se é entregue. Atributo de grupo com o subatributo store_code. |
store_code | Qual unidade física tem o veículo. |
<item>
<g:id>STK-88214</g:id>
<g:title>2023 Volkswagen Passat 1.5 TSI Business DSG</g:title>
<g:description>Single owner, full service history, no accident record.</g:description>
<g:link>https://example.com/ilan/88214</g:link>
<g:image_link>https://cdn.example.com/88214-01.jpg</g:image_link>
<g:price>1450000.00 TRY</g:price>
<g:condition>used</g:condition>
<g:brand>Volkswagen</g:brand>
<g:model>Passat</g:model>
<g:trim>1.5 TSI Business DSG</g:trim>
<g:year>2023</g:year>
<g:vin>WVWZZZ3CZPE000000</g:vin>
<g:mileage>
<g:value>42500</g:value>
<g:unit>km</g:unit>
</g:mileage>
<g:body_style>sedan</g:body_style>
<g:color>Grey</g:color>
<g:vehicle_fulfillment>
<g:option>in_store</g:option>
<g:store_code>IST-01</g:store_code>
</g:vehicle_fulfillment>
</item>
O que torna os feeds de veículos operacionalmente diferentes:
- O estoque tem uma unidade só. Cada item é uma unidade única. Quando ele é vendido, precisa sair do feed imediatamente — e não na sincronização de amanhã. Anúncios de veículos desatualizados desperdiçam cliques de CPC alto com carros que não existem mais e prejudicam a qualidade da conta.
- A frequência de atualização é tudo. Ciclos de atualização a cada quatro horas são prática padrão no setor automotivo, e não uma otimização.
- A consistência com a landing page é fiscalizada. O preço e a quilometragem no feed precisam corresponder exatamente à página de detalhes do veículo. Uma mudança de preço em toda a concessionária que atualiza o site, mas não o feed, provoca uma onda de reprovações em poucas horas.
- Os anúncios de estoque automotivo da Meta usam um vocabulário de campos separado —
state_of_vehicle,exterior_color,transmission,drivetrain,dealer_id—, então os mesmos dados de origem precisam de uma transformação diferente para cada canal.
8. Feeds de turismo
O turismo se divide em três tipos distintos de catálogo, e o erro é tratá-los como um só.
Hotéis
O feed de propriedades é relativamente estático: nome, descrição, endereço, coordenadas, classificação por estrelas, imagens, um preço inicial. O que muda são a disponibilidade e a tarifa, e é por isso que as configurações de hotéis geralmente combinam um feed estático de propriedades com feeds dinâmicos de tipos de quarto e preços.
Parâmetros principais: hotel_id, name, description, brand, url, image, latitude, longitude, address (com city, region, country, postal_code), base_price, currency, star_rating, neighborhood, phone, guest_ratings.
<item>
<g:hotel_id>HTL-BDR-114</g:hotel_id>
<g:name>Blue Bay Resort Bodrum</g:name>
<g:description>Seafront resort with private beach, three restaurants and a spa.</g:description>
<g:url>https://example.com/otel/blue-bay-bodrum</g:url>
<g:image>https://cdn.example.com/htl-114-01.jpg</g:image>
<g:latitude>37.0344</g:latitude>
<g:longitude>27.4305</g:longitude>
<g:address>Yalıkavak Mah. Sahil Cad. 12, Bodrum, Muğla, TR, 48990</g:address>
<g:base_price>4200.00 TRY</g:base_price>
<g:star_rating>5</g:star_rating>
<g:neighborhood>Yalıkavak</g:neighborhood>
</item>
Voos
O item é uma rota, e não um assento. A identidade é o par origem–destino: origin_airport e destination_airport como códigos IATA, mais price, url, image, description. Os preços normalmente são preços "a partir de" e mudam o tempo todo, o que faz da frequência de atualização a restrição decisiva.
Destinos
O item é um lugar para o qual você vende viagens: destination_id, name, address, neighborhood, types, price, url, image. Útil para prospecção no topo do funil, quando o viajante tem intenção, mas nenhuma propriedade específica em mente.
O problema recorrente do turismo é que preço e disponibilidade são calculados, e não armazenados. O "preço" de um hotel depende das datas, da ocupação e da duração da estadia; o de um voo depende do momento em que você pergunta. Os feeds querem um único número. Escolher qual número — o menor disponível nos próximos 30 dias, o menor para o próximo fim de semana, a média — é uma decisão comercial que determina silenciosamente o desempenho dos seus anúncios, e vale a pena tomá-la de forma deliberada, em vez de aceitar o que a exportação gerou por padrão.
9. Feeds de imóveis
Estruturalmente semelhantes aos de veículos: ativos físicos únicos, estoque de uma unidade, alto valor por clique e um anúncio que precisa desaparecer no momento em que o imóvel é negociado.
Parâmetros principais: home_listing_id, name, description, address, latitude, longitude, url, image, price, currency, property_type (apartamento, casa, terreno, comercial), listing_type (venda, aluguel, lançamento), num_beds, num_baths, area_size, area_unit, year_built, availability, agent_name, agent_phone.
<item>
<g:home_listing_id>EMK-2291</g:home_listing_id>
<g:name>3+1 Apartment with Sea View — Kadıköy</g:name>
<g:description>Renovated 3+1 apartment, 4th floor, elevator, closed parking.</g:description>
<g:address>Caferağa Mah., Kadıköy, İstanbul, TR</g:address>
<g:latitude>40.9862</g:latitude>
<g:longitude>29.0299</g:longitude>
<g:url>https://example.com/ilan/2291</g:url>
<g:image>https://cdn.example.com/emk-2291-01.jpg</g:image>
<g:price>12500000.00 TRY</g:price>
<g:property_type>apartment</g:property_type>
<g:listing_type>for_sale</g:listing_type>
<g:num_beds>3</g:num_beds>
<g:num_baths>2</g:num_baths>
<g:area_size>135</g:area_size>
<g:area_unit>sq_m</g:area_unit>
<g:availability>available</g:availability>
</item>
Algo que não é um problema de feed, mas vai travar a sua campanha: imóveis são uma categoria de publicidade restrita na Meta. Campanhas que promovem anúncios de imóveis precisam ser declaradas na categoria especial de anúncios de imóveis, o que restringe as opções de segmentação. O catálogo pode estar perfeito e a campanha ainda assim falhar se isso não estiver configurado.
10. Feeds de vagas de emprego
O recrutamento usa uma estrutura de documento totalmente diferente — <source> e <job> em vez de <rss> e <item> —, e vale a pena conhecê-la, porque ela mostra que "feed XML" é um padrão, e não um esquema único.
<?xml version="1.0" encoding="UTF-8"?>
<source>
<publisher>Example Company</publisher>
<publisherurl>https://example.com</publisherurl>
<lastBuildDate>Wed, 12 Aug 2026 09:00:00 GMT</lastBuildDate>
<job>
<title><![CDATA[Senior Backend Engineer]]></title>
<date><![CDATA[Mon, 10 Aug 2026 08:00:00 GMT]]></date>
<referencenumber><![CDATA[ENG-4471]]></referencenumber>
<url><![CDATA[https://example.com/careers/eng-4471]]></url>
<company><![CDATA[Example Company]]></company>
<city><![CDATA[İstanbul]]></city>
<state><![CDATA[İstanbul]]></state>
<country><![CDATA[TR]]></country>
<postalcode><![CDATA[34394]]></postalcode>
<description><![CDATA[<p>We are hiring a senior backend engineer to work on our data pipeline...</p>]]></description>
<salary><![CDATA[120000 - 160000 TRY monthly]]></salary>
<jobtype><![CDATA[fulltime]]></jobtype>
<category><![CDATA[Engineering]]></category>
<experience><![CDATA[5+ years]]></experience>
</job>
</source>
Quatro regras específicas dos feeds de vagas:
CDATAé a norma, e não a exceção. As descrições de vagas contêm HTML, "e comerciais" e apóstrofos. Envolver cada campo em<![CDATA[...]]>evita toda uma classe de falhas de processamento.- A localização precisa ter, no mínimo, cidade, estado e país. Se você os omitir, a vaga perde, por padrão, visibilidade orgânica nos principais agregadores.
- Vagas preenchidas precisam ser removidas, e não marcadas como encerradas. Não existe um equivalente a
availability. A presença no feed é o sinal de disponibilidade, e os agregadores penalizam feeds que mantêm vagas desatualizadas. - Um idioma, uma entrada de vaga. Uma vaga publicada em dois idiomas precisa de duas entradas separadas, com números de referência distintos.
Separadamente do feed, os dados estruturados JobPosting em JSON-LD na página de carreiras são o que torna uma vaga elegível para as listagens de vagas nos resultados de busca. Os dois são complementares: o feed cuida da distribuição para os agregadores, e os dados estruturados cuidam da busca orgânica. A maioria das equipes de recrutamento faz um e não o outro.
11. Estoque com prazo
A categoria de feed mais interessante não tem especificação oficial, porque as plataformas nunca a previram: estoque cujo atributo definidor é quando, e não o quê.
Partidas de futebol. Shows. Sessões de cinema. Partidas de voos. Lotes de leilão. Horários de reserva em restaurantes. Janelas de entrega.
Todos eles têm as propriedades de produtos — uma identidade, um preço, uma imagem, uma landing page — e mais uma para a qual a especificação de varejo não tem campo: um prazo de validade medido em horas. Uma partida que já começou não está "fora de estoque"; ela simplesmente perdeu o sentido.
A abordagem que funciona é modelá-los como produtos de catálogo padrão e codificar a dimensão de tempo em campos que a plataforma já entende:
<item>
<g:id>MTC-2026-08-16-GS-FB</g:id>
<g:title>Galatasaray - Fenerbahçe | Super League, Week 2</g:title>
<g:description>Saturday 16 August, 19:00. Live odds and in-play betting.</g:description>
<g:link>https://example.com/mac/2026-08-16-gs-fb</g:link>
<g:image_link>https://cdn.example.com/creatives/mtc-2026-08-16-gs-fb.jpg</g:image_link>
<g:availability>in_stock</g:availability>
<g:price>1.00 TRY</g:price>
<g:product_type>Football > Super League > Week 2</g:product_type>
<g:custom_label_0>2026-08-16</g:custom_label_0>
<g:custom_label_1>derby</g:custom_label_1>
<g:custom_label_2>ms1-2.10</g:custom_label_2>
<g:expiration_date>2026-08-16T19:00+0300</g:expiration_date>
</item>
Três coisas fazem isso funcionar:
expiration_dateou uma regra de remoção equivalente, para que o item saia do catálogo no início da partida, e não na próxima sincronização programada.- Custom labels com a dimensão de tempo, para que as campanhas possam ser estruturadas em torno de "este fim de semana", "clássico" ou "odds acima de 2.0".
- Um criativo por item. É aqui que a abordagem costuma emperrar. Uma lista de várias centenas de partidas por semana precisa de várias centenas de imagens, cada uma com os times, a data, o horário e as odds atuais. Nenhuma equipe de design produz isso. Gerar o criativo a partir da linha do feed é o único método que acompanha o ritmo — e foi exatamente assim que a Bilyoner rodou anúncios de catálogo pela primeira vez e aumentou o ROAS em 49%.
Se o seu estoque tem um horário de início, ele pertence a um catálogo. A barreira quase sempre é o formato, e não o conceito.
12. Feeds de estoque local
O estoque local fica entre o varejo e os segmentos específicos: os mesmos produtos, descritos por unidade física.
Parâmetros: id, store_code, quantity, price, sale_price, sale_price_effective_date, availability, pickup_method (compra, reserva, envio para a loja, não disponível), pickup_sla (no mesmo dia, no dia seguinte, em vários dias).
O ponto estrutural é que o feed local é um complemento, e não um substituto. Ele faz referência aos itens do feed de produtos principal pelo id e adiciona informações por loja. Um item, muitas lojas, muitas linhas.
Uma observação de 2026 que vale destacar: versões online e em loja física do mesmo produto com preços ou disponibilidade diferentes agora precisam de IDs de produto separados, em vez de serem consolidadas em um só. Os feeds que as consolidavam estão sendo solicitados a separá-las.
13. Regras de formatação
Estas regras valem para todos os tipos de feed deste artigo e, juntas, respondem pela grande maioria dos feeds que falham por completo.
Codificação. UTF-8, sempre, declarada na declaração XML e servida com um cabeçalho Content-Type correspondente. Divergências entre a codificação declarada e a real corrompem todos os caracteres não ASCII.
Escape. Cinco caracteres precisam de escape no conteúdo XML: & → &, < → <, > → >, " → ", ' → '. "E comerciais" sem escape em URLs de rastreamento são a causa número um de feeds que não podem ser processados. A alternativa é o CDATA, que é prática padrão em feeds de vagas e útil em qualquer lugar onde as descrições contenham marcação.
Datas. ISO 8601 com um deslocamento de fuso horário explícito. 2026-08-16T19:00+0300, e não 16.08.2026 19:00. Feeds que atendem a vários mercados a partir de uma única fonte sem fuso horário geram itens que expiram horas antes ou depois do previsto.
Preços. Valor e moeda ISO 4217, ponto decimal em vez de vírgula, sem separador de milhar. 4299.00 TRY. E o preço no feed precisa corresponder ao da landing page — isso é verificado por rastreamento na maioria das plataformas.
Os valores enumerados diferenciam maiúsculas, minúsculas e formato, e variam conforme a plataforma. O Google espera in_stock; a Meta espera in stock. Essa única diferença já quebrou mais importações de catálogo do que qualquer outra. Nunca presuma que um valor enumerado vale para outro destino.
Entrega do arquivo. Compressão gzip para arquivos grandes, uma URL HTTPS estável, nenhuma barreira de autenticação, a menos que a plataforma a suporte explicitamente, e um servidor que responda dentro do tempo limite da plataforma. Uma URL de feed atrás da proteção contra bots do Cloudflare é uma URL de feed que não é buscada.
A frequência de atualização deve seguir a volatilidade dos dados subjacentes, e não uma convenção: a cada hora ou mais rápido para odds, preços de voos e estoque de varejo de giro rápido; a cada poucas horas para veículos e imóveis; diariamente para catálogos estáveis.
14. XML vs CSV vs JSON vs API
| Formato | Ideal para | Cuidado com |
|---|---|---|
| XML | Estruturas aninhadas e repetidas — frete por região, várias imagens, atributos de grupo | Verboso; erros de escape quebram o arquivo inteiro |
| CSV | Catálogos simples e planos, edições manuais rápidas | Vírgulas dentro de títulos e descrições; bugs de aspas |
| TSV | O mesmo, com mais segurança | Quase nada — tabulações raramente aparecem em dados de produtos |
| JSON | APIs modernas, pipelines criados por desenvolvedores | Não é aceito por todos os destinos |
| API | Atualizações em tempo real, catálogos muito grandes, atualizações parciais | Custo de engenharia; limites de taxa |
O XML continua sendo o padrão para tudo o que tem aninhamento, e é por isso que feeds de veículos, turismo e de varejo com muitos dados de frete tendem a ser em XML, enquanto catálogos simples de moda costumam ser em TSV. Observe também que vários destinos importantes estão migrando para a ingestão com prioridade para API, então tratar o arquivo como seu único caminho de integração é um risco de médio prazo.
Se os seus títulos contêm vírgulas — e títulos com cor e tamanho quase sempre contêm —, use TSV em vez de CSV. Toda uma classe de bugs de processamento desaparece.
15. Checklist antes do lançamento
- [ ] O arquivo é validado em um validador de XML antes de chegar perto de qualquer plataforma
- [ ]
UTF-8declarado e servido corretamente; caracteres não ASCII são exibidos corretamente - [ ] Todo
&em todas as URLs com escape, ou o campo envolvido emCDATA - [ ] IDs únicos, estáveis entre sincronizações e correspondentes aos eventos do seu pixel ou tag
- [ ] Todos os atributos obrigatórios presentes para o destino — verificados na especificação desse destino, e não em uma genérica
- [ ] Valores enumerados transformados por destino, e não copiados
- [ ] Preços exatamente iguais aos das landing pages, incluindo a moeda e qualquer tratamento de impostos
- [ ] Datas em ISO 8601 com deslocamento de fuso horário
- [ ] Imagens atendem ao mínimo de 500x500 e carregam via HTTPS sem redirecionamentos
- [ ] Itens vendidos, preenchidos, expirados ou já partidos saem do feed no cronograma certo
- [ ] A frequência de atualização corresponde à velocidade com que os dados subjacentes realmente mudam
- [ ] A URL do feed está acessível publicamente e não está bloqueada por proteção contra bots
- [ ] Existe uma regra de monitoramento para mudanças inesperadas na quantidade de itens
16. Perguntas frequentes
O XML ainda é o formato certo em 2026?
Para qualquer coisa com dados aninhados, sim. Para catálogos planos, o TSV é mais simples e menos frágil. Para requisitos em tempo real, uma integração via API supera qualquer arquivo. O formato deve seguir os dados, e não o hábito.
Posso usar um único feed para todas as plataformas?
Uma única fonte, sim. Um único arquivo, não. Nomes de campos, valores enumerados, limites de caracteres e atributos obrigatórios variam por destino, e as diferenças não são cosméticas. A arquitetura viável é um único catálogo canônico com transformações por canal aplicadas na exportação.
E se o meu estoque não for de produtos?
Então você precisa da especificação do seu segmento, e não da de varejo. Veículos, hotéis, voos, destinos, imóveis e vagas têm cada um a sua. E, se o seu estoque for algo para o qual nenhuma plataforma tem especificação — partidas, sessões, horários, lotes —, você o modela como produtos e codifica a dimensão que falta nos campos que existem.
Com que frequência o feed deve ser atualizado?
Com a frequência com que os dados subjacentes mudam de forma relevante. Um veículo vendido hoje de manhã que continua sendo anunciado à tarde está gastando dinheiro com nada.
Preciso de GTINs?
No varejo, na prática, sim. O GTIN é o que conecta o seu item ao conhecimento de produtos de uma plataforma, o que cada vez mais determina se você aparece ou não em superfícies de comparação e em resultados de compras orientados por IA. Para veículos, imóveis e vagas, os campos de identidade equivalentes são o vin, o ID do anúncio e o número de referência.
Onde a coisa fica difícil
Nenhuma das regras individuais deste artigo é difícil. A dificuldade é que existem várias centenas delas, elas variam por destino, mudam sem aviso, e violá-las falha em silêncio.
Um único catálogo exportado para Google, Meta, TikTok e três marketplaces são seis contratos diferentes sendo cumpridos ao mesmo tempo a partir de uma única fonte de verdade. Fazer isso manualmente significa manter seis arquivos e conciliá-los toda vez que o catálogo muda.
É para essa camada que a Feedance foi construída — regras de feed para normalizar os atributos na origem, exportações por canal que aplicam a transformação certa para cada um dos mais de 200 destinos sem mexer nos seus dados de origem, o Feed Protection para detectar atributos ausentes e mudanças inesperadas na quantidade de itens antes que uma plataforma o faça, e um Creative Suite que gera uma imagem ou um vídeo por linha do feed para catálogos em que a produção manual nunca foi realista.
Ela trata segmentos fora do varejo como prioridade, e não como algo secundário — estoque de turismo com preços em tempo real, catálogos de apostas com dados de horário das partidas e canais de distribuição para automotivo, imóveis e vagas.
Se você quiser saber como está o seu feed atual antes de mudar qualquer coisa, nossa ferramenta gratuita de auditoria de feeds o avalia quanto à completude, à qualidade dos dados e à saúde técnica, sem custo. Ou agende uma demonstração de 15 minutos e analisamos juntos.
Última revisão: agosto de 2026. As especificações das plataformas mudam com frequência; verifique os requisitos atuais na documentação oficial de cada destino antes da implementação.

Cofundador da Feedance, onde aproveita sua formação como engenheiro de computação e profissional de marketing para gerar insights analíticos. Com um forte foco em transformar dados em estratégias acionáveis, ele se dedica a ajudar marcas a alcançar um crescimento significativo no cenário digital.
LinkedIn
















