Per-produktvolymrabatter i Shopify: Räkna samma produkt, inte hela samlingen

Shopifys inbyggda volymrabatter räknar kvantitet över alla berättigade varor i varukorg, inte per enskild produkt. När du anger en minimikvantitetsrabatt på en samling lägger Shopify ihop alla berättigade enheter tillsammans, så en kund som köper 2 av en produkt och 1 av en annan kan utlösa en nivå som du avsåg för köp av 3 av en enda produkt. För att räkna samma produkt eller samma variant på egen hand behöver du per-produkträkning, vilket Shopifys inbyggda rabatter inte erbjuder. Du får det från en app som låter dig välja vad som räknas som "samma produkt" innan nivåberäkningen körs.

Den här guiden förklarar exakt hur inbyggda kvantitetsrabatter räknar, de tre räkningsmöderna (per-variant, per-produkt och per-grupp) i enkelt svenska, varför samlingspooling ger rabatter du aldrig avsåg, hur minimiorderkvantitet fungerar, och ett helt genomarbetat exempel med matbordsstolar räknade per stol. Du kommer att avsluta med att veta vilket räkningsläge som passar varje kampanj och hur du ställer in det så att den nivå en kund ser är nivån de faktiskt betalar.

Hur räknar Shopifys inbyggda volymrabatter kvantiteten?

Shopifys inbyggda rabattbyggare kan definitivt skapa en volymrabatt. Du väljer "Belopp rabatt på produkter", begränsar den till en produkt eller samling, och lägger till en minimikvantitet av varor som inköpskrav. Den delen fungerar. Problemet är inte om du kan bygga en nivå. Problemet är vad nivån räknar.

När du anger en minimikvantitet behandlar Shopify det som ett tröskelvärde mot summan av alla berättigade varor i varukorg. Enligt Shopifys utvecklardokumentation, DiscountMinimumQuantity objektet "anger den minimiantal varor som krävs för rabattberättigande" och "detta tröskelvärde gäller för berättigade varor i kundens varukorg." Exemplet Shopify ger är en "Köp 3, få 10% rabatt" kampanj som anger minimikvantiteten till 3 varor. Ingenting i denna regel säger tre av samma vara. Det säger tre berättigade varor, punkt slut.

Samma pooling visas i Köp X få Y. Shopifys DiscountOnQuantity objekt driver nivåindelade "köp mer, spara mer" effekter, och Shopify beskriver det med ett blanda-och-matchningsexempel: "Köp 4 ljus, få 2 ljus 50% rabatt (blanda och matcha)." Blanda och matcha är nyckeln. De fyra ljusen som låser upp affären kan vara vilka som helst från den berättigade uppsättningen. De behöver inte vara samma ljus. Och förutsättningsvarorna i en Köp X få Y rabatt kan vara, enligt DiscountCustomerBuysInput dokumentationen, "antingen samlingar eller produkter," med ett enda kvantitetsvärde som täcker hela uppsättningen.

Så det inbyggda beteendet, verifierat mot shopify.dev, är konsekvent över rabatttyper: kvantitetströskeln räknar varje berättigad radartikel tillsammans. Begränsa rabatten till en samling och hela samlingen matar ett delat nummer. Det är fint för en butiksvid "spendera mer, spara mer" push. Det är fel för "köp mer av denna specifika produkt."

BILDPLATSHÅLLARE (Bild 1): Hur inbyggd räkning slår ihop en samling

Föreslagen visuell: Ett rent 16:9 diagram på vita bakgrund. Vänster sida visar en varukorg med tre olika stolsprodukter, kvantiteter 2, 1 och 1, var och en en distinkt silhuett i grå skifer. En stor violett pil märkt "inbyggd minimikvantitet: räknar alla berättigade varor" pekar på en enda poolad räknare som visar "4 enheter till ett delat tröskelvärde." En liten röd flagga läser "inte 4 av samma stol." Platt vektorstil, varumärkesfarger violett och guld, sans-serif etiketter, ingen fotografi.

Varför samlingområdet gör detta värre, inte bättre

