La guida completa ai feed di varianti di prodotto

La maggior parte dei problemi di feed non sembra un problema di feed. Sembra una disapprovazione di Google Merchant Center che non riesci a spiegarti, una campagna Advantage+ che spende il budget su un'unica t-shirt nera, o un annuncio Shopping che manda un cliente in cerca di una scarpa numero 42 su una pagina dove è rimasto solo il 38.

Sotto quasi tutti questi casi c'è la stessa cosa: le varianti.

Una variante è qualsiasi versione di un prodotto che differisce per un aspetto visibile e acquistabile: taglia, colore, materiale, capacità, finitura. Nel retail sono una cosa normale e nei feed sono insolitamente difficili, perché ogni canale le modella in modo diverso e perché gli errori non fanno rumore. Non si rompe niente. I tuoi annunci rendono semplicemente meno del dovuto, e la diagnosi si trova quattro livelli più in basso, in un file di dati che nessuno apre.

Questa guida copre l'intero argomento: cosa conta davvero come variante, come funziona item_group_id e dove viene usato male, ogni attributo che definisce le varianti con i suoi limiti reali, esempi di feed funzionanti in XML, CSV e JSON, come Google, Meta, TikTok, Pinterest, Amazon e i marketplace regionali si aspettano che le varianti siano strutturate, e una tabella diagnostica per gli errori più frequenti.

È lunga perché l'argomento lo è. Usa l'indice per saltare alle sezioni.

1. Cos'è davvero una variante

Una variante è una versione acquistabile di un prodotto che differisce dalle altre per almeno un attributo tra cui il cliente sceglierebbe, pur restando lo stesso prodotto.

L'ultima parte della frase è decisiva. Una t-shirt blu taglia M e una t-shirt nera taglia L sono lo stesso prodotto. Una t-shirt blu e una felpa blu no, anche se sono dello stesso brand e dello stesso tessuto.

Il modello standard nella maggior parte dei canali è parent/child (prodotto principale/varianti):

• Il parent è il prodotto concettuale: "Merino Crew Neck Sweater". Di solito non è acquistabile da solo.
• I children sono le varianti, ognuna con il proprio SKU, il proprio livello di stock e talvolta il proprio prezzo e la propria immagine.

In un feed di prodotto questo si esprime quasi sempre in forma piatta: ogni variante è una riga o un <item> a sé, e una chiave di raggruppamento comune le collega. Non c'è annidamento. Un maglione in 4 colori e 5 taglie corrisponde a 20 righe, tutte con lo stesso ID di gruppo.

Cosa non è una variante

È qui che i feed sbagliano prima ancora di scrivere una sola riga di XML.

Raggruppare uno di questi casi sotto un item_group_id comune produce un gruppo i cui membri non sono intercambiabili, il che confonde il selettore di varianti sulla pagina di destinazione e, su alcuni canali, attiva una disapprovazione per mancata corrispondenza.

2. La decisione da cui dipende tutto

Prima di scrivere qualsiasi logica del feed, rispondi a una domanda per ogni tipologia di prodotto che vendi:

Quando un cliente sceglie un'opzione diversa, arriva su una pagina diversa o sulla stessa pagina in uno stato diverso?

È il test pratico, e corrisponde direttamente al modo in cui dovresti strutturare il feed.

Caso A: URL separati per ogni variante. Ogni colore ha la propria pagina prodotto (/merino-sweater-navy, /merino-sweater-charcoal). Invia ogni variante come riga a sé con il proprio link. È la configurazione più pulita, offre la migliore pertinenza degli annunci ed è quella che i canali preferiscono.

Caso B: un unico URL, variante selezionata sulla pagina. Tutto si trova in /merino-sweater e il cliente sceglie colore e taglia con un selettore. Puoi comunque inviare ogni variante, ma dovresti aggiungere un parametro di deep link perché l'annuncio arrivi sullo stato preselezionato corretto:

https://example.com/merino-sweater?colour=navy&size=m

Senza questo parametro, un acquirente che ha cliccato su un annuncio per un blu navy taglia M arriva su uno stato predefinito che mostra un grigio antracite taglia S. Questa discrepanza è uno dei più grandi killer silenziosi delle conversioni nella pubblicità delle varianti e, su Google, può anche attivare una disapprovazione "Mismatched value (page crawl)", perché il crawler vede una pagina il cui colore visibile non corrisponde al valore color inviato.

Caso C: varianti che non vale la pena separare. Alcune variazioni non incidono abbastanza sulla decisione d'acquisto da giustificare annunci separati, ad esempio la lunghezza del cavo di un caricabatterie. In questo caso puoi decidere di inviare una sola variante rappresentativa. La sezione 7 spiega quando è la scelta giusta.

Attributi che definiscono le varianti e attributi descrittivi

Ogni attributo del tuo feed rientra in una di due categorie, e confonderle è una causa frequente di gruppi malformati.

