Den kompletta guiden till produktvariantflöden

De flesta flödesproblem ser inte ut som flödesproblem. De ser ut som ett ogillande i Google Merchant Center som du inte kan förklara, en Advantage+-kampanj som spenderar sin budget på en enda svart t-shirt, eller en Shopping-annons som skickar en kund som letar efter en sko i storlek 42 till en sida där bara storlek 38 finns kvar.

Under nästan alla dessa ligger samma sak: varianter.

En variant är vilken version som helst av en produkt som skiljer sig åt på ett synligt, köpbart sätt – storlek, färg, material, kapacitet, finish. De är vanliga i detaljhandeln och ovanligt svåra i flöden, eftersom varje kanal modellerar dem olika, och eftersom det i tysthet misslyckas att göra fel. Ingenting går sönder. Dina annonser presterar bara i tysthet underpresterande, och diagnosen lever fyra lager längre ner i en datafil som ingen öppnar.

Den här guiden täcker hela ämnet: vad som faktiskt räknas som en variant, hur item_group_id fungerar och var folk missbrukar det, varje variantdefinierande attribut med dess verkliga begränsningar, exempel på fungerande flöden i XML, CSV och JSON, hur Google, Meta, TikTok, Pinterest, Amazon och regionala marknadsplatser förväntar sig att varianter ska vara strukturerade, och en diagnostisk tabell för de fel som dyker upp oftast.

Den är lång eftersom ämnet är det. Använd innehållsförteckningen för att hoppa.

1. Vad en variant egentligen är

En variant är en köpbar version av en produkt som skiljer sig från sina syskon i minst en egenskap som en kund skulle välja mellan, samtidigt som den förblir samma produkt.

Den sista klausulen gör en hel del jobb. En blå t-shirt i mellanstorlek och en svart t-shirt i stor storlek är samma produkt. En blå t-shirt och en blå hoodie är det inte, inte ens från samma märke i samma tyg.

Standardmodellen för de flesta kanaler är förälder/barn :

• Ocuco-landskapet förälder är den konceptuella produkten — "Merino Crew Neck Sweater". Den går vanligtvis inte att köpa separat.
• Ocuco-landskapet barn är varianterna – var och en med sin egen SKU, sin egen lagernivå, ibland sitt eget pris och sin egen image.

I ett produktflöde uttrycks detta nästan alltid flatt : varje variant är en egen rad eller <artikel>, och en delad grupperingsnyckel binder samman dem. Det finns ingen kapsling. En tröja i 4 färger och 5 storlekar är 20 rader, alla med samma grupp-ID.

Vad är inte en variant

Det är här flöden blir fel innan en enda rad XML har skrivits.

Att gruppera någon av dessa under ett delat item_group_id skapar en grupp vars medlemmar inte är utbytbara – vilket förvirrar variantväljaren på destinationssidan och, på vissa kanaler, utlöser ett underkännande på grund av felmatchning.

2. Beslutet som avgör allt

Innan du skriver någon flödeslogik, svara på en fråga för varje produkttyp du säljer:

När en kund väljer ett annat alternativ, landar de på en annan sida – eller samma sida i ett annat tillstånd?

Detta är det praktiska testet, och det visar direkt hur du bör strukturera flödet.

Fall A — separata webbadresser per variant. Varje färg har sin egen produktsida (/merino-tröja-marinblå, /merino-tröja-grön). Skicka varje variant som en egen rad med en egen länk. Detta är den renaste konfigurationen, ger bäst annonsrelevans och är vad kanalerna föredrar.

Fall B — en URL, variant vald på sidan. Allt finns på /merino-tröja och kunden väljer färg och storlek med en väljare. Du kan fortfarande skicka alla varianter, men du bör lägga till en djuplänksparameter så att annonsen landar i rätt förvalt tillstånd:

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

