กับดักตรรกะคูปอง: กฎการซ้อนที่ไม่ทำให้ตะกร้าพัง

ทำไมตรรกะโปรโมชันถึงพังบ่อย

โปรโมชันดูเรียบง่ายจนกว่าจะใส่ลงในเช็คเอาต์จริง ตะกร้าสินค้ากำลังเปลี่ยนตลอดเวลา แต่ส่วนลดมักถูกเขียนเป็นกฎครั้งเดียว ช่องว่างนี้แหละที่ทำให้เกิดกับดักตรรกะคูปองส่วนใหญ่

จุดยากคือกฎใหม่เพียงข้อเดียวสามารถเปลี่ยนยอดรวมได้ทั้งระบบ เพิ่ม “ลด 10% แต่ไม่รวมสินค้าลดราคา” แล้วคุณต้องตัดสินใจว่า "ลดราคา" หมายความว่าอะไร ตรวจสอบเมื่อไร และ 10% ควรคำนวณจากจำนวนเงินใด ถ้ามีโปรโมชันอื่นที่เกี่ยวข้องกับสินค้าชิ้นเดียวกัน ลำดับการประยุกต์ใช้ก็มีผล และลำดับจะเปลี่ยนราคา

หลายทีมยังผสมคณิตศาสตร์เข้ากับกฎธุรกิจ แก้แบบด่วนเช่น “จำกัดส่วนลดที่ยอดรวมย่อย” ถูกก็อปปี้ไปสามที่ แล้วไม่นานคุณจะได้คำตอบต่างกันขึ้นอยู่กับว่าคำนวณยอดรวมที่ไหน (หน้าตะกร้า เช็คเอาต์ ใบแจ้งหนี้ อีเมล)

ช่วงเวลาที่มีความเสี่ยงสูงคือเวลาที่ระบบของคุณคำนวณราคาซ้ำ:

• การอัปเดตตะกร้า: เปลี่ยนจำนวน ลบสินค้า เปลี่ยนวิธีการจัดส่ง
• แก้ไขหลังชำระเงิน: เปลี่ยนที่อยู่ ยกเลิกบางส่วน แทนสินค้า
• คืนเงินและการคืนสินค้า: การคำนวณสัดส่วนระหว่างสินค้า การปรับภาษี เครดิตร้านค้า
• การเปลี่ยนสกุลเงินหรือโหมดภาษี: ราคาก่อน/หลังภาษี รวมภาษีหรือไม่

ตัวอย่างเล็ก ๆ : ผู้ซื้อเพิ่มชุดโปรโมชั่น แล้วใช้โค้ด “ลด $20 เมื่อสั่ง $100” แล้วลบสินค้าชิ้นหนึ่ง หากโค้ดของคุณยัง “จำ” ยอดรวมเดิม คุณอาจให้ส่วนลด $20 กับตะกร้า $85 หรือแม้แต่ทำให้ราคาสินค้าเป็นค่าลบ

เมื่อจบบทความนี้ คุณควรป้องกันความล้มเหลวโปรโมชันที่พบบ่อยที่สุดได้: การลดซ้ำ การไม่ตรงกันของยอดระหว่างหน้าจอ ยอดติดลบ ส่วนลดที่ไปใช้กับสินค้าที่ถูกยกเว้น และการคืนเงินที่ไม่ตรงกับที่ลูกค้าจ่ายจริง

เริ่มจากกฎการซ้อนและลำดับความสำคัญที่ชัดเจน

กับดักตรรกะคูปองส่วนใหญ่เริ่มจากประโยคเดียวที่ขาดหายไป: ส่วนลดใดสามารถใช้ร่วมกันได้ และใช้ตามลำดับใด ถ้าคุณอธิบายกฎการซ้อนได้ไม่เป็นภาษาธรรมดา ตะกร้าจะทำสิ่งที่น่าประหลาดใจในที่สุด

กำหนดการซ้อนด้วยคำตอบใช่หรือไม่ ตัวอย่าง: “คูปองที่พนักงานใส่ได้หนึ่งอันต่อคำสั่งซื้อ โปรโมชันอัตโนมัติยังใช้ได้ เว้นแต่คูปองจะระบุว่าบล็อกโปรโมชันอื่น” ประโยคเดียวนี้ป้องกันการรวมกันแบบสุ่มที่นำไปสู่การลดซ้ำ

แยกส่วนลดระดับรายการออกจากส่วนลดระดับคำสั่งซื้อตั้งแต่ต้น กฎระดับรายการเปลี่ยนราคาของสินค้าบางชิ้น (เช่น ลด 20% รองเท้าบางรุ่น) ส่วนลดระดับคำสั่งซื้อเปลี่ยนยอดรวม (เช่น ลด $10 จากตะกร้า) การผสมโดยไม่มีโครงสร้างคือสาเหตุที่ยอดรวมไหลเบี้ยวระหว่างหน้าสินค้า ตะกร้า และเช็คเอาต์