Gli attributi che definiscono le varianti devono differire tra i membri del gruppo. Sono le cose che il cliente sceglie: color, size, material, pattern, più dimensioni specifiche del prodotto come capacità o finitura.

Gli attributi costanti nel gruppo devono essere identici in tutti i membri: brand, gender, age_group, item_group_title, google_product_category. Se due righe condividono un item_group_id ma hanno valori gender diversi, hai raggruppato male i prodotti oppure li hai etichettati male.

Gli attributi specifici della riga ma non definitori della variante variano da riga a riga senza definire la variazione: id, price, availability, gtin, image_link, link. Due varianti possono legittimamente avere prezzi diversi (una taglia 3XL spesso costa di più) senza che sia il prezzo a distinguerle.

3. item_group_id: le fondamenta

item_group_id è la chiave condivisa che dice a un canale "queste righe sono lo stesso prodotto". Tutto il resto della gestione delle varianti dipende dal fatto che sia corretta.

La specifica

Poiché Google tratta il valore senza distinguere maiuscole e minuscole mentre Meta e TikTok no, standardizza ovunque su minuscole (o maiuscole). Un catalogo in cui compaiono sia SWTR-001 sia swtr-001 verrà raggruppato correttamente su Google e diviso in due prodotti su Meta.

Scegliere il valore

Il miglior item_group_id è lo SKU parent che hai già nel tuo ERP o PIM. Esiste, è stabile ed è univoco.

Corretto:

SWTR-MERINO-CREW
12345
parent-8891

Sbagliato, e perché:

L'ultimo caso merita un'enfasi particolare. item_group_id deve essere stabile nel tempo. I canali accumulano storico di performance sul gruppo. Se la tua esportazione rigenera gli ID, azzeri quello storico a ogni sincronizzazione, e nessuna ottimizzazione delle offerte potrà compensarlo.

Le tre regole

1. Tutti i membri di un gruppo condividono lo stesso item_group_id.
2. Ogni membro ha un id univoco. Un id duplicato in qualsiasi punto del feed fa scartare silenziosamente la riga successiva.
3. Ogni membro differisce per almeno un attributo che definisce la variante. Due righe con lo stesso ID di gruppo e lo stesso colore e la stessa taglia sono duplicati, non varianti.

Una convenzione che soddisfa tutte e tre le regole:

item_group_id: SWTR-MERINO-CREW
id:            SWTR-MERINO-CREW-NAV-M
id:            SWTR-MERINO-CREW-NAV-L
id:            SWTR-MERINO-CREW-CHR-M

Leggibile, facile da analizzare, ricavata da dati che possiedi già.

item_group_title

Un attributo più recente di Google, facoltativo ma consigliato ogni volta che invii item_group_id. Contiene il nome del prodotto parent (massimo 150 caratteri) e deve essere identico in tutte le varianti del gruppo.

xml

<g:item_group_id>SWTR-MERINO-CREW</g:item_group_id>
<g:item_group_title>Merino Crew Neck Sweater</g:item_group_title>
<title>Merino Crew Neck Sweater — Navy, Medium</title>

Nota lo schema: title è specifico della variante, item_group_title no. Inviare la stessa stringa in entrambi spreca il segnale.

variant_option

Anch'esso più recente lato Google: un modo strutturato per dichiarare quali proprietà definiscono la variazione, invece di lasciare che sia il canale a dedurlo. Accetta fino a 30 coppie nome/valore (ogni sotto-attributo fino a 250 caratteri, 5.000 caratteri in totale).

xml

<g:variant_option>
  <g:name>Colour</g:name>
  <g:value>Navy</g:value>
</g:variant_option>
<g:variant_option>
  <g:name>Size</g:name>
  <g:value>M</g:value>
</g:variant_option>

È particolarmente utile per i prodotti i cui assi di variazione non sono coperti dagli attributi standard dell'abbigliamento: capacità di archiviazione, livello del processore, wattaggio, numero di posti. Invece di forzare "256GB" in size, lo dichiari nel modo corretto.

4. Gli attributi che definiscono le varianti, nel dettaglio

color

L'attributo con più regole di tutta la specifica, e quello rifiutato più spesso.

Non accettati:

• Numeri: Colour 42, RAL 5013
• Codici esadecimali: #001F5B
• Lettere singole: N per navy
• Rimandi a un'immagine: see photo
• Parole alfanumeriche o unite: Navy1, NavyBlue (scrivi Navy Blue)

Gestire i nomi di colore del marketing. I brand di moda raramente chiamano un colore "navy". Lo chiamano "Midnight Regatta". Il canale ha bisogno di un colore che un acquirente cercherebbe; il tuo brand ha bisogno del proprio nome sulla pagina.

Il compromesso praticabile:

color:       Navy
description: ...available in Midnight Regatta (navy)...

Nel feed, mappa i nomi del marketing su nomi standard e mantieni il nome del brand visibile sulla landing page e nella descrizione. Non mettere il nome di marketing in color sperando che funzioni: peggiora l'abbinamento con le ricerche che includono un colore, che sono tra le ricerche con l'intenzione più alta nell'abbigliamento.