Utan den parametern kommer en kund som klickar på en annons för en marinblå medium-annons att få ett standardläge som visar charcoal small. Den missmatchningen är en av de största orsakerna till tysta konverteringar i variantannonsering, och på Google kan den också utlösa ett underkännande av "Felmatchande värde (sidgenomsökning)" , eftersom sökroboten ser en sida vars synliga färg inte matchar den inskickade färgen.

Fall C — varianter som inte är värda att dela upp. Vissa varianter påverkar inte köpbeslutet tillräckligt för att motivera separata annonser — till exempel kabellängden på en laddare. Här kan du medvetet skicka en representativ variant. Avsnitt 7 tar upp när detta är rätt beslut.

Variantdefinierande kontra beskrivande attribut

Varje attribut i ditt flöde faller inom en av två kategorier, och att blanda ihop dem är en vanlig orsak till felaktigt utformade grupper.

Variantdefinierande attribut måste skilja sig åt mellan medlemmarna i gruppen. Det här är de saker kunden väljer: färg, storlek, material, mönster, plus produktspecifika dimensioner som kapacitet eller finish.

Gruppkonstantattribut måste vara identiska för varje medlem: brand, gender, age_group, item_group_title, google_product_category. Om två rader delar ett item_group_id men har olika gender-värden har du antingen grupperat produkterna fel eller taggat dem fel.

Radspecifika men inte variantdefinierande attribut varierar per rad utan att definiera varianten: id, price, availability, gtin, image_link, link. Två varianter kan legitimt ha olika priser – en storlek 3XL kostar ofta mer – utan att priset är det som skiljer dem åt.

3. item_group_id: stiftelsen

item_group_id är den delade nyckeln som talar om för en kanal att "dessa rader är samma produkt". Allt annat gällande varianthantering beror på att den är korrekt.

Specifikationen

Eftersom Google behandlar värdet okänsligt för versaler och skiftlägen, men inte Meta och TikTok, standardisera användningen av gemener (eller versaler) överallt. En katalog där både SWTR-001 och swtr-001 visas kommer att grupperas korrekt på Google och delas upp i två produkter på Meta.

Att välja värde

Det bästa item_group_id:t är den överordnade SKU som du redan har i ditt ERP- eller PIM-system. Den existerar, är stabil och unik.

Bra:

SWTR-MERINO-CREW
12345
parent-8891

Dåligt, och varför:

Det sista förtjänar att betonas. item_group_id måste vara stabilt över tid. Kanaler ackumulerar prestationshistorik mot gruppen. Om din export genererar ID:n återställer du den historiken vid varje synkronisering, och ingen mängd budoptimering kommer att kompensera.

De tre reglerna

1. Varje medlem i en grupp delar samma item_group_id.
2. Varje medlem har ett unikt ID. Ett dubblett-ID någonstans i flödet gör att den senare raden tas bort tyst.
3. Varje medlem skiljer sig åt i minst ett variantdefinierande attribut. Två rader med samma grupp-ID och samma färg och storlek är dubbletter, inte varianter.

En konvention som uppfyller alla tre:

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

Läsbar, felsökningsbar, härledd från data du redan har.

artikelgrupptitel

Ett nyare Google-attribut, valfritt men rekommenderat när du skickar in item_group_id. Det innehåller namnet på den överordnade produkten – max 150 tecken – och måste vara identiskt för varje variant i gruppen.

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>

Observera mönstret: titeln är variantspecifik, item_group_title är det inte. Att skicka samma sträng i båda slösar bort signalen.

variant_alternativ

Även nyare på Googles sida: ett strukturerat sätt att deklarera vilka egenskaper som definierar variationen, snarare än att låta kanalen härleda den. Den accepterar upp till 30 namn/värde-par (varje underattribut upp till 250 tecken, totalt 5 000 tecken).

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>

Detta är särskilt användbart för produkter vars variationsaxlar inte täcks av standardattributen för klädsel – lagringskapacitet, processornivå, effekt, antal platser. Istället för att tvinga fram "256 GB" i storleken deklarerar du den korrekt.

4. Variantdefinierande attribut, i detalj

färg

Det mest regelbundna attributet i specifikationen, och det som oftast avvisas.