ตัดสินใจว่า “ข้อเสนอที่ดีที่สุด” หมายความว่าอะไร ก่อนเขียนโค้ด หลายทีมเลือก “ประหยัดมากสุด” แต่แบบนั้นอาจทำให้ราคาต่ำกว่าต้นทุน คุณอาจต้องมีกฎเช่น “อย่าให้ส่วนลดต่ำกว่าต้นทุน” หรือ “อย่าให้ค่าจัดส่งติดลบ” เลือกกฎชัดเจนข้อเดียวเพื่อให้เอนจินไม่ต้องเดา

ลำดับความสำคัญง่าย ๆ จะทำให้การชนกันคาดเดาได้:

• โปรโมชันอัตโนมัติก่อน (กฎแคตาล็อกหรือตามฤดูกาล)
• คูปองที่ลูกค้าใส่ถัดไป
• เครดิตร้านค้าหรือบัตรของขวัญสุดท้าย (เป็นวิธีชำระเงิน ไม่ใช่ส่วนลด)
• คำนวณภาษีและค่าจัดส่งหลังส่วนลด

ตัวอย่าง: ตะกร้ามีโปรโมชันอัตโนมัติ 10% บนสินค้าทั้งหมด บวกคูปองพิมพ์ว่า "ลด $15 เมื่อสั่งเกิน $100" ถ้าลำดับของคุณบอกว่าอัตโนมัติก่อน คุณจะตอบได้ชัดเจนว่าเกณฑ์ $100 ใช้ยอดก่อนหรือหลังส่วนลดหรือไม่ เขียนไว้แล้วรักษาความสอดคล้องทุกที่

เมื่อเลือกเหล่านี้แล้ว กฎการซ้อนคูปองของคุณจะกลายเป็นกฎที่ทดสอบได้ ไม่ใช่พฤติกรรมที่ซ่อนเร้น นี่คือวิธีที่เร็วที่สุดในการหลีกเลี่ยงกับดักตรรกะคูปองในภายหลัง

ทำให้ส่วนลดเป็นข้อมูลที่ชัดเจนและเรียบง่าย

กับดักตรรกะคูปองหลายอย่างเกิดเมื่อส่วนลดกระจายอยู่ใน if-else ทั่วโค้ดเช็คเอาต์ วิธีที่ปลอดภัยคือมองทุกโปรโมชันเป็นข้อมูลที่มีประเภท ขอบเขต และข้อจำกัดชัดเจน แล้วคณิตศาสตร์ในตะกร้าจะกลายเป็นตัวประเมินขนาดเล็กที่คาดเดาได้

เริ่มจากตั้งชื่อประเภทส่วนลด ไม่ใช่ไอเดียการตลาด ส่วนใหญ่โปรโมชันเข้ากับรูปแบบไม่กี่แบบ: ลดเป็นเปอร์เซ็นต์ ลดจำนวนคงที่ ของแถม (ซื้อ X แถม Y) และส่งฟรี เมื่อนำโปรโมชันมาเป็นหนึ่งในประเภทเหล่านี้ คุณจะหลีกเลี่ยงกรณีพิเศษที่ยากต่อการทดสอบ

ต่อมา ให้ทำให้ขอบเขตชัดเจน เปอร์เซ็นต์เดียวกันทำงานต่างกันอย่างมากขึ้นอยู่กับเป้าหมาย กำหนดว่ามันใช้กับคำสั่งซื้อทั้งหมด หมวดหมู่ ผลิตภัณฑ์ หนึ่งบรรทัดสินค้า หรือค่าจัดส่ง หากขอบเขตคลุมเครือ คุณจะเผลอไปลดยอดย่อยผิดหรือซ้อนส่วนลด

บันทึกข้อจำกัดเป็นฟิลด์ ไม่ใช่คอมเมนต์โค้ด ข้อจำกัดทั่วไปได้แก่ ยอดขั้นต่ำ เฉพาะคำสั่งซื้อแรก และช่วงวันที่ รวมถึงระบุพฤติกรรมกับราคาที่ลดแล้ว: ซ้อนทับได้ นำไปคำนวณจากราคาตั้งต้น หรือยกเว้นสินค้าลดราคา

สคีมารูปแบบสั้น ๆ อาจรวม:

• 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)

สุดท้าย เพิ่ม "ราคาใต้สุด" ที่เอนจินต้องเคารพเสมอ: ยอดรวมไม่เคยต่ำกว่า 0 และถ้าธุรกิจต้องการ สินค้าไม่ควรต่ำกว่าต้นทุน (หรือราคาขั้นต่ำที่กำหนด) ถ้าสร้างไว้ คุณจะป้องกันยอดติดลบและกรณีขอบที่ร้านจ่ายให้ลูกค้า

