Parametri standard dei feed di prodotto XML

La maggior parte degli articoli sui feed XML dà per scontato che tu venda t-shirt.

Era un presupposto sensato dieci anni fa, quando "feed di prodotto" significava un file per Google Shopping e nient'altro. Oggi non regge più. Una concessionaria d'auto, un portale di annunci di lavoro, una catena alberghiera, un portale immobiliare e una piattaforma di scommesse fanno tutti pubblicità basata sui feed, e nessuno di loro invia size o gtin. Inviano numeri di telaio (VIN), codici IATA, numero di camere da letto, tipologie contrattuali e orari di inizio delle partite.

I meccanismi di fondo sono identici. I parametri no.

Questa guida copre entrambi gli aspetti: le regole strutturali che valgono per ogni feed XML indipendentemente dal settore e gli insiemi di attributi specifici per ciascuno dei principali tipi di feed: retail, inventario locale, veicoli, viaggi, immobili, lavoro e inventario legato al tempo come partite, eventi e proiezioni. Con XML funzionante per ognuno.

1. Cos'è davvero un feed XML

Un feed XML è un file strutturato che descrive un inventario in modo che le macchine possano utilizzarlo senza che una persona debba interpretarlo. Una piattaforma recupera il file secondo una programmazione, lo analizza e crea schede, annunci o risultati di ricerca in base a ciò che trova.

Il formato conta meno di quanto si pensi. Ciò che conta è il contratto: ogni destinazione pubblica una specifica che indica quali campi sono obbligatori, quali valori sono ammessi e come si comporterà se sono sbagliati. Il feed è la tua parte di quel contratto.

Ne derivano due conseguenze, ed è per questo che i feed sono più difficili di quanto sembrino:

Il contratto è diverso per ogni destinazione. La specifica di prodotto di Google, la specifica del catalogo di Meta e l'XML per gli annunci di lavoro di Indeed non hanno quasi nessun nome di campo in comune. Un unico catalogo di origine deve essere trasformato in modo diverso per ciascuna.

Le violazioni falliscono quasi sempre in silenzio. Un campo malformato raramente rompe il file. Fa rifiutare un articolo, declassa una scheda o elimina un attributo dall'annuncio, e niente nella dashboard della campagna te lo segnala.

2. L'anatomia del file

La maggior parte dei feed XML pubblicitari usa RSS 2.0 con un'estensione di namespace. La struttura è sempre la stessa, su tre livelli:

<?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>

• La dichiarazione XML imposta la codifica. In pratica deve essere UTF-8; qualsiasi altra codifica corrompe i caratteri nei cataloghi non in inglese ed è in assoluto la causa più comune di titoli di prodotto turchi, tedeschi e cechi illeggibili.
• La dichiarazione del namespace (xmlns:g="...") è ciò che rende valido <g:price>. Se la ometti, ogni elemento con prefisso viene ignorato in silenzio: il feed viene analizzato, ma non viene importato quasi nulla.
• <channel> contiene i metadati a livello di feed.
• <item> è un'unità di inventario. Cosa significhi "un'unità" è una decisione, non un dato di fatto: uno SKU, una variante, un veicolo, un'offerta di lavoro, un hotel, una partita.

Non tutti i settori usano questa forma. I feed per gli annunci di lavoro usano <source><job> e alcuni marketplace definiscono elementi radice completamente propri. La logica a tre livelli (documento, contenitore, elemento ripetuto) resta comunque valida.

3. Il nucleo universale

Sette parametri compaiono praticamente in ogni specifica di feed mai scritta, con nomi diversi. Se li capisci, puoi leggere qualsiasi specifica.

Tre regole sull'ID che valgono ovunque e causano più danni di qualsiasi altro campo:

1. Deve essere stabile. Se il tuo ID viene rigenerato a ogni esportazione (derivato dall'ordine delle righe, da un timestamp, da un hash di contenuti che cambiano), ogni sincronizzazione cancella lo storico di performance accumulato dall'articolo, che riparte da zero.
2. Deve essere univoco. Gli ID duplicati fanno scartare le righe successive senza alcun messaggio di errore. Gli articoli semplicemente spariscono.
3. Deve corrispondere a ciò che invia il tuo pixel o tag. L'abbinamento del catalogo di Meta, il remarketing dinamico di Google e ogni prodotto di retargeting dipendono dal fatto che l'ID del feed e l'ID dell'evento sul sito siano la stessa stringa. È il motivo più comune per cui il retargeting dinamico "non funziona".

4. Parametri per retail / e-commerce

È la specifica meglio documentata e la base da cui attingono la maggior parte degli altri settori.

Obbligatori

Identificatori

brand, gtin, mpn e identifier_exists. Il GTIN è il campo che determina se il tuo prodotto viene abbinato al knowledge graph dei prodotti di Google e quindi se compare o meno nelle superfici di confronto e di shopping basate sull'AI. Nella pratica non è facoltativo, qualunque cosa dica la specifica.

Varianti

item_group_id, item_group_title, color, size, size_type, size_system, material, pattern, gender, age_group.

Le varianti sono un argomento a sé; in breve, item_group_id deve essere identico in tutto il gruppo e derivato da dati di origine stabili, e gender e age_group sono costanti nel gruppo, mentre color e size no.

Categorizzazione

google_product_category (la tassonomia di Google, ID o percorso completo), product_type (la tua tassonomia: è il campo che rende possibile la struttura delle campagne, ed è a testo libero, quindi usalo).

Commerciali

sale_price, sale_price_effective_date, unit_pricing_measure, unit_pricing_base_measure, installment, subscription_cost, loyalty_program.

Logistica

shipping, shipping_weight, shipping_length / _width / _height, shipping_label, transit_time_label, min_handling_time, max_handling_time, tax.

Controllo delle campagne

excluded_destination, included_destination, ads_redirect, da custom_label_0 a custom_label_4.

Le cinque custom label sono i campi più sottoutilizzati dell'intera specifica. Per Google non hanno alcun significato: esistono solo per permetterti di segmentare. Fasce di margine, profondità di stock, stagionalità, età del prodotto, livello di performance in GA4. Se la struttura delle tue campagne non riesce a esprimere una regola di business, di solito il motivo è questo.

Media

additional_image_link, lifestyle_image_link, virtual_model_link, video_link.

Un articolo retail minimo ma 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>

Nota & e > in product_type. I caratteri & non sottoposti a escape negli URL e nei percorsi di categoria sono la causa più frequente di file XML che non vengono proprio analizzati.

5. Cosa è cambiato nel 2026

Tre modifiche alla specifica dei dati di prodotto di Google meritano di essere affrontate subito, invece che a ridosso della scadenza.

La risoluzione minima delle immagini è ora 500x500 px per image_link e additional_image_link, in tutte le categorie e per tutti i metodi di marketing. Gli avvisi hanno iniziato a comparire in Merchant Center ad aprile 2026; l'applicazione obbligatoria parte il 31 gennaio 2027. Google può ingrandire automaticamente alcune immagini più piccole, ma considerarla una soluzione è un errore: le immagini ingrandite si vede che sono ingrandite, e la qualità delle immagini è una variabile del CTR.

video_link è attivo e in pubblicazione. I video inviati tramite questo attributo sono diventati idonei alla pubblicazione dal 30 giugno 2026, con convalida di policy e qualità. Gli errori bloccano il video ma non l'offerta, il che lo rende un campo a basso rischio da compilare. La maggior parte dei cataloghi non ha video di prodotto per la maggior parte degli SKU, ed è proprio per questo che generarli su larga scala dai dati del feed oggi rappresenta un divario competitivo e non un optional.

I controlli di spedizione a livello di prodotto si sono ampliati. handling_cutoff_time imposta un orario limite giornaliero per l'elaborazione degli ordini e minimum_order_value specifica la spesa minima per la consegna. L'attributo shipping ha inoltre ottenuto i sotto-attributi loyalty_program_label e loyalty_tier_label per i vantaggi di consegna legati ai programmi fedeltà.

La direzione è coerente: Google continua a spostare a livello di articolo dettagli che prima si trovavano a livello di account. Tutto ciò che viene espresso per singolo articolo è qualcosa che un livello di gestione dei feed può automatizzare e un processo manuale no.

6. La mappa dei settori

Il retail è una riga di questa tabella, non l'intera tabella.

Due regole strutturali da interiorizzare prima di costruire qualsiasi cosa:

Un catalogo Meta contiene esattamente un tipo di inventario. Non puoi mescolare hotel e prodotti. Se vendi entrambi, ti servono due cataloghi.

Google separa i settori a livello di origine dati. Un'origine dati di veicoli deve essere destinata solo agli annunci di veicoli. Inviare veicoli in un'origine dati Shopping produce rifiuti, non schede, e le origini dati di veicoli non devono contenere ricambi o accessori, che vanno in un normale feed di prodotto.

7. Feed di veicoli

L'automotive è il settore in cui "usa semplicemente la specifica retail" fallisce nel modo più evidente. Un'auto è un oggetto fisico unico con un identificativo legale, non uno SKU con una profondità di stock.

Gli attributi di Google per i veicoli si aggiungono al nucleo comune:

<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>

Cosa rende i feed di veicoli diversi dal punto di vista operativo:

• L'inventario ha profondità uno. Ogni articolo è un'unità singola. Quando viene venduto, deve uscire subito dal feed, non alla sincronizzazione di domani. Le schede di veicoli non aggiornate sprecano clic con CPC elevato su auto che non esistono più e danneggiano la qualità dell'account.
• La frequenza di aggiornamento è tutto. Cicli di aggiornamento ogni quattro ore sono prassi standard nell'automotive, non un'ottimizzazione.
• La coerenza con la landing page è obbligatoria. Prezzo e chilometraggio nel feed devono corrispondere esattamente alla pagina di dettaglio del veicolo. Una variazione di prezzo su tutto il concessionario che aggiorna il sito ma non il feed provoca un'ondata di rifiuti nel giro di poche ore.
• Gli annunci di inventario automotive di Meta usano un vocabolario di campi diverso (state_of_vehicle, exterior_color, transmission, drivetrain, dealer_id), quindi gli stessi dati di origine richiedono una trasformazione diversa per ogni canale.

8. Feed per i viaggi

I viaggi si dividono in tre tipi di catalogo distinti, e l'errore è trattarli come uno solo.

Hotel

Il feed delle strutture è relativamente statico: nome, descrizione, indirizzo, coordinate, stelle, immagini, un prezzo di partenza. Ciò che cambia sono disponibilità e tariffe, ed è per questo che le configurazioni per gli hotel di solito abbinano un feed statico delle strutture a feed dinamici di tipologie di camera e prezzi.

Parametri principali: hotel_id, name, description, brand, url, image, latitude, longitude, address (con 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>

Voli

L'articolo è una tratta, non un posto a sedere. L'identità è la coppia origine–destinazione: origin_airport e destination_airport come codici IATA, più price, url, image, description. I prezzi sono di solito prezzi "a partire da" e cambiano continuamente, il che rende la frequenza di aggiornamento il vincolo determinante.

Destinazioni

L'articolo è un luogo verso cui vendi viaggi: destination_id, name, address, neighborhood, types, price, url, image. Utile per la prospezione nella parte alta del funnel, quando il viaggiatore ha un'intenzione ma nessuna struttura specifica in mente.

Il problema ricorrente dei viaggi è che prezzo e disponibilità vengono calcolati, non memorizzati. Il "prezzo" di un hotel dipende da date, occupazione e durata del soggiorno; quello di un volo dal momento in cui lo chiedi. I feed vogliono un unico numero. Scegliere quale numero (il più basso disponibile nei prossimi 30 giorni, il più basso per il prossimo weekend, la media) è una decisione commerciale che determina silenziosamente le performance dei tuoi annunci, e vale la pena prenderla consapevolmente invece di accettare ciò che produce di default l'esportazione.

9. Feed immobiliari

Strutturalmente simili ai veicoli: beni fisici unici, inventario con profondità uno, alto valore per clic e una scheda che deve sparire nel momento in cui l'immobile viene venduto o affittato.

Parametri principali: home_listing_id, name, description, address, latitude, longitude, url, image, price, currency, property_type (appartamento, casa, terreno, commerciale), listing_type (in vendita, in affitto, nuova costruzione), 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>

Una cosa che non è un problema di feed ma bloccherà la tua campagna: su Meta l'immobiliare è una categoria pubblicitaria soggetta a restrizioni. Le campagne che promuovono annunci immobiliari devono essere dichiarate nella categoria speciale di annunci relativa agli alloggi, che limita le opzioni di targeting. Il catalogo può essere perfetto e la campagna fallire comunque se questa impostazione non è attiva.

10. Feed per gli annunci di lavoro

Il recruiting usa una struttura di documento completamente diversa (<source> e <job> invece di <rss> e <item>) e vale la pena vederla, perché dimostra che "feed XML" è uno schema ricorrente, non un unico formato.

<?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>

Quattro regole specifiche dei feed per gli annunci di lavoro:

1. CDATA è la norma, non l'eccezione. Le descrizioni delle offerte di lavoro contengono HTML, e commerciali e apostrofi. Racchiudere ogni campo in <![CDATA[...]]> evita un'intera categoria di errori di analisi.
2. La località richiede almeno città, regione e paese. Se li ometti, l'annuncio perde di default visibilità organica sui principali aggregatori.
3. Le posizioni coperte devono essere rimosse, non contrassegnate come chiuse. Non esiste un equivalente di availability. La presenza nel feed è il segnale di disponibilità, e gli aggregatori penalizzano i feed che contengono annunci scaduti.
4. Una lingua, una voce. Un annuncio pubblicato in due lingue richiede due voci separate con numeri di riferimento distinti.

Separatamente dal feed, sono i dati strutturati JobPosting in JSON-LD nella pagina delle carriere a rendere una posizione idonea agli elenchi di offerte di lavoro nei risultati di ricerca. I due elementi sono complementari: il feed gestisce la distribuzione agli aggregatori, i dati strutturati gestiscono la ricerca organica. La maggior parte dei team di recruiting fa una cosa e non l'altra.

11. Inventario legato al tempo

La categoria di feed più interessante non ha una specifica ufficiale, perché le piattaforme non l'hanno mai prevista: l'inventario il cui attributo distintivo è il quando, non il cosa.

Partite di calcio. Concerti. Proiezioni al cinema. Partenze di voli. Lotti d'asta. Fasce orarie per prenotare al ristorante. Finestre di consegna.

Hanno tutte le proprietà dei prodotti (un'identità, un prezzo, un'immagine, una landing page) più una per cui la specifica retail non ha un campo: una durata di vita misurata in ore. Una partita già iniziata non è "esaurita": non ha più senso.

L'approccio che funziona è modellarli come normali prodotti di catalogo e codificare la dimensione temporale in campi che la piattaforma già comprende:

<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>

Tre elementi fanno funzionare questo approccio:

• expiration_date o una regola di rimozione equivalente, così l'articolo esce dal catalogo al calcio d'inizio e non alla sincronizzazione programmata successiva.
• Custom label che contengono la dimensione temporale, così le campagne possono essere strutturate intorno a "questo weekend", "derby" o "quote superiori a 2,0".
• Una creatività per ogni articolo. È qui che di solito l'approccio si blocca. Un calendario di diverse centinaia di partite a settimana richiede diverse centinaia di immagini, ognuna con squadre, data, ora e quote aggiornate. Nessun team di design riesce a produrle. Generare la creatività dalla riga del feed è l'unico metodo che tiene il passo, ed è esattamente così che Bilyoner ha usato gli annunci catalogo per la prima volta, aumentando il ROAS del 49%.

Se il tuo inventario ha un orario di inizio, il suo posto è in un catalogo. L'ostacolo è quasi sempre il formato, non il concetto.

12. Feed di inventario locale

L'inventario locale si colloca tra il retail e i settori verticali: gli stessi prodotti, descritti per singola sede fisica.

Parametri: id, store_code, quantity, price, sale_price, sale_price_effective_date, availability, pickup_method (acquisto, prenotazione, spedizione in negozio, non supportato), pickup_sla (in giornata, giorno successivo, più giorni).

Il punto strutturale è che il feed locale è un supplemento, non un sostituto. Fa riferimento agli articoli del feed di prodotto principale tramite id e aggiunge informazioni per singolo negozio. Un articolo, molti negozi, molte righe.

Una nota sul 2026 da evidenziare: le versioni online e in negozio dello stesso prodotto con prezzi o disponibilità diversi ora richiedono ID prodotto separati invece di essere accorpate in uno solo. Ai feed che le avevano consolidate viene chiesto di separarle.

13. Regole di formattazione

Valgono per ogni tipo di feed citato in questo articolo e, insieme, spiegano la grande maggioranza dei feed che falliscono del tutto.

Codifica. UTF-8, sempre, dichiarata nella dichiarazione XML e servita con un header Content-Type corrispondente. Le discrepanze tra la codifica dichiarata e quella effettiva corrompono ogni carattere non ASCII.

Escape. Nel contenuto XML cinque caratteri devono essere sottoposti a escape: & → &, < → <, > → >, " → ", ' → '. Le e commerciali non sottoposte a escape negli URL di tracciamento sono la causa numero uno dei feed che non vengono analizzati. L'alternativa è CDATA, prassi standard nei feed per gli annunci di lavoro e utile ovunque le descrizioni contengano markup.

Date. ISO 8601 con offset del fuso orario esplicito. 2026-08-16T19:00+0300, non 16.08.2026 19:00. I feed che servono più mercati da un'unica origine senza fuso orario producono articoli che scadono con ore di anticipo o di ritardo.

Prezzi. Valore e valuta ISO 4217, punto decimale e non virgola, nessun separatore delle migliaia. 4299.00 TRY. E il prezzo nel feed deve corrispondere alla landing page: sulla maggior parte delle piattaforme viene verificato tramite scansione.

I valori predefiniti sono sensibili a maiuscole e formato e cambiano da piattaforma a piattaforma. Google si aspetta in_stock; Meta si aspetta in stock. Questa singola differenza ha rotto più importazioni di cataloghi di qualsiasi altra. Non dare mai per scontato che un valore predefinito valga per tutte le destinazioni.

Consegna del file. Compressione gzip per i file di grandi dimensioni, un URL HTTPS stabile, nessuna autenticazione a meno che la piattaforma non la supporti esplicitamente e un server che risponda entro il timeout della piattaforma. Un URL di feed dietro la protezione anti-bot di Cloudflare è un URL di feed che non viene recuperato.

La frequenza di aggiornamento deve seguire la volatilità dei dati sottostanti, non una convenzione: ogni ora o più spesso per quote, prezzi dei voli e stock retail ad alta rotazione; ogni poche ore per veicoli e immobili; giornaliera per cataloghi stabili.

14. XML, CSV, JSON o API

XML resta lo standard per tutto ciò che ha strutture annidate, ed è per questo che i feed di veicoli, viaggi e retail con molte regole di spedizione tendono a essere in XML, mentre i cataloghi moda semplici sono spesso in TSV. Tieni presente anche che diverse destinazioni importanti si stanno spostando verso un'acquisizione API-first, quindi considerare il file come unico canale di integrazione è un rischio nel medio periodo.

Se i tuoi titoli contengono virgole (e i titoli con colore e taglia quasi sempre le contengono), usa TSV invece di CSV. Un'intera categoria di bug di analisi scompare.

15. Checklist prima del lancio

• [ ] Il file viene analizzato correttamente da un validatore XML prima di avvicinarsi a qualsiasi piattaforma
• [ ] UTF-8 dichiarato e servito correttamente; i caratteri non ASCII vengono visualizzati bene
• [ ] Ogni & in ogni URL sottoposto a escape, oppure il campo racchiuso in CDATA
• [ ] ID univoci, stabili tra le sincronizzazioni e corrispondenti agli eventi del pixel o del tag
• [ ] Tutti gli attributi obbligatori presenti per la destinazione di riferimento, verificati sulla specifica di quella destinazione e non su una generica
• [ ] Valori predefiniti trasformati per ogni destinazione, non copiati
• [ ] Prezzi esattamente corrispondenti alle landing page, compresi valuta ed eventuale trattamento fiscale
• [ ] Date in ISO 8601 con offset del fuso orario
• [ ] Immagini che rispettano il minimo di 500x500 e si caricano via HTTPS senza reindirizzamenti
• [ ] Articoli venduti, posizioni coperte, eventi scaduti o voli partiti escono dal feed con la tempistica giusta
• [ ] Frequenza di aggiornamento in linea con la velocità con cui cambiano davvero i dati sottostanti
• [ ] URL del feed raggiungibile pubblicamente e non bloccato dalla protezione anti-bot
• [ ] Esiste una regola di monitoraggio per variazioni impreviste del numero di articoli

16. Domande frequenti

XML è ancora il formato giusto nel 2026?
Per tutto ciò che ha dati annidati, sì. Per i cataloghi piatti, TSV è più semplice e meno fragile. Per esigenze in tempo reale, un'integrazione API batte qualsiasi file. Il formato deve seguire i dati, non le abitudini.

Posso usare un unico feed per tutte le piattaforme?
Un'unica origine, sì. Un unico file, no. Nomi dei campi, valori predefiniti, limiti di caratteri e attributi obbligatori cambiano da una destinazione all'altra, e le differenze non sono estetiche. L'architettura che funziona è un unico catalogo di riferimento con trasformazioni per canale applicate in fase di esportazione.

E se il mio inventario non è fatto di prodotti?
Allora ti serve la specifica del tuo settore, non quella retail. Veicoli, hotel, voli, destinazioni, immobili e offerte di lavoro hanno tutti la propria. E se il tuo inventario è qualcosa per cui nessuna piattaforma ha una specifica (partite, proiezioni, fasce orarie, lotti), lo modelli come prodotti e codifichi la dimensione mancante nei campi esistenti.

Con quale frequenza dovrebbe aggiornarsi il feed?
Tutte le volte che i dati sottostanti cambiano in modo significativo. Un veicolo venduto stamattina e ancora pubblicizzato nel pomeriggio sta spendendo soldi per niente.

Mi servono i GTIN?
Per il retail, di fatto sì. Il GTIN è ciò che collega il tuo articolo alla conoscenza dei prodotti di una piattaforma, che determina sempre di più se compari o meno nelle superfici di confronto e nei risultati di shopping basati sull'AI. Per veicoli, immobili e offerte di lavoro, i campi di identità equivalenti sono vin, l'ID della scheda e il numero di riferimento.

Dove le cose si complicano

Nessuna delle singole regole di questo articolo è difficile. La difficoltà è che sono diverse centinaia, cambiano da destinazione a destinazione, cambiano senza preavviso e, se le violi, il fallimento è silenzioso.

Un singolo catalogo esportato su Google, Meta, TikTok e tre marketplace significa sei contratti diversi da rispettare contemporaneamente partendo da un'unica fonte attendibile. Farlo a mano significa mantenere sei file e riallinearli ogni volta che il catalogo cambia.

È il livello per cui è stato creato Feedance: regole del feed per normalizzare gli attributi all'origine, esportazioni per canale che applicano la trasformazione giusta per ciascuna delle oltre 200 destinazioni senza toccare i dati di origine, Feed Protection per intercettare attributi mancanti e variazioni impreviste del numero di articoli prima che lo faccia una piattaforma, e una Creative Suite che genera un'immagine o un video per ogni riga del feed nei cataloghi in cui la produzione manuale non è mai stata realistica.

Supporta i settori non retail come protagonisti e non come ripiego: inventario di viaggi con prezzi in tempo reale, cataloghi per le scommesse con dati sugli orari delle partite, canali di distribuzione per automotive, immobiliare e annunci di lavoro.

Se vuoi sapere a che punto è il tuo feed attuale prima di cambiare qualsiasi cosa, il nostro strumento gratuito di audit del feed lo valuta per completezza, qualità dei dati e salute tecnica, senza alcun costo. Oppure prenota una demo di 15 minuti e lo analizziamo insieme.

Ultima revisione: agosto 2026. Le specifiche delle piattaforme cambiano spesso; prima dell'implementazione verifica i requisiti attuali nella documentazione ufficiale di ciascuna destinazione.