RFM และกลุ่มลูกค้า
หนึ่งออเดอร์มีหลายสินค้า: จะนับความถี่ซื้อสำหรับ RFM อย่างไร
แยกจำนวนออเดอร์ที่เข้าเกณฑ์ออกจากแถวรายการสินค้า พร้อมตัวอย่างไฟล์ส่งออก 6 แถว วิธีตรวจยอด และขั้นตอนในสเปรดชีตก่อนคำนวณ Frequency ใน RFM
Read in English
ปัญหาที่คุ้นเคยในร้านค้าออนไลน์ไทยสมมติแห่งหนึ่ง
ลองนึกถึงร้านสกินแคร์ขนาดเล็กในกรุงเทพฯ แห่งหนึ่ง — เรียกว่า Glow Lab ก็ได้ — ที่เปิดมาประมาณสองปีและมีลูกค้าซื้อซ้ำสะสมอยู่หลายร้อยคน ผู้จัดการร้านส่งออกข้อมูลออเดอร์ลงสเปรดชีตเพื่อคำนวณคะแนน RFM เป็นครั้งแรก พอเปิดไฟล์ก็เจอสิ่งที่ชวนสับสนทันที: ลูกค้าคนหนึ่ง ซึ่งในบัญชีแสดงว่าเคยมีออเดอร์ 3 ครั้ง กลับปรากฏอยู่ 6 แถวแยกกัน ขณะที่ลูกค้าอีกคนที่สั่งเพียง 1 ครั้งกลับมีแค่ 1 แถว ก่อนจะให้คะแนน Frequency กับใครได้ เธอต้องเข้าใจก่อนว่าทำไมจำนวนแถวกับจำนวนออเดอร์จึงไม่ใช่ตัวเลขเดียวกัน และควรใส่ค่าไหนลงในคอลัมน์ F
ในตัวอย่างนี้ การนับแถวรายการสินค้าให้ค่า 6 แต่การนับออเดอร์ที่เสร็จสมบูรณ์แบบไม่ซ้ำให้ค่า 3 ตัวเลขเหล่านี้เป็นค่าตั้งต้นของ Frequency ไม่ใช่คะแนนที่สรุปได้จากลูกค้าคนเดียว ความผิดพลาดจะทำให้ลูกค้าอยู่คนละควอร์ไทล์หรือไม่ ขึ้นอยู่กับข้อมูลของลูกค้ารายอื่นและกติกาการให้คะแนน ซึ่งอาจส่งผลต่อกลุ่มที่ทีมเลือกติดตาม
คู่มือนี้จะพาไล่ตั้งแต่นิยาม หลักคำนวณ และขั้นตอนปฏิบัติที่จำเป็น เพื่อให้นับ Frequency ได้อย่างถูกต้อง ชื่อลูกค้า เลขออเดอร์ และตัวเลขทั้งหมดที่ใช้เป็นตัวอย่างในบทความนี้เป็นข้อมูลสมมติที่สร้างขึ้นเพื่ออธิบายแนวคิดเท่านั้น
จริง ๆ แล้ว Frequency วัดอะไรใน RFM
การวิเคราะห์ RFM จัดกลุ่มลูกค้าจากสัญญาณพฤติกรรม 3 ด้าน: ซื้อครั้งล่าสุดเมื่อไร ซื้อบ่อยแค่ไหน และใช้จ่ายไปเท่าไร Frequency — ตัว F ตรงกลาง — ตอบคำถามว่าลูกค้าคนนั้นซื้อกี่ครั้งภายในช่วงเวลาวิเคราะห์ที่เลือกไว้ แนวปฏิบัติโดยทั่วไปของ RFM มักนิยาม “การซื้อ” ในระดับออเดอร์ ไม่ใช่จำนวนสินค้าแต่ละชิ้นภายในออเดอร์นั้น คู่มือ RFM ของ Shopify อธิบาย Frequency ว่าเป็นจำนวนออเดอร์ภายในช่วงเวลาวิเคราะห์ และระบุจำนวนออเดอร์รวมเป็นหนึ่งในข้อมูลนำเข้า 3 อย่างที่ต้องใช้ในการรันโมเดล ร้านค้าควรกำหนดกติกาเรื่องการนับออเดอร์ให้สอดคล้องกันภายในชุดข้อมูลของตัวเอง
ทำไมนิยามนี้จึงสำคัญ? เพราะคำว่า “purchase” อาจหมายถึงคนละอย่าง ขึ้นอยู่กับโครงสร้างข้อมูลที่คุณกำลังดูอยู่ ในภาษาทั่วไป การซื้อโทนเนอร์ โฟมล้างหน้า และกันแดดพร้อมกันครั้งเดียว ให้ความรู้สึกเหมือนเป็นการมาช้อปหนึ่งครั้ง — เป็นการตัดสินใจครั้งเดียวที่จะเข้าเว็บไซต์ ใส่ของลงตะกร้า และชำระเงิน การมาซื้อครั้งนั้นจึงก่อให้เกิดออเดอร์ 1 รายการ แต่ในไฟล์ส่งออกที่จัดโครงสร้างแบบหนึ่งแถวต่อหนึ่งสินค้า การช้อปครั้งเดียวนี้อาจปรากฏเป็น 3 แถว ถ้าคุณนับจำนวนแถวแทนที่จะนับจำนวนออเดอร์ คุณกำลังวัดสิ่งที่ใกล้เคียงกับ “ลูกค้าคนนี้เคยเลือกสินค้ากี่แบบ” มากกว่า “ลูกค้าคนนี้กลับมาซื้อกี่ครั้ง”
ความต่างนี้สำคัญต่อการแบ่งกลุ่ม เพราะตัวนับทั้งสองแบบสะท้อนพฤติกรรมลูกค้าคนละมิติ ลูกค้าที่ซื้อ 3 สินค้าใน 1 ออเดอร์เพียงครั้งเดียว มีพฤติกรรมต่างจากลูกค้าที่ทำ 3 ออเดอร์แยกกันใน 3 ช่วงเวลา ทั้งสองคนอาจมีจำนวนแถวเท่ากันในไฟล์ส่งออกแบบ line item แต่มีเพียงลูกค้าคนหลังเท่านั้นที่แสดงให้เห็นว่าเขากลับมาซื้อซ้ำหลายครั้ง — และการกลับมาซื้อซ้ำนี่เองคือสิ่งที่ Frequency ถูกออกแบบมาเพื่อวัด
อ้างอิง: Shopify: RFM Analysis — Definition and Segmentation Guide · Shopify IN: RFM Analysis — Definition and Segmentation Guide
Line item คืออะไร และทำไมไฟล์ส่งออกจึงถูกจัดโครงสร้างตาม line item
Line item คือสินค้าหนึ่งชิ้นหรือหนึ่งตัวเลือกสินค้าในออเดอร์ พร้อมจำนวนและรายละเอียดด้านราคา หากลูกค้าใส่สินค้าต่างกัน 3 ชิ้นลงตะกร้าและชำระเงินครั้งเดียว ออเดอร์ที่เกิดขึ้นจะมี 3 line items — แต่ละรายการมีชื่อสินค้า SKU จำนวน ราคาต่อหน่วย และส่วนลดที่เกี่ยวข้อง เอกสาร API ของ Shopify อธิบายออบเจ็กต์ LineItem ในลักษณะนี้อย่างชัดเจน: มันแทนสินค้าหรือบริการหนึ่งรายการที่ถูกซื้อภายในออเดอร์ พร้อมฟิลด์อย่าง quantity, unit price, variant title และ fulfilment status
แพลตฟอร์มต่าง ๆ จัดโครงสร้างไฟล์ส่งออกในระดับ line item เพราะรายละเอียดที่นำไปใช้งานจริงมักอยู่ตรงนั้น ร้านค้าที่ต้องการรู้ว่าสินค้าใดถูกคืน SKU ไหนใกล้หมด หรือสินค้าตัวเลือกแบบใดถูกใช้ส่วนลดมากที่สุด จำเป็นต้องเห็นข้อมูลหนึ่งแถวต่อหนึ่ง line item ไม่ใช่หนึ่งแถวต่อหนึ่งออเดอร์ นี่เป็นการออกแบบที่สมเหตุสมผลมากสำหรับงานด้านสต็อกและโลจิสติกส์ ปัญหาจะเกิดก็ต่อเมื่อนักวิเคราะห์เผลอถือว่าแต่ละแถวมีความหมายเท่ากับเหตุการณ์การสั่งซื้อ โดยยังไม่ได้ตรวจสอบก่อนว่าข้อมูลอยู่ในระดับใด
ผลในทางปฏิบัตินั้นตรงไปตรงมา: ก่อนจะนับอะไรก็ตามเพื่อทำ RFM ให้ดูไฟล์ส่งออกของคุณก่อนว่าแต่ละแถวแทนหนึ่งออเดอร์หรือหนึ่ง line item หากแต่ละแถวแทน line item คุณต้องรวมข้อมูลกลับขึ้นไปที่ระดับออเดอร์ก่อนคำนวณ Frequency วิธีทำคือจัดกลุ่มหรือเอาข้อมูลซ้ำออกโดยอิงคอลัมน์รหัสออเดอร์ ซึ่งมักเป็นฟิลด์อย่าง order_id หรือ order_number
อ้างอิง: Shopify Admin GraphQL API: LineItem object reference
ตัวอย่างไฟล์ส่งออกสมมติ 6 แถว: มองให้เห็นทั้งสองแบบของการนับพร้อมกัน
ตารางด้านล่างเป็นตัวอย่างเพื่อการสอนที่แต่งขึ้นทั้งหมดสำหรับ Glow Lab โดยมี 6 แถวจาก 3 ออเดอร์ที่ต่างกัน ซึ่งมาจากลูกค้าสมมติคนเดียวชื่อ Malee (customer ID C-001) ไม่มีข้อมูลลูกค้าจริงใด ๆ ปรากฏในตัวอย่างนี้เลย ทั้งเลขออเดอร์ ชื่อสินค้า และยอดเงินทุกตัวถูกสร้างขึ้นเพื่ออธิบายคำถามเรื่องการนับเท่านั้น
เมื่ออ่านตามตาราง จะเห็นว่า 6 แถวนี้จริง ๆ แล้วเป็นของ 3 ออเดอร์ต่างกัน ออเดอร์ ORD-101 ซึ่งสั่งเมื่อวันที่ 3 กุมภาพันธ์ มี 2 line items: โทนเนอร์ (฿390) และเซรั่ม (฿890) ออเดอร์ ORD-118 ซึ่งสั่งเมื่อวันที่ 15 เมษายน มี 3 line items: คลีนเซอร์ (฿290) มอยส์เจอไรเซอร์ (฿650) และกันแดด (฿480) ส่วนออเดอร์ ORD-135 ซึ่งสั่งเมื่อวันที่ 9 สิงหาคม มี 1 line item: ชุดชีตมาสก์ (฿750) ดังนั้นไฟล์ส่งออกนี้จึงมี 6 แถว แต่ Malee ตัดสินใจซื้อแยกกัน 3 ครั้งใน 3 วัน
ตอนนี้เราจึงมองเห็นจำนวน Frequency ได้ 2 แบบชัดเจน ถ้าคุณนับจำนวนแถวในสเปรดชีต จะได้ F = 6 แต่ถ้านับจำนวน order_id ที่ไม่ซ้ำกัน จะได้ F = 3 ทั้งสองตัวเลขคำนวณจากไฟล์เดียวกันได้ แต่มีเพียงแบบเดียวเท่านั้นที่นับสิ่งที่ RFM Frequency ตั้งใจจะวัด: จำนวนครั้งที่ Malee กลับมาซื้อ ค่าที่ถูกต้องสำหรับนำไปใช้เป็น Frequency ของเธอคือ 3
| แถว | customer_id | order_id | order_date | product_name | line_item_total (฿) |
|---|---|---|---|---|---|
| 1 | C-001 | ORD-101 | 2024-02-03 | Hydrating Toner 150 ml | 390 |
| 2 | C-001 | ORD-101 | 2024-02-03 | Brightening Serum 30 ml | 890 |
| 3 | C-001 | ORD-118 | 2024-04-15 | Gentle Cleanser 100 ml | 290 |
| 4 | C-001 | ORD-118 | 2024-04-15 | Daily Moisturiser 50 ml | 650 |
| 5 | C-001 | ORD-118 | 2024-04-15 | SPF 50 Sunscreen 60 ml | 480 |
| 6 | C-001 | ORD-135 | 2024-08-09 | Sheet Mask Set × 5 | 750 |
เหตุผลทางธุรกิจว่าทำไมจึงควรนับจำนวนออเดอร์ แทนการนับจำนวนรายการสินค้า
Frequency แบบนับจำนวนออเดอร์ ตอบคำถามทางธุรกิจที่เฉพาะเจาะจงว่า ลูกค้าคนนี้ตัดสินใจกลับมาซื้อกี่ครั้ง แต่ละออเดอร์คือการตัดสินใจหนึ่งครั้ง — ลูกค้าเข้ามาที่ร้าน เห็นว่าข้อเสนอมีความคุ้มค่า ตัดสินใจจ่ายเงิน และทำขั้นตอนเช็กเอาต์ สัญญาณเชิงพฤติกรรมแบบนี้เองที่การวิเคราะห์การรักษาลูกค้าให้ความสำคัญ ลูกค้าที่กลับมาซื้อ 3 ครั้ง มีส่วนร่วมกับร้านมากกว่าลูกค้าที่เข้ามาครั้งเดียวแต่บังเอิญใส่สินค้าหลายชิ้นลงรถเข็น แม้วยอดใช้จ่ายรวมของทั้งสองคนจะเท่ากันก็ตาม
เอกสารด้านการวิเคราะห์ของ IBM ก็แบ่งความหมายเชิงแนวคิดนี้ไว้เหมือนกัน: orders และ items ordered เป็นคนละตัวชี้วัด — ตัวหนึ่งใช้วัดเหตุการณ์การซื้อ ส่วนอีกตัวใช้วัดจำนวนสินค้าภายในเหตุการณ์เหล่านั้น หากนำสองอย่างนี้มาปนกัน ลูกค้าที่ซื้อกิฟต์บันเดิล 10 ชิ้นในการเข้าร้านครั้งเดียว อาจดูเหมือนมีความถี่สูงกว่าลูกค้าที่กลับมาซื้อรีฟิลเดือนละครั้ง ทั้งที่จริงแล้วการตีความแบบนั้นทำให้สัญญาณเรื่องความภักดีที่ Frequency ต้องการวัดเพี้ยนไป
ยังมีเหตุผลด้านความสม่ำเสมอในการทำงานด้วย หากทุกคนในทีมของ Glow Lab ตกลงตรงกันว่า Frequency หมายถึงจำนวนออเดอร์ที่ไม่ซ้ำกัน ลูกค้าทุกคนก็จะถูกวัดบนฐานเดียวกัน ไม่ว่าปกติเขาจะชอบใส่กี่สินค้าต่อหนึ่งตะกร้า ลูกค้าที่ชอบซื้อหลายแบบเป็นบันเดิลกับลูกค้าที่ซื้อทีละชิ้น จะถูกจัดอันดับตามจำนวนครั้งที่กลับมาเยือนร้านเหมือนกันทันที แต่ถ้าสมาชิกแต่ละคนใช้กติกาคนละแบบ — คนหนึ่งนับจำนวนแถว อีกคนหนึ่งนับ order ID — คะแนนก็จะเทียบกันไม่ได้ และเซกเมนต์ที่ได้ก็จะไม่น่าเชื่อถือ
อ้างอิง: IBM Support: Why is the Orders metric greater than Items Ordered?
วิธีที่การนับสองแบบให้ผลควอร์ไทล์ต่างกัน
เพื่อให้เห็นชัดว่าหน่วยที่ใช้ในการนับส่งผลต่อการให้คะแนนอย่างไร ลองดูตัวอย่างแบบย่อจากรายชื่อลูกค้าสมมติของ Glow Lab สมมติว่าร้านใช้การแบ่ง 4 ควอร์ไทล์ในแต่ละมิติของ RFM โดยใช้หลักการที่ควอร์ไทล์ 1 คือกลุ่มที่ดีที่สุด และควอร์ไทล์ 4 คือกลุ่มที่เคลื่อนไหวน้อยที่สุด ดังนั้นในมิติ Frequency เลขควอร์ไทล์ยิ่งต่ำก็ยิ่งหมายถึงซื้อบ่อยกว่า
ค่า Frequency ดิบของมาลี คือ 3 ออเดอร์ถ้านับตาม order ID ที่ไม่ซ้ำกัน หรือ 6 ถ้านับตามจำนวนแถวรายการสินค้า ว่าทั้งสองค่านี้จะไปอยู่ควอร์ไทล์เดียวกันหรือต่างกัน ขึ้นอยู่ทั้งหมดกับการกระจายของค่าของลูกค้าคนอื่น ๆ ด้วย ลูกค้าที่สั่งออเดอร์ย่อยหลายครั้งและแต่ละครั้งมีสินค้าไม่กี่ชิ้น อาจมีจำนวนออเดอร์สูง ขณะที่จำนวนแถวรายการสินค้าใกล้เคียงกันมาก ทำให้ถูกจัดอยู่ในควอร์ไทล์ที่ดีไม่ว่าจะใช้วิธีไหน แต่ลูกค้าที่ซื้อไม่กี่ครั้งแต่แต่ละครั้งเป็นบันเดิลใหญ่ อาจมีจำนวนแถวรายการสินค้ามากกว่าจำนวนออเดอร์หลายเท่า และอาจถูกจัดไปอยู่ควอร์ไทล์ที่ดูดีกว่าภายใต้วิธีนับแบบแถวสินค้าเมื่อเทียบกับวิธีนับแบบออเดอร์ ประเด็นสำคัญไม่ใช่ว่าสองวิธีนี้จะให้ผลไม่ตรงกันทุกครั้ง แต่คือมันกำลังวัดคนละอย่าง และจะค่อย ๆ ให้ผลแยกจากกันอย่างเป็นระบบ โดยเฉพาะในลูกค้าที่ขนาดออเดอร์แตกต่างกันมาก
ความเสี่ยงเชิงปฏิบัติคือการระบุเซกเมนต์ผิด ลูกค้าที่สั่ง 7 ออเดอร์ โดยแต่ละออเดอร์มีสินค้า 1 ชิ้น จะดูเป็นลูกค้าซื้อซ้ำที่มีส่วนร่วมสูงมากเมื่อวัดด้วยจำนวนออเดอร์ ลูกค้าคนเดียวกันนั้นจะมีเพียง 7 แถวรายการสินค้า — เท่ากับลูกค้าอีกคนที่สั่งเพียง 1 ออเดอร์แต่มีสินค้า 7 ชิ้น — และทั้งสองคนอาจไปอยู่ควอร์ไทล์เดียวกัน ทั้งที่รูปแบบการซื้อแตกต่างกันโดยสิ้นเชิง การนับจำนวนออเดอร์ยังคงรักษาความต่างด้านพฤติกรรมนี้ไว้ ขณะที่การนับจำนวนรายการสินค้าจะลบความต่างนั้นทิ้ง
ทั้งสองค่านี้มาจากไฟล์ส่งออก 6 แถวเดียวกัน ค่าแบบนับออเดอร์ (3) สะท้อนเหตุการณ์การซื้อที่ไม่ซ้ำกัน ค่าแบบนับรายการสินค้า (6) สะท้อนจำนวนแถวสินค้ารายชิ้น ทั้งสองตัวเลขนี้วัดคนละเรื่อง และมีเพียงค่าเดียวเท่านั้นที่ควรอยู่ในคอลัมน์ Frequency ของ RFM
ใช้หน่วยนับที่ถูกต้องอย่างสม่ำเสมอกับลูกค้าทุกคน
เมื่อคุณกำหนดชัดแล้วว่า Frequency หมายถึงจำนวนออเดอร์ที่ไม่ซ้ำกัน — ไม่ใช่จำนวนแถวรายการสินค้า — สิ่งที่สำคัญไม่แพ้กันคือการใช้คำนิยามนี้อย่างสม่ำเสมอกับลูกค้าทุกคนในการให้คะแนนรอบเดียวกัน โมเดล RFM จัดอันดับลูกค้าโดยเปรียบเทียบกันภายในกลุ่มเดียวกัน ดังนั้นคะแนนจะมีความหมายได้ก็ต่อเมื่อทุกคนถูกวัดบนฐานเดียวกัน การปล่อยให้หน่วยนับปะปนกันจะทำให้การกระจายทั้งชุดเสีย ไม่ใช่แค่บางเรคคอร์ด
คู่มือ RFM ของ Shopify อธิบายช่วงคะแนนและช่วงเวลาที่ใช้วิเคราะห์ ก่อนเปรียบเทียบคะแนนระหว่างระบบ ให้ตรวจสเกล เกณฑ์แบ่งช่วง และช่วงเวลาวิเคราะห์ สำหรับใบงานในคู่มือนี้ ให้บันทึกด้วยว่ารายการใดนับเป็นออเดอร์ที่เข้าเกณฑ์ และใช้หน่วยนับเดียวกันกับลูกค้าทุกคน
หากคุณคำนวณ Frequency ของลูกค้า A โดยนับจำนวนออเดอร์ที่ไม่ซ้ำกัน แต่กลับเผลอใช้จำนวนแถวของลูกค้า B เพราะโครงสร้างไฟล์ส่งออกของเธอไม่เหมือนกัน อันดับเปรียบเทียบใด ๆ ที่เกี่ยวข้องกับลูกค้าสองคนนั้นก็จะเสียทันที ในทางปฏิบัติ ความสม่ำเสมอหมายถึงการบันทึกนิยามเป็นลายลักษณ์อักษรก่อนเริ่มคำนวณ ได้แก่ วันเริ่มต้นและวันสิ้นสุดของช่วงเวลาวิเคราะห์ หน่วยนับของ Frequency (จำนวนออเดอร์ที่ไม่ซ้ำกัน) สถานะออเดอร์ใดบ้างที่นับรวม วิธีจัดการกับออเดอร์ที่ถูกยกเลิก และวิธีจัดการกับออเดอร์ที่คืนเงิน ไม่ว่าคุณจะตัดสินใจแบบไหน ก็ต้องใช้กติกาเดียวกันกับลูกค้าทุกคนภายในการให้คะแนนรอบเดียวกัน
อ้างอิง: Shopify SG: RFM Analysis — Definition and Segmentation Guide
ทีละขั้น: คำนวณ Frequency ที่ถูกต้องจากไฟล์ส่งออกระดับรายการสินค้าในสเปรดชีต
ขั้นตอนต่อไปนี้ตั้งอยู่บนสมมติฐานว่าคุณได้ส่งออกข้อมูลออเดอร์เป็นไฟล์ CSV โดยอย่างน้อยมี 4 คอลัมน์ ได้แก่ customer_id, order_id, order_date และ order_total (หรือชื่อใกล้เคียงกัน) แต่ละแถวในไฟล์แทนรายการสินค้า 1 รายการ ขั้นตอนเหล่านี้เขียนสำหรับโปรแกรมสเปรดชีตทั่วไป คุณสามารถปรับชื่อคอลัมน์ให้ตรงกับฟิลด์จริงของคุณได้
ขั้นตอนที่ 1: เปิดไฟล์ส่งออกและอ่านนิยามของแต่ละฟิลด์ ตรวจตัวอย่างแถว รวมถึงออเดอร์ที่คุณยืนยันกับข้อมูลต้นทางได้ ค่า order_id ที่ปรากฏซ้ำเป็นเหตุให้ตรวจสอบว่ามาจากรายการสินค้า แถวส่งออกซ้ำ ประวัติสถานะ หรือรายการปรับปรุง คีย์ที่ซ้ำกันเพียงอย่างเดียวยังบอกหน่วยนับของแต่ละแถวไม่ได้ ยืนยันว่ามี customer_id, order_id, order_date และฟิลด์ที่จำเป็นตามกฎคัดเลือกออเดอร์ ก่อนกรองและตรวจยอดข้อมูล
ขั้นตอนที่ 2: สร้างตารางออเดอร์ที่ไม่ซ้ำกัน คัดลอกคอลัมน์ customer_id, order_id และ order_date ไปยังชีตใหม่ จากนั้นลบแถวที่ซ้ำออก เพื่อให้แต่ละคู่ของ customer_id และ order_id ปรากฏเพียงครั้งเดียวเท่านั้น ในเครื่องมือสเปรดชีตส่วนใหญ่ คุณสามารถใช้ฟังก์ชัน Remove Duplicates กับคอลัมน์ customer_id และ order_id พร้อมกัน หรือใช้ pivot table ที่จัดกลุ่มตาม customer_id และ order_id ได้
ขั้นตอนที่ 3: นับจำนวนออเดอร์ที่ไม่ซ้ำกันต่อหนึ่งลูกค้า ในชีตที่ลบข้อมูลซ้ำแล้ว — ซึ่งแต่ละแถวแทน 1 ออเดอร์ — ให้ใช้ COUNTIF กับคอลัมน์ customer_id เพื่อนับว่าแต่ละลูกค้ามีกี่แถว ตัวอย่างเช่น =COUNTIF(customer_id_column, current_customer_id) ผลลัพธ์ที่ได้คือค่า Frequency ของลูกค้าคนนั้น สำหรับมาลีที่มี 3 ออเดอร์ การนับนี้จะได้ค่า 3
ขั้นตอนที่ 4: กำหนดช่วงเวลาวิเคราะห์ก่อนการนับ ถ้าช่วงเวลาของคุณคือ 12 เดือนย้อนหลัง ให้กรอง order_date ให้เหลือเฉพาะแถวที่อยู่ในช่วงนั้นก่อนจะทำการนับในขั้นตอนที่ 3 ออเดอร์ที่อยู่นอกช่วงต้องไม่ถูกนำมาคิดใน Frequency แม้ว่าลูกค้าจะเคยสั่งจริงก็ตาม
ขั้นตอนที่ 5: เก็บทั้งจำนวนดิบและรายการ order ID ไว้เพื่อการตรวจสอบย้อนหลัง หากภายหลังมีคะแนนที่ดูผิดคาด การมีรายการ order ID ที่ถูกนับให้ลูกค้าแต่ละคน จะช่วยให้คุณย้อนเช็กเลขได้เร็ว โดยไม่ต้องรันไฟล์ส่งออกใหม่ทั้งหมด
- ยืนยันก่อนเริ่มนับเสมอว่าไฟล์ส่งออกของคุณเป็น 1 แถวต่อ 1 ออเดอร์ หรือ 1 แถวต่อ 1 รายการสินค้า
- ลบข้อมูลซ้ำโดยอิงคู่ customer_id และ order_id เพื่อสร้างรายการออเดอร์ที่ไม่ซ้ำกัน; อย่าลบข้อมูลซ้ำโดยอิง order_id อย่างเดียว เว้นแต่คุณยืนยันแล้วว่า order_id ไม่ซ้ำกันทั้งไฟล์ข้ามลูกค้าทุกคน
- ใช้ตัวกรองวันที่ของช่วงเวลาวิเคราะห์ก่อนการนับ — ออเดอร์ที่อยู่นอกช่วงต้องถูกตัดออก
- ในชีตที่ลบข้อมูลซ้ำแล้ว ให้ใช้ COUNTIF กับคอลัมน์ customer_id (เช่น =COUNTIF(customer_id_column, current_customer_id)) หรือใช้ pivot table เพื่อนับจำนวนออเดอร์ต่อหนึ่งลูกค้า; อย่าใช้การรวมคอลัมน์ quantity สำหรับขั้นตอนนี้
- บันทึกวันเริ่มและวันสิ้นสุดของช่วงเวลา สถานะออเดอร์ที่นับรวม และวิธีจัดการการคืนเงินเป็นลายลักษณ์อักษรก่อนให้คะแนน
- เก็บรายการ order ID ของลูกค้าแต่ละคนไว้สำหรับการตรวจสอบหลังการวิเคราะห์
การทำงานกับไฟล์ CSV export จาก CasperBrain
CasperBrain รองรับการส่งออกข้อมูลลูกค้าเป็น CSV สำหรับผู้ใช้ที่ได้รับสิทธิ์ โดยฟิลด์ที่มองเห็นขึ้นอยู่กับสิทธิ์ของผู้ขอส่งออก อย่าสมมติว่าไฟล์ข้อมูลลูกค้าเป็นประวัติออเดอร์หรือรายการสินค้าที่ครบถ้วน ให้ตรวจหน่วยนับ ตัวระบุ ช่วงวันที่ และรายการที่ถูกตัดออกของไฟล์จริง หากจะทำซ้ำตัวอย่างข้อมูลออเดอร์ในคู่มือนี้ ต้องใช้แหล่งข้อมูลที่ตรวจสอบแล้วและมีตัวระบุลูกค้ากับออเดอร์ที่จำเป็น แถวสรุปลูกค้าเพียงแถวเดียวไม่เพียงพอ
ค่า order_id ที่ซ้ำกันภายในลูกค้าคนเดียวแสดงว่าคีย์ออเดอร์ปรากฏซ้ำ แต่ยังไม่ยืนยันว่าไฟล์มีหนึ่งแถวต่อรายการสินค้า ตรวจนิยามของแหล่งข้อมูลและตัวอย่างแถว เพื่อแยกรายการสินค้าที่ถูกต้องออกจากข้อมูลส่งออกซ้ำ ประวัติสถานะ หรือรายการปรับปรุง ใช้กฎการคัดเลือกออเดอร์ที่กำหนดไว้และตรวจยอดคู่ตัวระบุลูกค้าและออเดอร์ที่ไม่ซ้ำก่อนนับ จะนับแถวได้โดยตรงก็ต่อเมื่อตรวจแล้วว่าแต่ละแถวที่เหลือแทนหนึ่งออเดอร์ที่เข้าเกณฑ์ และคู่ตัวระบุลูกค้ากับออเดอร์ไม่ซ้ำกัน
โปรดทราบว่าระบบให้คะแนน RFM ของ CasperBrain ใช้การแบ่งเป็น 4 quartiles และให้คะแนนเป็นเลข 1 ถึง 4 โดยเลข 1 หมายถึงกลุ่มที่ดีที่สุดในแต่ละมิติ ซึ่งเป็นทิศทางตรงข้ามกับบางเครื่องมือที่ให้เลข 5 เป็นกลุ่มที่ดีที่สุด หากคุณกำลังสร้างการคำนวณเองนอก CasperBrain และวางแผนจะนำผลไปเทียบกับคะแนนของ CasperBrain ภายหลัง ให้ตรวจสอบก่อนเสมอว่าแต่ละระบบใช้ทิศทางคะแนนแบบใด ก่อนตีความรหัสผสมอย่าง "114" เช่น ในมาตรฐานของ CasperBrain เลข "1" ในมิติ Frequency หมายถึงลูกค้าที่ซื้อบ่อยที่สุด แต่ในบางเครื่องมือแบบ 5 ระดับ เลข "1" อาจหมายถึงลูกค้าที่ซื้อน้อยที่สุด สองระบบนี้ใช้แทนกันไม่ได้
ข้อผิดพลาดที่พบบ่อย และวิธีจับให้ได้ตั้งแต่เนิ่น ๆ
ข้อผิดพลาดหนึ่งที่ควรระวังคือการนับแถวในสเปรดชีตโดยไม่ตรวจว่าแต่ละแถวแทนอะไร เลือกออเดอร์จากข้อมูลต้นทางที่คุณยืนยันลูกค้าและรายการสินค้าได้ แล้วตรวจทุกแถวที่ตรงกันในไฟล์ส่งออก การมีหลายแถวอาจมาจากรายการสินค้า การเปลี่ยนสถานะ รายการปรับปรุง หรือข้อมูลซ้ำ ให้ตรวจความหมายจากนิยามของแหล่งข้อมูลและกฎคัดเลือกออเดอร์ที่กำหนดไว้ ก่อนสร้างคู่ตัวระบุลูกค้ากับออเดอร์ที่ไม่ซ้ำกัน
ข้อผิดพลาดอย่างที่สองคือการนับออเดอร์ที่ถูกยกเลิกหรือคืนเงินเต็มจำนวนรวมเข้าไปใน Frequency โดยที่ยังไม่ได้ตกลงกติกาให้ชัด ทีมของคุณควรตัดสินใจล่วงหน้าว่าจะนับออเดอร์แบบใดเป็นเหตุการณ์การซื้อ — เช่น นับเฉพาะออเดอร์ที่ชำระเงินและจัดส่งสำเร็จแล้ว หรือจะนับทุกออเดอร์ที่ถูกสร้างขึ้นโดยไม่ดู status ก็ได้ ไม่ว่าคุณจะเลือกแบบใด ต้องบันทึกกติกาไว้และใช้เหมือนกันกับลูกค้าทุกรายอย่างสม่ำเสมอ แหล่งอ้างอิงเรื่อง RFM มักเน้นให้ใช้กติกาที่สม่ำเสมอสำหรับออเดอร์ที่ยกเลิกและคืนเงิน มากกว่าจะกำหนดข้อยกเว้นสากลแบบเดียว
ข้อผิดพลาดอย่างที่สามเกิดเมื่อใช้ช่วงเวลาวิเคราะห์ไม่สอดคล้องกัน หากนักวิเคราะห์คนหนึ่งกรองด้วย order_date แต่อีกคนกรองด้วย payment_date หรือ shipped_date การรันจากข้อมูลดิบชุดเดียวกันจะให้ค่า Frequency ต่างกันสำหรับลูกค้าที่มีออเดอร์คาบเส้นแบ่งเดือน ควรตกลงกันให้ชัดว่าจะใช้ฟิลด์วันใดฟิลด์หนึ่ง แล้วใช้ฟิลด์นั้นเหมือนกันทุกครั้ง
ข้อผิดพลาดอย่างที่สี่ — ซึ่งสังเกตยากกว่าแต่มีผลมาก — คือการนำคะแนน RFM จากแพลตฟอร์มหนึ่งไปใช้อีกแพลตฟอร์มหนึ่งโดยไม่ตรวจสอบก่อนว่าทั้งสองระบบใช้ทิศทางคะแนนเหมือนกันหรือไม่ ลูกค้าที่ได้คะแนน Frequency เป็น "1" จากแพลตฟอร์มที่นิยาม 1 = ซื้อน้อยที่สุด จะดูเหมือนเป็นลูกค้าชั้นดีทันทีถ้านำเข้าไปตีความใน CasperBrain ซึ่งใช้ 1 = ซื้อบ่อยที่สุด ดังนั้นควรคำนวณคะแนนใหม่บนแพลตฟอร์มปลายทางเสมอ แทนที่จะยกตัวเลขเดิมมาจากระบบที่ใช้คนละมาตรฐาน
- ตรวจแบบ spot-check: หาลูกค้าที่รู้แน่ว่ามีหนึ่งออเดอร์แบบหลายสินค้า แล้วตรวจว่าจำนวนแถวของเขาในไฟล์ export เหลือเท่ากับ 1 หลังจากลบข้อมูลซ้ำแล้ว
- ตัดสินใจล่วงหน้าว่าจะนับ status ของออเดอร์แบบใดเป็นเหตุการณ์การซื้อ แล้วบันทึกกติกาและใช้กับลูกค้าทุกรายอย่างสม่ำเสมอ
- ใช้ฟิลด์วันเดียวอย่างสม่ำเสมอ — เลือก order_date, payment_date หรือ shipped_date อย่างใดอย่างหนึ่ง แล้วใช้เหมือนกันในทุกรอบการให้คะแนน
- อย่านำคะแนน RFM ดิบข้ามแพลตฟอร์มที่ใช้ทิศทางคะแนนต่างกัน ให้คำนวณใหม่บนแพลตฟอร์มปลายทางเสมอ
- หลังให้คะแนนแล้ว ให้ sanity-check ลูกค้าใน quartile บนสุด: ชื่อที่ออกมาควรเป็นลูกค้าที่คุณจำได้จากประสบการณ์หน้าร้านว่าเป็นลูกค้าที่ซื้อบ่อยจริง
ข้อจำกัดของการใช้จำนวนออเดอร์เป็น Frequency และเมื่อไรควรทบทวน
การนับจำนวนออเดอร์ที่ไม่ซ้ำกันคือความหมายมาตรฐานของ Frequency ใน RFM และใช้ได้ดีกับสถานการณ์ค้าปลีกส่วนใหญ่ อย่างไรก็ตาม วิธีนี้ก็มีข้อจำกัดที่ควรรับรู้ไว้ เพื่อให้คุณตัดสินใจได้ว่าวิธีมาตรฐานนี้เหมาะกับร้านของคุณจริงหรือไม่
จำนวนออเดอร์ไม่ได้สะท้อนปริมาณสินค้าที่ซื้อภายในแต่ละออเดอร์ ลูกค้าที่ซื้อสินค้าครั้งละ 10 ชิ้นทุกครั้ง จะดูเหมือนลูกค้าที่ซื้อครั้งละ 1 ชิ้น หากทั้งสองคนสั่งซื้อจำนวนครั้งเท่ากัน ถ้าปริมาณสินค้าต่อออเดอร์มีความสำคัญเชิงกลยุทธ์กับร้านของคุณมาก — เช่น ร้านของคุณขายส่งให้ธุรกิจขนาดเล็กที่สต็อกของครั้งละมาก ๆ — คุณอาจต้องติดตามค่าเฉลี่ยจำนวนชิ้นต่อออเดอร์เป็นตัวชี้วัดเสริมควบคู่ไปกับ Frequency แบบมาตรฐาน แทนที่จะเอาไปแทนที่กัน
จำนวนออเดอร์ยังไม่แยกความต่างระหว่างออเดอร์ที่มียอดเงินต่างกันมาก ๆ ด้วย มิตินี้เป็นหน้าที่ของ Monetary ใน RFM ไม่ใช่ของ Frequency ควรแยกบทบาทของแต่ละมิติให้ชัด และปล่อยให้แต่ละตัวชี้วัดทำหน้าที่ของตัวเอง การพยายามใส่น้ำหนักตามมูลค่าออเดอร์ลงไปใน Frequency เพื่อให้สะท้อนเรื่องเงินด้วย จะขัดกับการออกแบบดั้งเดิมของโมเดล และทำให้คะแนนตีความยากขึ้น
สุดท้าย Frequency ไวต่อช่วงเวลาวิเคราะห์โดยธรรมชาติอยู่แล้ว หน้าต่างเวลา 12 เดือนจะจับลูกค้าซื้อซ้ำที่กลับมาภายในปีได้ แต่ถ้าใช้หน้าต่างเวลา 6 เดือน ลูกค้าคนเดิมก็จะได้ค่า Frequency ต่ำลง ไม่มีความยาวของช่วงเวลาที่ “ถูกต้องสากล” คุณควรเลือกช่วงเวลาที่สะท้อนวงจรการซื้อซ้ำตามธรรมชาติของร้านคุณ — ร้านสินค้าบริโภครายเดือนกับร้านอิเล็กทรอนิกส์ย่อมต้องใช้ช่วงเวลาต่างกัน — และใช้ช่วงเวลาเดิมทุกครั้งที่คำนวณใหม่ เพื่อให้คะแนนข้ามช่วงเวลานำมาเทียบกันได้
สรุปให้ครบ: เช็กลิสต์ตัดสินใจก่อนเริ่มให้คะแนน
ก่อนที่คุณจะใส่ค่า Frequency ให้ลูกค้าคนใดก็ตาม ให้ไล่ตัดสินใจตามลำดับต่อไปนี้ก่อน เพราะทุกข้อมีผลต่อค่าที่คุณจะคำนวณได้ การเคลียร์กติกาเหล่านี้ให้จบก่อนแตะข้อมูล จะมีประสิทธิภาพกว่าการมาพบความไม่สอดคล้องหลังจากนำคะแนนไปใช้แล้วมาก
ข้อแรก ยืนยันช่วงเวลาวิเคราะห์ให้ชัด: มีวันเริ่มต้นและวันสิ้นสุดที่แน่นอน พร้อมระบุฟิลด์วันที่ที่จะใช้กรองไว้เป็นลายลักษณ์อักษร ข้อสอง ยืนยันโครงสร้างไฟล์ export: หนึ่งแถวเท่ากับหนึ่งออเดอร์ หรือหนึ่งแถวเท่ากับหนึ่งรายการสินค้าในออเดอร์ ถ้าเป็นระดับ line item ต้องวางแผนทำขั้นตอนลบข้อมูลซ้ำบนคู่ค่า customer_id และ order_id ข้อสาม ตัดสินใจว่า status แบบใดนับเป็นเหตุการณ์การซื้อ และ status แบบใดต้องตัดออก — นี่เป็นกติกาเฉพาะของแต่ละร้าน ไม่ใช่ข้อบังคับสากล ข้อสี่ ตัดสินใจว่าจะจัดการกับการคืนเงินบางส่วนอย่างไร: ถ้าออเดอร์หนึ่งใบมีรายการสินค้าบางชิ้นถูกคืนเงิน ออเดอร์นั้นยังนับเป็นหนึ่งเหตุการณ์การซื้อหรือไม่ ข้อห้า ตรวจสอบทิศทางสเกลของเครื่องมือที่จะใช้ให้คะแนนจากจำนวนออเดอร์ที่ลบซ้ำแล้ว โดยเฉพาะถ้าคุณจะเปรียบเทียบผลข้ามแพลตฟอร์ม
เมื่อบันทึกการตัดสินใจทั้งห้าข้อนี้เรียบร้อยแล้ว ตัวการคำนวณเองจะเป็นงานเชิงกลล้วน ๆ สำหรับลูกค้าสมมติของ Glow Lab ที่ชื่อ Malee ผลลัพธ์คือ: มีออเดอร์ที่ไม่ซ้ำกัน 3 ออเดอร์ภายในช่วงเวลาวิเคราะห์ ซึ่งคือตัวเลขที่ควรใส่ในคอลัมน์ Frequency — ไม่ใช่เลข 6 ที่ปรากฏเป็นจำนวนแถวดิบในไฟล์ export ระดับ line item ความต่างกันเพียงหลักเดียวนี้ เมื่อขยายไปในลูกค้าหลายร้อยราย คือความต่างระหว่างการแบ่งเซ็กเมนต์ที่สะท้อนพฤติกรรมการซื้อจริง กับการแบ่งเซ็กเมนต์ที่ตั้งอยู่บนสิ่งเพี้ยนจากโครงสร้างข้อมูล
- กำหนดและบันทึกวันเริ่มต้น วันสิ้นสุด และฟิลด์ที่ใช้กรองของช่วงเวลาวิเคราะห์ให้เสร็จก่อนเปิดไฟล์ export
- ระบุให้ชัดว่าไฟล์ export เป็นแบบหนึ่งแถวต่อหนึ่งออเดอร์ หรือหนึ่งแถวต่อหนึ่งรายการสินค้าในออเดอร์
- หากไฟล์อยู่ในระดับ line item ให้ลบข้อมูลซ้ำโดยอิงคู่ค่า customer_id และ order_id และตรวจว่าจำนวนออเดอร์ที่ไม่ซ้ำตรงกับประวัติออเดอร์ที่ทราบแน่ของลูกค้าทดสอบอย่างน้อย 1 ราย
- กำหนดว่า status ของออเดอร์แบบใดนับรวม แล้วใช้กติกานั้นอย่างสม่ำเสมอ
- ตัดสินใจว่าออเดอร์ที่มีการคืนเงินบางส่วนจะมีผลต่อการนับอย่างไร แล้วบันทึกกติกาไว้
- ตรวจสอบทิศทางสเกลของ Frequency (1 = ดีที่สุด หรือ 1 = แย่ที่สุด) ของเครื่องมือให้คะแนนทุกตัวก่อนป้อนค่าที่คำนวณได้
แหล่งข้อมูลและวิธีจัดทำ
ตัวอย่างในบทความเป็นข้อมูลสมมติ ไม่มีข้อมูลลูกค้าจริง บทความจัดทำโดยทีม CasperBrain โดยใช้ AI ช่วยร่าง ตรวจข้อเท็จจริงและภาษาก่อนเผยแพร่