Kupon mantığı tuzakları: sepetleri bozmayacak birleştirme kuralları

Neden promosyon mantığı bu kadar sık bozuluyor

Promosyonlar basit görünür, ta ki gerçek bir ödeme akışına koyana kadar. Sepet sürekli değişir, ancak indirim kuralları genellikle tek seferlik kontroller olarak yazılır. Bu fark, kupon mantığı tuzaklarının çoğunun ortaya çıktığı yerdir.

Zor olan taraf şu: tek bir yeni kural her yere etki edebilir. "İndirimli ürünlerde geçerli değil" şeklinde bir "%10 indirim" eklerseniz, "indirimli"nin ne anlama geldiğini, ne zaman kontrol edildiğini ve %10'un hangi tutara uygulanacağını kararlaştırmanız gerekir. Başka bir promosyon aynı ürünlere dokunuyorsa, uygulama sırası önem kazanır ve sıra fiyatı değiştirir.

Birçok ekip ayrıca matematiği iş kurallarıyla karıştırır. "İndirimi ara toplamla sınırla" gibi hızlı bir düzeltme üç yere kopyalanır ve yakında toplam farklı yerlerde (sepet sayfası, ödeme, fatura, e-posta) farklı sonuçlar verir.

Riskli anlar, sisteminizin fiyatları yeniden hesapladığı anlardır:

• Sepet güncellemeleri: miktar değişti, ürün çıkarıldı, kargo yöntemi değişti
• Ödeme sonrası düzenlemeler: adres değişikliği, kısmi iptaller, ürün ikameleri
• İadeler ve geri ödemeler: ürünler arasında prorata hesaplama, vergi ayarlamaları, mağaza kredisi
• Çoklu para birimi veya vergi modu değişiklikleri: net vs brüt fiyatlandırma, vergi dahil toplamlar

Küçük bir örnek: bir müşteri bir paket ekler, sonra "100$ üzeri 20$ indirim" kodu uygular, sonra bir ürün çıkarır. Kodunuz eski ara toplamı "hatırlamaya" devam ederse, 85$'lık sepete 20$ indirim verebilir ya da bir ürün satırını negatif gösterebilir.

Bu yazının sonunda en sık görülen promosyon hatalarını önleyebiliyor olmalısınız: çift indirim, ekranlar arasında uyuşmayan toplamlar, negatif tutarlar, hariç tutulmuş ürünlere uygulanan indirimler ve müşterinin aslında ödediğiyle eşleşmeyen iadeler.

Açık birleştirme (stacking) ve öncelik kurallarıyla başlayın

Çoğu kupon mantığı tuzağı bir eksik cümleyle başlar: hangi indirimlerin birlikte uygulanmasına izin veriliyor ve hangi sırayla. Yığın kurallarını açık bir dille açıklayamıyorsanız, sepetiniz sonunda şaşırtıcı bir şey yapacaktır.

Birleştirmeyi basit evet/hayır ifadeleriyle tanımlayın. Örneğin: "Sipariş başına bir manuel kupon. Kuponun engellediği belirtilmedikçe otomatik promosyonlar yine de uygulanabilir." Bu tek satır, çift indirimlemeye yol açan rastgele kombinasyonları önler.

Erken aşamada ürün düzeyindeki indirimleri sipariş düzeyindeki indirimlerden ayırın. Ürün düzeyindeki kurallar belirli ürünlerin fiyatını değiştirir (ör. ayakkabılarda %20). Sipariş düzeyindeki kurallar toplamı değiştirir (ör. sepette 10$ indirim). Bunları yapısız karıştırmak, ürün sayfası, sepet ve ödeme arasında toplamların sürüklenmesine yol açar.

"En iyi fırsat"ın ne anlama geldiğine kod yazmadan önce karar verin. Birçok ekip "azami tasarruf" seçer, ancak bu fiyat tabanlarını bozabilir. Ayrıca "maliyetin altına asla indirmeyin" veya "kargoyu negatif yapmayın" gibi kurallara ihtiyaç duyabilirsiniz. Motorun tahmin yürütmemesi için tek bir açık kazanan kural seçin.