Handlare griper efter en samling för att det känns som rätt behållare. "Jag säljer fem matbordsstolar, jag lägger dem i en Chairs samling och ställer in rabatten där." Det är den intuitiva flytten, och det är den exakta flytten som förstör avsikten.

När rabatten är begränsad till den samlingen särskiljer Shopify inte mellan de fem stolarna inuti den. Varje enhet av varje stol räknas mot samma tröskelvärde. Lägg en produkt till samlingen senare och den ansluter sig tyst till räkningen också. Handlare på Shopify-forumen beskriver detta exakt: de vill ha nivåer "per specifik stol, ingen sammanblandning mellan produkter," och Shopify-supporten bekräftar att inbyggda rabatter inte kan "räkna samma produkter endast." Samlingen är ett filter för berättigande, inte en gräns för räkning.

Vilka är de tre räkningsmöderna?

Varje kvantitetsbaserad rabatt måste svara på en fråga innan den gör någon matematik: vad räknas som "samma produkt"? Det finns tre rimliga svar, och det rätta beror helt på kampanjen. Att namnge dem explicit är hela spelet, för att Shopify bara ger dig det bredaste.

Per-variant: räkna bara exakt SKU

Per-variant räkning behandlar varje variant som sin egen ö. En stor t-shirt och en medium t-shirt av samma stil räknas separat, mot separata tröskelvärden. A3 och A4 storlekar på samma poster slår aldrig ihop.

Använd per-variant när dina varianter är effektivt olika produkter för prissättningsändamål. Utskriftsstorlekar som kostar verkligen olika belopp att producera, material som bär olika marginaler, eller något där "5 av denna exakta SKU" är den verkliga enheten för affären. Om en kund inte bör kunna nå en nivå genom att blanda storlekar, är per-variant läget som framtvingar det.

Per-produkt: räkna varje variant av en produkt tillsammans

Per-produkträkning är den som de flesta handlare faktiskt menar när de säger "köp mer av denna vara." Varje variant av en enskild produktsida räknas mot samma nivå. Alla storlekar och färger på en t-shirt-stil adderas tillsammans, men en annan t-shirt-stil bidrar inte.

Det är det vettiga standardvalet för volumnivåer. En möbelhandlare som säljer en matbordsstol i fyra utföranden vill att alla fyra utföranden ska räknas som "stolen," eftersom det är vad kunden upplever. Två ek plus två valnöt är fyra stolar, och det bör slå nivån för fyra stolar. Per-produkt får det rätt medan det fortfarande vägrar att räkna en helt annan stolmodell.

Per-grupp: handplocka en liten uppsättning relaterade produkter

Per-gruppräkning låter dig nominera en specifik, explicit uppsättning produkter som bör dela ett tröskelvärde. En "startpaket" av ett rengöringsmedel, en tonik och en fuktighetskräm kan räknas tillsammans, så vilka tre enheter som helst från den triaden låser upp affären, utan att dra hela din katalog in i räkningen.

Per-grupp är det läge som ligger närmast Shopifys inbyggda samlingsbeteende, och det är poängen. Använd det medvetet när du verkligen vill ha en blanda-och-matchningspool, som en butiksvid "vilka 6 varor som helst, 10 procent rabatt" kampanj. Skillnaden från inbyggd är att du väljer poolen med intention, vara för vara, istället för att ärva den av misstag från vad som än råkar sitta i en samling.

Den ena mentalmodellen att hålla fast vid: Shopify erbjuder bara något som liknar per-grupp, begränsat till en samling, oavsett om du ville det eller inte. Per-variant och per-produkt är de två lägen som inbyggd räkning inte kan uttrycka, och de är de två som de flesta handlare faktiskt behöver.

Varför ger samlingspooling kunderna fel rabatt?

Här är det konkreta misslyckandet, och det skär båda vägar.

Först utlöser det för lätt. Du avsåg "köp 3 av denna stol, få 15 procent rabatt." En kund lägger till en av var och en av tre olika stolar, slår det delade tröskelvärdet på 3, och får 15 procent rabatt på alla tre. Det är inte det lojalitetsbeteende du var prissättning för. Du ville belöna engagemang för en produkt. Istället rabatterade du en bläddrig exempelkorg, och du gav bort marginal på enheter som aldrig skulle röra sig tillsammans i volym.

