Produktattribut i Ecommerce

Eftersom jag den här veckan blev tillfrågad av Consumidor Global om vissa metoder kring Temus priser, tar jag tillfället i akt att prata om en aspekt av Ecommerce som, precis som filter, jag tycker inte får den betydelse den förtjänar.

Och den har betydelse.

Verkligen.

Även om vi inte ser det i början av lanseringen.

Därför vill jag i den här artikeln klargöra hur långt dess påverkan på verksamheten sträcker sig.

Men innan vi börjar: om du har en Ecommerce, kika på det här eftersom jag tror att det kan intressera dig:

Nu till de där attributen…

Definition av produktattribut

Vi skulle kunna definiera produktattribut som valbara egenskaper hos samma produkt.

Det blir väldigt tydligt med exemplet med en T-shirt:

Som användare kan jag leta efter en enkel Nike-T-shirt att ha på gymmet.

Jag söker på Google, som tar mig till en butik där jag hittar den.

På T-shirtens produktsida ser jag att jag kan välja två alternativ:

• Färg.
• Storlek.

Varje alternativ är det vi kallar ett produkt-“attribut”.

Sedan väljer jag det som passar mig (till exempel, den svarta Nike-T-shirten i storlek M), betalar och väntar på leveransen.

Rätt använda, hjälper attribut mycket användaren att välja rätt produkt, som i det här fallet.

Men de används förstås inte alltid korrekt. Längre fram ser vi ett par fall där användningen pressas för långt.

Och dessutom lägger jag till en rad rekommendationer utifrån min erfarenhet av dem.

Först ska vi se vad användningen innebär för vår butik.

Att använda —eller inte använda— produktattribut

När vi bygger en webbutik och börjar lägga upp katalogen är det här ett av de avgörande: besluten: om vi ska använda attribut på produkterna eller inte.

Om du står inför det valet vill jag därför lägga fram de viktigaste för- och nackdelarna jag ser med attribut, så att du vet vad respektive väg innebär.

Sedan lägger jag, som sagt, till några extrema sätt de kan användas på.

Vi börjar med det kanske vanligaste fallet.

Användning av produktattribut i en webbutik

Även om det är ganska tydligt: när jag säger “använda produktattribut” menar jag att ge butikens användare möjlighet att välja mellan flera alternativ med olika egenskaper hos samma produkt.

Till exempel hos Yo pongo el hielo kan användaren välja flaskans volym:

I det här fallet varierar priset beroende på flaskstorlek, men för den tidigare Nike-T-shirten kostar alla storlekar lika mycket.

Det vill säga varje attribut kan ha ett annat eller samma pris.

Å andra sidan kan antalet attribut variera:

Vi kan ha mellan ett och tre attribut per produkt, medan fler är ovanligt (och inte särskilt rekommenderat). Utom i mycket speciella fall med extrem personalisering, till exempel när du köper flyers eller affischer från digitala tryckerier och väljer varje detalj i produkten.

Fördelar med att använda produktattribut

De är inte få, men en sticker ut framför de andra.

#1. Bekvämlighet för användaren

Det här är, för mig, den största fördelen.

Om kunden vet vad hen vill ha räcker det att komma till produktsidan och välja de attribut som passar bäst

Föreställ dig en tavelram: om du vill ha en enkel svart räcker det att söka på Google, klicka på den du gillar och välja rätt storlek på produktsidan.

Klart. Inga krångel.

Det är ett exempel på ett ganska vanligt och friktionsfritt flöde.

#2. Möjlighet att filtrera

Det är egentligen två separata saker och man kan filtrera utan att nödvändigtvis använda attribut, men bara om den aktuella egenskapen har lagts till på produktsidan.

Om du använder attribut har du ändå varit tvungen att göra det och kan ange i ditt CMS att du vill använda ett filter baserat på attributen:

#3. Vi undviker duplicerat innehåll

