SKU

Definition af SKU

En SKU (Stock Keeping Unit) er en unik identifikator, som en virksomhed opretter for at spore en specifik, salgbar version af et produkt gennem lager-, ordre- og salgssystemer. Hvis en hoodie kommer i tre farver og fire størrelser, er det tolv SKU’er, fordi hver kombination skal tælles, prissættes og genbestilles uafhængigt. En SKU er ikke det samme som et produktnavn eller en listning — ét produkt kan have mange SKU’er, én for hver variant, en kunde rent faktisk kan vælge og købe. SKU’er er interne for den virksomhed, der opretter dem, hvilket adskiller dem fra UPC’er og EAN’er, som er standardiserede koder tildelt af en ekstern instans (GS1) og delt på tværs af alle forhandlere, der sælger netop den vare. En forhandler kan derfor oprette sin egen SKU for et produkt, den køber på engros, og lægge en intern kode oven på producentens stregkode, så dens egne lager- og rapporteringssystemer kan spore det konsekvent.

Hvordan SKU-koder er struktureret

Der findes ingen universel standard for SKU-format, hvilket både er en styrke og en almindelig kilde til kaos. De fleste handlende opbygger en kort alfanumerisk streng, der indkoder de attributter, der betyder noget for lager- og rapporteringsformål: kategori, produktlinje, farve og størrelse er almindelige byggesten. Et typisk mønster ser ud som TSH-CREW-BLK-L for en sort, stor, crew-neck t-shirt, eller MUG-CER-12OZ for en 12-ounce keramikkop. God SKU-design følger typisk et par regler: hold koderne i en konsekvent længde, så de er nemme at scanne visuelt og sortere i et regneark, undgå mellemrum og specialtegn, der kan ødelægge CSV-import eller URL-slugs, og gør koden læselig nok til, at en lagermedarbejder kan genkende produktet ud fra koden alene uden at slå det op. Nogle virksomheder bruger i stedet sekventielle numeriske SKU’er (10001, 10002…), der genereres automatisk af deres platform, og bytter læsbarhed for garanteret unikhed. Begge tilgange virker, så længe de anvendes konsekvent — fejltilstanden er normalt inkonsekvens: én produktlinje kodet i hånden, en anden autogenereret, uden nogen fælles logik mellem dem.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Kom i gang Kontakt

Hvorfor SKU-sporing betyder noget for e-handel

SKU-granularitet er det, der overhovedet gør lagerstyring mulig. Sammensatte lagertal på “produkt”-niveau skjuler, at én variant er udsolgt, mens en anden har for meget på lager — en butik kan vise “T-shirt: på lager”, mens den størrelse, der rent faktisk sælger, har været i restordre i to uger. SKU-sporing ligger også til grund for genbestillingspunktsberegninger, da en mellemstørrelse og en XL af samme skjorte sælges i forskelligt tempo og har brug for forskellige genbestillingstriggere. Ud over lager er SKU den naturlige join-nøgle til margenanalyse: når først en SKU har en landingsomkostning (enhedsomkostning, indgående fragt, emballage) tilknyttet, kan hver ordrelinje knyttes tilbage til en reel omkostning, og omsætning og rentabilitet kan rapporteres med samme granularitet, som et lager bruger til at styre beholdning. Uden SKU-niveau omkostningsdata må rentabilitetsrapportering falde tilbage på ordreniveaugennemsnit, hvilket udvisker forskellen mellem højmargin- og underskudsprodukter på en måde, der skjuler, hvilke SKU’er der rent faktisk er værd at promovere.

SKU vs. UPC vs. Produkt-ID

Et enkelt fysisk produkt kan bære alle fire samtidigt: en producent-tildelt UPC, en forhandler-tildelt SKU, en markedsplads-tildelt ASIN og en platform-tildelt variant-ID. Flerkanalssælgere har normalt brug for en mapping-tabel, der afstemmer disse, så et salg på Amazon og et salg via en Shopify-butik begge ruller op til den samme underliggende SKU til rapportering.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