Prodotti multicolore:

color: Navy/White/Grey

Il colore principale va per primo. Google legge il primo valore come colore dominante.

size

La regola che conta: sii abbastanza specifico da non lasciare ambiguità, e coerente in tutto il catalogo. M va bene se tutti i prodotti usano M. Un feed che mescola M, Medium, med e M/L per lo stesso concetto frammenta i gruppi di varianti e rende impossibile la segmentazione per taglia.

Per i prodotti in cui una sola dimensione non basta, includi nel valore le dimensioni distintive:

size: 32/34          (waist/inseam)
size: 15.5/34        (neck/sleeve)
size: 9.5 Wide       (shoe width)
size: 200x140cm      (rugs, bedding)

size_type e size_system

Facoltativi, solo per l'abbigliamento, e poco usati: entrambi migliorano sensibilmente l'abbinamento con gli acquirenti che cercano usando questi qualificatori.

size_type: fino a 2 valori tra regular, petite, maternity, big, tall, plus.

size_system: uno tra US, UK, EU, DE, FR, JP, CN, IT, BR, MEX, AU. Se omesso, il canale presume il sistema del paese di destinazione, ed è l'origine di un errore specifico e costoso: un retailer turco che vende in Germania con taglie EU ma senza size_system dichiarato può vedere le proprie taglie interpretate sulla scala sbagliata.

xml

<g:size>10</g:size>
<g:size_system>UK</g:size_system>
<g:size_type>regular</g:size_type>

material

Massimo 200 caratteri su Google. Prima il materiale principale, poi fino a due materiali secondari separati da /.

material: Cotton
material: Leather/Suede
material: Merino Wool/Nylon/Elastane

Obbligatorio solo se distingue le tue varianti, ad esempio una borsa venduta in pelle e in tela. Altrimenti è facoltativo ma vale la pena inviarlo: il materiale è un qualificatore di ricerca comune.

pattern

Massimo 100 caratteri. Testo libero che descrive la stampa o la grafica: Striped, Polka Dot, Paisley, Floral, Herringbone. Stessa regola: obbligatorio se è ciò che varia.

age_group e gender

Entrambi sono costanti nel gruppo. Ogni variante di un gruppo deve avere lo stesso valore.

age_group: newborn, infant, toddler, kids, adult; un valore per prodotto.

gender: male, female, unisex.

Se un capo è davvero offerto in versione uomo e donna, si tratta di due item group separati, non di un unico gruppo con gender misto. I tagli sono diversi, le taglie sono diverse, e l'acquirente sta scegliendo tra prodotti e non tra opzioni.

Tabella di riferimento

5. Esempi di feed reali

XML (Google RSS 2.0)

Due varianti di un gruppo di sei. Nota cosa cambia e cosa no.

xml

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

    <item>
      <g:id>SWTR-MERINO-CREW-NAV-M</g:id>
      <g:item_group_id>SWTR-MERINO-CREW</g:item_group_id>
      <g:item_group_title>Merino Crew Neck Sweater</g:item_group_title>
      <title>Merino Crew Neck Sweater — Navy, Medium</title>
      <description>Fine-gauge 100% merino wool crew neck. Ribbed cuffs and hem, regular fit. Machine washable on wool cycle.</description>
      <link>https://example.com/merino-crew-sweater?colour=navy&amp;size=m</link>
      <g:image_link>https://cdn.example.com/swtr-merino-navy-1.jpg</g:image_link>
      <g:additional_image_link>https://cdn.example.com/swtr-merino-navy-2.jpg</g:additional_image_link>
      <g:availability>in_stock</g:availability>
      <g:price>89.00 EUR</g:price>
      <g:brand>Example</g:brand>
      <g:gtin>5012345678900</g:gtin>
      <g:mpn>SW-MC-NAV-M</g:mpn>
      <g:condition>new</g:condition>
      <g:google_product_category>1604</g:google_product_category>
      <g:color>Navy</g:color>
      <g:size>M</g:size>
      <g:size_system>EU</g:size_system>
      <g:size_type>regular</g:size_type>
      <g:material>Merino Wool</g:material>
      <g:gender>male</g:gender>
      <g:age_group>adult</g:age_group>
      <g:custom_label_0>core</g:custom_label_0>
      <g:custom_label_1>full-size-run</g:custom_label_1>
    </item>

    <item>
      <g:id>SWTR-MERINO-CREW-CHR-L</g:id>
      <g:item_group_id>SWTR-MERINO-CREW</g:item_group_id>
      <g:item_group_title>Merino Crew Neck Sweater</g:item_group_title>
      <title>Merino Crew Neck Sweater — Charcoal, Large</title>
      <description>Fine-gauge 100% merino wool crew neck. Ribbed cuffs and hem, regular fit. Machine washable on wool cycle.</description>
      <link>https://example.com/merino-crew-sweater?colour=charcoal&amp;size=l</link>
      <g:image_link>https://cdn.example.com/swtr-merino-charcoal-1.jpg</g:image_link>
      <g:availability>out_of_stock</g:availability>
      <g:price>89.00 EUR</g:price>
      <g:brand>Example</g:brand>
      <g:gtin>5012345678931</g:gtin>
      <g:mpn>SW-MC-CHR-L</g:mpn>
      <g:condition>new</g:condition>
      <g:google_product_category>1604</g:google_product_category>
      <g:color>Charcoal</g:color>
      <g:size>L</g:size>
      <g:size_system>EU</g:size_system>
      <g:size_type>regular</g:size_type>
      <g:material>Merino Wool</g:material>
      <g:gender>male</g:gender>
      <g:age_group>adult</g:age_group>
      <g:custom_label_0>core</g:custom_label_0>
      <g:custom_label_1>broken-size</g:custom_label_1>
    </item>

  </channel>