Basit bir öncelik sırası çakışmaları öngörülebilir kılar:

• Otomatik promosyonlar önce (katalog veya sezon kuralları)
• Manuel kupon sonra (müşterinin girdiği)
• Mağaza kredisi veya hediye kartı en son (ödeme aracı, indirim değil)
• Vergi ve kargo indirimlerden sonra yeniden hesaplanır

Örnek: Sepette tüm ürünlerde %10 otomatik promosyon ve 100$ üzeri 15$ indirim kuponu varsa, önceliğiniz otomatik promosyonlar ise şu soruya net cevap verirsiniz: 100$ eşiği indirim öncesi ara toplam mı yoksa indirimli ara toplam mı kullanılarak kontrol edilir? Yazın ve her yerde tutarlı olun.

Bu tercihleri yazılı hale getirdiğinizde, kupon yığılma kurallarınız gizli davranışlar değil test edilebilir kurallar olur. Bu, kupon mantığı tuzaklarından kaçınmanın en hızlı yoludur.

İndirimleri basit, açık veri olarak modelleyin

Çoğu kupon mantığı tuzağı, indirimlerin ödeme kodunun çeşitli yerlerine saçılmış if-else kontrolleri olarak yaşadığı zaman başlar. Daha güvenli bir yaklaşım, her promosyonu açık bir tip, kapsam ve limitlerle verisel olarak ele almaktır. Böylece sepet matematiğiniz küçük ve öngörülebilir bir değerlendirici olur.

Önce indirim tipine isim verin, pazarlama ifadesine değil. Çoğu promosyon birkaç biçime uyar: yüzde indirim, sabit tutar indirimi, ücretsiz ürün (veya X al Y bedava) ve ücretsiz kargo. Bir promosyonu bu türlerden biriyle ifade edebildiğinizde, test edilmesi zor özel durumlardan kaçınırsınız.

Sonra kapsamı açık hale getirin. Aynı yüzde indirimi hedeflediği şeye göre çok farklı davranır. Uygulandığı yerin tüm sipariş mi, bir kategori mi, bir ürün mü, tek bir satır mı yoksa kargo mu olduğunu tanımlayın. Kapsam net değilse yanlış ara toplamı indirgersiniz veya iki kez indirim uygularsınız.

Kısıtlamaları kod yorumları olarak değil alanlar (fields) olarak yakalayın. Yaygın olanlar asgari harcama, sadece ilk sipariş için geçerli olma ve tarih aralığıdır. Ayrıca indirimli fiyatlarla nasıl davranması gerektiğini de kaydedin: üst üste binebilir, liste fiyatına uygulanır ya da indirimli ürünleri dışlar.

Kompakt bir kural şeması şunları içerebilir:

• type (percent, fixed, free_item, free_shipping)
• scope (order, category, product, item, shipping)
• constraints (min_spend, first_order, start_at, end_at)
• floors (min_total = 0, min_item_price, optional min_margin)
• rounding policy (per item vs per order)

Son olarak, motorun her zaman uyması gereken fiyat tabanları ekleyin: toplamlar asla sıfırın altına düşemez ve iş gereksinimi varsa ürünler asla maliyetin altına (veya tanımlı bir minimum fiyatın altına) inemez. Bunu önden kurarsanız, negatif toplamları ve garip "müşteriye ödeme yapıyoruz" uç durumlarını önlersiniz.

Eğer bir indirim motoru prototipini Koder.ai içinde yapıyorsanız, bu alanları planlama modunda görünür tutun ki değerlendirme ekleyici promosyonlar eklendikçe basit ve test edilebilir kalsın.

Adım adım: promoları güvenli değerlendirme yolu

Çoğu kupon mantığı tuzağı, uygunluk kontrolleri ile matematiğin karıştığı yerde başlar. Daha güvenli bir desen iki aşamalıdır: önce hangi promosyonların uygulanabileceğine karar verin, sonra tutarları hesaplayın. Bu ayrım kuralları okunabilir kılar ve kötü durumları (örn. negatif toplamlar) önlemeyi kolaylaştırır.

Deterministik bir değerlendirme sırası