Inte accepterat:

• Siffror — Färg 42, RAL 5013
• Hexkoder — #001F5B
• Enskilda bokstäver — N för marinblå
• Referenser till en bild — se foto
• Alfanumeriska eller sammanfogade ord — Marinblå1, Marinblå (skriv Marinblå)

Hantera marknadsföringsfärgnamn. Modemärken kallar sällan färger för "marinblå". De kallar dem för "Midnight Regatta". Kanalen behöver en färg som en kund skulle söka efter; ditt varumärke behöver ett eget namn på sidan.

Den fungerande kompromissen:

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

Mappa marknadsföringsnamn till standardnamn i flödet och håll varumärkesnamnet synligt på landningssidan och i beskrivningen. Använd inte marknadsföringsnamnet i färg och hopp – det försämrar matchningen för färgkvalificerade sökfrågor, vilka är bland de mest avancerade sökningarna inom kläder.

Flerfärgade produkter:

color: Navy/White/Grey

Primär först. Google läser det första värdet som den dominerande färgen.

Storlek

Regeln som är viktig: var tillräckligt specifik för att vara entydig och konsekvent i hela katalogen. M är okej om varje produkt använder M. En foderblandning av M, Medium, Med och M/L för samma koncept fragmenterar dina variantgrupper och gör storleksbaserad segmentering omöjlig.

För produkter där en enda dimension inte räcker till, inkludera de utmärkande måtten i värdet:

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

storlekstyp och storlekssystem

Valfritt, endast kläder och underanvända – båda förbättrar matchningen avsevärt för kunder som söker med dessa kvalificeringsalternativ.

size_type — upp till 2 värden från: regular, petite, mammastorlek, stor, lång, plus.

size_system — ett av: US, UK, EU, DE, FR, JP, CN, IT, BR, MEX, AU. Om det utelämnas antar kanalen mållandets system, vilket är källan till ett specifikt och dyrt fel: en turkisk återförsäljare som säljer till Tyskland med EU-storlekar men inget deklarerat size_system kan ha storlekar tolkade mot fel skala.

xml

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

Materialet

Max 200 tecken på Google. Primärt material först, sedan upp till två sekundärt material separerat med /.

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

Krävs endast om det skiljer dina varianter åt — en väska som säljs i läder och canvas. Annars valfritt men värt att skicka in; material är en vanlig sökkvalificering.

mönster

Max 100 tecken. Fri text som beskriver trycket eller grafiken: Randig, Prickig, Paisley, Blommig, Fiskbensmönster. Samma regel — krävs om det är det som varierar.

åldersgrupp och kön

Båda är gruppkonstanter . Varje variant i en grupp måste ha samma värde.

åldersgrupp: nyfödd, spädbarn, småbarn, barn, vuxen — ett värde per produkt.

kön: man, kvinna, unisex.

Om ett plagg verkligen erbjuds i herr- och dammodeller är det två separata varugrupper , inte en grupp med blandade kön. Modellerna skiljer sig åt, storlekarna skiljer sig åt och kunden väljer mellan produkter snarare än mellan alternativ.

Referenstabell

5. Exempel på riktiga flöden

XML (Google RSS 2.0)

Två varianter av en grupp med sex varianter. Notera vad som ändras och vad som inte gör det.

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>

Fyra saker värda att påpeka:

1. item_group_id och item_group_title är identiska; id och titel är det inte.
2. länken innehåller djuplänksparametrar så att annonsen landar på rätt förvald status. &-tecknet escapes eftersom & — krävs i XML, och en vanlig källa till parsningsfel.
3. image_link är variantspecifik. Båda marinblå raderna pekar på det marinblå fotografiet. Att skicka en hjältebild för alla färger är det näst vanligaste variantmisstaget efter saknade grupp-ID:n.
4. Raden för slut i lager är taggad via custom_label_1, så att den kan exkluderas eller bjudas ned utan att ta bort den från flödet.

CSV / TSV