ถ้าคุณทำต้นแบบเครื่องยนต์ส่วนลดใน Koder.ai ให้เก็บฟิลด์เหล่านี้ไว้ในโหมดวางแผนเพื่อให้ตัวประเมินยังคงเรียบง่ายและทดสอบได้เมื่อเพิ่มโปรโมชันมากขึ้น

ขั้นตอนทีละขั้น: วิธีปลอดภัยในการประเมินโปรโมชัน

กับดักตรรกะคูปองส่วนใหญ่เกิดเมื่อการตรวจสอบสิทธิ์และคณิตศาสตร์ถูกผสมกัน รูปแบบที่ปลอดภัยคือสองเฟส: ตัดสินก่อนว่าสิ่งใดใช้ได้ แล้วคำนวณจำนวนเงิน การแยกกันแบบนี้ทำให้กฎอ่านง่ายและทำให้สถานะไม่ดี (เช่น ยอดติดลบ) ป้องกันได้ง่ายขึ้น

ลำดับการประเมินที่กำหนดได้

ใช้ลำดับเดียวกันทุกครั้ง แม้โปรโมชันจะมาจาก UI หรือ API ในลำดับต่างกัน ความนิ่งมีความสำคัญเพราะมันเปลี่ยนคำถาม "ทำไมตะกร้านี้ถึงเปลี่ยน" ให้กลายเป็นคำถามที่คุณตอบได้

โฟลว์ง่าย ๆ ที่ใช้ได้ดี:

• Validate อินพุต: รูปแบบรหัสโปรโมชัน ช่วงวันที่ ขอบเขตลูกค้า สกุลเงิน และราคาต้องไม่ติดลบ
• Select eligible promos: ตรวจสอบแค่ความมีสิทธิ์ (ยังไม่เกี่ยวเงิน) สร้างรายการผู้สมัคร
• Resolve stacking and priority: ใช้กฎการซ้อนของคุณ (เช่น "คูปองระดับคำสั่งซื้อได้หนึ่งรายการ") และเกณฑ์ตัดสิน (ลำดับความสำคัญ แล้วมูลค่าดีที่สุด แล้ว ID ที่คงที่)
• Apply calculations: คำนวณส่วนลดโดยใช้ฐานที่สอดคล้องกัน (ก่อนหรือหลังภาษี รวมค่าจัดส่งหรือไม่) และกฎการปัดเศษ
• Summarize totals: คำนวณยอดสั่งซื้อใหม่จากยอดบรรทัด แล้วจำกัดที่ศูนย์และบังคับขีดจำกัดส่วนลดสูงสุด

ติดตามการแจกแจงและบันทึกตรวจสอบ

เมื่อคุณประยุกต์โปรโมชัน อย่าเก็บแค่ "ยอดส่วนลดรวม" เดียว เก็บการแจกแจงต่อบรรทัดและระดับคำสั่งซื้อเพื่อให้คุณไกล่เกลี่ยยอดรวมและอธิบายได้

อย่างน้อย ให้บันทึก:

• กฎหรือโปรโมชันที่ใช้ (ID และเวอร์ชัน) และลำดับความสำคัญ
• เหตุผลที่มันใช้ (ข้อเท็จจริงการมีสิทธิ์ เช่น "category=shoes", "cart subtotal >= 50")
• สิ่งที่มันเปลี่ยน (รหัสบรรทัดที่ได้รับผล จำนวนฐาน ส่วนลด การปัดเศษ)
• สิ่งที่มันป้องกัน (เช่น "บล็อกโดยการยกเว้น: มีส่วนลดระดับรายการอยู่แล้ว")

ตัวอย่าง: ตะกร้ามีสองรายการ หนึ่งรายการลดราคาแล้ว เฟส 1 ทำเครื่องหมายโค้ดว่าสามารถใช้กับสินค้าราคาเต็มเท่านั้น เฟส 2 ประยุกต์ 10% กับบรรทัดนั้น ปล่อยให้รายการที่ลดราคาไม่เปลี่ยนแปลง แล้วคำนวณยอดรวมจากการแจกแจงบรรทัดเพื่อไม่ให้เกิดการลดซ้ำโดยไม่ตั้งใจ

เขียนการยกเว้นโดยไม่สร้างตรรกะสปาเก็ตตี้

กับดักตรรกะคูปองส่วนใหญ่เริ่มเมื่อการยกเว้นซ่อนอยู่ในสาขากรณีพิเศษ เช่น "ถ้ารหัสเป็น X ให้ข้าม Y" มันใช้ได้กับโปรโมชันหนึ่งรายการ แล้วพังเมื่อโปรโมชันถัดไปมาถึง