Her zaman aynı sırayı kullanın, promosyonlar UI veya API'den farklı bir sırada gelse bile. Determinizm önemlidir çünkü "neden bu sepet değişti?" sorusunu yanıtlanabilir hale getirir.

İyi çalışan basit bir akış:

• Doğrula girişleri: kupon kodu formatı, tarih penceresi, müşteri kapsamı, para birimi ve fiyatların negatif olmadığı kontrolü.
• Uygun promosyonları seç: sadece uygunluk çalıştırın (henüz para hesaba katılmasın). Aday listesi oluşturun.
• Yığın ve önceliği çöz: yığın kurallarınızı uygulayın (ör: "bir siparişe en fazla bir sipariş düzeyi promosyonu") ve eşitlikleri kırma (öncelik, sonra en iyi değer, sonra kalıcı ID).
• Hesaplamaları uygula: indirimleri tutarlı bir tabana göre hesaplayın (vergiden önce vs sonra, kargo dahil mi değil mi) ve yuvarlama kurallarını kullanın.
• Toplamları özetle: satır toplamlarından sipariş toplamını yeniden hesaplayın, sonra sıfırda sınırla ve maksimum indirim limitlerini uygula.

Bir döküm ve denetim izi tutun

Promoları uyguladığınızda sadece tek bir "indirim toplamı" saklamayın. Satır bazında ve sipariş düzeyinde bir döküm tutun ki toplamları mutabık hale getirebilesiniz ve açıklayabilesiniz.

En azından şunları kaydedin:

