· Av Erik Svedin
Så fungerar en Google Shopping-feed för en butik med kassa och webbshop: fält, varianter, EAN, lokalt lager i Merchant Center och de vanligaste avslagen.
En Google Shopping-feed är en fil eller ett automatiskt flöde som talar om för Google Merchant Center vilka produkter butiken säljer, vad de kostar, om de finns i lager och hur de ser ut. Feeden är det som gör att produkterna visas i fliken Shopping, i Googles gratislistningar och i Shopping-annonser, och den är också underlaget för att visa lagersaldo i den fysiska butiken på Google Maps. Principen är densamma oavsett om butiken säljer cyklar, skor, verktyg eller husgeråd: feeden är en spegel av artikelregistret, och den blir aldrig bättre än datan bakom. Den här sidan går igenom fälten, varianterna, uppdateringen, det lokala lagret och de fel som oftast stoppar en feed.
Feeden är en tabell där varje rad är en säljbar produkt och varje kolumn är ett attribut som Google definierat. Den kan levereras som en TSV- eller XML-fil som Google hämtar från en adress på schema, som ett Google Sheet, eller direkt via Merchant Centers API från webbshoppen. Abicart, WooCommerce, Shopify och de flesta andra webbshopsplattformar kan producera en feed, antingen inbyggt eller via tillägg. Saknas EAN-kod, bild eller varumärke i kassan eller webbshoppen, saknas de i feeden, och då är det registret som ska rättas, inte feeden.
Google skiljer på obligatoriska attribut, som stoppar produkten om de saknas, och rekommenderade, som påverkar hur ofta produkten visas.
| Attribut | Krav | Vad det betyder i praktiken |
|---|---|---|
| id | Obligatoriskt | Butikens artikelnummer. Måste vara unikt och får inte ändras när produkten uppdateras |
| title | Obligatoriskt | Märke, modell och det som skiljer varianten, till exempel storlek eller färg |
| description | Obligatoriskt | Produkttexten. Leverantörens text går, men en egen text ger bättre matchning |
| link | Obligatoriskt | Produktsidan i webbshoppen, en per variant |
| image_link | Obligatoriskt | Huvudbild, minst 100 × 100 pixlar, utan vattenstämpel eller text |
| availability | Obligatoriskt | in_stock, out_of_stock, preorder eller backorder. Måste stämma med produktsidan |
| price | Obligatoriskt | Pris i SEK inklusive moms |
| brand | Obligatoriskt för allt utom vissa egenproducerade varor | Varumärket, inte leverantören eller grossisten |
| gtin | Obligatoriskt om koden finns | EAN-koden. Se avsnittet om saknade koder nedan |
| mpn | Rekommenderat, obligatoriskt om gtin saknas | Tillverkarens artikelnummer |
| condition | Obligatoriskt | new eller used, till exempel för begagnat eller inbyten |
| item_group_id | Obligatoriskt för varianter | Gemensamt id för alla storlekar och färger av samma modell |
| size, color, material | Rekommenderat, obligatoriskt för kläder och skor | Variantens egenskaper, en per rad |
| google_product_category | Rekommenderat | Googles egen kategori för produkttypen |
| product_type | Rekommenderat | Butikens egen kategori, till exempel "Kök > Kastruller" |
| shipping | Obligatoriskt i Sverige om det inte satts i Merchant Center | Fraktkostnad, eller 0 för hämtning i butik |
Varje storlek och färg är en egen rad i feeden, med ett eget id, egen länk och egen tillgänglighet, och alla rader för samma modell delar ett item_group_id. Det är så Google förstår att en sko som är slut i storlek 42 fortfarande finns i 43, eller att en cykel som är slut i ramstorlek 50 finns i 54. Bilden bör vara rätt färg för varje rad, och titeln bör innehålla varianten, annars visas fel produkt i annonsen. Det vanligaste felet är att hela modellen ligger som en rad med ett enda lagersaldo; då blir produkten antingen ständigt i lager eller ständigt slut, oavsett vilka varianter som faktiskt står på hyllan.
Har produkten en EAN-kod ska den med, alltid. Saknar produkten en EAN-kod på riktigt, vilket är vanligt på småartiklar, hantverksvaror och delar från mindre tillverkare, sätts identifier_exists till false och brand plus mpn får identifiera produkten. Det som inte fungerar är att hitta på en kod, återanvända en kod från en annan variant eller sätta identifier_exists till false på en produkt som faktiskt har en kod; alla tre leder till avslag eller till att produkten paras ihop med fel produkt i Googles katalog. Produkter utan EAN får sämre spridning än produkter med, eftersom Google inte kan koppla dem till sin egen produktdatabas, så det lönar sig att hämta koderna från leverantörens prislista i stället för att gå runt problemet.
Minst en gång per dygn, och oftare för pris och lagersaldo. Google jämför feedens pris och tillgänglighet med vad produktsidan visar, och en avvikelse ger avslag för den produkten tills nästa hämtning. En feed som hämtas på schema en gång per natt räcker för sortiment och texter, men lagersaldo på varor som säljs över disk under dagen bör skickas via API eller genom att produktsidan bär strukturerad data som Google kan läsa automatiskt. Merchant Center kan uppdatera pris och tillgänglighet från produktsidans schema.org-märkning mellan hämtningarna, om funktionen slagits på.
Lokalt lager kräver tre saker: en verifierad företagsprofil på Google för butiken, en vanlig produktfeed och en lokal lagerfeed som per butik och produkt anger antal och pris. Den lokala feeden kopplar en store_code till varje rad, och det är den som gör att en kund som söker "regnjacka nära mig" eller "elcykel nära mig" ser att varan finns i butiken i dag. Lagerantalet i den lokala feeden kan komma från webbshoppen, men vanligast är att det hämtas från kassan, eftersom det är där saldot för den fysiska butiken faktiskt finns när samma varor säljs i båda kanalerna. Har butiken flera adresser får varje adress en egen store_code och egna rader.
| Fel i Merchant Center | Vanlig orsak | Åtgärd |
|---|---|---|
| Prisavvikelse | Kampanjpris i webbshoppen, ordinarie i feeden | Låt feeden hämta priset från samma källa som produktsidan |
| Tillgänglighetsavvikelse | Feeden uppdateras en gång per dygn, lagret ändras hela dagen | Tätare uppdatering eller automatisk uppdatering från produktsidan |
| Ogiltig GTIN | Kod med fel antal siffror, kopierad kod, artikelnummer i fältet | Hämta koden från leverantören, lämna fältet tomt hellre än fel |
| Bild med text eller för liten | Leverantörsbild med logotyp eller kampanjtext | Ren produktbild mot vit bakgrund |
| Saknad frakt | Ingen fraktinställning för Sverige | Sätt frakt i Merchant Center eller per rad |
| Dubblett-id | Samma artikelnummer på två varianter | Unikt id per variant, gemensamt item_group_id |
| Titel som ser ut som spam | Versaler, upprepade sökord | Märke, modell, variant, inget annat |
| Fel kategori | Butikens egen kategori i fältet för Googles | product_type för butikens träd, google_product_category för Googles |
Feeden är en spegel av butikens produktdata, och frågan är vilken källa som speglas. Är webbshoppen den enda kanalen räcker webbshoppens egen feed. Säljer butiken samma produkter i kassa och webbshop måste lagersaldot komma från kassan, och då måste kassan och webbshoppen vara kopplade innan feeden kan bli rätt. Har butiken dessutom många leverantörer med egna prislistor är det oftast enklare att samla artikeldata, EAN, bilder och texter på ett ställe och låta både webbshoppen och feeden hämta därifrån. Det är där prishantering och integrationer kommer in: en feed som fylls från ett korrekt artikelregister behöver sällan rättas för hand, oavsett vad butiken säljer.
Cykelbranschen visar problemen tydligare än de flesta. Samma cykel finns i fem ramstorlekar och tre färger, så en modell blir femton rader med gemensamt item_group_id och ramstorleken i titeln. EAN-koder saknas ofta på delar från mindre tillverkare, medan cyklarna nästan alltid har dem i leverantörens prislista. Cyklar som säljs i butiken under dagen gör att den lokala lagerfeeden måste följa kassan, inte webbshoppen. Lösningen är densamma som för andra butiker: rätt register bakom, koppling mellan kassa och webbshop, och en feed som fylls automatiskt därifrån.