รูปแบบที่ปลอดภัยกว่า: รักษาโฟลว์การประเมินเดียว แล้วทำให้การยกเว้นเป็นชุดการตรวจสอบที่สามารถปฏิเสธการรวมกันของโปรโมชันก่อนคำนวณเงินด้วยซ้ำ ด้วยวิธีนี้ ส่วนลดจะไม่ถูกใช้งานครึ่งเดียว

มองการยกเว้นเป็นข้อมูล ไม่ใช่การแตกสาขา

แทนที่จะฝังพฤติกรรมไว้ ให้โปรโมชันแต่ละรายการมี "โปรไฟล์ความเข้ากันได้" ขนาดเล็ก ชัดเจน ตัวอย่าง: ประเภทโปรโมชัน (คูปอง vs การลดอัตโนมัติ) ขอบเขต และกฎการรวมกัน

รองรับทั้งสองแบบ:

• รายการ "ไม่สามารถรวมกับ" (denylist): A บล็อก B
• รายการ "สามารถรวมได้เฉพาะกับ" (allowlist): A รวมได้เฉพาะกับชุดที่ระบุ
• ธงกฎเช่น "บล็อกการลดอัตโนมัติ" หรือ "ต้องไม่มีคูปองอื่น"

กุญแจคือเอนจินของคุณจะถามคำถามเดิมกับทุกโปรโมชัน แล้วตัดสินใจว่าชุดนั้นถูกต้องหรือไม่

ทำให้ความขัดแย้งชัดเจน รวมทั้งการลดอัตโนมัติ

การลดราคาอัตโนมัติมักถูกนำมาใช้ก่อน แล้วคูปองมาทีหลังแล้วเขียนทับอย่างเงียบ ๆ ตัดสินใจล่วงหน้าว่าควรเกิดอะไรขึ้น:

• คูปองซ้อนกับการลดของการขาย
• คูปองใช้กับสินค้าที่ไม่ลดราคาเท่านั้น
• คูปองถูกปฏิเสธถ้ามีการลดอัตโนมัติอยู่

เลือกหนึ่งอย่างต่อโปรโมชันแล้วเข้ารหัสเป็นการตรวจสอบ ไม่ใช่เส้นทางการคำนวณอีกแบบ

ทางปฏิบัติที่ช่วยหลีกเลี่ยงความประหลาดใจคือยืนยันความสมมาตร ถ้า "WELCOME10 ไม่สามารถรวมกับ FREESHIP" ควรเข้ารหัสให้ทั้งสองด้านบล็อกกัน หากไม่สมมาตรก็ทำให้เป็นเจตนาและมองเห็นได้ในข้อมูล

ตัวอย่าง: มีการลดอัตโนมัติ 15% ทั่วทั้งไซต์ ลูกค้าใส่คูปอง 20% ที่มีไว้สำหรับสินค้าราคาเต็ม เช็กของคุณควรปฏิเสธสินค้าที่ลดราคาออกจากคูปองก่อนคำนวณยอด มากกว่าจะลดให้แล้วค่อยมาซ่อมตัวเลขทีหลัง

ถ้าคุณสร้างกฎส่วนลดในแพลตฟอร์มอย่าง Koder.ai ให้เก็บการตรวจสอบเหล่านี้เป็นเลเยอร์แยกเพื่อทดสอบและเปลี่ยนกฎได้โดยไม่ต้องเขียนคณิตศาสตร์ใหม่

กรณีขอบที่ทำให้ยอดรวมไม่ตรงกัน

ข้อพิพาทคูปองส่วนใหญ่ไม่เกี่ยวกับส่วนลดชวนประเด็น พวกมันเกิดเมื่อเดียวกันคำนวณตะกร้าสองวิธีเล็กน้อย แล้วลูกค้าเห็นตัวเลขหนึ่งในตะกร้าและอีกตัวในเช็คเอาต์

เริ่มจากล็อกลำดับการดำเนินการของคุณ ตัดสินใจ และจดบันทึกว่า ส่วนลดระดับบรรทัดเกิดก่อนหรือหลังส่วนลดระดับคำสั่งซื้อ และค่าจัดส่งอยู่ตรงไหน กฎทั่วไปคือ: ส่วนลดระดับบรรทัดก่อน ส่วนลดระดับคำสั่งซื้อบนยอดย่อยที่เหลือ แล้วส่วนลดค่าจัดส่งเป็นอันดับสุดท้าย ไม่ว่าคุณจะเลือกอะไร ใช้ลำดับเดียวกันทุกที่ที่แสดงยอดรวม

ภาษีคือกับดักถัดไป ถ้าราคาของคุณรวมภาษี ส่วนลดจะลดส่วนที่เป็นภาษีด้วย หากราคาไม่รวมภาษี ภาษีจะคำนวณหลังส่วนลด การผสมโมเดลเหล่านี้ในส่วนต่าง ๆ ของโฟลว์เป็นกับดักคลาสสิก เพราะสองการคำนวณที่ถูกต้องยังสามารถไม่ตรงกันได้หากสมมติฐานฐานภาษีต่างกัน