Samma data, utplattade. Rubrikrad plus två varianter:

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

Det är i CSV som de flesta databrott sker i verkliga fält, eftersom kommatecken i titlar och beskrivningar måste citeras, och citat i citatfält måste escapeas. Om dina titlar innehåller kommatecken – och produkttitlar med färg och storlek nästan alltid gör det – använd TSV istället. Tabbar visas praktiskt taget aldrig i produktdata, och en hel klass av parsningsbuggar försvinner.

JSON

För API-baserad inmatning:

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"
    }
  ]
}

En fullstor löprunda

Sex varianter — två färger × tre storlekar — med ID-mönstret synligt:

Träkol har en storlek kvar på tre. Avsnitt 9 tar upp vad man ska göra åt det.

6. Kanal för kanal

Konceptet är universellt. Implementeringen är det inte. Här är hur varje större destination förväntar sig varianter, och var varje enskild skiljer sig åt.

Google Shopping / Merchant Center

Den mest föreskrivande, och referensimplementeringen som de flesta andra kanaler lånar från.

• item_group_id är Obligatorisk för gratisannonser och för Shopping-annonser i Brasilien, Frankrike, Tyskland, Japan, Storbritannien och USA, närhelst varianter skickas in.
• Variantdefinierande attribut måste fyllas i: färg och storlek krävs för kläder på dessa marknader.
• Kön och åldersgrupp är obligatoriska för kläder och måste vara konsekventa i hela gruppen.
• Landningssidan måste synligt matcha de inskickade variantvärdena, annars riskerar du en Felmatchande värde (sidgenomsökning) ogillande.
• Varje variant tävlar oberoende i auktionen. Google väljer vilken medlem i en grupp som ska visas för en given sökfråga, så en ofullständig grupp innebär en svagare kandidatpool.
• image_link måste vara minst 500×500 pixlar för kläder — ett minimum gäller från och med 31 januari 2027värt att granska nu snarare än i all hast.

Praktisk anmärkning: Merchant Center rapporterar på variantnivå (id), inte gruppnivå. För att utvärdera en produkt korrekt måste du själv aggregera efter item_group_id – vilket är mycket enklare om grupp-ID:t är rent och stabilt.

Meta (Facebook och Instagram)

Meta använder samma fältnamn med andra begränsningar och en väsentligt annorlunda visningsmodell.

• item_group_id tillåter upp till 100 tecken och är skiftlägeskänsliga.
• färg och storlek tillåter upp till 200 tecken.
• Användning av tillgänglighetsvärden mellanslag, inte understreck: i lager, inte i_lager. Denna enda skillnad gör att fler metaflöden bryts än någon annan, särskilt när ett Google-flöde återanvänds direkt.
• I butiker och på produktdetaljytor renderas en korrekt grupperad uppsättning som en produkt med en variantväljare, snarare än flera nästan identiska listningar.
• Katalogannonser i Advantage+ använder gruppen för att undvika att visa en användare sex versioner av samma tröja i en karusell – en ogrupperad katalog producerar synbart repetitiva annonser och slösade visningar.
• Variantnivårapportering i Commerce Manager är beroende av korrekt gruppering.

Praktisk anmärkning: Peka inte Meta mot ditt Google-flöde omodifierat. Kontrollera som ett minimum transformationstillgänglighet och teckenbegränsningarna. De flesta flödesplattformar – inklusive Feedance – hanterar detta som en transformation på kanalnivå så att källdata förblir orörd.

TikTok

• item_group_id tillåter upp till 150 tecken.
• sku_id är den unika identifieraren per variant — varje variantrad behöver ett distinkt värde.
• Färg och storlek tillåter upp till 200 tecken.
• Titeln får vara upp till 255 tecken lång, beskrivningen får vara upp till 10 000 tecken lång; google_product_category förväntas.
• TikTok är den strängaste kanalen gällande variantspecifika bilderProduktkort visar en variantväljare, och varianter som delar en enda generisk bild presterar mätbart sämre. Om du tar bort ett hörn i din bildpipeline, ta inte bort det här.