Jag förklarade det inte tidigare, men motsatsen till att använda produktattribut skulle vara att skapa en separat produktsida för varje möjlig kombination.

Det skulle alltså finnas en URL för den svarta Nike-T-shirten i storlek M.

En annan URL för den svarta i storlek L.

Ytterligare en för den röda i storlek M.

Och så vidare.

Om Google straffar duplicerat innehåll: ser du verkligen dig själv skriva olika produktbeskrivningar för varje kombination av samma T-shirtmodell?

Låter komplicerat…

Och det är det.

Med attribut kan du skriva en generell beskrivning av modellen som fungerar för alla kombinationer och gör det mycket enklare att lägga upp katalogen.

Nackdelar med att använda produktattribut

De finns också.

Och de är inte få.

#1. Visning i produktlistor

Jag menar att när användaren går in i en produktkategori på en webbplats och vi använder attribut visas normalt bara standardattributet i listan.

För en T-shirt kanske det inte spelar någon roll att olika storlekar inte syns, men när du köper sprit är prisskillnaden mellan formaten 70cl och 1L mycket viktig.

Särskilt för barer.

Vi behövde till exempel visa båda produktattributen i listorna och som standard gör PrestaShop 1.6 inte det.

Så vi fick ta till specialutveckling:

Det här är kanske, den största nackdelen med att använda attribut.

#2. Produktfeed

Varning, den här är lång.

Återigen —som med nästan allt i den här frågan— handlar det om en teknisk nackdel.

Och just den här är vanligare än den verkar. Det händer oss hos Yo pongo el hielo när vi annonserar på olika plattformar.

Men, lösningen är relativt enkel. Åtminstone enklare än lösningarna på de andra nackdelarna.

Så här ser situationen ut:

På plattformar där du annonserar flera produkter —som Google Shopping, jämförelsesajter eller vissa affiliates— laddar du normalt upp en Excel-liknande fil (“feed”) med alla dina produkter.

Här är ett exempel på feeden för Google Merchant:

I teorin, i den här filen, är varje rad en annan produkt, alltså med sina specifika attribut.

Den röda Nike-T-shirten i storlek M hamnar på en rad.

Och den röda Nike-T-shirten i storlek L på en annan.

Varje produkt får alltså ett unikt ID, ett visst pris, en egen bild och en specifik URL som användaren kommer till när hen klickar på annonsen.

Det är teorin.

Problemet är att om vi använder attribut på webbplatsen (som hos Yo pongo el hielo) kommer användaren normalt till en URL och kan välja där, som vi såg tidigare:

Problemet är att även om priset till exempel varierar mellan två attribut för samma produkt i feeden, kan vi kanske inte erbjuda en unik URL —eller andra värden som bilden— för varje attribut i feeden.

Då skickas vissa av dessa värden upprepade på flera rader.

Resultatet är att varje produktattribut kan ha:

• Samma produkttitel.
• Samma bild.
• Identisk URL.

Och då blir annonsplattformarna förstås förvirrade eftersom produktbild och titel (upprepade) blandas med priset för vilket attribut som helst.

Om attribut dessutom används fel (genom att lägga in produkter som inte är attribut) får vi AliExpress-fallet som vi ser senare, där Shopping tar produktbilden och produktnamnet tillsammans med priset för ett falskt attribut.

Och att detta händer kan uppmuntras av annonsören för att locka användaren till sin butik.

Ytterligare mätproblem

När jag ändå pratar om svårigheterna att skapa en korrekt produktfeed med attribut ska jag gå lite djupare i ett särskilt, men ganska vanligt, fall.

Föreställ dig alltså detta:

• En webbplats som använder attribut.
• Attributen har egen bild, eget pris och egen URL.

Med de egenskaperna kan man tro att man kan skicka en korrekt feed till plattformarna och att allt fungerar som väntat, eller hur?

Nej.

I Google Merchant / Shopping, ja.