</rss>

Quattro aspetti da sottolineare:

1. item_group_id e item_group_title sono identici; id e title no.
2. link contiene parametri di deep link, così l'annuncio arriva sullo stato preselezionato corretto. Il carattere & è codificato come &amp;: è obbligatorio in XML ed è una causa frequente di errori di parsing.
3. image_link è specifico della variante. Entrambe le righe navy puntano alla fotografia navy. Inviare un'unica immagine principale per tutti i colori è il secondo errore più comune sulle varianti, dopo gli ID di gruppo mancanti.
4. La riga esaurita è contrassegnata tramite custom_label_1, così può essere esclusa o ricevere offerte più basse senza essere rimossa dal feed.

CSV / TSV

Gli stessi dati in forma piatta. Riga di intestazione più due varianti:

csv

id,item_group_id,item_group_title,title,description,link,image_link,availability,price,brand,gtin,condition,google_product_category,color,size,size_system,material,gender,age_group,custom_label_0
SWTR-MERINO-CREW-NAV-M,SWTR-MERINO-CREW,Merino Crew Neck Sweater,"Merino Crew Neck Sweater — Navy, Medium","Fine-gauge 100% merino wool crew neck.",https://example.com/merino-crew-sweater?colour=navy&size=m,https://cdn.example.com/swtr-merino-navy-1.jpg,in_stock,89.00 EUR,Example,5012345678900,new,1604,Navy,M,EU,Merino Wool,male,adult,core
SWTR-MERINO-CREW-CHR-L,SWTR-MERINO-CREW,Merino Crew Neck Sweater,"Merino Crew Neck Sweater — Charcoal, Large","Fine-gauge 100% merino wool crew neck.",https://example.com/merino-crew-sweater?colour=charcoal&size=l,https://cdn.example.com/swtr-merino-charcoal-1.jpg,out_of_stock,89.00 EUR,Example,5012345678931,new,1604,Charcoal,L,EU,Merino Wool,male,adult,core

Il CSV è il formato in cui avviene la maggior parte dei problemi reali, perché le virgole all'interno di titoli e descrizioni vanno racchiuse tra virgolette, e le virgolette all'interno dei campi tra virgolette vanno codificate. Se i tuoi titoli contengono virgole (e i titoli di prodotto con colore e taglia le contengono quasi sempre), usa invece il TSV. Le tabulazioni non compaiono praticamente mai nei dati di prodotto, e un'intera categoria di bug di parsing scompare.

JSON

Per l'acquisizione tramite API:

json

{
  "products": [
    {
      "id": "SWTR-MERINO-CREW-NAV-M",
      "item_group_id": "SWTR-MERINO-CREW",
      "item_group_title": "Merino Crew Neck Sweater",
      "title": "Merino Crew Neck Sweater — Navy, Medium",
      "link": "https://example.com/merino-crew-sweater?colour=navy&size=m",
      "image_link": "https://cdn.example.com/swtr-merino-navy-1.jpg",
      "availability": "in_stock",
      "price": { "value": "89.00", "currency": "EUR" },
      "brand": "Example",
      "gtin": "5012345678900",
      "condition": "new",
      "google_product_category": "1604",
      "variant_attributes": {
        "color": "Navy",
        "size": "M",
        "size_system": "EU",
        "material": "Merino Wool"
      },
      "gender": "male",
      "age_group": "adult"
    }
  ]
}

Una serie completa di taglie

Sei varianti (due colori × tre taglie) con lo schema degli ID in evidenza:

Il colore Charcoal ha una sola taglia disponibile su tre. La sezione 9 spiega cosa fare in questo caso.

6. Canale per canale

Il concetto è universale. L'implementazione no. Ecco come ogni destinazione principale si aspetta le varianti, e dove ciascuna si differenzia.

Google Shopping / Merchant Center

Il più prescrittivo, e l'implementazione di riferimento da cui attinge la maggior parte degli altri canali.