Pinterest

• Följer Googles modell noggrant; item_group_id grupperar varianter.
• Pinterest visar varianter inuti en enda produkt-pin med valbara alternativ.
• Bildkvalitet och vertikala bildförhållanden spelar oproportionerligt stor roll – Pinterest är en yta för visuell upptäckt, och variantbilder som inte är distinkta sparas helt enkelt inte.

Amazon

Amazon använder inte item_group_id, och att anta något annat orsakar en hel del slöseri med arbete.

Amazon använder en explicit förälder/barn-relationsmodell :

• A överordnat ASIN skapas som en icke-köpbar annons.
• Varje underordnat ASIN refererar till föräldern genom fälten parent_sku / parent_child.
• A variationstema måste deklareras — SizeColor, Size, Color, SizeName-ColorName och så vidare, varierande beroende på kategori.
• Temat måste vara giltigt för den specifika kategorin; samma temanamn är inte tillgängligt överallt.

Om du exporterar till både Google och Amazon från en och samma källa, behandla detta som en genuin omvandling, inte ett namnbyte av fältet. Ditt flödeslager måste konstruera den överordnade listan, tilldela temat och mappa underordnade till den.

Regionala marknadsplatser och jämförelsemotorer

Turkiska och övriga Mellanöstern- och Nordöstra Afrika (MENA) kanaler har sina egna konventioner, och de är ofta skillnaden mellan en fungerande och en trasig katalog på dessa marknader.

• Trendyol använder sin egen förälder-/undermodell med en obligatorisk kategorispecifik attributuppsättning. Färg och storlek är separata strukturerade fält, och obligatoriska attributlistor skiljer sig åt beroende på kategori.
• Akakçe och Girig är prisjämförelsemotorer. De förväntar sig vanligtvis en rad per köpbar SKU, och dubbletter av nästan identiska rader tenderar att filtreras – så att skicka en fullstor körning utan differentierad data kan minska snarare än öka synligheten.
• Hepsiburada och N11 var och en definierar sina egna variantgrupperingsnycklar och obligatoriska attribut.

Det här är området där generiska globala flödesverktyg oftast inte når upp till förväntningarna, och där ett felmappat attribut i tysthet tar bort en hel kategori från en marknadsplats.

Jämförelse

7. Splittras eller kollapsar?

Att skicka alla varianter är standardrekommendationen, men det är inte universellt korrekt. Den verkliga frågan är om varianten förändrar vad köparen vill ha.

Skicka varje variant när…

• Variationen är köpbeslutet. Kläder, skor, allt där fel storlek inte är en rea.
• Lagerhalten skiljer sig avsevärt mellan olika varianter. Att annonsera en produkt vars enda återstående alternativ är storlek 3XL är slöseri med pengar.
• Priset varierar beroende på variant. Att visa 89 euro när det valda alternativet kostar 119 euro skapar en prismatch och en arg kund.
• Sökefterfrågan är variantkvalificerad. Folk söker efter "marinblå merinotröja medium". Du kan inte ranka för det utan att skicka in det.

Minimera till en representativ variant när…

• Katalogen är mycket omfattande och i stort sett homogen. En järnvaruhandlare med 200 000 SKU:er där 60 % är triviala längdvariationer vinner lite på full expansion och betalar för det i flödesbearbetning och kampanjkomplexitet.
• Kanalen bestraffar nästan dubbletter. Flera jämförelsemotorer filtrerar repetitiva rader; en körning i full storlek kan minska synligheten.
• Variationer påverkar inte pris, bild eller tillgänglighet. Om alla tolv varianter är identiska på alla kommersiellt relevanta sätt, skapar tolv rader brus snarare än signal.

När du komprimerar, välj representanten medvetet: den bäst säljande varianten i lager , inte den första raden i alfabetisk ordning. Det är precis här prestandadata förtjänar sin plats i flödet – GA4- eller plattformsdata kan välja representanten automatiskt istället för att låta den sorteras.