På de andra (de flesta), nej.

Åtminstone inte om URL:en ser ut så här:

Alltså:

https://www.yopongoelhielo.com/es/whisky/91-johnnie-walker-black-label.html#/volumen-1l

Med en parameter separerad av symbolen “#” som anger attributet kommer du att få problem på de flesta plattformar.

Varför?

Det URL-taggningen.

Ja, UTM:erna.

Och varför blir den här typen av parametrar ett problem om vi blandar dem med UTM:er?

För att dessa parametrar med “#” måste ligga sist i URL:en för att allt ska fungera korrekt.

Den korrekt taggade URL:en skulle alltså se ut ungefär så här:

https://www.yopongoelhielo.com/es/whisky/91-johnnie-walker-black-label.html?utm_source=afiliado&utm_medium=display&utm_campaign=retargeting#/volumen-1l

Lägg märke till ordningen och symbolerna (“?”, “&” och “#”) som skiljer parametrarna åt.

Det här är rätt ordning och den fungerar alltid korrekt.

De här plattformarna kan däremot inte “dela” URL:en och skicka parametern som anger attributet (den som separeras med “#”, i det här fallet #/volumen-1l) sist.

Det brukar snarare bli så här:

https://www.yopongoelhielo.com/es/whisky/91-johnnie-walker-black-label.html#/volumen-1l?utm_source=afiliado&utm_medium=display&utm_campaign=retargeting

Med UTM:erna efter attributparametern "#". Det är fel.

Vilka fel kan det ge?

Det är mycket möjligt att länken inte leder till rätt attribut och att användaren då ser ett annat pris och/eller en annan bild i annonsen än på landningen.

Eller, vilket är säkert GA4 kommer inte att registrera den trafiken korrekt.

Det kan inte läsa attributen korrekt, så det är som om kampanjen inte hade taggats.

Eller värre, som om den hade taggats fel.

Om du använder GA4 för att kontrollera konverteringarna från kampanjer på olika plattformar kommer du att märka att de inte stämmer.

Trafiken kommer inte heller att stämma, men det är mindre relevant än konverteringarna. Särskilt om du har affiliate program med CPA eller CPL.

Och varför händer det inte hos Google?

Hos Google händer det inte om du har aktiverat automatisk taggning. Du skickar rätt URL, med attributparametern men utan UTM:er, och glömmer saken.

All tracking sköter Google självt, eftersom det äger Google Ads, Shopping och Analytics.

Varför använder man då den här typen av parametrar om de kan orsaka fel?

För att det är ett (bra) sätt att undvika duplicerat innehåll. Googles bot behåller URL:en före parametern, som alltid är densamma för alla attribut.

Finns det en lösning?

Ja. Nåja, mer eller mindre.

I slutet, i avsnittet med rekommendationer berättar jag.

#3. Länka bilderna

En annan sak som inte finns i alla CMS är att när man klickar på en bild för ett visst attribut, ska väljaren byta till rätt attribut:

Om ditt CMS inte gör det och du vill använda attribut med olika bilder för varje attribut måste du implementera funktionen.

Om du vill undvika kundklagomål förstås.

#4. Flera attribut

Fortsätter vi med UX-problemen kan vi säga att ett eller två typer av attribut är relativt enkla att hantera.

Problemet kommer när vi har tre (eller värre, fler än tre).

Med tre typer av attribut är det väldigt vanligt att inte alla möjliga kombinationer finns.

Vad gör du då när en användare ändrar ett av de tre attributen och skapar en kombination som inte finns?

Säger du att den kombinationen inte finns?

Tar du användaren till den mest liknande som faktiskt finns?

Och hur avgör du vilken kombination som är mest lik?

Och om den är slut i lager?

Sen berättar jag hur vi löser det.

#6. Ändring av beskrivningen

Förutom bild och pris bör ett attributbyte också ändra delar av beskrivningen som den här:

Jag måste erkänna att vi hos Yo pongo el hielo fortfarande inte har utvecklat det. En prioriteringsfråga.

#7. Kuponger

Ditt CMS låter dig nästan helt säkert använda kuponger på specifika produkter.

Det är mindre säkert att det låter dig använda dem på specifika attribut för en produkt.

Och om attributen har olika priser har vi ett problem.

Så antingen undersöker du CMS-et i förväg, utvecklar funktionen eller använder inte kuponger på vissa produkter:

#8. Analysverktyg

Bra, då går vi till den sista nackdelen.

I det här fallet är den inte så mycket teknisk som konceptuell.

Om du använder produkter med attribut kan sättet att skicka dem till ditt digitala analysverktyg (förmodligen Google Analytics) vara via Produktvariant.

Ungefär så här:

Så hade vi det i Universal Analytics hos oss.

Det är logiskt, eftersom du då kan se exakt vilken konkret produkt, med sina attribut, som genererar försäljningen.

Det blir lite mer problematiskt när du vill räkna paket eller isolera ett attribut som “Burk”, men generellt var det den lämpligaste lösningen då.

I GA4 mäter vi det däremot så här:

Med attributet i namnet.

Även om det blev diskussion var en av huvudorsakerna att när vi började implementera GA4, fanns det inget sätt att visa produktvarianten.

Det andra relaterade problemet uppstår när du lägger till visning eller klick på en produkt i en lista (eller kampanj)

Händelserna view_item_list och select_item_list i GA4 gav oss problem om samma produkt lades till två gånger med olika varianter, så vi kapade problemet direkt.

Av båda skälen gjorde vi därför så här:

• La varianten i artikelnamnet.
• Skickade den också som variant.

På så sätt förlorar vi bara till exempel möjligheten att direkt få total försäljning för en artikel inklusive alla attribut (all försäljning av alla format av Johnnie Walker Black).

För att få fram det måste du filtrera eller exportera data.

Mellan två dåliga alternativ tyckte vi att detta var bättre än att inte kunna se de konkreta attributen för en produkt, bara de aggregerade, och dessutom inte veta vilka klick som genererats i listor.

Sammanfattning av attributanvändningen

Även om nackdelarna är fler än fördelarna är nästan alla tekniska och i allmänhet relativt enkla att lösa.

Jag säger det eftersom skälen att använda dem handlar mer om business, och det är det som räknas i slutändan.

Och också eftersom det finns egna nackdelar med att inte använda attribut.

Att undvika produktattribut

Som jag nämnde tidigare får vi här en produktsida för varje attribut av samma produkt.

Det är som om varje streckkod (eller SKU om du föredrar det) behövde en egen sida.

Ett exempel är den här webbplatsen, där varje Black Label-format har en egen sida.

Här kan du se den för flaskan på 4,5L:

Det finns ingen väljare för de andra. Du måste gå till kategorilistan eller sökfunktionen för att hitta dem.

Förstått systemet?

Då förklarar vi fördelarna.

Fördelar med att inte använda attribut

Självklart undviker det nackdelarna med att använda attribut, så jag upprepar inte dem vi redan gått igenom.

#1. Alla alternativ visas i listorna

Utan att göra något kommer vårt CMS att visa varje attribut som en fristående produkt, eftersom det faktiskt är så vi hanterar det, utan att behöva programmera något.

Här ser vi de två Dewar’s, formatet 70cl och formatet 1L:

#2. Bättre sökfunktion

Om du använder CMS-ets standardsökning kommer den nästan säkert att fungera bättre och ge alla relevanta resultat om du behandlar attribut som produkter och söker efter saker som “röd T-shirt” eller “byxor storlek M”.

Här är ett exempel på sökning efter ett varumärke:

#3. Du kan rikta mer mot SEO-long-tail

Om din produktkatalog är liten kan fler tillgängliga URL:er ge mer precisa resultat.

Om vi går tillbaka till Nike-T-shirten kan du utan attribut ha URL:er med dessa titles:

• Svart Nike-T-shirt storlek M.
• Röd Nike-T-shirt storlek L.
• Blå Nike-T-shirt storlek XL.

När någon söker på så specifika termer har din webbplats förstås goda chanser att hamna högt i resultaten.

Här ser vi ett exempel med “Dewar’s White Label 1L”:

Förutsatt förstås att varje URL har unikt innehåll (beskrivning) och att du inte skapar duplicerat innehåll.

#4. Enklare produktfeeds

Du slipper alla problem med att bygga produktfeeds för annonsplattformarna.

Här är det entydigt, varje produkt är en rad.

Nackdelar med att inte använda attribut

Egentligen är de fördelarna med att använda dem:

• Den bekvämlighet för användaren.
• För att använda filtrering måste jag ha kategoriserat produkterna korrekt i back-office (lagt till motsvarande attribut, även om användarna inte kan välja dem).
• På SEO-nivå är gränsen för duplicerat innehåll diffus och lätt att kliva över.

Dessutom lägger vi till ett par nackdelar:

#4. Visa hela katalogen

I butiker med en stor katalog är det svårare att visa användaren alla alternativ som erbjuds och kanske passar bättre för det hen söker.

#5. Visa hela produktfamiljen för en modell

Relaterat till föregående punkt är det väldigt svårt att på en enda URL visa alla alternativ av samma modell av T-shirt / skor / glasögon / datorer / … är mycket komplicerat.

Föreställ dig att ett varumärke köper en banner och vill att den ska länka till en sida med alla varianter av den annonserade produktmodellen.

Du måste använda taggar, sökfunktionen eller skapa specialanpassade landningar med utvalda produkter (om ditt CMS ens tillåter det).

Som sagt, varken smidigt eller snabbt.

Att tvinga fram produktattribut

Nu när vi har pratat lite om attribut och hur de används vill jag ta upp det jag betraktar som felaktig användning.

Det finns fler fall, men jag vill fokusera på två som jag ser som missbruk av attribut.

Vi börjar med fallet AliExpress.

Missbruk av produktattribut på AliExpress

Även om jag talar om AliExpress händer det också på Temu och generellt ser man detta oftare i kinesiska webbutiker än i andra.

Ett exempel:

Föreställ dig att du letar efter ett grafikkort till din PC.

Det är helt normalt att gå till Google och titta på priserna i Shopping.

När du söker efter AMD RX 580 kommer du till de här resultaten. Titta på prisskillnaden mellan de båda artiklarna, som på förhand ska vara samma (se titeln):

Modellen till höger har ett löjligt omöjligt pris i Google Shopping. Men om du inte är van vid detta kan du tro att det är ett erbjudande eller något liknande.

Så du klickar och även om du ser ett annat pris när du kommer in (21,90€) är det fortfarande ett fantastiskt pris:

Synd att det inte är på riktigt.

För nu är nästa steg att klicka på alternativväljaren.

Och när vi gör det öppnas popupen och vi ser problemet:

Jag vill köpa en RX 580 (det står i produkttiteln) och det som är valt som standard i alternativen är en annan grafikkortsmodell. Till och med från ett annat märke.

Närmare bestämt Nvidia GT 610, en otroligt föråldrad och mycket sämre modell.

En annan produkt har lagts in som attribut, med ett mycket lägre pris som fungerar som reklambete.

När jag väljer rätt attribut (RX 580) normaliseras priset:

Och om någon tror att den gamla modellen kanske inte är ett attribut utan att sidan från annonsen är en lista med kort, lägg märke till att de olika modellerna har lagts in som värden för attributet “färg”.

Glasklart.

Det här är den vanliga processen i dessa butiker.

Den här kedjan av fel (Google Shopping + butik med attribut) kan uppstå av 3 skäl:

1) Avsiktligt programmerat och genomfört så

Det är vad som verkar hända här:

Ett artikelnamn används och under det, andra artiklar -inte attribut- som är sämre och billigare, för att locka uppmärksamhet med priset.

Den godtrogna användaren går på det eftersom hen tror sig ha köpt ett riktigt fynd, vilket inte stämmer.

AliExpress-säljaren kommer att hävda att den skickade det som faktiskt köptes (ett standardvalt attribut som inte motsvarar produkttiteln).

Det mest sannolika är då att, om kunden klagar, någon form av överenskommelse nås.  

Men om kunden inte klagar, då vinst för säljaren, som har blivit av med en produkt ingen vill ha.

Och förstås för AliExpress, som tar sin provision på försäljningen.

Det här är vad man kallar en dark-pattern och Europa ska tydligen bekämpa dem, eftersom de berörda butikerna inte verkar bry sig särskilt mycket. Problemet är att jag tror det blir svårt att bevisa att orsaken till dessa "fel" inte är någon av de två följande.

Man måste också förstå att de här butikerna är marketplaces, vilket i praktiken betyder att, säljarna i dessa butiker som skapar dessa "fällor", även om själva plattformen inte sätter stopp för dem.

2) Mänskligt fel