• item_group_id è obbligatorio per le schede senza costi, e per gli annunci Shopping in Brasile, Francia, Germania, Giappone, Regno Unito e Stati Uniti, ogni volta che vengono inviate varianti.
• Gli attributi che definiscono le varianti devono essere compilati: color e size sono obbligatori per l'abbigliamento in questi mercati.
• gender e age_group sono obbligatori per l'abbigliamento e devono essere coerenti in tutto il gruppo.
• La landing page deve corrispondere visibilmente ai valori della variante inviati, altrimenti rischi una disapprovazione Mismatched value (page crawl).
• Ogni variante compete in modo indipendente nell'asta. Google sceglie quale membro di un gruppo mostrare per una determinata ricerca, quindi un gruppo incompleto significa un insieme di candidati più debole.
• image_link deve essere di almeno 500×500 pixel per l'abbigliamento, un minimo che verrà applicato dal 31 gennaio 2027: conviene verificarlo ora piuttosto che di corsa all'ultimo momento.

Nota pratica: Merchant Center fornisce i report a livello di variante (id), non di gruppo. Per valutare correttamente un prodotto devi aggregare tu i dati per item_group_id, il che è molto più facile se l'ID di gruppo è pulito e stabile.

Meta (Facebook e Instagram)

Meta usa lo stesso nome di campo con vincoli diversi e un modello di visualizzazione sostanzialmente differente.

• item_group_id ammette fino a 100 caratteri e distingue tra maiuscole e minuscole.
• color e size ammettono fino a 200 caratteri.
• I valori di availability usano spazi, non trattini bassi: in stock, non in_stock. Questa singola differenza rompe più feed Meta di qualsiasi altra, soprattutto quando un feed Google viene riutilizzato direttamente.
• Negli Shops e nelle superfici di dettaglio prodotto, un insieme raggruppato correttamente viene mostrato come un unico prodotto con un selettore di varianti, invece che come più inserzioni quasi identiche.
• Gli annunci catalogo Advantage+ usano il gruppo per evitare di mostrare a un utente sei versioni dello stesso maglione nello stesso carosello: un catalogo non raggruppato produce annunci visibilmente ripetitivi e impressioni sprecate.
• I report a livello di variante in Commerce Manager dipendono da un raggruppamento corretto.

Nota pratica: non collegare Meta al tuo feed Google senza modificarlo. Come minimo, trasforma availability e controlla i limiti di caratteri. La maggior parte delle piattaforme di feed, Feedance compresa, gestisce questo passaggio come trasformazione a livello di canale, così i dati sorgente restano intatti.

TikTok

• item_group_id ammette fino a 150 caratteri.
• sku_id è l'identificatore univoco per variante: ogni riga di variante ha bisogno di un valore distinto.
• color e size ammettono fino a 200 caratteri.
• title ammette fino a 255 caratteri; description fino a 10.000; google_product_category è previsto.
• TikTok è il canale più rigoroso sulle immagini specifiche per variante. Le schede prodotto mostrano un selettore di varianti, e le varianti che condividono un'unica immagine generica rendono in modo misurabilmente peggiore. Se devi fare un compromesso nella tua pipeline di immagini, non farlo qui.

Pinterest

• Segue da vicino il modello di Google; item_group_id raggruppa le varianti.
• Pinterest mostra le varianti all'interno di un unico Product Pin con opzioni selezionabili.
• La qualità delle immagini e i formati verticali contano in modo sproporzionato: Pinterest è una superficie di scoperta visiva, e le immagini di variante poco distinte semplicemente non vengono salvate.

Amazon

Amazon non usa item_group_id, e presumere il contrario fa sprecare moltissimo lavoro.

Amazon usa un modello esplicito di relazione parent/child:

• Un ASIN parent viene creato come inserzione non acquistabile.
• Ogni ASIN child fa riferimento al parent tramite i campi parent_sku / parent_child.
• Deve essere dichiarato un variation theme: SizeColor, Size, Color, SizeName-ColorName e così via, a seconda della categoria.
• Il tema deve essere valido per quella specifica categoria; lo stesso nome di tema non è disponibile ovunque.

Se esporti sia verso Google sia verso Amazon da un'unica fonte, consideralo una vera trasformazione e non una semplice rinomina dei campi. Il tuo livello di feed deve costruire l'inserzione parent, assegnare il tema e mappare i child su di essa.

Marketplace regionali e comparatori di prezzo

I canali turchi e, più in generale, dell'area MENA hanno ciascuno le proprie convenzioni, che spesso fanno la differenza tra un catalogo funzionante e uno rotto in questi mercati.

• Trendyol usa un proprio modello parent/child con un insieme obbligatorio di attributi specifici per categoria. Colore e taglia sono campi strutturati separati, e gli elenchi degli attributi obbligatori variano da categoria a categoria.
• Akakçe e Cimri sono comparatori di prezzo. Di solito si aspettano una riga per ogni SKU acquistabile, e le righe duplicate quasi identiche tendono a essere filtrate: inviare una serie completa di taglie senza dati differenziati può quindi ridurre la visibilità invece di aumentarla.
• Hepsiburada e N11 definiscono ciascuno le proprie chiavi di raggruppamento delle varianti e i propri attributi obbligatori.