För det andra, och mindre uppenbart, kan det underbelöna kunden du ville ha. Om dina nivåer eskalerar (3 till 5 enheter till 15 procent, 6 till 9 till 18 procent, 10 eller fler till 20 procent) och räkningen slår ihop över en hel samling, blir matematiken smutsig snabbt. En grossistköpare som tar 10 av en stol sitter i samma poolade bucket som en detaljhandelskund som tar 2 av tre olika stolar. Du kan inte bort prissätta en per-produktbulknivå rent när räknaren inte vet vilka enheter som tillhör vilken produkt.

För det tredje är det skört att underhålla. Eftersom samlingen definierar räkningen, redigerar redigeringen av samlingen kampanjen. Lägg till en säsongstol i Chairs samlingen och varje köpare av den nya stolen bidrar nu till, och drar nytta av, en nivå du designade för månader sedan för olika produkter. Ingenting ger ett fel. Rabatten bara börjar tyst bete sig annorlunda. Tyst drift som denna är samma problem som gör att handlare misstror rabattstödet på första plats: varukorggen visar fortfarande ett nummer, det är bara fel nummer.

Fixningen är inte en smartare samling. Det räknar per produkt så att tröskelvärdet betyder vad du trodde det betydde.

Vad är minimiorderkvantitet (MOQ) prissättning, och hur möjliggör per-produkträkning det?

Minimiorderkvantitetsprissättning är grossist- och bulkmönstret där en produkt helt enkelt inte är tillgänglig, eller inte rabatterad, under ett minimumantal, och sedan tjänar en fastställd ränta över den. "Ingen handelspris under 12 enheter. Vid 12 eller fler, denna enhetspris." Det är hur många B2B och på-beställning kataloger fungerar.

MOQ-prissättning lever eller dör på per-produkt- eller per-varianträkning, för golvet måste betyda "12 av denna sak," inte "12 av något i kategorin." Om räkningen slår ihop över en samling, en köpare monterar 12 blandade enheter och kräver en handelspris på en detaljhandelsorder. Det är motsatsen till vad MOQ är för.

Med per-varianträkning blir MOQ exakt: ingen rabatt under 12 enheter av samma SKU, sedan ett fast enhetsprisöverstyring på 12 och upp. Detaljhandelköpare under golvet betalar fullt pris. Bulkköpare korsar golvet på en enskild produkt och får automatiskt upp handelsenhetspriset, utan en separat prislista att underhålla och ingen utkastorder-lösning. Räkningsmoden gör verkställandet, vilket är varför att få rätt läge rätt räknas mer än nivånumren.

Utarbetat exempel: matbordsstolar räknade per stol

Låt oss göra detta konkret med det exakta scenariot handlare håller att beskriva på forumen. En möbelbutik säljer flera matbordsstolmodeller och vill ett per-stol volymavtal på en av dem:

• 3 till 5 stolar: 15 procent rabatt
• 6 till 9 stolar: 18 procent rabatt
• 10 eller fler stolar: 20 procent rabatt

Avsikten är strikt. Nivån bör räkna den ena stolen (alla utföranden tillsammans), den bör kräva ett minimum på 3 för att starta, och den måste inte slå ihop med de andra stolmodellerna i samlingen. Här är hur samma varukorg löses under inbyggd samlingspooling kontra per-produkträkning.

Titta på rad tre och fyra. Det är de fall som skiljer en kampanj som fungerar från en som läcker marginal. Under inbyggd pooling kan fyra orelaterade enheter låsa upp en nivå som är avsedd för köp av fyra av en stol. Under per-produkträkning når endast genuint engagemang för den stolen (i vilket utförande som helst) nivån, exakt som avsett. Bulkraderna fungerar fortfarande perfekt, för per-produkträkning adderar varje utförande av stolen innan den kontrollerar tröskelvärdet.