ปัญหาการปัดเศษดูเล็กแต่สร้างตั๋วซัพพอร์ตใหญ่ ตัดสินใจว่าจะปัดต่อบรรทัด (แต่ละ SKU หลังส่วนลด) หรือปัดแค่ระดับคำสั่งซื้อ และยึดตามทศนิยมของสกุลเงิน ที่มีคูปองแบบเปอร์เซ็นต์ การปัดต่อบรรทัดอาจเบี้ยวลงไปเป็นเซนต์เมื่อเทียบกับการปัดระดับคำสั่งซื้อ โดยเฉพาะกับสินค้าราคาต่ำจำนวนมาก

นี่คือกรณีขอบที่ควรจัดการอย่างชัดเจน:

• การคืนสินค้าและการคืนเงินบางส่วน: แบ่งส่วนลดตามสัดส่วนเพื่อให้การคืนเงินไม่เกินสิ่งที่จ่ายไป
• แก้ไขตะกร้าหลังใส่คูปอง: ประเมินสิทธิ์และขีดจำกัดใหม่เมื่อเพิ่มหรือลบสินค้า
• การเปลี่ยนค่าจัดส่ง: เปลี่ยนที่อยู่หรือวิธีอาจเปลี่ยนฐานภาษีและสิทธิ์การลดค่าจัดส่ง
• การเปลี่ยนจำนวน: การเพิ่มจำนวนเดียวกันอาจข้ามเกณฑ์ (เช่น ยอดขั้นต่ำ หรือ ซื้อ X แถม Y)
• สินค้าที่มีภาษีผสม: บางรายการอาจไม่ต้องเสียภาษี แต่ยังมีสิทธิ์รับคูปอง

ตัวอย่างชัดเจน: คูปองลด 10% บนคำสั่งซื้อบวกค่าส่งฟรีเมื่อสั่งเกิน $50 หากคูปองใช้ก่อนตรวจเกณฑ์ ยอดหลังส่วนลดอาจต่ำกว่า $50 ทำให้ค่าส่งไม่ฟรี เลือกการตีความเดียว เขียนเป็นกฎ และรักษาให้สอดคล้องทั้งตะกร้า เช็คเอาต์ และการคืนเงิน

บั๊กโปรโมชันที่พบบ่อยและสาเหตุเกิด

กับดักตรรกะคูปองส่วนใหญ่ปรากฏเมื่อการประเมินตะกร้าทำผ่านมากกว่าหนึ่งเส้นทาง โปรโมชันอาจถูกประยุกต์ที่ระดับบรรทัดในที่หนึ่งและอีกครั้งที่ระดับคำสั่งซื้อที่อื่น ทั้งสองอาจดู “ถูกต้อง” แยกกัน

นี่คือตัวบั๊กที่พบบ่อยที่สุด และสาเหตุปกติของแต่ละอย่าง:

• การลดซ้ำกับรายการเดียวกัน: โปรโมชันเดียวกันถูกใช้ครั้งหนึ่งในราคาบรรทัดและอีกครั้งเมื่อคำนวณยอดรวมคำสั่งซื้อ มักเพราะสองบริการต่างคนต่างก็พยายามประยุกต์ส่วนลด
• ยอดรวมหรือลิสต์ไอเท็มเป็นค่าลบ: ส่วนลดจำนวนคงที่ถูกอนุญาตให้เกินยอดที่มีสิทธิ์ (เช่น ลด $20 กับยอดที่มีสิทธิ์ $12) โดยไม่มีการจำกัดต่ำสุดเป็นศูนย์
• เปอร์เซ็นต์ถูกนำไปคำนวณหลังส่วนลดโดยไม่ได้ตั้งใจ: เอนจินนำ 10% ไปคำนวณจากราคาที่ถูกลดแล้ว ทั้งที่กฎตั้งใจให้คิดจาก "ราคาป้าย" เพราะโค้ดใช้ราคาปัจจุบันแทนราคาฐาน
• เช็กยอดขั้นต่ำกับยอดผิดฐาน: กฎเช็กยอดก่อนส่วนลด แต่ธุรกิจคาดหวังให้เช็กหลังส่วนลด (หรือกลับกัน) ทำให้โปรโมชันใช้หรือล้มเหลวแบบน่าประหลาดใจ
• รายการที่ถูกยกเว้นยังได้รับคูปอง: การมีสิทธิ์พึ่งพาแท็กสินค้า แต่การติดแท็กหายหรือไม่สอดคล้อง (หรือมีเส้นทาง fallback) ทำให้นำรายการที่ไม่รู้จักมาถูกพิจารณาว่าได้รับสิทธิ์