È l'area in cui gli strumenti di feed globali generici risultano più spesso inadeguati, e in cui un attributo mappato male rimuove silenziosamente un'intera categoria da un marketplace.

Confronto

7. Separare o accorpare?

Inviare ogni variante è la raccomandazione predefinita, ma non è corretta in ogni caso. La vera domanda è se la variazione cambia ciò che l'acquirente desidera.

Invia ogni variante quando…

• La variazione è la decisione d'acquisto. Abbigliamento, calzature, qualsiasi prodotto in cui la taglia sbagliata non porta a una vendita.
• Lo stock differisce sensibilmente da una variante all'altra. Pubblicizzare un prodotto la cui unica opzione rimasta è una taglia 3XL spreca budget.
• Il prezzo differisce da una variante all'altra. Mostrare 89 € quando l'opzione selezionata costa 119 € produce una discrepanza di prezzo e un cliente arrabbiato.
• La domanda di ricerca è qualificata per variante. Le persone cercano "maglione merino navy taglia M". Non puoi posizionarti per questa ricerca senza inviare quella variante.

Accorpa in una sola variante rappresentativa quando…

• Il catalogo è molto grande e in gran parte omogeneo. Un rivenditore di ferramenta con 200.000 SKU, di cui il 60% sono banali variazioni di lunghezza, guadagna poco dall'espansione completa e la paga in elaborazione del feed e complessità delle campagne.
• Il canale penalizza i quasi duplicati. Diversi comparatori di prezzo filtrano le righe ripetitive; una serie completa di taglie può ridurre la visibilità.
• La variazione non incide su prezzo, immagine o disponibilità. Se tutte e dodici le varianti sono identiche sotto ogni aspetto commercialmente rilevante, dodici righe creano rumore invece che segnale.

Quando accorpi, scegli la variante rappresentativa con criterio: la variante disponibile più venduta, non la prima riga in ordine alfabetico. È esattamente qui che i dati di performance si guadagnano un posto nel feed: GA4 o i dati della piattaforma possono selezionare automaticamente la variante rappresentativa invece di lasciarla all'ordinamento.

Una via di mezzo

Separa sull'asse che guida la decisione; accorpa su quello che non la guida.

Per le calzature, di solito significa una riga per colore, con le taglie accorpate: il colore è l'asse della scoperta, la taglia è la verifica della vestibilità che avviene sulla pagina. Per un prodotto in cui la capacità determina il prezzo, separa per capacità e accorpa per colore.

8. I 12 errori più comuni sulle varianti

Gli errori 1, 2, 4 e 11 rappresentano la grande maggioranza di ciò che vediamo negli audit reali. Nessuno è difficile da risolvere; tutti sono invisibili finché qualcuno non va a cercarli.

9. Taglie mancanti e salute dell'inventario

Una serie di taglie incompleta (broken size) riguarda un prodotto il cui gruppo è tecnicamente attivo ma in pratica invendibile: un maglione disponibile solo in XS e 3XL, una scarpa con solo due numeri rimasti su nove.

Conta più di quanto sembri. Quando un acquirente clicca sull'annuncio di un prodotto e scopre che la sua taglia non è disponibile, hai pagato un clic che non poteva convertire, e ci hai rimesso anche in reputazione del brand. Su larga scala, i prodotti con taglie mancanti possono consumare una quota significativa del budget contribuendo quasi nulla al fatturato.

Come individuarle

Calcola, per ogni item_group_id:

size_availability_ratio = in_stock_variants / total_variants

Poi agisci in base a delle soglie. Un punto di partenza praticabile:

Pondera questo dato in base alla domanda, non solo al conteggio. Perdere XXS e XXL conta molto meno che perdere M e L, che di solito rappresentano la maggior parte dei volumi. Un rapporto che tratta tutte le taglie allo stesso modo reagirà troppo poco alla perdita delle taglie principali.

Come intervenire

L'implementazione più pulita contrassegna la condizione nel feed invece di rimuovere il prodotto:

xml

<g:custom_label_1>broken-size</g:custom_label_1>

Contrassegnare invece di eliminare preserva lo storico del prodotto nel canale e ti permette di riattivarlo all'istante quando lo stock torna disponibile. Rimuovere e aggiungere di nuovo azzera l'apprendimento.

Due ulteriori accorgimenti che vale la pena implementare:

• Riporta il dato al merchandising. Un elenco ricorrente di taglie mancanti è un segnale per gli acquisti, non solo un problema pubblicitario.
• Ricontrolla a ogni sincronizzazione. Lo stock si muove, e il contrassegno deve muoversi con esso. Un elenco statico di taglie mancanti è peggio di nessun elenco, perché sopprime prodotti che nel frattempo sono stati riassortiti.

10. Usare le varianti per segmentare le campagne