Det är också här minimivärdet på 3 gör sitt jobb rent. För att räkningen är per produkt, "minst 3 av denna stol" är entydig. Det finns inget sätt att tillfredsställa det med en spridning av engångsvaror, vilket är exakt hålet som samlingspooling lämnar öppen.

BILDPLATSHÅLLARE (Bild 2): Samma varukorg, två räkningslägen, två totaler

Föreslagen visuell: En 16:9 split-panel illustration. Vänster panel märkt "Inbyggd: poolad över samling" visar en varukorg med fyra olika stolar med en grön 15 procent badge och en liten röd varning "oönskad nivå." Höger panel märkt "Per-produkt: räknar samma stol" visar den identiska fyra-olika-stolar varukorg utan rabatt och en lugn grå "ingen nivå, som avsett" anteckning. Nedan, en andra rad visar fyra av samma stol som tjänar 15 procent i båda panelerna. Varumärkesfarger violett och guld, platt vektor, ingen fotografi.

Hur man ställer in per-produktvolymrabatter, steg för steg

Du kan bygga en poolad volymrabatt inbyggt på några minuter. Vad inbyggt inte kan göra är att välja räkningsmoden, så per-produkt- och per-variantnivåer behöver en app som exponerar räkning som en explicit inställning. Här är den pålitliga sekvensen, vilken väg du tar.

1. Bestäm vad "samma produkt" betyder för denna kampanj

Innan du rör någon byggare, skriv meningen ut. "Köp mer av denna exakta SKU" är per-variant. "Köp mer av denna produkt i någon variant" är per-produkt. "Köp vilken blandning som helst från denna specifika uppsättning varor" är per-grupp. Detta ena beslut bestämmer allt efterströmt, och det är beslutet Shopify gör åt dig (alltid det bredaste).

2. Välj räkningsmoden explicit

I ett verktyg som stöder det, ställ in räkningsmoden först, inte sist. Per-produkt är det säkra standardvalet för en "köp mer av denna vara" nivå. Byt till per-variant när olika varianter verkligen är olika produkter för prissättning, som utskriftsstorlekar eller material. Reservera per-grupp för avsiktliga blanda-och-matchningspooler, och plocka medlemmarna för hand.

3. Ställ in dina nivågränspunkter

Lägg till de kvantitets- och rabattpar din strategi behöver: 3 till 5, 6 till 9, 10 eller fler, var och en med sin egen procentsats eller fast belopp. För MOQ-prissättning, gör den första nivån börja vid ditt golv (till exempel 12 eller fler) och lämna allt under den till fullt pris. Ett fast enhetsprisöverstyring, snarare än en procentsats, är ofta det renare uttrycket för en handelspris.

4. Begränsa erbjudandet till rätt produkt eller uppsättning

Bifoga nivåerna till den specifika produkten för per-produkt, eller den specifika varianten för per-variant. Om du använder per-grupp, är det här du nominerar medlemmarna. Håll omfånget tight. Räkningsmoden hanterar redan vad som slås ihop, så du behöver inte en långtråkig samling för att få det att fungera.

5. Visa nivåerna på produktsidan

En kvantitetsrabatt kunden inte kan se är en kvantitetsrabatt som inte konverterar. Visa nivåtabellen på produktsidan så att köpare kan se nästa gränspunkt och sparandet. Tabellen bör uppdateras live när de ändrar kvantitet, utan sidladdning, och den markerade nivån bör alltid matcha vad kassan kommer att debitera.

6. Testa en bör-tillämpas och en bör-inte-tillämpas varukorg

Bygga en varukorg som köper nog av den ena produkten för att slå varje nivå, placera en utkast- eller testorder, och läsa kassasummans rad för rad för att bekräfta att rätt nivå brann. Sedan bygga fällkorglen: en spridning av olika produkter som skulle utlösa en poolad rabatt men bör utlösa ingenting under per-produkträkning. Bekräfta att den stannar på fullt pris. Tysta misslyckanden är fienden här, för en rabatt som brinner felaktigt kastar aldrig ett fel heller.

BILDPLATSHÅLLARE (Bild 3): Väljaren för räkningsmoden