När man matar in produktpriser i en Ecommerce är det lätt att skriva fel och sätta ett felaktigt pris på något attribut. Särskilt vid massuppladdningar med Excel.

Alla som någon gång har hanterat den här typen av processer har råkat ut för det, inklusive förstås stora aktörer som Mediamarkt eller Fnac.

Det märkliga är bara att det händer så många gånger och på så många produkter som på AliExpress…

3) Teknisk omöjlighet

Den tredje orsaken är lite mer komplex eftersom den, som sagt, är teknisk och det är den jag pratade om tidigare när jag nämnde problemen med att skapa datafeeds för webbutiker som använder attribut.

Avslutning av AliExpress-fallet

Som du ser finns det vid missbruk av attribut i kinesiska butiker många hål i processen som de "skyldiga" butikerna har litet intresse av att täppa till och som säljarna utnyttjar för att blåsa de mest godtrogna användarna.

Men det här är bara den första knepiga användningen av attribut.

Låt oss gå vidare till en (lite) mindre tricky.

Amazon-fallet

Innan jag börjar prata om den här användningen av attribut vill jag klargöra ett par saker:

• Amazon använde tidigare “normala” attribut. Om de har bytt till dessa, med alla tester de gör, är det för att det fungerar för dem. Punkt. Vad jag tycker om den här attributanvändningen spelar alltså liten roll.
• Att det fungerar för Amazon betyder inte att för de 99,999% webbutiker som inte är Amazon deras system också måste fungera. Vi har varken deras trafik, kunder eller tester. Så var försiktig med att kopiera “för att Amazon gör så”.