Una volta strutturate correttamente le varianti, i dati diventano un livello di segmentazione: probabilmente l'uso più redditizio di un feed di varianti pulito.

Google mette a disposizione cinque campi custom_label (0–4). Accettano valori arbitrari ed esistono solo per la tua logica di campagna. I dati delle varianti sono l'input ideale.

Uno schema praticabile

Con queste etichette, la logica delle campagne diventa semplice:

• Aumenta le offerte su bestseller + full-size-run + high-margin
• Escludi broken-size dal prospecting
• Dai a clearance una campagna dedicata con un tROAS aggressivo
• Isola ss26 al lancio della stagione

Performance Max e Advantage+

Entrambi sono in gran parte automatizzati, il che rende la segmentazione a livello di feed più importante, non meno. Non controlli più le offerte a livello di parola chiave, quindi il feed diventa la tua leva principale per orientare la spesa.

In Performance Max, le custom label guidano la struttura di gruppi di asset e gruppi di schede. Dividere un unico gruppo di asset onnicomprensivo in gruppi basati sul margine o sulla salute dello stock è una delle poche leve strutturali rimaste, e dipende interamente dal fatto che le etichette siano compilate con dati reali.

Negli annunci catalogo Advantage+, un raggruppamento corretto evita che il carosello si riempia di sei tonalità dello stesso maglione, e le definizioni dei set di prodotti basate sugli attributi delle varianti ti permettono di separare l'inventario per il prospecting da quello per il retargeting.

Arricchire le etichette con i dati di performance

Le etichette statiche invecchiano. Un bestseller assegnato la scorsa stagione è un'informazione sbagliata in questa.

L'implementazione più solida ricalcola le etichette dai dati di performance live (fatturato GA4, tasso di conversione, numero di visualizzazioni) a ogni sincronizzazione del feed. Un prodotto che smette di vendere esce automaticamente da bestseller; uno che inizia a vendere ci entra. È una parte fondamentale di ciò che significa in pratica l'arricchimento del feed, ed è la differenza tra etichette che orientano il budget ed etichette che si limitano a descrivere il trimestre scorso.

11. Misurare le performance delle varianti

I dati a livello di variante sono il punto in cui la maggior parte della reportistica crolla senza che nessuno se ne accorga.

Il problema dell'aggregazione. Merchant Center e Ads forniscono i report a livello di id. Un maglione con 20 varianti compare come 20 righe, ognuna con una frazione del volume e nessuna significativa da sola. Qualsiasi conclusione tratta da una singola riga di variante è probabilmente rumore.

Analizza sempre su due livelli:

1. Livello di gruppo (item_group_id): questo prodotto funziona? Aggrega spesa, conversioni e fatturato di tutti i membri.
2. Livello di variante (id): quali opzioni funzionano? Quali colori vendono, quali taglie finiscono per prime, quali combinazioni non si muovono mai.

È al secondo livello che si trovano le scoperte interessanti. Risponde a domande che interessano al merchandising: il navy vende tre volte più del charcoal? Le varianti in taglia L convertono meglio perché sono sempre disponibili? C'è un colore che abbassa la media del gruppo?

Metriche da monitorare per ogni gruppo:

Una nota sull'attribuzione. Spesso un acquirente vede l'annuncio di una variante e ne compra un'altra: clicca sul navy, compra il charcoal. Il ROAS a livello di variante preso alla lettera attribuirà quindi in modo errato. Valuta i prodotti a livello di gruppo; usa i dati delle varianti per capire i comportamenti, non per prendere decisioni sulle offerte basate su campioni ridotti.

12. Checklist prima del lancio

Eseguila prima di pubblicare un feed di varianti e dopo qualsiasi modifica strutturale.

Struttura

•  Ogni variante ha un id univoco
•  Tutti i membri di un gruppo condividono un item_group_id identico
•  item_group_id è ricavato da un campo sorgente stabile e non cambia tra un'esportazione e l'altra
•  item_group_id usa maiuscole e minuscole in modo coerente in tutto il feed
•  Ogni membro differisce per almeno un attributo che definisce la variante
•  item_group_title è presente e identico in tutto il gruppo

Attributi

•  color usa nomi di colore semplici: niente codici esadecimali, numeri o lettere singole
•  I colori multipli sono separati da /, con il principale per primo
•  I valori di size sono normalizzati in tutto il catalogo
•  size_system è dichiarato quando vendi in aree con sistemi di taglie diversi
•  gender e age_group sono identici all'interno di ogni gruppo
•  material e pattern sono compilati quando definiscono la variazione

Link e immagini

•  Il link di ogni variante porta allo stato preselezionato corretto
•  & è codificata come &amp; nell'XML
•  image_link è specifica della variante, non un'immagine principale condivisa
•  Le immagini rispettano le dimensioni minime di ogni canale

Trasformazioni per canale

•  Sintassi di availability adattata a ogni canale (in_stock o in stock)
•  Limiti di caratteri rispettati per ogni canale
•  Le esportazioni verso Amazon creano le inserzioni parent e dichiarano un variation theme valido
•  Insiemi di attributi dei marketplace regionali mappati per categoria