• Hangi kural veya promosyon uygulandı (ID ve versiyon) ve önceliği
• Neden uygulandı (ör: "kategori=ayakkabı", "sepet ara toplamı \u003e= 50" gibi uygunluk gerçeği)
• Ne değiştirdi (etkilenen satır ID'leri, baz tutar, indirim tutarı, yuvarlama)
• Ne engellediği (örn: "hariç tutma ile engellendi: zaten ürün düzeyi indirimi var")

Örnek: Sepette iki ürün var, biri zaten indirimde. 1. aşama kodu yalnızca tam fiyatlı ürün için uygun olarak işaretler. 2. aşama o satıra %10 uygular, indirimdeki satırı olduğu gibi bırakır ve sonra satır dökümünden sipariş toplamını yeniden hesaplar; böylece yanlışlıkla çift indirim uygulanmaz.

Spagetti mantık oluşturmadan hariç tutmaları kodlayın

Çoğu kupon mantığı tuzağı, hariç tutmaların "eğer kod X ise Y'yi atla" gibi özel durum dallanmalarının içine gizlendiği zaman başlar. Bu bir promosyon için işe yarar, sonra bir sonraki promosyon geldiğinde bozulur.

Daha güvenli desen: tek bir değerlendirme akışını koruyun ve hariç tutmaları promosyon kombinasyonunu hesaplamadan önce reddedebilen bir dizi kontrol olarak tutun. Böylece indirimler asla yarım uygulanmaz.

Hariç tutmaları kod yerine veri olarak ele alın

Davranışları kodlamak yerine her promosyona küçük, açık bir "uyumluluk profili" verin. Örneğin: promosyon türü (kupon vs otomatik indirim), kapsam (ürünler, kargo, sipariş) ve kombinasyon kuralları.

Hem şunu destekleyin:

• "Birleştirilemez" listesi (denylist): promosyon A, promosyon B'yi engeller.
• "Yalnızca şu ile birleştirilebilir" listesi (allowlist): promosyon A yalnızca belirtilen küme ile yığını olabilir.
• "otomatik satışları engeller" veya "başka kupon gerektirmez" gibi kural bayrakları.

Anahtar nokta: motorunuz her promosyon için aynı soruları sorsun, sonra kümenin geçerli olup olmadığına karar versin.

Çakışmaları açık yapın, otomatik satışlar dahil

Otomatik satışlar genellikle önce uygulanır, sonra bir kupon girilir ve otomatik satış sessizce üzerine yazılır. Önceden ne olacağını belirleyin:

• Kupon satışın üstüne yığılır
• Kupon sadece satış olmayan ürünlere uygulanır
• Kupon satış varsa reddedilir

Her promosyon için bir tercih seçin ve bunu ayrı bir kontrol olarak kodlayın, alternatif bir hesaplama yolu olarak değil.

Sürprizleri önlemenin pratik yolu simetriyi doğrulamaktır. Eğer "WELCOME10, FREESHIP ile birleştirilemez" düşünülüyorsa, bunu iki yönlü engelleyecek şekilde kodlayın. Eğer iki yönlü değilse, bunun kasıtlı ve veride görünür olduğundan emin olun.

Örnek: Site genelinde %15 otomatik satış varken müşteri %20 kupon girerse ve kupon sadece tam fiyatlı ürünler içinse, kontroller kupon için satışlı ürünleri hesaplamadan önce hariç tutmalıdır; indirim uygulayıp sonra sayıları düzeltmeye çalışmamak gerekir.

Eğer indirim kurallarınızı Koder.ai gibi bir platformda oluşturuyorsanız, bu kontrolleri ayrı, test edilebilir bir katman olarak tutun ki kuralları değiştirmek için matematiği yeniden yazmanız gerekmesin.

Uyuşmayan toplamlara yol açan uç durumlar

Çoğu kupon anlaşmazlığı başlık indirimiyle ilgili değildir. Aynı sepetin iki hafif farklı yolla hesaplandığı ve müşterinin bir sayı gördüğü, ödeme ekranında başka bir sayı olduğu durumlarda çıkar.

İşlem sırasını kilitleyerek başlayın. Ürün düzeyi indirimlerin sipariş düzeyi indirimlerden önce mi sonra mı olduğunu ve kargonun nereye girdiğini belgeleyin. Yaygın bir kural: önce ürün indirimleri, sonra kalan ara toplam üzerinden sipariş indirimi, son olarak kargo indirimleri. Ne seçerseniz seçin, toplam gösterdiğiniz her yerde aynı sıralamayı kullanın.

Vergi bir sonraki tuzaktır. Fiyatlar vergi dahil ise, indirim vergi payını da küçültür. Fiyatlar vergi hariçse, vergi indirim sonrası hesaplanır. Akışın farklı bölümlerinde bu modelleri karıştırmak klasik hatalardan biridir çünkü iki doğru hesaplama bile farklı vergi tabanları varsayıyorsa uyuşmayabilir.

Yuvarlama küçük görünür ama büyük destek biletleri yaratır. Her satır için (indirim sonrası her SKU) mi yoksa yalnızca sipariş düzeyinde mi yuvarlanacağına karar verin ve para birimi hassasiyetine bağlı kalın. Yüzde kuponlarda, satır yuvarlaması çok sayıda düşük fiyatlı ürünle sipariş yuvarlamasından birkaç kuruş sapma yaratabilir.

Aşağıdaki uç durumları açıkça ele alın:

• İadeler ve kısmi geri ödemeler: iadelerde indirimleri ürünlere prorata dağıtın ki geri ödeme ödenenden fazla olmasın.
• Kupon uygulandıktan sonra sepet düzenlemeleri: öğe eklenip çıkarıldığında uygunluğu ve sınırları yeniden değerlendirin.
• Kargo değişiklikleri: adres veya yöntem değişikliği vergilendirilebilir tutarları ve kargo indirimi uygunluğunu değiştirebilir.
• Miktar değişiklikleri: aynı ürünün tekrarı eşikleri geçebilir (ör. min harcama veya al-X-kazan-Y durumları).
• Karışık vergilendirilebilir ürünler: bazı ürünler vergiden muaf olabilir ama yine de kuponlara uygun olabilir.

Somut örnek: %10 sipariş kuponu ve 50$ üzeri ücretsiz kargo. Eğer kupon eşiği kontrolünden önce uygulanıyorsa, indirimli ara toplam 50$'ın altına düşebilir ve kargo artık ücretsiz olmaz. Bir yorum seçin, kural olarak kodlayın ve sepet, ödeme ve iade işlemlerinde tutarlı hale getirin.

Yaygın promosyon hataları ve nasıl ortaya çıkarlar

Çoğu kupon mantığı tuzağı sepetin birden fazla yol üzerinden değerlendirilmesiyle ortaya çıkar. Bir promosyon bir yerde satır düzeyinde uygulanırken başka bir yerde sipariş düzeyinde tekrar uygulanabilir ve her ikisi de izole halde "doğru" görünebilir.

En sık görülen hatalar ve arkasındaki nedenler:

• Aynı öğelerin çift indirimlenmesi: aynı promosyon bir kez ürün fiyatlandırmasında ve tekrar sipariş toplamı hesaplanırken uygulanır; genellikle iki servis de "yardımcı olmak" ister.
• Negatif toplamlar veya negatif satır tutarları: sabit tutarlı indirim, uygun tutarı aşmasına izin verilir (ör. 12$ uygun ara topluma 20$ indirim uygulanması) ve sıfır tabanı yoktur.
• Yüzde indirimin yanlışlıkla zaten indirilen fiyata uygulanması: kural "liste fiyatından %10" demesine rağmen motor mevcut fiyatı baz alır.
• Asgari harcamanın yanlış ara toplama karşı kontrol edilmesi: kural ön indirim ara toplamına bakarken iş bekliyorsa sonrasında uygulama şaşırtıcı sonuçlar verir.
• Hariç tutulmuş ürünlerin yine de kupondan etkilenmesi: uygunluk ürün etiketlerine dayanır, ama etiketleme eksik veya tutarsızsa (veya bir geri dönüş yolu varsa) bilinmeyen öğeler uygun kabul edilir.

Somut örnek: Sepette iki ürün var, biri uygun diğeri hariç tutulmuş. Motor yüzde promosyon için uygun ara toplamı doğru hesaplasa da daha sonra sabit indirimi tüm sipariş toplamından düşerse, hariç tutulmuş ürün etkilenmiş olur.

En güvenli desen, her promosyonu açık bir "uygun tutar"a karşı hesaplamak ve sınırlı bir düzeltme döndürmektir (asla sıfırın altına düşmeyen), ayrıca hangi satırları etkilediğine dair açık bir iz. Eğer indirim motorunuzu Koder.ai gibi bir araçla üretirseniz, çıktının izi düz veri olarak olsun ki testler hangi satırların uygun olduğunu ve hangi ara toplamın kullanıldığını netçe iddia edebilsin.

Kurallarınızı doğru test takımıyla test edilebilir kılın

Çoğu kupon mantığı tuzağı testlerin sadece nihai toplamı kontrol etmesinden kaynaklanır. İyi bir test takımı hem uygunluğu kontrol eder (bu promosyon uygulanmalı mı?) hem de matematiği (ne kadar indirim yapmalı?), ve okunabilir bir döküm sağlar ki zaman içinde karşılaştırılabilsin.

Küçükten gerçeğe doğru testler oluşturun

Önce tek bir kuralı izole eden birim testleriyle başlayın. Girdiyi küçük tutun, sonra gerçek sepet senaryolarına genişletin.

• Uygunluk birim testleri: promosyon müşteri türü, tarihler, ürün etiketleri ve minimum harcamaya göre uygulanmalı mı?
• Matematik birim testleri: belirli bir uygun ara toplam verildiğinde hesaplama yuvarlama ve para birimi kurallarına uyuyor mu?
• Senaryo testleri: karışık ürünler, miktarlar, kargo, vergi ve birkaç promosyonun yarıştığı durumlar.
• "Sepet değişti" testleri: fiyat güncellendi, ürün çıkarıldı veya miktar ödeme ve değerlendirme arasında değişti.
• Döküm altın-görüntü (snapshot) testleri: beklenen satır bazlı indirim dağılımını saklayın, sadece nihai toplamı değil.

Kapsama sahip olduktan sonra birkaç "her zaman doğru" kontrol ekleyin. Bunlar elle yazmadığınız garip durumları yakalar.

• Toplam asla 0.00'ın altına düşmez.
• Bir indirim toplamı asla toplamı arttırmaz.
• Uygulanan indirim, uygun bazından daha büyük olamaz.
• Uygun olmayan bir öğeyi kaldırmak indirim tutarını büyütmemelidir.

Küçük bir sepet örneği

2 üründen oluşan bir sepet hayal edin: 40$ gömlek (uygun) ve 30$ hediye kartı (hariç). Kargo 7$. Bir promosyon "giyim %20 indirim, maksimum 15$", ikinci promosyon ise "50$ üzeri siparişlere 10$" ve yüzde promosyonlarla birleştirilemez.

Senaryo testiniz hangi promosyonun (öncelik) kazandığını, hediye kartının dışlandığını ve tam tahsisi doğrulamalı: 40$'ın %20'si 8$ eder, kargo değişmez, nihai toplam doğru olmalı. Bu dökümü altın görüntü olarak saklayın ki sonraki düzenlemeler hangi promosyonun uygulandığını veya hariç tutmanın değişmeye başladığını sessizce değiştirmesin.

Hızlı lansman öncesi kontrol listesi

Yeni bir promosyonu yayına almadan önce, müşterilerin anında fark edeceği hataları yakalayan kısa bir kontrolden geçirin: garip toplamlar, kafa karıştırıcı mesajlar ve tutarsız iadeler. Bu kontroller aynı zamanda en yaygın kupon mantığı tuzaklarını yakalar çünkü kurallarınızın her sepette aynı davranmasını zorunlu kılar.

Bu kontrolleri küçük bir "bilinen zorlu" sepet setine karşı çalıştırın (tek ürün, çok ürün, karışık vergi oranları, kargo ve yüksek miktarlı bir satır). Sepetleri kaydedin ki fiyat kodunu her değiştirdiğinizde tekrar çalıştırabilesiniz.

Çoğu hatayı yakalayan beş kontrol

• Toplamlarda koruyucular: Nihai sipariş toplamı ve her satırın net fiyatı asla sıfırın altına düşmemeli. Bir indirim uygulanabileceğinden fazla olursa, sınırla ve sınırlanan tutarı kaydedin.
• Açıklanabilir matematik: Alışveriş yapanın gördüğü indirim dökümü (promoya göre, satır bazında, kargo bazında) ödenen nihai tutara tam olarak eşit olmalı. Bir cümlede açıklayamıyorsanız, kurallar çok bulanık demektir.
• Tek bir yığılma politikası, sürpriz yok: Neyin birlikte uygulanabileceğini (kupon ile otomatik promosyon, yüzde ile sabit, kargo indirimi ile ürün indirimi) kararlaştırın ve doğrulayın. Öncelik sırasını açık hale getirin ve müşteri destek ekibinizin söyleyeceği şeyle uyuştuğundan emin olun.
• Yuvarlama tutarlı: Bir yuvarlama kuralı seçin (satır başına vs sipariş başına, yarıya-yuvarlama vs banka yuvarlama, para birimine özgü ondalıklar). Belgeleyin ve 0.99$, 3 adet gibi fiyatlarla ve karışık yüzde indirimlerle test edin.
• İadeler ve geri ödemeler doğru: Kısmi iadeler doğru oranda indirim, vergi ve kargo iadesi yapmalı. "3 üründen 1'ini iade et", "önce indirime giren ürünü iade et" ve "promosyon süresi bittikten sonra iade" gibi senaryoları test edin.

Eğer indirim kurallarınızı Koder.ai gibi bir üreticide oluşturuyorsanız, bu durumları kural tanımlarıyla birlikte otomatik testler olarak ekleyin. Amaç basit: gelecekteki herhangi bir promosyon değişikliği, müşteri sepetinde değil testlerde hızlıca başarısız olsun.

Kurallarınızı doğrulamak için gerçekçi bir yığılma senaryosu

Aşağıda çoğu kupon mantığı tuzağını ortaya çıkaran ama karmaşık olmayan küçük bir sepet var.

Bu kuralları varsayın (bunları sisteminizde tam olarak böyle yazın):

• Otomatik promosyon önce uygulanır, ürün düzeyinde, sadece uygun tam fiyatlı ürünlerde
• Kupon sipariş düzeyinde 15$ indirimdir, en az 100$ uygun ürün gerektirir
• "Uygun ürün" indirimli ürünleri, kargoyu ve vergiyi dışlar
• Kupon indirimi, önceki promosyonlardan sonra kalan uygun ara toplamı aşamaz
• Vergi, indirimlerden sonra hesaplanır (indirimli ürünler artı kargo üzerinden)

Sepet ve promolar

Sepet:

Promolar:

• Promo 1: eligible items üzerinde otomatik %10 hafta sonu indirimi
• Promo 2: 100$ uygun harcama için 15$ kupon, indirimli ürünleri hariç tutar

Adım adım ve nihai döküm

1. Kupon asgari harcama kontrolü: indirim öncesi uygun ürün toplamı 60$ + 40$ = 100$, bu yüzden kupon uygulanabilir.

2. Promo 1 uygulansın (%10 eligible ürünlerde): 100$ x %10 = 10$ indirim. Uygun ara toplam 90$ olur.

3. Promo 2 uygulansın (15$): üst sınır 90$ olduğundan tam 15$ uygulanır. Yeni uygun ara toplam 75$ olur.

Toplamlar:

• Ürünler: uygun 75$ + indirimli ürün 30$ = 105$
• Kargo: 8$
• Vergi (%%8): (105 + 8) x 0.08 = 9.04$
• Nihai toplam: 105 + 8 + 9.04 = 122.04$

Şimdi bir şeyi değiştirin: müşteri Item B'yi (40$) çıkarıyor. Uygun ürün toplamı 60$ olur, dolayısıyla 15$ kupon asgari harcama kontrolünü geçemez. Sadece %10 otomatik promo kalır: Item A 54$ olur, ürünler 54$ + 30$ = 84$, ve nihai toplam 99.36$ olur. Bu, uygunluk ve işlem sırasının açık olmadığı durumlarda sepetleri bozabilen "küçük düzenleme" tipik örneğidir.

Sonraki adımlar: promoları güvenle yayınlayın ve sürdürülebilir tutun

Kupon mantığı tuzaklarından kaçınmanın en hızlı yolu, promoları "ödeme içinde biraz matematik" gibi değil ürün kuralları gibi ele almaktır. Yayına almadan önce herkesin okuyup üzerinde anlaşabileceği kısa bir spesifikasyon yazın.

Dört şeyi sade dille dahil edin:

• Birleştirme kuralları (ne birleştirilebilir, ne birleştirilemez)
• Öncelik sırası (iki kural aynı öğeyi hedeflediğinde hangisi kazanır)
• Hariç tutmalar (kategoriler, markalar, indirimli ürünler, abonelikler, hediye kartları)
• Tabanlar ve üst sınırlar (min ara toplam, max indirim ve "asla 0'ın altına inme")

Yayın sonrası, toplamları hata kayıtlarını izlediğiniz gibi izleyin. Bir indirim hatası genellikle geçerli bir sipariş gibi görünür ta ki finans görüp fark edene kadar.

Aşağıdakileri tetikleyecek bir izleme kurun: neredeyse sıfır total, negatif toplamlar, toplamdan büyük indirimler veya "%100 indirimli" sepetlerde ani artışlar. Uyarıları ödeme hatalarının gittiği aynı yere yönlendirin ve bir promosyonu güvenle devre dışı bırakma için kısa bir çalışma planı tutun.

Regresyon olmadan yeni promolar eklemek için tekrarlanabilir bir iş akışı kullanın: önce spesifikasyonu güncelleyin, kuralı verisel olarak kodlayın (dallanmış kod değil), birkaç "normal" sepet için test ekleyin artı bir-iki zorlu uç durum, sonra tam indirim test süitini çalıştırıp merge edin.

Daha hızlı uygulamak ve yinelemeler yapmak isterseniz, Koder.ai içinde planlama modunda promosyon motoru akışlarını prototipleyebilir, sonra test görüntüleri ve geri alma ile kural değişikliklerini kaydederek hızlıca deneyebilirsiniz. Bu, kural değişikliklerini denerken bilinen iyi bir sürümü kaybetmemenize yardımcı olur.