Bra, låt oss se hur Bezos-folket använder attribut.

I det här fallet har vi redan köpt grafikkortet på AliExpress och behöver nu ett chassi gaming som matchar.

Du vet, ett sånt som är fullt av ljus och färg.

Som tidigare söker vi på Google:

Och jag ser den här Amazon-modellen, som jag gillar och som inte är för dyr. Så jag klickar.

När jag kommer in på Amazon ser jag direkt att, till skillnad från AliExpress-fallet priset ligger kvar:

Men här nedanför ser jag en väljare för “stil”.

Det luktar redan lite skumt eftersom “stil” inte är något objektivt som “färg” eller “storlek”, utan mycket mer subjektivt.

När jag öppnar den ser jag mycket olika chassimodeller, alla inlagda på samma produktsida.

Och när jag säger olika menar jag helt olika:

Varken formen, färgen eller förstås priset på den här chassimodellen liknar den förra.

Det är en ny produkt, inlagd som attribut så att användaren ser flera alternativ på samma produktsida.

Sedan får var och en avgöra om det är bra UX-praxis eller inte.

Amazon använder dock inte alltid den här typen av attributväljare. I andra sektioner använder de också en mer traditionell variant, troligen på grund av mängden alternativ:

I det här fallet ser vi att en attributväljare används med alla alternativ synliga.