Föreslagen visuell: En 16:9 produktskärmmockup av Stackable kampanjeditorräkningssteg. Visa tre valbara alternativ märkta "Per-variant, räkna den exakta SKU," "Per-produkt, räkna alla varianter av en produkt" (vald, violett markering), och "Per-grupp, räkna en handplockad uppsättning," var och en med en radflats engelskspråkig förhandsvisning under. Rensa Shopify Polaris adminöversättning, varumärkesaccentfärg i violett. Referera till dokumentationen/screenshot-manifest.md volym-rabatter-steg-1 slot för att fånga den riktiga skärmen senare.

Kör detta pålitligt med Stackable

Om du vill ha per-produkt- eller per-variantnivåer kan inte Shopify uttrycka dem inbyggt, och det är exakt gapet Stackable byggdes för att stänga, ärligt och inom Shopifys verkliga regler.

• Stackable ger dig räkningsmoden som ett explicit val: per-variant, per-produkt eller per-grupp, så tröskelvärdet räknar det du faktiskt avsåg istället för att slå ihop en hel samling per standard.
• Nivåerna håller från varukorg till kassa för att matematiken körs inuti en Shopify Function, så priset en köpare ser på produktsidan är priset de betalar vid kassan, inklusive på Shop Pay och andra accelererade kassor.
• Butiksfrontens nivåtabell uppdateras live när kunden ändrar kvantitet, utan sidladdning, markerar den aktiva nivån så nästa gränspunkt är alltid synlig.
• Stackable skriver aldrig om dina produktpriser. Nivåerna finns bara som kassajusteringar, så avinstallation lämnar din katalog exakt som den var.

Installera Stackable gratis och sätt en rabattnivå per produkt som räknar rätt vara, från varukorg till Shop Pay, på usestackable.com/pricing. 🚀

Slutresultatet

• Shopifys inbyggda volymrabatter räknar minimikvantiteten över alla berättigade varor i varukorg, inte per produkt, så orelaterade varor kan utlösa en nivå som är avsedd för en produkt.
• Att begränsa till en samling gör detta värre: varje produkt i samlingen matar ett delat tröskelvärde, och att lägga till en produkt senare ändrar tyst kampanjen.
• Tre räkningslägen täcker varje fall: per-variant (exakt SKU), per-produkt (alla varianter av en produkt) och per-grupp (en handplockad uppsättning). Shopify erbjuder bara något som liknar per-grupp, begränsat till en samling.
• Per-produkt är rätt standard för "köp mer av denna vara." Per-variant framtvingar exakt-SKU-nivåer och MOQ-golv. Per-grupp är för avsiktliga blanda-och-matchningspooler.
• Samlingspooling kostar pengar i båda riktningarna: det utlöser för lätt för bläddrande varukorgar och kan inte bort prissätta en per-produktbulknivå rent.
• Testa alltid en bör-tillämpas varukorg (nog av en produkt) och en bör-inte-tillämpas varukorg (en spridning av olika produkter), och läs kassasummans rad för rad.
• Verktyg som Stackable exponerar räkningsmoden explicit och kör nivåmatematiken i en Shopify Function, så nivån en köpare ser är nivån de betalar, från produktsidan till Shop Pay.

Relaterade artiklar

• Volymrabatter och kvantitetsbrytningar: ställ in nivåer som räknar den exakta produkten, med en live produktsidas nivåtabell.
• Per-produkträkning förklarad: per-variant, per-produkt och per-grupp i enkelt svenska, med utförda recept.
• Rabattstacking, gjort rätt: lagra en volumnivå med order- och frakt rabatter med hjälp av de tre per-klasskombinatörcheekerna.
• Stackable prissättning: planer, den fria nivån och vad varje innehåller.
• Hur rabattstacking fungerar i Shopify: varför inbyggd endast tillämpar den högsta rabatten, och hur man kombinerar erbjudanden korrekt.
• Upprepa flerkörningsavtal som omräknas per uppsättning: "4 för GBP 10, 8 för GBP 20" prissättning som återkommer per uppsättning istället för att rabattera en gång.