LisboaEstamos no Web Summit, estande A1-33.Ver detalhes
Feedance
Artigo

Parâmetros padrão de feeds de produtos em XML

Guia dos parâmetros de feeds XML para varejo, veículos, turismo, imóveis, vagas e eventos, com exemplos de XML, regras de formatação e checklist.

Cagdas PolatCagdas Polat
22 min de leitura
Parâmetros padrão de feeds de produtos em XML

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.

ConceitoGoogle ShoppingCatálogo da MetaVagas do IndeedFinalidade
ID únicoidid / vehicle_id / home_listing_idreferencenumberIdentidade entre sincronizações
Nometitletitle / nametitleO que é
DetalhedescriptiondescriptiondescriptionPor que importa
URL de destinolinkurlurlOnde converte
Imagemimage_linkimage[0].url—Como é
PreçopricepricesalaryQuanto custa
Estadoavailabilityavailability(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:

  1. 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.
  2. Ele precisa ser único. IDs duplicados fazem com que as linhas posteriores sejam descartadas sem nenhuma mensagem de erro. Os itens simplesmente somem.
  3. 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

AtributoObservações
idMáx. 50 caracteres. Estável, único e correspondente aos eventos do pixel.
titleMáx. 150 caracteres. Coloque no início a marca e os termos que as pessoas realmente buscam.
descriptionMáx. 5.000 caracteres. Texto simples; sem textos promocionais nem HTML.
linkA página do produto, e não uma categoria ou um resultado de busca. Precisa ser rastreável.
image_linkImagem principal. Mínimo de 500x500 pela especificação de 2026 (veja abaixo).
availabilityin_stock, out_of_stock, preorder, backorder.
priceValor 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 &amp; Kitchen &gt; Dinnerware &gt; 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 &amp; e o &gt; 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.

SegmentoDestino no GoogleTipo de catálogo da MetaOutros canais comuns
Varejo / e-commerceAnúncios do Shopping, listagens gratuitasProdutos (e-commerce)Marketplaces, comparadores de preços, redes de afiliados
Varejo em loja físicaAnúncios de inventário localProdutos com disponibilidade localPlataformas de busca local
AutomotivoAnúncios de veículos, listagens de veículosVeículos / ofertas de veículosPortais de classificados, marketplaces automotivos
Hotéis e hospedagemAnúncios de hotéis (Hotel Center)HotéisOTAs, metabuscadores
VoosGoogle FlightsVoosMetabuscadores
Destinos e pacotes—DestinosAfiliados de turismo
Imóveis—Anúncios de imóveisPortais imobiliários, agregadores de imóveis
RecrutamentoDados estruturados de vagas (JobPosting)—Sites de vagas, distribuição via ATS, agregadores de vagas
Eventos, partidas, sessõesProdutos (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:

AtributoObservações
vinA identidade legal do veículo. VINs malformados e divergências entre VIN e ano são a reprovação mais comum.
year, model, trimA versão (trim) é o que diferencia um anúncio dos concorrentes do mesmo modelo.
body_styleValores enumerados.
mileageValor mais a unidade (miles ou km). Precisa corresponder à landing page. Valores fora da faixa plausível para o ano do modelo são sinalizados.
conditionNovo, usado, seminovo certificado.
certified_pre-ownedIndicador separado.
engine, fuel_consumption, energy_consumption, co2_emissions, emissions_standardCada vez mais relevantes nos mercados da UE.
electric_range, fuel_consumption_discharged_batteryEspecíficos de elétricos e híbridos.
date_first_registeredMês e ano do primeiro emplacamento.
vehicle_msrp, vehicle_price_typePreço de tabela versus preço de oferta.
vehicle_fulfillmentSe o veículo está na loja, se pode ser transferido ou se é entregue. Atributo de grupo com o subatributo store_code.
store_codeQual 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 &gt; Super League &gt; 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_date ou 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: & → &amp;, < → &lt;, > → &gt;, " → &quot;, ' → &apos;. "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

FormatoIdeal paraCuidado com
XMLEstruturas aninhadas e repetidas — frete por região, várias imagens, atributos de grupoVerboso; erros de escape quebram o arquivo inteiro
CSVCatálogos simples e planos, edições manuais rápidasVírgulas dentro de títulos e descrições; bugs de aspas
TSVO mesmo, com mais segurançaQuase nada — tabulações raramente aparecem em dados de produtos
JSONAPIs modernas, pipelines criados por desenvolvedoresNão é aceito por todos os destinos
APIAtualizações em tempo real, catálogos muito grandes, atualizações parciaisCusto 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-8 declarado e servido corretamente; caracteres não ASCII são exibidos corretamente
  • [ ] Todo & em todas as URLs com escape, ou o campo envolvido em CDATA
  • [ ] 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.

Quer uma segunda opinião sobre o seu feed? Vamos revisá-lo com você e mostrar onde estão as lacunas antes do próximo envio.
Faça uma auditoria gratuita
Cagdas Polat
Escrito por
Cagdas Polat

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

Descubra quais
produtos dão retorno.

Conecte seu feed e o GA4. Mostramos Product Score, 4T, Price War e Broken Size no seu próprio catálogo.