Problemet är återigen att det inte är samma laptopmodell med olika konfigurationer, utan olika modeller. Faktum är att det står direkt i specifikationerna.

Som följd finns inte alla kombinationer av de tre attributen. Inte alls. Det finns bara 4 möjliga och beroende på var du klickar väljer Amazon den “mest lika”.

Personligen övertygar det mig inte, eftersom varje alternativ är helt olikt de andra och inte hjälper mig att välja modell, utan gör valet svårare.

Men kanske har de sett att användarna stannar längre på webbplatsen när olika modeller visas och att konverteringsgraden till slut ökar.

Kanske missar användarna en stor del av en så enorm produktkatalog och ser på det här sättet fler “mer eller mindre” liknande alternativ.

Ingen aning.

Det jag vet är att det här är en påtvingad användning av vad jag anser att produktattribut borde vara.

Men bortsett från UX innebär det här också ett SEO-problem…

Duplicerat innehåll

Låt oss återvända till vårt gamingchassi.

Titta på de här två bilderna:

Den här motsvarar denna URL:

https://www.amazon.es/MC300W-Cristal-Templado-Frontal-3xVentilador/dp/B09BFM6NHT?ref_=ast_sto_dp&th=1

Den här andra bilden däremot —som liknar den men inte har samma URL—:

Motsvarar denna andra (du kan titta i webbläsarfältet för att vara säker):

https://www.amazon.es/Mars-Gaming-MC100-ventilación-convect-cool/dp/B09BFM6NHT?ref_=ast_sto_dp&th=1

Vet du vad? Det här är Googles definition av duplicerat innehåll.

Och vet du vad mer? Amazon straffas inte.

Trots att de har flera andra URL:er (utöver dessa två) som är praktiskt taget identiska.

Om du söker efter märket och modellen på Google (“mars gaming mc51w”) är tredje resultatet deras. Före andra konkurrenter som arbetar väldigt bra med SEO, som PcComponentes.

Och bara slaget av märkets officiella webbplats:

Amazon spelar efter andra regler.

Skulle du slå vad om att Google behandlar din webbplats likadant?

För mina egna vet jag helt klart att det inte gör det.

Så, som sagt: var väldigt försiktig med att kopiera dem.

Rekommendationer när du använder eller inte använder produktattribut

Nu har du kunnat se vilken modell (med eller utan attribut) som passar din bransch eller verksamhet bäst.

Du har också sett hur felaktigt använda attribut kan missbrukas.

Oavsett vilket du väljer vill jag ge dig några tips som erfarenheten har lärt mig.

#1. Katalogens storlek

Om din webbplats har många produkter och de har varianter skulle jag säga att jag är 99% säker på att det är lämpligt att använda attribut på produktsidorna.

Om butiken är liten idag (några tiotal produkter) men du tror att den kommer att växa gäller samma sak.

Om du tror att den inte kommer att växa och att du kan skapa unikt innehåll för varje produktvariant, då använd inte attribut.

#2. Använd attribut som faktiskt är attribut

Kom ihåg vad vi just såg i fallet med kinesiska butiker, med AliExpress i spetsen.

Kort sagt: använd attribut för att lägga till varianter av samma produkt, inte för att lägga till nya produkter.

För att lägga till liknande produkter finns bättre lämpade moduler:

#3. Antal attribut

Förutom i mycket specifika fall och produkter med maximal personalisering bör du inte använda mer än tre typer av attribut per produkt, eftersom det leder till många kombinationer som inte finns.

När det finns alternativ som inte existerar är lösningen vi har implementerat hos Yo pongo el hielo följande:

• Vi låter inte användaren välja en kombination som inte finns: när användaren väljer ett attributvärde som skulle ge ett sådant resultat ändrar vi värdena på de andra attributen så att kombinationen finns.
• Vi har “primära” och “sekundära” attribut: det innebär att om vi måste ändra ett attributvärde för att undvika en ogiltig kombination prioriterar vi först att ändra sekundära attribut, eftersom vi antar att det primära är det användaren bryr sig mest om.
• Vi prioriterar kombinationer som finns i lager: om en kombination finns men är slut i lager prioriterar vi att visa en som finns. Även om vi måste ändra värdet på ett primärt attribut.

Just nu är vi nöjda med dessa regler, även om de säkert går att förbättra.

#4. Låt dem visas i listorna

Attribut som ändrar produktpriset bör visas i listorna.

Det gäller alkohol, parfym, hundmat…

Det kanske finns något fall där det inte borde vara så, men jag kommer faktiskt inte på något just nu.

Och självklart ska ett klick på dem leda till URL:en med rätt attribut valt.

#5. SEO spelar roll

Och angreppssättet med attribut skiljer sig från det som rekommenderas utan attribut.

Jag hoppas att det jag förklarade tidigare om duplicerat innehåll och long-tail  ger dig något att fundera över i ditt projekt.

#6. Produktfeeden är relevant

Och ju mer projektet växer, desto viktigare blir den.

Så, till rekommendationerna:

1. Oavsett vad, skaffa unika URL:er. Om du har attribut, ta reda på hur du kan få dem utan att skada SEO.
2. När du har dem och de använder parametrar med “#” måste du göra två olika feeds:
• En för Google, med alla produkter och deras attribut, som fungerar korrekt.
• En annan för de övriga plattformarna, som kan vara av två typer:
• Om plattformen tillåter det, skicka själv de korrekt UTM-taggade URL:erna som jag har förklarat och skicka hela katalogen med produkter och attribut. Se till att de ALDRIG lägger till någon parameter efteråt.
• Om plattformen inte tillåter att du skickar URL:er med UTM:er måste du skicka bara ett attribut per produkt —det primära— och skicka den rena URL:en, utan attributparametrar med “#”. Då blir katalogen mindre, men det blir inga fel vare sig när annonserna visas eller i analysverktyget.

#7. Om du inte använder attribut

Se till att lägga till en tydligt synlig modul på produktsidan med de olika produktalternativen som användaren kan välja.

#8. Om du är användare…

Jag antar att du inte är nybörjare om du läser den här artikeln och har kommit ända hit.

Men för säkerhets skull: det är viktigt att titta på butikens returpolicy, på omdömen från andra användare och att betala med PayPal, eftersom det i sådana fall ger användaren större garantier än bankkort.

Slutsatser

Den som aldrig har ställts inför det här beslutet i ett projekt har förmodligen inte tänkt så mycket på många av frågorna jag tar upp i artikeln.

Men jag hoppas att jag har fått dig att se hur viktiga de är.

Och att valet att använda attribut eller inte har konsekvenser utöver de uppenbara.

Jag hade gärna lagt till ytterligare en punkt: de olika UX-alternativen för attributval.

Även om vi redan har sett flera upplägg (Amazon, AliExpress, Yo pongo el hielo…) finns andra som jag tycker är intressanta, som pop-up hos TiendAnimal till exempel.

Men jag har redan skrivit mer än 5.000 ord och ville inte göra artikeln ännu tätare.

Kanske återkommer jag till attribut i framtiden, men då uteslutande med fokus på UX.

I vilket fall var min avsikt att ge dig lite mer sammanhang så att du kan förstå allt som ryms i ett beslut som vid första anblick verkar harmlöst.

Men förstås, i medelstora eller stora Ecommerce-projekt, är inget centralt beslut någonsin harmlöst.

Jag antar att du håller med.