SKU-data og AI-drevet handel

I takt med at shopping i stigende grad foregår via AI-assistenter som ChatGPT Shopping, Perplexity Shopping og Amazon’s Rufus, afhænger produktdatafeeds — den strukturerede information, der fortæller disse systemer, hvad der er på lager, til hvilken pris og i hvilken variant — af rene SKU-niveau-data under overfladen. En AI-shoppingassistent, der anbefaler “den mellemstore i blå”, har brug for at det underliggende feed kan omsætte det til en faktisk SKU med reel lagerbeholdning og pris, ikke en generisk produktlistning. Rodede eller duplikerede SKU’er er en almindelig årsag til, at produktfeeds bliver afvist eller fejlrepræsenteret på tværs af disse kanaler. På analysesiden arbejder værktøjer som AmICited’s eshop_get_products og eshop_list_product_costs rapporter på SKU-granularitet netop fordi det er det niveau, hvor rentabilitetsspørgsmål rent faktisk bliver besvaret — “hvilken variant af dette produkt skal jeg blive ved med at lagre” er et SKU-niveau-spørgsmål, ikke et produktnavn-niveau-spørgsmål. Rapportering af omsætning og margin pr. SKU, frem for efter produkttitel, er det, der gør det muligt for en forhandler at se, at den sorte mellemstor sælges med 40% margin, mens den neon-grønne XXL, på trods af at være “samme produkt”, knap nok går i nul.

Bedste praksis for SKU-styring

• Etablér én kanonisk SKU pr. variant før listning på tværs af flere kanaler, og map hvert kanalspecifikt ID tilbage til den
• Hold SKU-koder korte, konsekvente i længden og fri for mellemrum og specialtegn
• Tilknyt en landingsomkostning til hver SKU, ikke kun en detailpris, så margin kan beregnes automatisk
• Undgå at genbruge en udfaset SKU til et nyt, ikke-relateret produkt — historisk rapportering vil blande de to sammen
• Gennemgå jævnligt for duplikerede eller næsten-duplikerede SKU’er (et almindeligt resultat af manuelle regnearksredigeringer)
• Inkludér SKU i alle eksporter — ordrer, returvarer og omkostningsark — så datasæt altid kan samles igen

Almindelige SKU-fejl

Et hyppigt problem er at behandle “produkt” og “SKU” som udskiftelige i rapportering, hvilket giver lagertal og margin-tal, der ser fine ud samlet set, men skjuler en dårligt præsterende variant under en velfungerende. Løsningen er at sikre, at alle rapporter — salg, lager, omkostning — genereres på SKU-niveau og kun rulles op til produktniveau som en visningsbekvemmelighed, ikke som den underliggende beregning. Et andet almindeligt problem er SKU-drift på tværs af salgskanaler: en forhandler opretter ét SKU-skema i deres POS-system, et andet autogenereres af deres e-handelsplatform, og et tredje format dukker op på en markedspladslistning, hvilket efterlader ingen pålidelig måde at afstemme samlet salg for en given variant uden manuel matchning. Standardløsningen er en mapping-tabel, der vedligeholdes centralt, ideelt set inde i den platform, der laver rapporteringen, i stedet for at blive genskabt ad hoc i et regneark hver gang. En tredje fejl er at genbruge SKU’er, når et produkt udfases og erstattes — en ny formulering eller et redesign, der får den gamle SKU, mudrer historiske trenddata, så det ser ud som om det samme produkt pludselig ændrede præstation i stedet for at vise et rent før/efter-skifte. Endelig undlader mange mindre forhandlere at knytte en reel landingsomkostning til hver SKU og bruger i stedet et fladt estimeret margin-gennemsnit på tværs af hele kataloget; dette gør SKU-niveau rentabilitetsrapportering teknisk mulig, men praktisk vildledende, da det ikke kan afsløre den faktiske spredning mellem de bedst og dårligst præsterende varianter.