Data Science
Machine learning ในอีคอมเมิร์ซมักถูกอธิบายแบบคลุมเครือ สำหรับผู้ขาย คำถาม ML ที่มีประโยชน์ที่สุดนั้นชัดเจนกว่านั้นมาก:
SKU นี้จะขายได้เท่าไรในเร็ว ๆ นี้?
คำถามนั้นป้อนเข้าสู่ทุก operational decision ที่ผู้ขาย marketplace ต้องทำ — สต็อก ads ราคา โปรโมชัน กระแสเงินสด ประเมิน demand ต่ำเกินไป SKU ก็ stockout ในจังหวะที่แย่ที่สุด ประเมินสูงเกินไป เงินสดก็ไปจมอยู่ในสต็อกที่หมุนช้า เข้าใจรูปร่างของ demand ผิด งบโฆษณาก็ไหลเข้าสินค้าที่รับยอดขายเพิ่มไม่ไหว demand forecasting ไม่ได้เป็นการทำนายเพื่อทำนาย แต่มันคือ decision infrastructure
ทำไม demand บน marketplace จึง forecast ยาก
demand บน marketplace ผันผวนในแบบที่ classical retail forecasting ไม่เคยถูกออกแบบมารับมือ ผู้ขาย Shopee เห็น demand แกว่งได้จาก payday campaign, double-day campaign, voucher, ราคาของคู่แข่ง, ad spend ของตัวเอง, การเปลี่ยน keyword ranking, content จาก creator, รีวิว, สต็อกที่มี, seasonality, สภาพอากาศ, การเปลี่ยนความเร็วจัดส่ง หรือแม้แต่การแก้หน้า product page เล็ก ๆ — บางทีหลายอย่างพร้อมกัน
ค่าเฉลี่ยย้อนหลังแบบง่าย ๆ อยู่ไม่รอดในสภาพแวดล้อมแบบนั้น สินค้าที่ขายได้ 100 หน่วยเดือนที่แล้วไม่จำเป็นต้องขายได้ 100 หน่วยเดือนนี้ บางทีมันอาจ stockout ไปหนึ่งสัปดาห์ บางทีงบ ads อาจสูงกว่า บางที campaign อาจดัน demand ขึ้นแบบไม่เป็นธรรมชาติ บางทีคู่แข่งอาจลดราคา บางทีปัญหารีวิวอาจฉุด conversion ผู้ขายที่ใช้ตัวเลขเดือนที่แล้วเป็นแผนของเดือนหน้ากำลัง fit เส้นตรงเข้ากับเส้นโค้ง
สูตร demand forecasting พื้นฐาน
แม้แต่ model แบบ additive ที่ทำให้ง่ายแล้วก็ยังครอบคลุมสิ่งสำคัญส่วนใหญ่ได้:
Expected demand = base demand
+ seasonality
+ promotion lift
+ ad effect
+ price effect
+ channel effect
− stock constraintแต่ละ component ทำงานเฉพาะของมัน base demand จับ pattern ปกติ seasonality จับ spike ที่เกิดซ้ำ promotion lift จับพฤติกรรมช่วง campaign ad effect จับ visibility ที่จ่ายเงินซื้อ price effect จับ elasticity ส่วน stock constraint กันไม่ให้โมเดลอ่าน stockout ผิดเป็นการตกของ demand จริง — ซึ่งฟังดูชัดเจนจนกว่าจะได้เห็นว่าเกิดอะไรขึ้นเมื่อมันหายไป
ปัญหา stockout distortion
stockout ทำให้ข้อมูลย้อนหลังเสีย ถ้าสินค้า out of stock ไป 10 วัน ข้อมูลยอดขายจะแสดงหน่วยที่ขายได้น้อยลงในช่วงนั้น — แต่นั่นไม่ได้แปลว่า demand หายไป มันแปลว่า demand ไม่ได้รับการเสิร์ฟต่างหาก
เหตุผลที่เรื่องนี้สำคัญในทางปฏิบัติคือ feedback loop ประเมิน demand ต่ำไปหลัง stockout สั่งของ batch เล็กลง stockout เร็วขึ้นอีก — และโมเดลก็ "เรียนรู้" ที่จะคาด demand ของ SKU นี้ต่ำลงเรื่อย ๆ ทั้งที่ลูกค้าจริงของมันยังอยู่
ML ช่วยได้อย่างไร
machine learning เรียนรู้ pattern จากหลายสัญญาณพร้อมกันได้ — ยอดขายย้อนหลัง วันที่ campaign ad spend การเปลี่ยนราคา สต็อกที่มี category สินค้า วันในสัปดาห์ seasonality order velocity และพฤติกรรมราย channel — โดยที่ผู้ขายไม่ต้องเลือกล่วงหน้าว่าตัวไหนสำคัญ งานวิจัยทบทวนเชิงระบบปี 2025 เรื่อง machine learning ใน inventory control (ScienceDirect) วิเคราะห์ 122 บทความ และจัดหมวด ML application เป็น demand forecasting ก่อน optimisation, ML ที่ฝังเข้าไปใน optimisation โดยตรง และวิธีแบบ dynamic เช่น reinforcement learning สำหรับ inventory policy
sMAPE = symmetric mean absolute percentage error ขั้นตอนที่ได้ leverage สูงสุดเพียงจุดเดียว — การ censor ยอดขายในช่วง stockout แทนที่จะถือว่าเป็น demand ที่สังเกตได้ — ให้ความแม่นยำเพิ่มมากกว่าการอัป model architecture เสียอีก ผลคือ ในการใช้งานจริง คุณภาพข้อมูลมีน้ำหนักเหนือการเลือก model บน hierarchical retail series
สำหรับผู้ขาย ข้อสรุปที่ใช้ได้จริงไม่ใช่ "ใช้ ML เพราะ ML กำลังฮิต" แต่ตรงประเด็นกว่านั้น:
forecasting ควรเชื่อมไปสู่ decision
forecasting ที่ไม่มี decision นั้นไม่พอ
forecast ที่บอกว่า "คุณอาจขายได้ 500 หน่วยเดือนหน้า" น่าสนใจ แต่ในเชิงปฏิบัติมันเฉื่อย ผู้ขายต้องรู้ว่าต้องทำอะไร — ควรสั่งของตอนนี้ไหม ควรเพิ่ม ads ไหม ควรลด ads เพราะสต็อกใกล้หมดไหม ควรขึ้นราคาเพื่อชะลอ demand ไหม ควรเลี่ยง campaign เพราะสต็อกรองรับไม่ไหวไหม ควรจับ SKU นี้รวมเป็น Bundle Deal กับอย่างอื่นไหม forecast ที่ไม่ตอบคำถามเหล่านี้อย่างน้อยหนึ่งข้อ กำลังทำ analysis แทนที่จะทำงานจริง นี่คือเหตุผลที่ DataGlass เชื่อม forecasting เข้ากับ action โดยตรง
ความเชื่อมโยงระหว่าง ads กับสต็อก
ads กับสต็อกไม่ควรถูกจัดการในคนละ tab SKU ที่มี margin แข็งแรงและสต็อกพอจะรับงบ ads เพิ่มได้ SKU ที่ demand แรงแต่สต็อกต่ำจะเจ็บถ้าเพิ่มงบ ads — เพราะทุก click ที่เพิ่มขึ้นไปลงที่หน้าซึ่งกำลังจะทำให้ผู้ซื้อผิดหวัง SKU ที่สต็อกเหลือเฟือแต่ margin อ่อนบางทีก็ได้ประโยชน์จากการลดราคา แต่ต่อเมื่อส่วนลดถูก cap ด้วย contribution margin ไม่ใช่ด้วยสัญชาตญาณล้างสต็อก
ความมั่นใจของ forecast สำคัญ
forecast ไม่ควรแกล้งทำเป็นว่าสมบูรณ์แบบ ระบบที่ดีจะแสดงความมั่นใจควบคู่ไปกับการทำนาย เพราะพฤติกรรม reorder ที่ถูกต้องต่างกันเมื่อความมั่นใจสูง กลาง และต่ำ:
High confidence: reorder now
Medium confidence: monitor and prepare supplier
Low confidence: avoid aggressive inventory betเรื่องนี้สำคัญเป็นพิเศษกับสินค้าใหม่ และสินค้าที่ถูกขับโดย viral content ที่สัญญาณย้อนหลังสั้น มี noise สูง หรือทั้งสองอย่าง
Sensitivity — อะไรเปลี่ยน operating decision
forecasting system ใน production มีอยู่เพื่อป้อน decision และตารางด้านล่าง stress-test ว่า operating decision สามอย่าง — reorder, ad scale, campaign participation — เปลี่ยนไปอย่างไรภายใต้ระดับความมั่นใจของ forecast ที่ต่างกัน
| Decision | มั่นใจสูง | มั่นใจกลาง | มั่นใจต่ำ |
|---|---|---|---|
| Reorder timing | Auto-reorder ที่ lead-time + safety buffer | review โดยคน; supplier เตรียมพร้อม | เลี่ยงการ commit สต็อกแบบ aggressive |
| Ad budget allocation | scale ไปที่ระดับ demand ที่ forecast รองรับ | คงงบปัจจุบัน; monitor รายสัปดาห์ | cap งบไว้ที่ run-rate ปัจจุบัน |
| Campaign-window participation | เข้าร่วมที่ eligibility tier เต็ม | เข้าร่วมที่ voucher tier ต่ำกว่า | ปฏิเสธ; รักษาสต็อกไว้สำหรับ baseline demand |
| Pricing change | ทำ price test พร้อม monitoring | เลื่อนออกไปจนกว่า forecast จะนิ่ง | คงราคาปัจจุบัน |
| Stockout-risk alert | แจ้งเตือนที่สต็อกเหลือ 14 วัน | แจ้งเตือนที่สต็อกเหลือ 21 วัน | แจ้งเตือนที่ 28 วันขึ้นไป; ถือเป็นสัญญาณ soft |
matrix นี้คือ integration layer ระหว่าง forecast กับ operating decision forecast ที่ไม่มี decision rule แบ่งตามระดับความมั่นใจคือ analysis ที่ไม่มี action ส่วนระบบที่แบ่งตามระดับความมั่นใจจะสร้าง case แบบ auto-handled ที่ฝั่งมั่นใจสูง และ case แบบ human-review ที่ฝั่งมั่นใจต่ำ ซึ่งรวมความสนใจของผู้ดูแลร้านไว้ตรงจุดที่สำคัญ
ข้อจำกัด และจุดที่ argument นี้ใช้ไม่ได้
ห้าข้อจำกัดที่ชัดเจน
- ขอบเขตขั้นต่ำของความยาว history framework สมมติว่ามี order-line history สะอาดอย่างน้อย 6 เดือนต่อ SKU ถ้าต่ำกว่านั้น heuristic ที่ง่ายกว่า (moving average, reorder ตาม supplier lead time, category-mean inference) ทำได้ดีกว่า ML model การเปิดตัวสินค้าใหม่ต้องใช้ operating procedure ที่ต่างออกไป: ตั้ง reorder cadence โดยคน แล้วค่อย graduate ไปใช้ model อัตโนมัติเมื่อ history สะสมพอ
- การบิดเบือนจาก viral content SKU ที่ถูกขับโดย content ของ creator หรือ live-stream session มี distribution ของ demand ที่ classical model จัดการได้ไม่ดี — เป็น burst, window สั้น, variance สูง ควรใช้ confidence interval ที่กว้างกว่าและ reorder แบบ human-in-the-loop production code ควรตรวจจับและ flag เคสเหล่านี้แทนที่จะตัดสินเองอัตโนมัติ
- การ interact ของ demand ข้ามแพลตฟอร์ม framework มองว่า demand รายแพลตฟอร์มเป็นอิสระต่อกัน demand จริงบางครั้งย้ายระหว่าง Shopee, Lazada และ TikTok Shop บน SKU เดียวกันเมื่อ price-mirror automation ปิด arbitrage term ของ cross-platform interaction model ได้ไม่ง่าย และเป็นแหล่ง underestimation ที่รู้กันอยู่
- คุณภาพของการ censoring ขั้นตอน censor ช่วง stockout ดีได้เท่ากับ input สถานะสต็อกเท่านั้น ถ้าข้อมูลสถานะสต็อกมี noise (อัปเดตล่าช้า, SKU หลายคลัง) การ censor ที่ใช้ผิดจะสร้างทั้ง over-forecasting (ถ้า aggressive เกินไป) หรือ under-forecasting (ถ้า conservative เกินไป)
- ขอบเขต internal data ตัวเลขความแม่นยำ (~13% sMAPE production baseline, ตัวเลขเปรียบเทียบใน chart) aggregate จากบัญชี Thai SEA-6 Shopee ที่เรา model โดยตรง ไม่ใช่ population claim ของทุก setup demand-forecasting ในอีคอมเมิร์ซ และ exclude ฝั่งล่างสุดของ size distribution ตามที่ระบุข้างต้น
Methodology
Public-data citations มาจากงานวิจัยทบทวนเชิงระบบปี 2025 ของ ScienceDirect เรื่อง ML approach ใน inventory control, methodology และผลของ M5 Forecasting Competition (Kaggle), commentary e-Conomy SEA 2025 ของ Bain เกี่ยวกับปัจจัยที่ขับความผันผวนของ demand ในภูมิภาค และเอกสาร Help Center ของ Shopee เรื่อง stockout policy และการตอบสนองของ ranking algorithm ต่อสถานะสต็อก
Internal-data claims — ตัวเลข sMAPE ข้าม forecasting method ต่าง ๆ, lift ของ stockout-prevention recall 20-40%, สัดส่วน operating-decision ทั่วไปภายใต้ rule ที่แบ่งตามระดับความมั่นใจ — aggregate จากบัญชีผู้ขาย marketplace ที่ active ประมาณ 400 บัญชีใน sample frame ตาม DataGlass research methodology (Jan 2024 – Apr 2026, window สังเกต 28 เดือน) โดยมี order-line history สะอาดอย่างน้อย 6 เดือนต่อ SKU รวมอยู่ใน forecasting evaluation set forecast ถูกประเมินบน rolling out-of-sample window 28 วัน และรายงานตัวเลขความแม่นยำเป็น sample median ข้าม SKU
ผู้ขายไม่จำเป็นต้องเห็นโมเดล ผู้ขายต้องเห็น decision