Operatività

•  La frequenza di aggiornamento corrisponde alla velocità reale di movimento dello stock
•  Il rilevamento delle taglie mancanti viene eseguito a ogni sincronizzazione
•  Il controllo degli id duplicati viene eseguito prima dell'esportazione
•  Il feed viene validato come XML/CSV ben formato prima della pubblicazione
•  Sono configurati avvisi per i cali improvvisi del numero di prodotti

13. FAQ

Devo inviare ogni singola variante? Non sempre, ma di solito sì per abbigliamento e calzature, dove taglia e colore sono la decisione d'acquisto. Per cataloghi molto grandi e omogenei, o per canali che filtrano i quasi duplicati, inviare per ogni gruppo una sola variante rappresentativa ben scelta può rendere di più. Scegli la variante rappresentativa in base a performance di vendita e stock, non in ordine alfabetico.

Cosa succede se ometto item_group_id? Ogni variante viene trattata come un prodotto a sé stante. Perdi il selettore di varianti sulla superficie di destinazione, gli annunci diventano ripetitivi, la reportistica a livello di variante si rompe e su Google potresti non rispettare un requisito: item_group_id è obbligatorio per le schede senza costi e per gli annunci Shopping in diversi mercati principali quando vengono inviate varianti.

Le varianti possono avere prezzi diversi? Sì. Il prezzo non è un attributo che definisce la variante, ma può legittimamente differire da una variante all'altra: le taglie più grandi spesso costano di più. Il prezzo inviato deve corrispondere a quello mostrato dalla landing page per quella specifica variante.

Le varianti esaurite devono restare nel feed? In generale sì. Mantienile con availability: out_of_stock invece di eliminarle. Rimuoverle e aggiungerle di nuovo azzera lo storico dell'articolo nel canale. Escludile invece dalle campagne attive con una regola o una custom label.

Un prodotto può appartenere a due gruppi? No. item_group_id accetta un solo valore per articolo. Se un prodotto appartiene davvero a due gruppi concettuali, hai un problema di tassonomia del merchandising da risolvere a monte.

Mi servono valori di item_group_id diversi per ogni canale? No, e non dovresti usarli. Usa lo stesso raggruppamento logico ovunque. Ciò che cambia da un canale all'altro è la trasformazione applicata: limiti di caratteri, maiuscole/minuscole, sintassi. Mantieni un'unica fonte di verità e adattala in fase di esportazione.

Come gestisco i prodotti davvero a taglia unica? Invia size come one_size, OS oppure OSFA. Non lasciarlo vuoto per l'abbigliamento nei mercati in cui la taglia è obbligatoria.

Versione uomo e versione donna dello stesso design: un gruppo o due? Due. gender deve essere identico in tutto il gruppo. Tagli e taglie diversi li rendono prodotti diversi dal punto di vista dell'acquirente.

Cosa si rompe più spesso nella pratica? Nei nostri audit: immagini principali condivise tra varianti di colore, valori di item_group_id rigenerati a ogni esportazione e sintassi di availability riportata senza modifiche da un feed Google a Meta. Tutti e tre sono invisibili nell'interfaccia ed emergono solo come performance inferiori senza spiegazione.

A che punto sei

I feed di varianti premiano la precisione come poche altre cose nel marketing digitale. In item_group_id non c'è spazio per il giudizio creativo: o è stabile e condiviso, o non lo è. I valori di colore o seguono la specifica, o vengono rifiutati. Le immagini o corrispondono alla variante, o il clic è stato sprecato.

La buona notizia è proprio questa: è un problema risolvibile con una risposta precisa. Il lavoro sta nel mantenerlo nel tempo, perché i cataloghi cambiano ogni giorno, lo stock si muove ogni ora e ogni canale aggiorna la propria specifica con i propri tempi.

Le aziende che lo fanno bene trattano il feed di varianti come un'infrastruttura e non come un file. Ricavano gli ID di gruppo da dati sorgente stabili, normalizzano gli attributi una volta sola alla fonte, applicano le trasformazioni per canale in fase di esportazione, ricalcolano la salute dello stock a ogni sincronizzazione e ricevono avvisi quando qualcosa si muove in modo inatteso.

È esattamente il livello per cui è costruito Feedance: regole del feed per normalizzare gli attributi alla fonte, rilevamento delle taglie mancanti ricalcolato a ogni sincronizzazione, arricchimento con GA4 per mantenere aggiornate le etichette di performance ed esportazioni verso i canali che applicano la trasformazione giusta per ciascuna delle oltre 200 destinazioni senza toccare i tuoi dati sorgente.

Se vuoi sapere a che punto è la struttura delle tue varianti prima di cambiare qualcosa, il nostro strumento gratuito di audit del feed valuta gratuitamente un feed esistente per completezza, qualità dei dati e salute tecnica, compreso il raggruppamento delle varianti.