ตัวอย่าง: ตะกร้ามีสองรายการ หนึ่งรายการมีสิทธิ์ อีกหนึ่งรายการถูกยกเว้น ถ้าเอนจินคำนวณ "ยอดที่มีสิทธิ์" สำหรับโปรโมชันเปอร์เซ็นต์ถูกต้อง แต่ต่อมาลบส่วนลดคงที่จากยอดรวมทั้งหมด รายการที่ถูกยกเว้นก็ถูกลดไปโดยอ้อม

รูปแบบที่ปลอดภัยคือคำนวณแต่ละโปรโมชันกับ "จำนวนที่มีสิทธิ์" ที่ชัดเจน แล้วคืนการปรับที่ถูกจำกัด (ไม่เคยต่ำกว่า 0) พร้อมกับแทรซที่ชัดเจนว่าแตะอะไรบ้าง ถ้าคุณสร้างเครื่องยนต์ส่วนลดในเครื่องมืออย่าง Koder.ai ให้ให้ออกแทรซเป็นข้อมูลเพื่อให้เทสต์สามารถยืนยันได้อย่างชัดเจนว่าบรรทัดใดมีสิทธิ์และยอดย่อยใดถูกใช้

ทำให้กฎทดสอบได้ด้วยชุดทดสอบที่เหมาะสม

กับดักตรรกะคูปองส่วนใหญ่โผล่มาเพราะเทสต์ตรวจเฉพาะยอดรวมสุดท้าย ชุดที่ดีจะตรวจทั้งการมีสิทธิ์ (โปรโมชันควรใช้หรือไม่?) และคณิตศาสตร์ (มันควรลดเท่าไร?) พร้อมการแจกแจงที่อ่านได้เพื่อนำเปรียบเทียบเมื่อเวลาผ่านไป

สร้างเทสต์จากเล็กไปใหญ่

เริ่มจากยูนิตเทสต์ที่แยกกฎทีละข้อ เก็บอินพุตเล็ก ๆ แล้วขยายเป็นสถานการณ์เต็ม

• ยูนิตเทสต์ความมีสิทธิ์: โปรโมชันใช้ได้ไหม given ประเภทลูกค้า วันที่ แท็กสินค้า และยอดขั้นต่ำ
• ยูนิตเทสต์คณิตศาสตร์: เมื่อให้ยอดที่มีสิทธิ์คงที่ การคำนวณตรงตามกฎการปัดเศษและทศนิยมหรือไม่
• เทสต์สถานการณ์: สินค้าผสม จำนวน จัดส่ง ภาษี และโปรโมชันสองตัวแข่งขันกัน
• เทสต์ "ตะกร้าเปลี่ยน" : ราคาอัปเดต ลบสินค้า หรือเปลี่ยนจำนวนระหว่างการประเมินและเช็คเอาต์
• เทสต์สแนปช็อตการแจกแจง: เก็บการแจกแจงส่วนลดทีละบรรทัดที่คาดหวัง ไม่ใช่แค่ยอดรวมสุดท้าย

หลังจากมีความคุ้มครองแล้ว ให้เพิ่มการเช็ก "จับตลอดเวลา" บางอย่าง ซึ่งจับกรณีแปลก ๆ ที่คุณไม่ได้คิดจะเขียนด้วยมือ

• ยอดรวมไม่เคยต่ำกว่า 0.00
• ส่วนลดไม่เคยทำให้ยอดเพิ่มขึ้น
• ส่วนลดที่ใช้ไม่เคยเกินฐานที่มีสิทธิ์ของมัน
• การลบไอเท็มที่ไม่มีสิทธิ์ไม่ควรทำให้ส่วนลดใหญ่ขึ้น

ตัวอย่างตะกร้าเล็ก ๆ

สมมติตะกร้ามี 2 รายการ: เสื้อราคา $40 (มีสิทธิ์) และบัตรของขวัญราคา $30 (ถูกยกเว้น) ค่าจัดส่ง $7 โปรโมชันคือ "20% บนเสื้อผ้า สูงสุด $15" และโปรโมชันที่สอง "ลด $10 เมื่อสั่งเกิน $50" ซึ่งไม่สามารถซ้อนกับส่วนลดเปอร์เซ็นต์ได้

เทสต์สถานการณ์ของคุณควรยืนยันว่าโปรโมชันใดชนะ (ตามลำดับความสำคัญ) ยืนยันว่าบัตรของขวัญถูกยกเว้น และตรวจการจัดสรรที่แน่นอน: 20% ของ $40 คือ $8 ค่าจัดส่งไม่ถูกแตะต้อง ยอดรวมสุดท้ายถูกต้อง เก็บการแจกแจงนี้เป็นสแนปช็อตทองคำเพื่อให้การรีแฟคเตอร์ในอนาคตไม่เปลี่ยนว่าโปรโมชันใดใช้ หรือเริ่มลดรายการที่ถูกยกเว้น

เช็คลิสต์ด่วนก่อนเปิดใช้