En medelväg

Dela på axeln som driver beslutet; kollaps på den som inte gör det.

För skor betyder det vanligtvis en rad per färg, med storlekarna hopfällda – färgen är identifieringsaxeln, storleken är passformskontrollen som sker på sidan. För en produkt där kapacitet styr priset, dela upp efter kapacitet och hopfäll efter färg.

8. De 12 vanligaste variantfelen

Felen 1, 2, 4 och 11 står för den stora majoriteten av vad vi ser i verkliga revisioner. Inget av dem är svårt; alla är osynliga förrän någon tittar.

9. Trasiga storlekar och lagerstatus

En trasig storlek är en produkt vars grupp tekniskt sett är aktiv men praktiskt taget osäljbar – en tröja som endast finns i XS och 3XL, en sko med två storlekar kvar av nio.

Detta spelar större roll än det verkar. När en kund klickar på en annons för en produkt och upptäcker att deras storlek inte är tillgänglig, har du betalat för ett klick som inte kunde konverteras, och du har spenderat varumärkesgoodwill på att göra det. I stor skala kan produkter med trasig storlek sluka en betydande del av budgeten samtidigt som de nästan inte bidrar till intäkterna.

Upptäcka det

Beräkna, per item_group_id:

size_availability_ratio = in_stock_variants / total_variants

Agera sedan utifrån tröskelvärdena. En fungerande utgångspunkt:

Vikta detta efter behov , inte bara antal. Att gå ner XXS och XXL spelar mycket mindre roll än att gå ner M och L, som vanligtvis utgör huvuddelen av volymen. Ett förhållande som behandlar alla storlekar lika kommer att underreagera på förlusten av dina core-storlekar.

Agera utifrån det

Den renaste implementeringen taggar villkoret i flödet snarare än att ta bort produkten:

xml

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

Att tagga istället för att ta bort bevarar produktens historik i kanalen och låter dig återaktivera den direkt när lagret återkommer. Att ta bort och lägga till igen återställer inlärningen.

Två ytterligare förbättringar som är värda att bygga vidare på:

• Återkoppla till varumarknadsföringen. En återkommande trasig lista är en köpsignal, inte bara ett reklamproblem.
• Kontrollera igen vid varje synkronisering. Lagret flyttas; taggen måste flyttas med. En statisk lista med trasig storlek är värre än ingen alls, eftersom den undertrycker produkter som sedan dess har fyllts på.

10. Använda varianter för kampanjsegmentering

När varianterna är korrekt strukturerade blir informationen ett segmenteringslager – förmodligen den mest avkastande användningen av ett rent variantflöde.

Google tillhandahåller fem custom_label-fält (0–4). De accepterar godtyckliga värden och finns enbart för din egen kampanjlogik. Variantdata är idealisk indata.

Ett fungerande system

Med dessa på plats blir kampanjlogiken enkel:

• Bjud upp bästsäljare + full upplaga + hög marginal
• Exkludera trasig storlek från prospektering
• Ge försäljning en egen kampanj med en aggressiv tROAS
• Isolera ss26 när säsongen börjar

Performance Max och Advantage+

Båda är till stor del automatiserade, vilket gör segmentering på flödesnivå viktigare snarare än mindre. Du kontrollerar inte längre budgivning på sökordsnivå, så flödet blir din främsta hävstång för att styra utgifter.

I Performance Max styr anpassade etiketter strukturen för tillgångsgrupper och listgrupper . Att dela upp en enda samlad tillgångsgrupp i marginalbaserade eller aktiebaserade grupper är en av få återstående strukturella hävstångseffekter, och det är helt beroende av att etiketter fylls i från verkliga data.

I Advantage+ katalogannonser förhindrar korrekt gruppering att karusellen fylls med sex nyanser av samma tröja – och produktuppsättningsdefinitioner som bygger på variantattribut låter dig separera prospektering från retargeting-annonsering.

Berika etiketter med prestandadata

