Native Shopify volumenrabatter tæller mængde på tværs af alle berettigede varer i kurven, ikke pr. individuelt produkt. Når du sætter en minimumsantal-rabat på en samling, lægger Shopify alle de kvalificerede enheder sammen, så en kunde, der køber 2 af ét produkt og 1 af et andet, kan udløse et niveau, du mente for køb af 3 af en enkelt vare. For at tælle det samme produkt eller den samme variant alene, skal du bruge per-produkt tælling, som native Shopify-rabatter ikke tilbyder. Du får det fra en app, der lader dig vælge hvad der tæller som "det samme produkt" før niveaumatematikken kører.
Denne guide forklarer præcis hvordan native mængderabatter tæller, de tre tællemodi (per-variant, per-produkt og per-gruppe) på klart dansk, hvorfor samling-pooling giver rabatter du aldrig mente, hvordan minimumsorderantal-priser fungerer, og et fuldt eksempel på spisestuestole tællet pr. stol. Du vil afslutte med at vide hvilken tællemodus der passer til hver promotion og hvordan du sætter det op, så niveauet en kunde ser er niveauet de faktisk betaler.
Hvordan tæller native Shopify volumenrabatter mængde?
Shopify's native rabatbygger kan absolut lave en volumenrabat. Du vælger "Beløb rabat på produkter", begrænser det til et produkt eller en samling, og tilføjer et minimumsantal af varer som købekrav. Den del virker. Problemet er ikke om du kan lave et niveau. Problemet er hvad niveauet tæller.
Når du sætter et minimumsantal, behandler Shopify det som en tærskel mod totalen af alle berettigede varer i kurven. Ifølge Shopify's udvikler-dokumentation er DiscountMinimumQuantity objektet "angiver det minimumsantal af varer, der kræves for rabatberettigelse" og "denne tærskel gælder for berettigede varer i kundens kurv." Eksemplet Shopify giver er en "Køb 3, få 10% rabat" kampagne, der sætter minimumsantallet til 3 varer. Intet i den regel siger tre af samme vare. Det siger tre berettigede varer, punktum.
Den samme pooling vises i Køb X få Y. Shopify's DiscountOnQuantity objekt driver gradueret "køb mere, spar mere" effekter, og Shopify beskriver det med et blandet eksempel: "Køb 4 lys, få 2 lys 50% rabat (blandet og match)." Blandet og match er nøgleordet. De fire lys, der låser up med tilbuddet, kan være alle fire lys i det berettigede sæt. De behøver ikke være samme lys. Og de nødvendige varer i en Køb X få Y rabat kan være, per DiscountCustomerBuysInput dokumentation, "enten samlinger eller produkter," med en enkelt mængdeværdi der dækker hele sættet.
Så native adfærd, verificeret mod shopify.dev, er konsistent på tværs af rabattyper: mængdetærsklen tæller hver berettiget linjepunkt sammen. Begræns rabatet til en samling og hele samlingen fodrer et delt tal. Det er fint for en butiks-bred "spar mere, spar mere" push. Det er forkert for "køb mere af dette specifikke produkt."
BILLEDE PLACEHOLDER (Billede 1): Hvordan native tælling pooler en samling
Foreslået visual: Et rent 16:9 diagram på hvid baggrund. Venstre side viser en kurv med tre forskellige stol-produkter, mængder 2, 1 og 1, hver en tydelig siluet i skifergråt. En stor violet pil mærket "native minimumsantal: tæller alle berettigede varer" peger på en enkelt poolet tæller læsning "4 enheder til en delt tærskel." Et lille rødt flag læser "ikke 4 af samme stol." Fladt vektorgrafik stil, brand farver violet og guld, sans-serif etiketter, ingen fotografi.
Hvorfor samlings-scope gør dette værre, ikke bedre
Forretninger når for en samling fordi det føles som den rigtige beholder. "Jeg sælger fem spisestuestole, jeg vil sætte dem i en Stole-samling og sætte rabatet der." Det er det intuitive træk, og det er præcis det træk der bryder hensigten.
Når rabatet er begrænset til den samling, skelner Shopify ikke mellem de fem stole i den. Hver enhed af hver stol tæller mod samme tærskel. Tilføj senere et produkt til samlingen og det deltager stille i tællingen også. Forhandlere på Shopify-forumerne beskriver dette præcis: de ønsker niveauer "pr. specifik stol, ingen pooling på tværs af produkter," og Shopify-support bekræfter native rabatter kan ikke "tælle samme produkter kun." Samlingen er et filter for berettigelse, ikke en grænse for tælling.
Hvad er de tre tællemodi?
Hver mængdebaseret rabat skal besvare et spørgsmål før den laver noget matematik: hvad tæller som "det samme produkt"? Der er tre fornuftige svar, og det rigtige afhænger helt og holdent af kampagnen. At nævne dem eksplicit er hele spillet, fordi native Shopify giver dig kun altid det bredeste.
Per-variant: tæl kun den nøjagtige SKU
Per-variant tælling behandler hver variant som sin egen ø. En stor t-shirt og en mellemstor t-shirt af samme stil tæller separat, mod separate tærskler. A3 og A4 størrelse af samme plakat pooler aldrig.
Brug per-variant når dine varianter er effektivt forskellige produkter til prisissætning. Print størrelser der koster virkelig forskellige beløb at producere, materialer der bærer forskellige margener, eller hvad som helst hvor "5 af denne nøjagtige SKU" er den rigtige enhed af aftalen. Hvis en kunde ikke skal kunne nå et niveau ved at blande størrelser, er per-variant den tilstand der gennemtvinger det.
Per-produkt: tæl hver variant af ét produkt sammen
Per-produkt tælling er det de fleste forretninger faktisk mener når de siger "køb mere af denne vare." Hver variant af en enkelt produktside tæller mod samme niveau. Alle størrelser og farver af en t-shirt-stil lægges sammen, men en anden t-shirt-stil bidrager ikke.
Dette er den fornuftige standard for volumen-niveauer. En møbelforretning, der sælger en spisestuestol i fire finisher, ønsker alle fire finisher at tælle som "stolen," fordi for kunden er de stolen. To eg plus to valnød er fire stole, og det skal ramme fire-stol-niveauet. Per-produkt får det rigtige mens det stadig nægter at tælle en helt anden stol-model.
Per-gruppe: hånd-vælg et lille sæt af relaterede produkter
Per-gruppe tælling lader dig nominere et specifikt, eksplicit sæt af produkter, der skal dele en tærskel. En "starter kit" af en renser, en toner og en fugtighed kan tælle sammen, så alle tre enheder trukket fra det trio låser op for aftalen, uden at trække hele dit katalog ind i tællingen.
Per-gruppe er den tættest tilstand til Shopify's native samlings-adfærd, og det er pointen. Brug det bevidst når du virkelig ønsker en blandet og match pool, som en butiks-bred "alle 6 varer, 10% rabat" kampagne. Forskellen fra native er at du vælger poolet med vilje, vare for vare, i stedet for at arve det ved et uheld fra hvad der tilfældigvis sidder i en samling.
Den ene mental model at holde fast på: native Shopify tilbyder kun noget som per-gruppe, begrænset til en samling, hvad enten du ønskede det eller ej. Per-variant og per-produkt er de to tilstande native tælling ikke kan udtrykke, og de er de to tilstande de fleste forretninger faktisk har brug for.
Hvorfor giver samlings-pooling kunder den forkerte rabat?
Her er det konkrete fiasko, og det skærer begge veje.
For det første udløses det for let. Du mente "køb 3 af denne stol, få 15% rabat." En kunde tilføjer en af hver af tre forskellige stole, rammer den delte tærskel på 3, og får 15% rabat på alle tre. Det er ikke det lojali-adfærd du prisissatte til. Du ønskede at belønne forpligtelse til ét produkt. I stedet diskonterede du en browse-y eksempel-kurv, og du gav margin bort på enheder der aldrig ville bevæge sig sammen i volumen.
For det andet, og mindre indlysende, kan det under-belønne kunden du gjorde ønsket. Hvis dine niveauer eskalerer (3 til 5 enheder ved 15%, 6 til 9 ved 18%, 10 eller mere ved 20%) og tællingen pooler på tværs af en hel samling, bliver matematik mudret hurtigt. En engros-køber der tager 10 af en stol sidder i samme poolede spand som en detail-shopper der griber 2 af tre forskellige stole. Du kan ikke rent prissætte et per-produkt bulk-niveau når tælleren ikke ved hvilke enheder der tilhører hvilket produkt.
For det tredje er det skrøbeligt at vedligeholde. Fordi samlingen definerer tællingen, redigerer redigering af samlingen kampagnen. Tilføj en sæson-stol til Stole-samlingen og alle køber af den nye stol bidrager nu til, og drager fordel af, et niveau du designede måneder siden til forskellige produkter. Intet fejler. Rabattet starter bare stille hen ad vejen at opføre sig anderledes. Stilfejl som dette er samme klasse af problem der gør forretninger mistænk rabat-værktøjer i første omgang: kurven viser stadig et tal, det er bare det forkerte tal.
Reparationen er ikke en klogere samling. Det er tælling pr. produkt så tærsklen betyder hvad du troede den gjorde.
Hvad er minimumsorderantal (MOQ) prissætning, og hvordan giver per-produkt tælling mulighed for det?
Minimumsorderantal prissætning er engros- og bulk-mønsteret hvor et produkt simpelt hen ikke er tilgængeligt, eller ikke diskonteret, under et gulv-antal, og derefter tjener en fast sats over den. "Ingen handels-pris under 12 enheder. Ved 12 eller mere, denne enhedspris." Det er hvordan en masse B2B og made-to-order kataloger virker.
MOQ prissætning lever eller dør på per-produkt eller per-variant tælling, fordi gulvet skal betyde "12 af denne ting," ikke "12 af hvad som helst i kategorien." Hvis tællingen pooler på tværs af en samling, montering en køber 12 blandede enheder og krav om en engros-sats på en detail-ordre. Det er det modsatte af hvad MOQ er til.
Med per-variant tælling bliver MOQ eksakt: ingen rabat under 12 enheder af samme SKU, derefter en fast enhedspris-tilsidesættelse ved 12 og op. Detailkøbere under gulvet betaler fuld pris. Bulk-købere krydser gulvet på et enkelt produkt og plukker automatisk engros-enhedsprisen op, uden separate primlister at vedligeholde og ingen udkast-ordre workaround. Tællemoden gør håndhævelsen, hvilket er hvorfor at få tilstanden rigtig betyder mere end niveautalene.
Arbejdet eksempel: spisestuestole niveauer tællet pr. stol
Lad os gøre dette konkret med det nøjagtige scenarie forretninger holder beskriver på forumerne. En møbelbutik sælger flere spisestuestol-stilarter og ønsker en per-stol volumen-aftale på en af dem:
- 3 til 5 stole: 15% rabat
- 6 til 9 stole: 18% rabat
- 10 eller flere stole: 20% rabat
Hensigten er streng. Niveauet skal tælle den stol (alle finisher sammen), det skal kræve et minimum af 3 at starte, og det må ikke pooler med de andre stol-stilarter i samlingen. Her er hvordan den samme kurv opløser sig under native samlings-pooling versus per-produkt tælling.
Kig på rækker tre og fire. Disse er tilfælde der adskiller en kampagne der virker fra en der lækker margin. Under native pooling, fire ikke-relaterede enheder kan låse op for et niveau beregnet til køb af fire af en stol. Under per-produkt tælling, kun ægte forpligtelse til den stol (i alle finisher) når niveauet, præcis som ment. Bulk-rækkerne virker stadig perfekt, fordi per-produkt tælling tilføjer hver finisher af stolen sammen før den kontrollerer tærsklen.
Dette er også hvor minimum af 3 gør sit arbejde rent. Fordi tællingen er pr. produkt, "mindst 3 af denne stol" er utvetydig. Der er ingen måde at tilfredsstille den med en spredning af engangsvarer, hvilket er præcis det smuthul samlings-pooling efterlader åbent.
BILLEDE PLACEHOLDER (Billede 2): Samme kurv, to tællemodi, to totaler
Foreslået visual: Et 16:9 split-panel illustration. Venstre panel mærket "Native: poolet på tværs af samling" viser en kurv af fire forskellige stole med et grønt 15% badge og et lille rødt advarsels "ubetvunget niveau." Højre panel mærket "Per-produkt: tæller samme stol" viser den identiske fire-forskellige-stole kurv med ingen rabat og en rolig grå "no tier, som ment" note. Nedenfor, anden rækker viser fire af samme stol tjener 15% i begge panels. Brand farver violet og guld, fladt vektorgrafik, ingen fotografi.
Hvordan du sætter op per-produkt volumen rabatter, trin for trin
Du kan lave en poolet volumen rabat nativt på et par minutter. Hvad native ikke kan gøre er vælge tællemoden, så per-produkt og per-variant niveauer har brug for en app der viser tælling som en eksplicit indstilling. Her er den pålidelige sekvens, uanset hvilken rute du tager.
1. Beslut hvad "det samme produkt" betyder for denne kampagne
Før du rører nogen bygger, skriv sætningen ud. "Køb mere af denne nøjagtige SKU" er per-variant. "Køb mere af dette produkt i alle varianter" er per-produkt. "Køb alle blanding fra dette specifikke sæt varer" er per-gruppe. Denne ene beslutning bestemmer alt nedstrøms, og det er den beslutning native Shopify laver for dig (altid den bredeste).
2. Vælg tællemoden eksplicit
I et værktøj der understøtter det, sæt tællemoden først, ikke sidst. Per-produkt er den sikre standard for et "køb mere af denne vare" niveau. Skift til per-variant når forskellige varianter er virkelig forskellige produkter til prissætning, som print-størrelser eller materialer. Reservér per-gruppe til bevidst blanding og match puljer, og vælg medlemmerne for hånden.
3. Sæt dine niveau-brudpunkter
Tilføj mængde-og-rabat-parene din strategi har brug for: 3 til 5, 6 til 9, 10 eller mere, hver med sin egen procent eller fast beløb. For MOQ-prissætning, gør det første niveau start ved dit gulv (for eksempel, 12 eller mere) og efterlad alt under det til fuld pris. En fast enhedspris-tilsidesættelse, i stedet for en procent, er ofte det renere udtryk for en engros-sats.
4. Begræns tilbuddet til det rigtige produkt eller sæt
Attach niveauerne til det specifikke produkt for per-produkt, eller den specifikke variant for per-variant. Hvis du bruger per-gruppe, er dette hvor du nominerer medlemmerne. Hent scope snævrt. Tællemoden håndterer allerede hvad der pooler sammen, så du har ikke behov for en spredt samling for at få det til at fungere.
5. Vis niveauerne på produkt-siden
En mængde-rabat kunden ikke kan se er en mængde-rabat der ikke konverterer. Vis niveau-tabellen på produktsiden så shoppere kan se det næste brudpunkt og besparelsen. Tabellen skal opdatere live mens de ændrer mængde, med ingen side reload, og det fremhævede niveau skal altid matche hvad checkout vil debitere.
6. Test en skal-anvende og en skal-ikke-anvende kurv
Byg en kurv der køber nok af det ene produkt til at ramme hver niveau, placer et udkast eller test ordre, og læs checkout-resumélinjen for linjer for at bekræfte det rigtige niveau fårede. Derefter byg fælde kurven: en spredning af forskellige produkter der ville udløse en poolet rabat men skulle udløse ingenting under per-produkt tælling. Bekræft det holder til fuld pris. Stille fejl er fjenden her, fordi en rabat der affyrer forkert kaster aldrig en fejl enten.
BILLEDE PLACEHOLDER (Billede 3): Tællemodus-vælgeren
Foreslået visual: Et 16:9 produkt-screenshot mockup af Stackable kampagne-editor Tælling trin. Vis tre valgbare indstillinger mærket "Per variant, tæl den nøjagtige SKU," "Per produkt, tæl alle varianter af et produkt" (valgt, violet markering), og "Per gruppe, tæl et hånd-valgt sæt," hver med en-linje klart engelsk forhåndsvisnings sætning under. Rent Shopify Polaris admin stilering, brand accent i violet. Reference dokumenterne /screenshot-manifest.md slot volume-discounts-step-1 for at fange den rigtige skærm senere.
Kør dette pålideligt med Stackable
Hvis du ønsker per-produkt eller per-variant niveauer, kan native Shopify ikke udtrykke dem, og dette er præcis gabet Stackable blev bygget til at lukke, ærligt og inden for Shopify's virkelige regler.
- Stackable giver dig tællemoden som et eksplicit valg: per-variant, per-produkt eller per-gruppe, så tærsklen tæller hvad du faktisk mente i stedet for pooling en hel samling som standard.
- Niveauer holder fra kurv til checkout fordi matematik kører inden for en Shopify Function, så prisen en shopper ser på produktsiden er prisen de betaler ved checkout, herunder på Shop Pay og andre accelererede checkouts.
- Storefront niveau-tabellen opdaterer live mens kunden ændrer mængde, med ingen side reload, markering af det aktive niveau så det næste brudpunkt altid er synlig.
- Stackable omskriver aldrig dine produkt-priser. Niveauerne eksisterer kun som checkout-justeringer, så afinstallation efterlader dit katalog præcis som det var.
Installer Stackable gratis og opsæt et rabattrin per produkt, der tæller den rigtige vare, fra kurv til Shop Pay, på usestackable.com/pricing. 🚀
Bundlinen
- Native Shopify volumenrabatter tæller minimumsantal på tværs af alle berettigede varer i kurven, ikke pr. produkt, så ikke-relaterede varer kan udløse et niveau beregnet til et produkt.
- Scope til en samling gør dette værre: hvert produkt i samlingen fodrer en delt tærskel, og tilføjelse af et produkt senere ændrer stilfart kampagnen.
- Tre tællemodi dækker alle tilfælde: per-variant (nøjagtig SKU), per-produkt (alle varianter af et produkt) og per-gruppe (et hånd-valgt sæt). Native Shopify tilbyder kun noget som per-gruppe, skopet til en samling.
- Per-produkt er det rigtige standard for "køb mere af denne vare." Per-variant gennemtvinger nøjagtige-SKU-niveauer og MOQ-gulve. Per-gruppe er til bevidst blanding og match puljer.
- Samlings-pooling koster penge i begge retninger: det udløses for let til browse-y kurve og kan ikke rent prissætte et per-produkt bulk-niveau.
- Test altid en skal-anvende kurv (nok af et produkt) og en skal-ikke-anvende kurv (en spredning af forskellige produkter), og læs checkout-resumé linjen for linjer.
- Værktøjer som Stackable viser tællemoden eksplicit og kører niveau-matematikin en Shopify Function, så niveauet en shopper ser er niveauet de betaler, fra produktsiden til Shop Pay.
Relaterede artikler
- Volumenrabatter og mængde-brud: sæt niveauer der tæller det nøjagtige produkt, med en live produkt-side niveau-tabel.
- Per-produkt tælling forklaret: per-variant, per-produkt og per-gruppe på klart dansk, med arbejdede opskrifter.
- Rabat-stabling, gjort rigtigt: lag et volumen-niveau med ordre og forsendelse rabatter ved hjælp af de tre per-klasse kombinere switch.
- Stackable prissætning: planer, det gratis niveau, og hvad hver inkluderer.
- Hvordan rabat-stabling virker i Shopify: hvorfor native kun anvender den højeste rabat, og hvordan man korrekt kombinerer tilbud.
- Gentagne multibuy-aftaler der genberegnes pr. sæt: "4 for GBP 10, 8 for GBP 20" prissætning der gentager pr. sæt i stedet for rabattering en gang.