ก่อนปล่อยโปรโมชันใหม่ ทำการตรวจสุดท้ายด้วยเช็คลิสต์ที่จับความล้มเหลวที่ลูกค้าสังเกตได้ทันที: ยอดแปลก ๆ ข้อความสับสน และการคืนเงินที่ไม่ลงตัว เช็คลิสต์เหล่านี้ยังช่วยป้องกันกับดักตรรกะคูปองส่วนใหญ่ เพราะบังคับให้กฎต้องทำงานเหมือนกันในทุกตะกร้า

รันการเช็กเหล่านี้กับชุดตะกร้า "ยาก" เล็ก ๆ (หนึ่งรายการ หลายรายการ อัตราภาษีผสม ค่าจัดส่ง และรายการที่มีจำนวนมาก) เก็บตะกร้าเหล่านี้เพื่อรันซ้ำทุกครั้งที่คุณเปลี่ยนโค้ดการตั้งราคา

ห้าเช็กที่จับความล้มเหลวได้มากที่สุด

• กรอบป้องกันยอดรวม: ยอดรวมคำสั่งซื้อสุดท้ายและราคาสุทธิต่อบรรทัดต้องไม่ต่ำกว่า 0 หากส่วนลดเกินสิ่งที่ใช้ได้ ให้จำกัดมันและบันทึกจำนวนที่ถูกจำกัดไว้
• คณิตศาสตร์ที่อธิบายได้: การแจกแจงส่วนลดที่แสดงให้ผู้ซื้อเห็น (แยกตามโปรโมชัน ตามบรรทัด ตามค่าจัดส่ง) ต้องรวมกันเท่ากับยอดสุดท้ายที่จ่ายได้ ถ้าคุณอธิบายมันเป็นประโยคเดียวไม่ได้ กฎกำกวมเกินไป
• นโยบายการซ้อนเดียว ไม่มีความประหลาดใจ: ตัดสินใจและยืนยันว่าสิ่งใดซ้อนกันได้ (คูปองกับโปรโมชันอัตโนมัติ, เปอร์เซ็นต์กับจำนวนคงที่, ส่วนลดค่าจัดส่งกับส่วนลดสินค้า) ทำให้ลำดับความสำคัญชัดเจนและยืนยันว่าตรงกับสิ่งที่ทีมซัพพอร์ตจะบอกลูกค้า
• การปัดเศษสอดคล้อง: เลือกกฎการปัดเศษ (ต่อบรรทัด vs ต่อคำสั่งซื้อ, half-up vs bankers, ทศนิยมตามสกุลเงิน) จดไว้และทดสอบด้วยราคาตัวอย่างเช่น $0.99 ปริมาณ 3 และคูปองเปอร์เซ็นต์ผสม
• การคืนสินค้าและคืนเงินถูกต้อง: การคืนบางส่วนควรคืนส่วนของส่วนลด ภาษี และค่าจัดส่งที่ถูกต้อง ทดสอบ "คืน 1 ใน 3 รายการ" "คืนสินค้าที่ได้รับส่วนลดก่อน" และ "คืนหลังโปรโมชันหมดอายุ"

ถ้าคุณสร้างกฎส่วนลดในเครื่องกำเนิดเช่น Koder.ai ให้เพิ่มกรณีเหล่านี้เป็นเทสต์อัตโนมัติข้าง ๆ คำจำกัดความกฎ เป้าหมายคือ: โปรโมชันใหม่ใด ๆ ควรล้มเหลวเร็วในการทดสอบ มากกว่าจะล้มเหลวในตะกร้าของลูกค้า

สถานการณ์การซ้อนที่สมจริงเพื่อยืนยันกฎของคุณ

นี่คือตะกร้าเล็ก ๆ ที่เปิดเผยกับดักตรรกะคูปองส่วนใหญ่โดยไม่ซับซ้อนมาก

สมมติกฎเหล่านี้ (เขียนลงระบบของคุณให้ชัดเจน):

• โปรโมชันอัตโนมัติใช้ก่อน ระดับรายการ และใช้เฉพาะกับสินค้าที่มีสิทธิ์เป็นราคาปกติเท่านั้น
• คูปองระดับคำสั่งซื้อ ลด $15 ต้องมีสินค้า "มีสิทธิ์" อย่างน้อย $100
• "สินค้าที่มีสิทธิ์" ยกเว้นสินค้าลดราคา ค่าส่ง และภาษี
• ส่วนลดคูปองไม่สามารถเกินยอดย่อยที่มีสิทธิ์หลังโปรโมชันก่อนหน้า
• ภาษีคำนวณหลังส่วนลด (บนสินค้าที่ถูกลดรวมค่าจัดส่ง)

ตะกร้าและโปรโมชัน

ตะกร้า:

โปรโมชัน:

• Promo 1: automatic 10% weekend sale on eligible items
• Promo 2: coupon $15 off, min $100 eligible spend, excludes sale items

การเดินผ่านและการแจกแจงสุดท้าย

1. เช็กยอดขั้นต่ำของคูปอง: สินค้าที่มีสิทธิ์ก่อนส่วนลดคือ $60 + $40 = $100 ดังนั้นคูปองใช้ได้

2. ประยุกต์ Promo 1 (ลด 10% กับสินค้าที่มีสิทธิ์): $100 x 10% = $10 off ยอดย่อยที่มีสิทธิ์กลายเป็น $90

3. ประยุกต์ Promo 2 ($15 off): ขีดจำกัดคือ $90 จึงใช้ได้เต็ม $15 ยอดย่อยที่มีสิทธิ์เหลือ $75

ยอดรวม:

• สินค้า: มีสิทธิ์ $75 + สินค้าลดราคา $30 = $105
• ค่าจัดส่ง: $8
• ภาษี (8%): (105 + 8) x 0.08 = $9.04
• ยอดรวมสุดท้าย: $105 + $8 + $9.04 = $122.04

เปลี่ยนหนึ่งอย่าง: ลูกค้าลบ Item B ($40) ยอดสินค้าที่มีสิทธิ์เหลือ $60 ดังนั้นคูปอง $15 จะไม่ผ่านการเช็กยอดขั้นต่ำ เหลือแค่โปรโมชันอัตโนมัติ 10%: Item A กลายเป็น $54 สินค้ารวมเป็น $54 + $30 = $84 และยอดรวมสุดท้ายกลายเป็น $99.36 นี่คือชนิดของ "แก้ไขเล็ก ๆ" ที่มักทำให้ตะกร้าพังถ้าการมีสิทธิ์และลำดับไม่ชัดเจน

ขั้นตอนต่อไป: ปล่อยโปรโมชันอย่างปลอดภัยและทำให้บำรุงรักษาง่าย

วิธีที่เร็วที่สุดในการหลีกเลี่ยงกับดักตรรกะคูปองคือมองโปรโมชันเป็นกฎของผลิตภัณฑ์ ไม่ใช่ "คณิตศาสตร์เล็ก ๆ ในเช็คเอาต์" ก่อนปล่อย ให้เขียนสเปกสั้น ๆ ที่ใครในทีมก็อ่านและตกลงกันได้

รวมสี่อย่างเป็นภาษาธรรมดา:

• กฎการซ้อน (อะไรสามารถรวมกันได้ และอะไรไม่สามารถ)
• ลำดับความสำคัญ (ส่วนลดใดชนะเมื่อสองอย่างเจาะเป้าหมายเดียวกัน)
• การยกเว้น (หมวดหมู่ แบรนด์ สินค้าลดราคา การสมัคร บัตรของขวัญ)
• ราคาใต้สุดและขีดจำกัด (ยอดขั้นต่ำ ส่วนลดสูงสุด และ "อย่าให้ต่ำกว่า $0")

หลังปล่อย ติดตามยอดรวมเหมือนติดตามข้อผิดพลาด บั๊กส่วนลดมักดูเหมือนคำสั่งซื้อที่ถูกต้องจนกว่าฝ่ายการเงินจะเห็นมัน

ตั้งการมอนิเตอร์ที่แจ้งเตือนคำสั่งซื้อที่มีรูปแบบแปลก เช่น ยอดใกล้ศูนย์ ยอดติดลบ ส่วนลดมากกว่ายอดย่อย หรือการเพิ่มขึ้นของตะกร้า "ฟรี 100%" ส่งการแจ้งเตือนไปยังที่เดียวกับที่ส่งข้อผิดพลาดเช็คเอาต์ และเตรียมเพลย์บุ๊กสั้น ๆ สำหรับการปิดโปรโมชันอย่างปลอดภัย

เพื่อเพิ่มโปรโมชันโดยไม่มีรีเกรสชัน ใช้เวิร์กโฟลว์ที่ทำซ้ำได้: อัปเดตสเปกก่อน เข้ารหัสกฎเป็นข้อมูล (ไม่ใช่โค้ดแตกสาขา) เพิ่มเทสต์สำหรับตะกร้าปกติสองสามแบบและหนึ่งหรือสองกรณีขอบที่เลวร้าย แล้วรันชุดทดสอบส่วนลดทั้งหมดก่อน merge

ถ้าคุณต้องการนำไปใช้งานและวนปรับได้เร็วขึ้น คุณสามารถทำต้นแบบโฟลว์เครื่องยนต์โปรโมชันใน Koder.ai โดยใช้โหมดวางแผน แล้วใช้สแนปช็อตและการย้อนกลับขณะที่ปรับเทสต์ ช่วยให้ลองเปลี่ยนกฎได้เร็วโดยไม่สูญเสียเวอร์ชันที่ใช้งานได้