Statiska etiketter förfaller. Bästsäljare som tilldelades förra säsongen är felaktig information denna säsong.

Den starkare implementeringen beräknar om etiketter från liveprestandadata – GA4-intäkter, konverteringsfrekvens, visningsantal – vid varje flödessynkronisering. En produkt som slutar sälja försvinner automatiskt från bästsäljarlistan; en som börjar sälja hamnar i den. Detta är en central del av vad flödesberikning innebär i praktiken, och det är skillnaden mellan etiketter som styr budgeten och etiketter som bara beskriver förra kvartalet.

11. Mätning av variantprestanda

Det är data på variantnivå som den mesta rapporteringen tyst faller isär.

Aggregeringsproblemet. Merchant Center och Ads-rapporter på ID-nivå. En tröja i 20 varianter visas som 20 rader, var och en med en bråkdel av volymen, ingen individuellt signifikant. Alla slutsatser som dras från en enskild variantrad är förmodligen brus.

Analysera alltid på två nivåer:

1. Gruppnivå (artikelgrupps-id) — gör detta produkt fungerar? Sammanlagda utgifter, konverteringar och intäkter för alla medlemmar.
2. Variantnivå (id) — vilket alternativ fungerar? Vilka färger säljer, vilka storlekar tar slut först, vilka kombinationer ändras aldrig.

Det andra är där de intressanta resultaten finns. Det besvarar frågor som varuhandeln bryr sig om: säljer marinblått tre gånger mer än antracitgrå? Konverterar storlek L-varianter bättre eftersom de alltid finns i lager? Drar en färg ner gruppens genomsnitt?

Mätvärden värda att följa per grupp:

En anmärkning om attribution. En kund ser ofta en annons för en variant och köper en annan – klickar på den marinblå färgen och köper den antracitgröna. ROAS på variantnivå, tagen bokstavligt, kommer därför att felattributionera. Bedöm produkter på gruppnivå; använd variantdata för att förstå beteende, inte för att fatta budbeslut på tunna prover.

12. Checklista före lansering

Kör detta innan du publicerar ett variantflöde, och efter eventuella strukturella förändringar.

Structure

•  Varje variant har ett unikt id
•  Varje medlem i en grupp delar ett identiskt item_group_id
•  item_group_id härleds från ett stabilt källfält och ändras inte mellan exporter
•  item_group_id använder konsekvent gemener och skiftläge i hela flödet
•  Varje medlem skiljer sig åt i minst ett variantdefinierande attribut
•  item_group_title finns och är identisk i hela gruppen

attribut

•  färg använder vanliga färgnamn — inga hexagoner, siffror eller enstaka bokstäver
•  Flera färger separeras med /, primärfärger först
•  Storleksvärdena normaliseras över hela katalogen
•  size_system deklareras där du säljer över olika storleksregioner
•  kön och åldersgrupp är identiska inom varje grupp
•  material och mönster är ifyllda där de definierar variationen

Länkar och bilder

•  Varje variants länk omvandlas till rätt förvald status
•  & escapes som & i XML
•  image_link är variantspecifik, inte en delad huvudbild
•  Bilderna uppfyller minimimåtten för varje kanal

Kanaltransformationer

•  tillgänglighetssyntax justerad per kanal (i lager vs. i lager)
•  Teckengränser respekteras per kanal
•  Amazon-exporter bygger överordnade listningar och deklarerar ett giltigt varianttema
•  Regionala marknadsplatsattributuppsättningar mappade per kategori

Operationer

•  Uppdateringsfrekvensen matchar hur snabbt lagret faktiskt rör sig
•  Detektering av trasig storlek körs vid varje synkronisering
•  Kontroll av dubblett-ID körs före export
•  Flödet validerar som korrekt formaterad XML/CSV innan publicering
•  Aviseringar är konfigurerade för plötsliga minskningar av produktantalet

13. FAQ

Måste jag skicka in varje enskild variant? Inte alltid, men oftast ja för kläder och skor, där storlek och färg är det avgörande köpbeslutet. För mycket stora homogena kataloger, eller kanaler som filtrerar bort nästan dubbletter, kan det ge bättre resultat att skicka in en väl vald representativ variant per grupp. Välj representativ variant efter försäljningsprestanda och lager, inte alfabetiskt.

Vad händer om jag utelämnar item_group_id? Varje variant behandlas som en orelaterad produkt. Variantväljaren försvinner på destinationsytan, annonserna blir repetitiva, rapporteringen på variantnivå avbryts och på Google kan du misslyckas med ett krav – item_group_id krävs för gratisannonser och för Shopping-annonser på flera större marknader när varianter skickas in.

Kan varianter ha olika priser? Ja. Priset är inte ett variantdefinierande attribut, men det kan legitimt skilja sig mellan olika varianter – större storlekar kostar ofta mer. Det angivna priset måste matcha vad landningssidan visar för den specifika varianten.

Bör varianter som är slut i lager finnas kvar i flödet? Generellt sett ja. Behåll dem med tillgänglighet: out_of_stock istället för att ta bort dem. Att ta bort och lägga till igen återställer artikelns historik i kanalen. Exkludera dem från aktiva kampanjer med hjälp av en regel eller anpassad etikett istället.

Kan en produkt tillhöra två grupper? Nej. item_group_id accepterar ett enda värde per artikel. Om en produkt verkligen tillhör två konceptuella grupper har du ett problem med varuhanteringstaksonomi att lösa uppströms.

Behöver jag separata item_group_id-värden per kanal? Nej – och det borde du inte. Använd samma logiska gruppering överallt. Det som skiljer sig per kanal är den transformation som tillämpas på den: teckenbegränsningar, gemener och versaler, syntax. Behåll en sanningskälla och anpassa vid export.

Hur hanterar jag produkter som verkligen är one size? Skicka in storlek som one_size, OS eller OSFA. Lämna inte fältet tomt för kläder på marknader där storlek krävs.

Herr- och damversioner av samma design – en grupp eller två? Två. Kön måste vara identiska i en grupp. Olika snitt och olika storlekar gör dem till olika produkter ur köparens perspektiv.

Vad går oftast sönder i praktiken? I våra granskningar: delade huvudbilder över olika färgvarianter, regenererade item_group_id-värden vid varje export och tillgänglighetssyntax som överförs oförändrad från ett Google-flöde till Meta. Alla tre är osynliga i gränssnittet och dyker bara upp som oförklarlig underprestanda.

Var detta lämnar dig

Variantflöden belönar precision på ett sätt som den mesta digitala marknadsföringen inte gör. Det finns inget kreativt omdöme i item_group_id – antingen är det stabilt och delat, eller så är det inte det. Färgvärden följer antingen specifikationen, eller så avvisas de. Bilderna matchar antingen varianten, eller så var klicket bortkastat.

Det är den goda nyheten: detta är ett lösbart problem med en definitiv lösning. Arbetet ligger i att underhålla det – eftersom kataloger ändras dagligen, lagret rör sig varje timme och varje kanal justerar sina specifikationer enligt sitt eget schema.

De företag som lyckas med detta behandlar variantflödet som infrastruktur snarare än en fil. De härleder grupp-ID:n från stabila källdata, normaliserar attribut vid källan, transformerar per kanal vid export, beräknar om lagerstatus vid varje synkronisering och varnar när något oväntat rör sig.

Det är precis det lagret Feedance är byggt för – flödesregler för normalisering av attribut vid källan, detektering av trasig storlek som beräknas om vid varje synkronisering, GA4-berikning för att hålla prestandaetiketter aktuella och kanalexporter som tillämpar rätt transformation för var och en av över 200 destinationer utan att röra din källdata.

Om du vill veta hur din egen variantstruktur ser ut innan du ändrar något, kan vårt kostnadsfria verktyg för flödesgranskning bedöma ett befintligt flöde utifrån fullständighet, datakvalitet och teknisk hälsa – inklusive variantgruppering – utan kostnad.