RFM และกลุ่มลูกค้า
วิธีวัดการซื้อซ้ำให้ถูกต้อง: คู่มือฉบับสมบูรณ์สำหรับร้านค้าออนไลน์ไทย
3 วิธีวัดการซื้อซ้ำในร้านเดียว: เรียนรู้ความต่างระหว่าง historical repeat share, period returning-buyer share และ first-purchase cohort second-order rate พร้อมตัวอย่างคำนวณ ข้อควรระวังเรื่อง cohort maturity คะแนน RFM และข้อตกลงการวัดผลรายสัปดาห์
Read in English
ร้านชื่อ Blossom Skin — และตัวเลข 3 ชุดที่ไม่ตรงกัน
ลองนึกถึงร้านสกินแคร์ไทยชื่อ Blossom Skin เจ้าของร้านคือคุณดาว ขายเซรั่มและมอยส์เจอไรเซอร์ออนไลน์มาสองปีแล้ว เช้าวันจันทร์ที่ผ่านมา เธอเปิดรายงานขึ้นมาสามชุด และเจอตัวเลขสามค่า: 19%, 18.75% และ 25% โดยแต่ละรายงานก็อ้างว่ากำลังแสดง “อัตราการซื้อซ้ำ” ของร้าน ทีมข้อมูลของเธอไม่ได้โกหก — ทั้งสามวิธีคำนวณถูกต้องตามหลักเลขทั้งหมด แต่แต่ละค่ากำลังวัดคนละเรื่อง ตอบคนละคำถาม และไม่ควรถูกนำมาใส่ไว้ในประโยคเดียวกันโดยไม่มีป้ายกำกับอย่างเด็ดขาด
คู่มือนี้จะแยก 3 ตัวชี้วัดที่มีประโยชน์ อธิบายกติกาเรื่อง valid order และการระบุตัวตนลูกค้า แสดงไทม์ไลน์สมมติ 5 แบบ และให้แนวทางวัดผลรายสัปดาห์ ตัวเลขทั้งหมดเป็นตัวอย่างแต่งขึ้นเพื่อการสอน ไม่ใช่ผลวิจัยหรือผลลัพธ์จากผลิตภัณฑ์จริง ทุกผลลัพธ์ต้องระบุให้ชัดว่ากำลังวัดประชากรกลุ่มใด และใช้ช่วงเวลาสังเกตเท่าใด เพื่อให้ทีมรู้ว่าตัวเลขนั้นรองรับการตัดสินใจแบบไหนได้บ้าง
ทำไมจึงมี 3 ตัวชี้วัด และทำไมจึงต่างกัน
ตัวชี้วัดที่เกี่ยวข้องกันสามารถให้ค่าต่างกันได้อย่างถูกต้อง เพราะใช้ประชากรและหน้าต่างเวลาไม่เหมือนกัน เริ่มต้นด้วยการตั้งชื่อคำถามและตัวหารให้ชัดเจน อย่าเรียกทุกเปอร์เซ็นต์รวม ๆ ว่า “อัตราการซื้อซ้ำ”
Historical repeat share: ในบรรดาลูกค้าไม่ซ้ำกันที่มี valid purchase อย่างน้อย 1 ครั้งภายในประวัติที่กำลังวิเคราะห์อยู่ มีกี่เปอร์เซ็นต์ที่มี valid order แบบไม่ซ้ำกันอย่างน้อย 2 ออเดอร์ หากประวัติของคุณครบตั้งแต่วันเปิดร้าน นี่อาจเป็นตัวชี้วัดแบบ all-time ได้ แต่ถ้าเป็นการ export ข้อมูลมาแค่บางช่วง ต้องติดป้ายช่วงวันที่ที่ใช้ แทนการอ้างว่าเป็นพฤติกรรมตลอดอายุร้าน สัดส่วนนี้อาจเปลี่ยนได้เมื่อมีลูกค้าใหม่เข้ามา หรือมีการนำเข้าออเดอร์เก่าเพิ่มเติม แม้พฤติกรรมล่าสุดของลูกค้าแต่ละคนจะไม่ได้เปลี่ยนเลยก็ตาม
Period returning-buyer share: ในบรรดาลูกค้าที่ซื้อในเดือนกรกฎาคม มีกี่เปอร์เซ็นต์ที่มี valid order ในเดือนกรกฎาคม โดยก่อนหน้านั้นเคยมี valid order อยู่แล้วในประวัติการซื้อของตนเอง การซื้อก่อนหน้าสามารถเกิดก่อนเดือนกรกฎาคมได้ ลูกค้าที่ซื้อหนึ่งครั้งในเดือนมิถุนายน และอีกหนึ่งครั้งในเดือนกรกฎาคม ถือเป็นลูกค้ากลับมาซื้อ แม้เขาจะซื้อเพียงครั้งเดียวในเดือนกรกฎาคมก็ตาม ตัวหารคือผู้ซื้อเดือนกรกฎาคมแบบไม่ซ้ำกันทั้งหมด เมื่อขยายช่วงเวลารายงาน ทั้งตัวนับและตัวหารจะเปลี่ยนได้ ดังนั้นอัตราที่ได้จึงไม่จำเป็นต้องสูงขึ้นเสมอไป
First-purchase cohort second-order rate: ในบรรดาลูกค้าที่มี valid purchase ครั้งแรกอยู่ในช่วงรับลูกค้าใหม่ที่กำหนด มีกี่เปอร์เซ็นต์ที่วาง valid order ครั้งที่สองแบบไม่ซ้ำกัน ภายในช่วงเวลาคงที่หลังจากการสั่งซื้อครั้งแรกของตนเอง นาฬิกาจะเริ่มนับแยกกันสำหรับลูกค้าแต่ละคน ตัวชี้วัดนี้อธิบายพฤติกรรมการกลับมาซื้อในช่วงต้น ซึ่งช่วยตอบคำถามด้าน onboarding ได้ แต่เพียงลำพังยังไม่ใช่การวัดผลเชิงเหตุและผลของแคมเปญ onboarding ควรเปรียบเทียบเฉพาะหน้าต่างเวลาที่ครบแล้ว แยกจากหน้าต่างเวลาที่ยังไม่ครบ
คู่มือตัวชี้วัดการมีส่วนร่วมและอีคอมเมิร์ซของ Shopify อธิบายลูกค้าที่ซื้อซ้ำและตัวหารที่นับลูกค้า นิยามรายงานสามแบบในบทความนี้เป็นกติกาตัวอย่างที่ระบุไว้ชัดเจน ก่อนเทียบกับรายงานของแพลตฟอร์มต้องตรวจนิยาม เกณฑ์คำสั่งซื้อ และช่วงเวลาจริง แหล่งอ้างอิงเหล่านี้ไม่ได้ยืนยันว่าทุกระบบรายงานเหมือนกัน
อ้างอิง: Shopify: customer engagement metrics · Shopify: ตัวชี้วัดอีคอมเมิร์ซและลูกค้าที่กลับมาซื้อ
กติกาการนับ 5 ข้อที่คุณต้องเขียนให้ชัดก่อนเริ่มวัด
แม้สองร้านจะมี transaction log ดิบชุดเดียวกัน แต่อาจได้อัตราการซื้อซ้ำที่ต่างกันอย่างมีนัยสำคัญ หากทั้งสองร้านตัดสินใจกันคนละแบบโดยไม่ได้บันทึกไว้ ว่าอะไรนับเป็นหนึ่งออเดอร์ หนึ่งลูกค้า หรือหนึ่งการซื้อที่มีผลจริง สิ่งเหล่านี้คือการตัดสินใจทางธุรกิจ ไม่ใช่มาตรฐานสากลที่ใช้เหมือนกันทุกที่ จดให้ชัด เก็บเวอร์ชันไว้ และใช้ให้สม่ำเสมอทุกครั้งที่ออกรายงาน
Order identity: เก็บ raw export และรายการสินค้าในออเดอร์ที่ถูกต้องตามจริงไว้เสมอ เมื่อตัวหน่วยวัดคือ “ออเดอร์” ให้ใช้จำนวน order ID แบบไม่ซ้ำกัน การนับ distinct ID ไม่ได้แปลว่าต้องลบแถวสินค้าออกจากข้อมูล กำหนดขอบเขตของ ID ตามแหล่งที่มา หากแต่ละช่องทางสามารถใช้เลขออเดอร์ซ้ำกันได้ กรณีที่พบเรคคอร์ดซ้ำกันจริง ควรแยกไปตรวจสอบต่างหาก ไม่ควรปะปนกับกรณีหลายสินค้าใน checkout เดียว
Rule 2 — Cancellations and refunds. ลูกค้าที่เคยสั่งออเดอร์แล้วจากนั้นยกเลิกก่อนจัดส่ง จะนับว่า “เคยซื้อ” หรือไม่ก็ได้ ขึ้นอยู่กับนิยามของคุณ หากคุณตัดออเดอร์ที่ถูกยกเลิกออก ออเดอร์วันที่ 10 ของลูกค้าคนหนึ่ง ซึ่งก่อนหน้านั้นมีออเดอร์วันที่ 1 แต่ถูกยกเลิก อาจกลายเป็นออเดอร์แรกที่มีผลจริงของเขาแทน ซึ่งจะทำให้วันเริ่มต้นของ cohort เปลี่ยนไป คุณต้องตัดสินใจให้ชัด: จะรวมหรือไม่รวม และจะยึดที่การเปลี่ยนสถานะขั้นไหน พร้อมบันทึกไว้ว่าตัดที่จุดใด เช่น “ไม่รวม หากสถานะ = cancelled ก่อนส่งสินค้า”
Cash on delivery: กำหนดให้ชัดว่าสถานะใดจึงจะถือว่าเข้าเกณฑ์สำหรับตัวชี้วัด ออเดอร์ที่มีการสั่งเข้ามาแล้วแต่ยังส่งไม่ถึงลูกค้า อาจยังถือว่า pending ภายใต้นโยบายที่ยึด delivered order แสดง pending orders แยกต่างหาก และบันทึกเวลาที่การเปลี่ยนสถานะส่งผลต่อรายงาน ใช้นโยบายเดียวกันทั้งกับออเดอร์แรกและออเดอร์ถัดไป อย่าเงียบ ๆ แล้วปะปนวันที่สั่งซื้อกับวันที่ส่งสำเร็จเข้าด้วยกัน
Multi-line-item orders: หนึ่ง checkout ที่มีสินค้า 3 ชิ้น ยังถือเป็น 1 ออเดอร์ เก็บแถวสินค้าไว้เพื่อใช้วิเคราะห์สินค้าได้ แต่ให้นับตัวตนของออเดอร์นั้นเพียงครั้งเดียว และหากมีการ export checkout เดิมซ้ำอีกครั้ง ก็ต้องไม่ทำให้เกิดการนับเป็นการซื้อใหม่อีกหนึ่งครั้ง ควรเก็บ counting key และขอบเขตแหล่งข้อมูลไว้คู่กับผลลัพธ์เสมอ
Rule 5 — Timestamp ties. หากเรคคอร์ดของลูกค้าคนหนึ่งแสดงออเดอร์ 2 รายการที่มี timestamp ตรงกันเป๊ะ — ซึ่งอาจเกิดจากนาฬิกาของระบบหรือการนำเข้าข้อมูลแบบ batch — คุณจะไม่สามารถระบุได้แน่ชัดว่าอันไหนคือ “ออเดอร์แรก” ให้ทำเครื่องหมายแถวเหล่านี้ไว้อย่างชัดเจน แทนที่จะเงียบ ๆ เลือกอันใดอันหนึ่ง จำนวนลูกค้าที่ได้รับผลกระทบ และวิธีที่คุณใช้แก้ปัญหา ควรปรากฏอยู่ใน data-quality log ด้วย
สำหรับตัวอย่างตัวเลขทั้งหมดต่อจากนี้ คำสั่งซื้อที่ผ่านเกณฑ์หมายถึงคำสั่งซื้อไม่ซ้ำในขอบเขตแหล่งข้อมูลเดียวกัน ซึ่งส่งสำเร็จ ชำระครบ และไม่ถูกยกเลิกหรือคืนเงิน ณ เวลาตัดรายงาน คำว่า “คำสั่งซื้อที่ยืนยันแล้ว” และ “คำสั่งซื้อที่เข้าเกณฑ์” ใช้นโยบายเดียวกันนี้ เวลาซื้อยึดเวลาสั่งเดิมอย่างสม่ำเสมอ สถานะส่งสำเร็จใช้ตัดสินสิทธิในการนับ ไม่ใช่ใช้แทนวันซื้อ คำสั่งซื้อที่ยกเลิก ORD-1003 ไม่ผ่านเกณฑ์ ทั้งหมดเป็นสมมติฐานการนับ ไม่ใช่กติกาสถานะของ CasperBrain
ความครบของ Cohort: ให้ลูกค้าทุกคนมีช่วงเวลาสังเกตเท่ากัน
สำหรับคู่มือนี้ ออเดอร์ที่สองที่จะนับเข้าเกณฑ์ ต้องเกิดหลัง timestamp ของ valid order แรก และไม่เกิน 30 วันเต็มหลังจากนั้น ต้องระบุ timezone และกติกาว่านับปลายทางของช่วงเวลาอย่างไร อัตราแบบ 30 วันซึ่งถือว่า “ครบแล้ว” ต้องให้สมาชิกทุกคนใน cohort นั้นได้รับช่วงเวลาสังเกตครบทั้งช่วง ผลลัพธ์ที่รายงานก่อนครบกำหนดยังสามารถแสดงได้ในฐานะค่าชั่วคราว แต่ให้คงตัวหารของ cohort เดิมไว้ และติดป้ายว่าการสังเกตยังเหลืออีกเท่าใด
ตัวอย่างสมมติ: มีลูกค้า 100 คนที่ทำ valid purchase ครั้งแรกในเดือนมิถุนายน 2026 ภายในวันที่ 31 กรกฎาคม ลูกค้าทุกคนที่เข้ามาในเดือนมิถุนายนได้รับเวลา 30 วันเต็มครบแล้ว เพราะคนที่เข้ามาช้าที่สุดในวันที่ 30 มิถุนายน จะครบเส้น 30 วัน ณ เวลาที่สอดคล้องกันในวันที่ 30 กรกฎาคม สมมติว่ามีลูกค้า 25 คนที่วาง distinct valid order ครั้งที่สองภายในหน้าต่างเวลาของตนเอง อัตราแบบครบหน้าต่างแล้วจึงเท่ากับ 25 ÷ 100 = 25% การซื้อที่เกิดหลังวันที่ 30 จะไม่ถูกนับเข้าตัวเศษของตัวชี้วัดนี้
ในวันที่ 28 กรกฎาคม ลูกค้าบางคนที่ซื้อครั้งแรกในวันที่ 29 หรือ 30 มิถุนายน ยังมีหน้าต่างเวลาที่ยังเปิดอยู่ อัตราชั่วคราวของพวกเขาอาจเพิ่มขึ้นก่อนที่ทุกหน้าต่างจะปิดครบ แต่ก็ไม่จำเป็นต้องเพิ่มเสมอไป: ไม่มีอะไรรับประกันว่าจะต้องมี second order เพิ่มเข้ามาอีก อย่าอนุมานว่ามีการเปลี่ยนแปลงด้าน retention เพียงเพราะนำอัตราที่ยังไม่ครบหน้าต่าง ไปเทียบกับอัตราที่ครบหน้าต่างแล้ว ต้องแสดง timestamp ของรายงานและสถานะความครบถ้วนของข้อมูลให้มองเห็นชัด
ทีนี้สมมติว่ามีลูกค้าใหม่อีก 20 คนที่เพิ่งซื้อครั้งแรกเมื่อวันที่ 25 กรกฎาคม หากคุณเอาพวกเขาไปรวมในตัวหารของ cohort เดือนมิถุนายน แต่ปล่อยตัวเศษไว้เท่าเดิม จะได้ 25 ÷ 120 ≈ 20.83% ซึ่งไม่ใช่อัตราของ cohort เดือนมิถุนายน เพราะเป็นการเอากลุ่มรับลูกค้าคนละช่วงและเวลาสังเกตคนละแบบมาปนกัน ผลลัพธ์ที่ถูกต้องของเดือนมิถุนายนยังคงเป็น 25 จาก 100 ควรรายงานกลุ่มวันที่ 25 กรกฎาคมแยกต่างหากในฐานะ cohort ที่ยังไม่ครบหน้าต่าง แทนที่จะตีความว่าเป็นผลงานเดือนมิถุนายนที่แย่ลง
เมื่อล็อกนิยามของการได้ลูกค้าใหม่และนโยบาย valid order แล้ว ให้บันทึก timestamp ล่าสุดที่หน้าต่างเวลาทั้งหมดปิดครบ คู่มือ cohort retention ของ Shopify อธิบายการจัดกลุ่มลูกค้าตามการซื้อครั้งแรก แล้วติดตามกิจกรรมในภายหลัง ตัวอย่าง 30 วันแบบคงที่ของเรา เพิ่มเงื่อนไขเรื่องขอบเขตเวลาที่เท่ากันอย่างชัดเจน เพื่อให้เปรียบเทียบได้ซ้ำอย่างเป็นระบบ หากภายหลังมีข้อมูลเข้ามาแก้ไขสถานะออเดอร์ หรือพบว่าก่อนหน้านี้นำเข้าข้อมูลไม่ครบ ต้องอธิบายด้วยว่าทำไมจำนวนที่เคยรายงานไว้จึงเปลี่ยนไป
ลูกค้าแต่ละคนจะได้รับเวลา 30 วันเต็มหลัง valid order แรกของตนเอง ผลลัพธ์ชั่วคราวต้องคงตัวหารของ cohort เดิมไว้ และระบุหน้าต่างเวลาที่ยังไม่ครบ ส่วนอัตราสุดท้ายให้ยึดตามเส้นแบ่ง timestamp ที่ประกาศไว้
- 01ช่วงรับลูกค้าเปิด
ลูกค้ากลุ่มแรกเริ่มเข้าสู่ cohort หน้าต่างเวลาสังเกตเริ่มนับจากวันที่สั่งซื้อครั้งแรกของสมาชิกแต่ละคนเอง
- 02ช่วงรับลูกค้าปิด
ไม่มีสมาชิกใหม่เข้ามาเพิ่มอีก ขนาดของ cohort จึงถูกล็อกไว้แล้ว
- 03หน้าต่างสุดท้ายปิดครบ
ผู้ที่เข้ามาช้าที่สุดในวันที่ 30 มิถุนายน จะครบ 30 วันเต็มในวันที่ 30 กรกฎาคม ณ เวลาที่สอดคล้องกัน ดังนั้นรายงานวันที่ 31 กรกฎาคมจึงอยู่หลังทุกหน้าต่างของเดือนมิถุนายนอย่างปลอดภัย
- 04คำนวณอัตราได้
นับจำนวนสมาชิก cohort แบบไม่ซ้ำกันที่มีออเดอร์ที่สองเข้าเกณฑ์ภายในหน้าต่างของตนเอง แล้วหารด้วยขนาด cohort เดิมที่ไม่เปลี่ยน
- 05เปรียบเทียบข้าม cohort
เปรียบเทียบด้วย horizon และนิยามเดียวกัน พร้อมแยกติดป้ายอัตราที่ยังไม่ครบหน้าต่าง แทนการปฏิบัติต่อมันเสมือนเป็นค่าขั้นสุดท้าย
อ้างอิง: Shopify: cohort retention analysis
ไทม์ไลน์ลูกค้า 5 แบบ (ตัวอย่างสมมติเพื่อการสอน)
ไทม์ไลน์สมมติทั้ง 5 แบบนี้ใช้เพื่ออธิบายการตัดสินใจในการนับข้อมูลแต่ละกรณี ตัวเลขวันใช้เวลาเดียวกันของวันเดียวกัน เว้นแต่จะระบุไว้ต่างหาก: Day 31 คือผ่านไปครบ 30 วันนับจาก Day 1 ตัวอย่างเหล่านี้เป็นกรณีแยกกันเพื่อการสอน ไม่ใช่ข้อมูลดิบที่อยู่เบื้องหลัง cohort 100 คน
ลูกค้า A — Nok สั่งซื้อครั้งแรกใน Day 1 (Order ID: ORD-1001) และมีคำสั่งซื้อครั้งที่สองที่ยืนยันแล้วใน Day 22 (Order ID: ORD-1042) Day 22 อยู่ภายในหน้าต่าง 30 วัน ดังนั้น Nok ถูกนับในตัวเศษ ✓
ลูกค้า B — Malee สั่งซื้อครั้งแรกใน Day 1 (Order ID: ORD-1002) และมีคำสั่งซื้อครั้งที่สองที่ยืนยันแล้วใน Day 35 (Order ID: ORD-1078) Day 35 อยู่นอกหน้าต่าง 30 วัน ดังนั้น Malee จะไม่นับในอัตราการสั่งซื้อครั้งที่ 2 ภายใน 30 วันของ cohort นี้ อย่างไรก็ตาม เธอจะถูกนับใน historical repeat share เพราะท้ายที่สุดแล้วเธอกลับมาซื้อซ้ำ กรณีนี้แสดงให้เห็นว่า historical repeat share สำหรับลูกค้ากลุ่มเดียวกัน จะสูงกว่าหรือเท่ากับ cohort rate ที่ใช้หน้าต่างเวลาสั้นกว่าเสมอ
ลูกค้า C — Pong สั่งซื้อครั้งแรกใน Day 1 (Order ID: ORD-1003, สถานะ: cancelled ใน Day 3) และสั่งซื้ออีกครั้งใน Day 10 (Order ID: ORD-1021, สถานะ: delivered) ภายใต้นโยบายที่ไม่นับคำสั่งซื้อที่ถูกยกเลิก ORD-1003 จะไม่ถือเป็นคำสั่งซื้อแรกที่ใช้ได้ ดังนั้น ORD-1021 จะกลายเป็นคำสั่งซื้อแรกที่มีผลจริงของ Pong และนาฬิกา cohort ของเขาจะเริ่มใน Day 10 ส่วนเขาจะมีคำสั่งซื้อซ้ำอีกภายใน 30 วันนับจาก Day 10 หรือไม่ ต้องอาศัยข้อมูลเพิ่มเติม แต่ถ้าใช้นโยบายที่นับคำสั่งซื้อที่ถูกยกเลิกตั้งแต่ตอนสร้างออเดอร์ ORD-1003 จะเป็นคำสั่งซื้อแรกของเขา และ ORD-1021 จะเป็นคำสั่งซื้อครั้งที่สอง ทำให้นับเข้าในตัวเศษได้ ลูกค้าคนเดิม แต่อัตราที่ได้ต่างกัน เพียงเพราะนโยบายที่บันทึกไว้ต่างกัน
Wanchai มีการเช็กเอาต์ 1 ครั้งใน Day 5 คือ ORD-1044 ซึ่งมีสินค้า 3 รายการ ในไฟล์ export จึงมี 3 แถวของ line item ที่ถูกต้องตามจริง ควรนับ ORD-1044 เพียงครั้งเดียวว่าเป็นการซื้อหนึ่งครั้ง และเก็บรายละเอียดของแต่ละรายการสินค้าไว้เหมือนเดิม ถ้านับ 3 แถวนี้เป็น 3 คำสั่งซื้อ จะทำให้ Wanchai ถูกระบุผิดว่าเป็นลูกค้าที่ซื้อซ้ำ
Som สั่งซื้อครั้งแรกใน Day 1 คือ ORD-1005 เส้นตายครบ 30 วันที่ผ่านไปของเธอคือ Day 31 ณ เวลาเดียวกัน แต่ใน Day 20 ผลลัพธ์ยังไม่สมบูรณ์ ควรเก็บ Som ไว้ในตัวหารของ acquisition cohort และทำเครื่องหมายว่า cohort นี้หรือหน้าต่างของสมาชิกคนนี้ยังเปิดอยู่ การตัดเฉพาะคนที่ยังไม่ทราบผลลัพธ์ออก จะเปลี่ยนคำถามที่กำลังวัด และอาจทำให้อัตราเกิดอคติได้
| ลูกค้า | รหัสคำสั่งซื้อแรกที่ผ่านเกณฑ์ | รหัสคำสั่งซื้อถัดไปที่ผ่านเกณฑ์ | วันที่ของคำสั่งซื้อครั้งที่สอง | อยู่ภายในหน้าต่าง 30 วันหรือไม่? | นับในตัวเศษของคำสั่งซื้อครั้งที่ 2 หรือไม่? | หมายเหตุ |
|---|---|---|---|---|---|---|
| Nok (A) | ORD-1001 | ORD-1042 | Day 22 | ใช่ | ใช่ | กรณีมาตรฐาน — นับเข้า |
| Malee (B) | ORD-1002 | ORD-1078 | Day 35 | ไม่ใช่ | ไม่ใช่ (cohort rate) / ใช่ (historical repeat share) | อยู่นอกตัวเศษของหน้าต่าง 30 วัน; เมื่อตรวจพบภายหลังจะถูกรวมใน historical repeat share |
| Pong (C) | ORD-1021 | ยังไม่แสดงคำสั่งซื้อที่มีผลจริงรายการถัดไป | ไม่ทราบ | ไม่ทราบ | ยังไม่พบคำสั่งซื้อครั้งที่สองที่เข้าเงื่อนไข | ไม่นับ ORD-1003 ที่ถูกยกเลิก; คำสั่งซื้อแรกที่ใช้ได้จึงเป็น Day 10 โดยรวม |
| Wanchai (D) | ORD-1044 (มี 3 line items) | — | — | N/A | ไม่ใช่ — มีเพียง 1 คำสั่งซื้อที่ไม่ซ้ำกัน | ต้อง deduplicate; การนับจำนวนแถวตรง ๆ ทำให้เข้าใจผิด |
| Som (E) | ORD-1005 | ยังไม่พบภายใน Day 20 | ไม่ทราบ | หน้าต่างยังไม่ครบ; จะปิดใน Day 31 | ยังสังเกตผลไม่ครบ; ให้คงไว้ในตัวหาร | รายงาน cohort นี้ว่าเป็นผลเบื้องต้น |
คำนวณให้เห็นชัด: 3 เมตริกวางเทียบกัน
ตัวเลขต่อไปนี้เป็นตัวอย่างของรายงาน 3 แบบสำหรับร้านสมมติ Blossom Skin ณ วันที่ 31 July 2026 ทั้งหมดเป็นร้านเดียวกัน แต่ไม่ได้ใช้ตัวหารเดียวกัน ตารางไทม์ไลน์ลูกค้า 5 คนก่อนหน้านี้ไม่ได้เป็นที่มาของยอดรวมชุดใหญ่นี้
Metric 1 — Historical repeat share จำนวนลูกค้าที่ไม่ซ้ำกันตลอดเวลาทั้งหมด: 200 คน (deduplicate ด้วย customer ID) ลูกค้าที่มีคำสั่งซื้อยืนยันแล้วอย่างน้อย 2 คำสั่งซื้อที่ไม่ซ้ำกันตลอดช่วงเวลาทั้งหมด: 38 คน วิธีคำนวณ: 38 ÷ 200 × 100 = 19.0%
July returning-buyer share: มีลูกค้าที่ไม่ซ้ำกัน 80 คนที่สั่งซื้ออย่างน้อย 1 คำสั่งซื้อที่ใช้ได้ในเดือน July ในจำนวนนี้ 15 คนมีคำสั่งซื้อที่ใช้ได้ใน July และมีคำสั่งซื้อที่ใช้ได้ก่อนหน้านั้นอยู่แล้วในประวัติที่เชื่อมกัน คำสั่งซื้อก่อนหน้านั้นอาจเกิดก่อนเดือน July ก็ได้ สัดส่วนนี้คือ 15 ÷ 80 × 100 = 18.75% เมตริกนี้อธิบายองค์ประกอบของผู้ซื้อในเดือน July ไม่ใช่เฉพาะคนที่สั่งสองครั้งภายในเดือน July
Metric 3 — Cohort second-order rate (June, evaluated 31 July) ลูกค้าใหม่ครั้งแรกในเดือน June: 100 คน ลูกค้าที่มีคำสั่งซื้อยืนยันแล้วครั้งที่สองที่ไม่ซ้ำกันภายใน 30 วันนับจากคำสั่งซื้อแรกของตัวเอง: 25 คน วิธีคำนวณ: 25 ÷ 100 = 25.0% ณ วันที่ 31 July หน้าต่างเวลาของทุกคนปิดครบแล้ว
Historical 19%, July 18.75% และ June 30-day 25% ตอบคนละคำถาม ใช้ historical measure เพื่ออธิบายประวัติสะสมตามที่ประกาศไว้ ใช้ period measure เพื่อดูสัดส่วนผสมของผู้ซื้อในช่วงเวลาปัจจุบัน และใช้ cohort measure เพื่อดูพฤติกรรมการซื้อซ้ำช่วงต้นภายใต้หน้าต่างเวลาเดียวกัน เมตริกใดเมตริกหนึ่งเพียงลำพังไม่สามารถพิสูจน์ได้ว่าแคมเปญเป็นสาเหตุให้เกิดการซื้อเพิ่มขึ้น
| เมตริก | ตัวเศษ | ตัวหาร | ผลลัพธ์ | ใช้ตอบคำถามอะไร |
|---|---|---|---|---|
| Historical repeat share | ลูกค้าที่ซื้อซ้ำตลอดเวลาทั้งหมด 38 คน | ลูกค้าที่ไม่ซ้ำกันตลอดเวลาทั้งหมด 200 คน | 19.0% | มีลูกค้าทั้งหมดกี่สัดส่วนที่เคยกลับมาสั่งซื้อซ้ำ? |
| Period returning-buyer share (July) | ผู้ซื้อใน July 15 คนที่มีคำสั่งซื้อที่ใช้ได้ก่อนหน้าอยู่แล้ว | ผู้ซื้อที่ไม่ซ้ำกันใน July 80 คน | 18.75% | ผู้ซื้อใน July มีกี่สัดส่วนที่เป็นการซื้อกลับมาอีกครั้ง? |
| Cohort second-order rate (June, mature) | ลูกค้า 25 คนที่มีคำสั่งซื้อครั้งที่ 2 ภายใน 30 วัน | ลูกค้าใหม่ครั้งแรกใน June 100 คน | 25.0% | ลูกค้าใหม่ครั้งแรกของ June มีกี่สัดส่วนที่สั่งซื้อครั้งที่ 2 ที่ใช้ได้ภายใน 30 วัน? |
อ้างอิง: Shopify: ตัวชี้วัดอีคอมเมิร์ซและลูกค้าที่กลับมาซื้อ
การแบ่งกลุ่มแบบ RFM และความเชื่อมโยงกับความลึกของการซื้อซ้ำ
CasperBrain ใช้การแบ่งเป็น 4 quartiles สำหรับ recency, frequency และ monetary value โดย 1 คืออันดับการซื้อที่แข็งแรงที่สุด และ 4 คืออ่อนที่สุด ตัวอย่าง 114 ให้อ่านว่า R=1, F=1, M=4: มีอันดับด้านความใหม่ของการซื้อและความถี่ที่แข็งแรง แต่มีอันดับด้านมูลค่าการใช้จ่ายรวมที่ต่ำกว่าในขอบเขตการให้คะแนนนั้น Monetary value ไม่ใช่ยอดใช้จ่ายต่อออเดอร์หรือกำไร และรหัส 3 ตัวนี้ไม่ควรถูกนำไปบวกหรือหาค่าเฉลี่ย
Frequency quartile เป็นอันดับเมื่อเทียบกับประชากร ไม่ได้หมายความโดยอัตโนมัติว่าลูกค้าคนนั้นต้องอยู่ในตัวเศษของ repeat metric ใด metric หนึ่ง ควรตรวจสอบจำนวนคำสั่งซื้อที่ใช้ได้และไม่ซ้ำกันจริง รวมถึงวันที่ของคำสั่งซื้อ ในประชากรที่ข้อมูลยังบาง แม้อันดับ frequency จะดูแข็งแรง ก็ยังไม่ได้รับประกันว่าลูกค้าคนนั้นมี 2 คำสั่งซื้อแล้ว การเลื่อนย้ายระหว่าง quartiles อาจสะท้อนการเปลี่ยนแปลงของประชากรหรือประวัติข้อมูล ไม่ใช่เพิ่งมีการสั่งซื้อครั้งที่สองเกิดขึ้นเสมอไป
ระบบคะแนนจากผู้ให้บริการรายอื่นอาจใช้ 5 ระดับ หรือกลับทิศทางของคะแนน ก่อนนำมาเปรียบเทียบ ต้องยืนยันนิยาม หน้าต่างเวลา และเกณฑ์แบ่งกลุ่มให้ชัดเจน และเมื่อจำเป็นควรคำนวณใหม่จาก source data ที่เหมาะสม อย่าสมมติว่าคะแนน 5 จากภายนอกจะเทียบกับ quartile ใดของ CasperBrain ได้ และอย่าแต่งเติมวิธี import คะแนนที่ระบบไม่ได้รองรับ ใช้ RFM เป็นข้อมูลบริบทควบคู่กับ repeat-purchase measure ที่นิยามไว้อย่างชัดเจน
แยกให้ออกระหว่างความสัมพันธ์ที่สังเกตได้กับ causal lift
การที่สมาชิกโปรแกรมสะสมแต้มมีอัตราการซื้อสูงกว่า ไม่ได้พิสูจน์ว่าการเข้าร่วมเป็นสาเหตุให้ซื้อเพิ่มขึ้น ลูกค้าที่ตั้งใจจะกลับมาซื้ออยู่แล้ว อาจมีแนวโน้มสมัครเข้าร่วมมากกว่า การเปรียบเทียบที่ดีต้องจัดการกับ selection และความแตกต่างอื่น ๆ หนึ่งในแนวทางที่ใช้ได้สำหรับคำถามเชิงแคมเปญสมมติด้านล่าง คือการสุ่มแบ่งกลุ่มล่วงหน้าแบบ prospective randomized assignment
สมมติว่ามีผู้ซื้อครั้งแรกที่เข้าเกณฑ์ 200 คน ถูกสุ่มทันทีหลังจากคำสั่งซื้อแรกที่ใช้ได้ของพวกเขาออกเป็น 2 กลุ่ม กลุ่มละ 100 คน กลุ่มหนึ่งถูกกำหนดให้ได้รับลำดับข้อความติดตามแบบใหม่ในกรณีที่สิทธิ์การติดต่ออนุญาต ส่วนอีกกลุ่มยังคงได้รับประสบการณ์ปกติโดยไม่มีลำดับข้อความเพิ่มเติมนั้น ห้ามงดการติดต่อกลับที่ตกลงไว้หรือการบริการที่จำเป็น ติดตามลูกค้าแต่ละคนเป็นเวลา 30 วันหลังคำสั่งซื้อแรก และให้คงทุกคนไว้ในกลุ่มที่ถูกสุ่มไว้ตั้งแต่ต้น รวมถึงกรณีที่ส่งข้อความไม่สำเร็จ
— Arm A: ลูกค้า 20 จาก 100 คนมีคำสั่งซื้อครั้งที่สอง = อัตราการสั่งซื้อครั้งที่ 2 เท่ากับ 20.0% — Arm B: ลูกค้า 14 จาก 100 คนมีคำสั่งซื้อครั้งที่สอง = อัตราการสั่งซื้อครั้งที่ 2 เท่ากับ 14.0% — ผลต่างเชิงสัมบูรณ์: 20% − 14% = 6 percentage points (pp) — ผลต่างเชิงสัมพัทธ์: 6 ÷ 14 ≈ 42.86% — หมายความว่าอัตราของ Arm A สูงกว่า Arm B ประมาณ 43% ในเชิงสัมพัทธ์ โปรดสังเกตว่า 6 pp และ 42.86% เป็นการอธิบายช่องว่างเดียวกันคนละแบบ จึงใช้แทนกันตรง ๆ ไม่ได้
ผลต่างที่สังเกตได้ดูเป็นบวกต่อชุดข้อความที่ถูกกำหนดให้ใช้ แต่กลุ่มละ 100 คนและจำนวนผู้ซื้อเพิ่มขึ้น 6 คน ยังไม่เพียงพอจะยืนยันผลเชิงบวกที่เชื่อถือได้ ความผันผวนจากความบังเอิญยังคงมีอยู่ และปัญหาในการปฏิบัติจริงอื่น ๆ เช่น การติดต่อข้ามกลุ่ม ก็อาจบิดเบือนการตีความได้ ควรกำหนดเกณฑ์ความสำเร็จ ช่วงเวลาสังเกตผล และแผนขนาดตัวอย่างก่อนเริ่มใช้งานจริง และประเมินความไม่แน่นอนด้วยวิธีทางสถิติที่เหมาะสม คู่มือนี้ไม่ได้ให้ช่วงความเชื่อมั่นเชิงอนุมาน หรือประกาศผลว่ามีนัยสำคัญทางสถิติ ขนาดตัวอย่างที่มากขึ้นช่วยเพิ่มความแม่นยำได้ ก็ต่อเมื่อการออกแบบและข้อมูลยังคงมีคุณภาพ ไม่ได้การันตีว่าผลลัพธ์จะออกมาเป็นบวก
เปรียบเทียบอัตราของคอร์ฮอร์ตที่ครบช่วงสังเกตแล้วกับคอร์ฮอร์ตที่ยังไม่ครบอย่างระมัดระวัง
คอร์ฮอร์ตที่ใหม่กว่าสามารถมีเวลาให้สังเกตพฤติกรรมน้อยกว่าได้ อัตราการซื้อครั้งที่สองของคอร์ฮอร์ตนั้นในตอนนี้จึงไม่ควรถูกนำไปเปรียบเทียบเป็นผลลัพธ์ 30 วันแบบสมบูรณ์ หากสมาชิกบางส่วนยังอยู่ในช่วงหน้าต่างเวลา 30 วันของตนเอง แท่งกราฟที่ต่ำกว่าในเบื้องต้นอาจสะท้อนว่าการสังเกตยังไม่ครบ กลุ่มลูกค้าต่างกัน พฤติกรรมการซื้อซ้ำอ่อนลง หรือเกิดจากหลายปัจจัยร่วมกัน กราฟเพียงอย่างเดียวบอกไม่ได้ว่าเป็นเพราะอะไร
พิจารณาตัวอย่างสมมติ 3 เดือนต่อไปนี้สำหรับ Blossom Skin โดยประเมินในวันรายงานเดียวกัน:
ข้อมูลสมมติ: Month A มีอัตรา 30 วันแบบสมบูรณ์ที่ 28%; Month B มี 22%; ส่วน Month C ตอนนี้แสดงอยู่ที่ 11% โดยมีสมาชิกประมาณครึ่งหนึ่งที่ยังอยู่ภายในหน้าต่าง 30 วันของตน ค่าสุดท้ายของ Month C เมื่อครบกำหนดยังไม่ทราบ ทุกกลุ่มใช้กติกา valid-order เดียวกันตามที่ระบุไว้
Month C อาจสูงขึ้นได้เมื่อมีการซื้อที่เข้าเงื่อนไขเพิ่มเติมเกิดขึ้น หรืออาจคงอยู่ที่ 11% ก็ได้ ข้อมูลที่มีอยู่ไม่ได้บอกว่าจะกลายเป็น 24% หรือ 26% ในอนาคต อย่าคิดค่าที่ครบกำหนดขึ้นมาเอง อย่าประกาศว่าแนวโน้มแย่ลงจากข้อมูลที่ยังสังเกตไม่ครบ และอย่ารับประกันว่าความต่างที่เห็นจะหายไปแน่นอน
แสดงป้ายกำกับสถานะความครบของช่วงสังเกตและวันคาดว่าจะปิดหน้าต่างล่าสุดไว้ข้างอัตรานั้นเสมอ หากคุณจำเป็นต้องเปรียบเทียบได้เร็วกว่านั้น ให้ใช้ช่วงเวลาที่สั้นลงเท่ากันสำหรับสมาชิกทุกคนที่รวมอยู่ และติดป้ายกำกับให้ชัดเจน อัตรารวมแบบผสมอาจซ่อนรูปแบบที่แตกต่างกันของแต่ละคอร์ฮอร์ตไว้ จึงควรแสดงกลุ่มที่เกี่ยวข้องพร้อมตัวหารให้ครบ
การวิเคราะห์แบบคอร์ฮอร์ตคือการแยกข้อมูลออกเป็นกลุ่มที่แตกต่างกันอย่างชัดเจน และเมื่อทำอย่างถูกต้อง มันจะทำหน้าที่เป็นระบบเตือนล่วงหน้าได้ แต่จะมีประโยชน์ก็ต่อเมื่อคุณเปรียบเทียบคอร์ฮอร์ตที่อยู่ในระดับความครบของช่วงสังเกตเท่ากัน ไม่ใช่เพียงแค่อยู่ในวันปฏิทินเดียวกัน
Month C ตอนนี้อยู่ที่ 11% โดยมีหน้าต่างเวลาของสมาชิกประมาณครึ่งหนึ่งที่ยังสังเกตไม่ครบ ค่า 30 วันสุดท้ายของมันยังไม่ทราบแน่ชัด; อาจมีการซื้อเพิ่มได้ แต่ไม่ได้รับประกันว่าจะเกิดขึ้น
อ้างอิง: Shopify: cohort retention analysis
เช็กลิสต์คุณภาพข้อมูลก่อนเผยแพร่อัตราใด ๆ
ก่อนส่งต่อหรือนำเสนอค่าการซื้อซ้ำใด ๆ ให้ไล่ตรวจ 8 ข้อต่อไปนี้ก่อน ทุกข้อออกแบบมาเพื่อป้องกันรูปแบบความผิดพลาดที่กล่าวถึงก่อนหน้านี้ในคู่มือนี้ ให้ผู้วิเคราะห์ลงชื่อย่อและวันที่กำกับแต่ละข้อในบันทึกข้อมูลของคุณ เพื่อให้สามารถตรวจสอบย้อนหลังได้ในภายหลัง
1. ช่วงหน้าต่างเวลาผ่านครบหรือยัง? หากจะรายงานอัตราคอร์ฮอร์ต 30 วันแบบสมบูรณ์ ให้ยืนยันก่อนว่าสมาชิกทุกคนได้ผ่านช่วงนั้นครบแล้ว มิฉะนั้นให้คงตัวหารของคอร์ฮอร์ตไว้เหมือนเดิม และติดป้ายผลลัพธ์ว่าเป็นค่าเบื้องต้น พร้อมแสดงให้เห็นว่ามีหน้าต่างที่ยังเปิดอยู่
2. การระบุตัวตนลูกค้า: เก็บ customer ID จากต้นทางของแต่ละรายการไว้ และใช้ตาราง lookup แยกต่างหากสำหรับลิงก์ที่ได้รับการยืนยันแล้วไปยัง shared customer keys การใช้อีเมลหรือเบอร์โทรร่วมกันหรือซ้ำกัน เพียงอย่างเดียว ยังไม่เพียงพอที่จะพิสูจน์ว่าเป็นคนเดียวกัน ให้แยกการจับคู่ที่ยังไม่แน่ชัดไว้ต่างหาก และเก็บหลักฐานของลิงก์ที่ยอมรับไว้
3. ใช้นโยบายการยกเลิก/คืนเงินแล้วหรือยัง? ตรวจว่ามีนำเอานโยบายปัจจุบันที่บันทึกไว้แล้วมาใช้แบบสม่ำเสมอหรือไม่ (จะนับรวมหรือไม่นับรวม และนับที่สถานะใด) หากนโยบายเปลี่ยนไปจากรายงานครั้งก่อน ให้จดการเปลี่ยนแปลงนั้นพร้อมวันที่เริ่มมีผล
4. สถานะ COD: แสดงออเดอร์ที่ยัง pending แยกออกมาต่างหาก และใช้นโยบาย valid-order ที่ระบุไว้อย่างสม่ำเสมอ รายการที่ยัง pending สามารถคงอยู่ในชุดข้อมูลต้นทางได้ โดยไม่จำเป็นต้องถูกนับเข้าเมตริกที่วัด delivered-order
5. แถวข้อมูลซ้ำ: แยกให้ออกระหว่างระเบียนนำเข้าที่ซ้ำจริง กับ product line ที่ถูกต้องหลายบรรทัดภายในออเดอร์เดียวกัน เก็บไฟล์ export ดิบและประวัติสินค้าไว้ ให้นับ distinct source-scoped order identities; อย่าลบเหลือเพียงหนึ่งบรรทัดสินค้าจากออเดอร์นั้น เพียงเพื่อคำนวณความถี่ของออเดอร์
6. หน่วยของออเดอร์: ให้นับ distinct source-scoped order identities โดยยังคงเก็บ product row ที่ถูกต้องไว้ ตรวจสอบว่าออเดอร์เดียวกันที่ถูก export ออกมาสองครั้งจะไม่ถูกนับซ้ำสองครั้ง
7. วันที่ออเดอร์แรกแน่ชัดหรือไม่? ให้ติดธงสมาชิกคอร์ฮอร์ตคนใดก็ตามที่วันที่ออเดอร์แรกยังไม่แน่ชัด — เช่น เคยมีออเดอร์แบบ guest checkout ที่เกิดก่อนหน้านี้ แต่ตอนนั้นยังไม่ได้ถูกเชื่อมเข้ากับบัญชีของลูกค้าคนนั้น
8. บันทึกวันออกรายงานแล้วหรือยัง? จดวันที่แน่นอนที่รันรายงานไว้ เพื่อให้สามารถตรวจสอบความครบของคอร์ฮอร์ตได้อีกครั้ง หากมีการย้อนกลับมาดูรายงานนั้นอีกหลายสัปดาห์ถัดมา
สัญญาการวัดผลรายสัปดาห์สำหรับร้านค้าไทย
เลือกรอบการทบทวนผลให้สอดคล้องกับการตัดสินใจ ข้อมูลเชิงปฏิบัติการสามารถตรวจทุกสัปดาห์ได้ แต่อัตราคอร์ฮอร์ต 30 วันแบบสมบูรณ์จะพร้อมใช้งานก็ต่อเมื่อหน้าต่างเวลาของมันปิดครบแล้ว การทำให้ข้อมูลอัปเดตอยู่เสมอ ไม่ได้หมายความว่าคุณควรติดป้ายผลลัพธ์ที่ยังไม่ครบว่าเป็นค่าท้ายสุด
วันจันทร์: ตรวจสอบออเดอร์ใหม่ที่พร้อมใช้งานและสถานะของออเดอร์เหล่านั้น เก็บประวัติออเดอร์/line-item ทั้งหมดไว้ ใช้นโยบาย valid-order ที่บันทึกไว้ และเชื่อมตัวตนลูกค้าที่ได้รับการยืนยันแล้วผ่าน lookup แยกต่างหาก ให้มองเห็นออเดอร์ COD ที่ยัง pending อยู่ภายใต้นโยบายที่เลือก และบันทึกจำนวนผู้ซื้อ/ออเดอร์แบบ distinct
วันอังคาร: อัปเดตตารางติดตามคอร์ฮอร์ต เพิ่มคอร์ฮอร์ตใดก็ตามที่หน้าต่างสุดท้ายของมันปิดลงในสัปดาห์ก่อน — คอร์ฮอร์ตเหล่านี้ถือว่า mature แล้ว และมีสิทธิ์ถูกรายงานเป็นค่าท้ายสุด คอร์ฮอร์ตอื่นทั้งหมดให้ทำเครื่องหมายชัดเจนว่า “windows still open” อย่าเผยแพร่อัตราของคอร์ฮอร์ตที่ยังไม่ครบ โดยไม่มีป้าย “preliminary” กำกับอย่างชัดเจน
วันพุธ: สำหรับคอร์ฮอร์ตที่หน้าต่างเวลาครบแล้ว ให้นับจำนวนลูกค้าจริงที่มี distinct qualifying second order ภายในหน้าต่างนั้น หาก RFM มีประโยชน์ในฐานะบริบทเพิ่มเติม ให้ตรวจแยกต่างหากหลังจากนำเข้าข้อมูลที่เกี่ยวข้องและให้คะแนนใหม่เรียบร้อยแล้ว อย่าเรียกการเปลี่ยนควอร์ไทล์ว่าเป็น onboarding conversion หรือผลของแคมเปญ
วันพฤหัสบดี: คำนวณ returning-buyer share ของสัปดาห์ก่อน โดยใช้ลูกค้าที่มี valid purchase ในสัปดาห์นั้น และมี valid order ก่อนหน้านั้นอยู่แล้วในประวัติของตน หารด้วยจำนวนผู้ซื้อแบบ distinct ทั้งหมดในสัปดาห์นั้น การซื้อก่อนหน้าสามารถเกิดขึ้นก่อนสัปดาห์ที่กำลังวัดได้ เปรียบเทียบช่วงเวลารายงานที่ยาวเท่ากัน และตรวจ coverage ของแหล่งข้อมูลก่อนตีความการเปลี่ยนแปลงที่รุนแรง
วันศุกร์: ส่งสรุป 1 หน้า ที่แยกให้ชัดเจนว่า (a) คอร์ฮอร์ตใด mature แล้ว และอัตราท้ายสุดของมันคือเท่าไร; (b) คอร์ฮอร์ตใดยัง immature และจะ mature เมื่อไร; (c) period returning-buyer share ของสัปดาห์ที่แล้ว พร้อมแนวโน้มย้อนหลัง 4 สัปดาห์; (d) ความผิดปกติด้านคุณภาพข้อมูลใด ๆ จากการตรวจในวันจันทร์/อังคาร ตัวเลขทุกตัวบนหน้านี้ต้องมีทั้งตัวหารและป้ายกำกับหน้าต่างเวลา เมตริกแบบคอร์ฮอร์ตโดยทั่วไปเหมาะกับการทบทวนรายเดือนถึงรายไตรมาสมากกว่ารายวัน เพราะคอร์ฮอร์ตต้องใช้เวลาเพื่อสะสมกิจกรรมให้เพียงพอจนเห็นรูปแบบที่มีความหมาย จังหวะรายสัปดาห์ที่อธิบายที่นี่เป็นเพียงชั้นของการติดตาม ไม่ใช่สิ่งทดแทนการทบทวนคอร์ฮอร์ตแบบรายเดือน
อ้างอิง: Shopify: customer engagement metrics
ก่อนใช้ Benchmark ให้ตรวจสอบก่อนว่าวัดสิ่งเดียวกันหรือไม่
เปอร์เซ็นต์ที่ตีพิมพ์ในวงการอีคอมเมิร์ซไม่ได้หมายความว่าจะเหมาะใช้เป็นเป้าหมายสำหรับร้านค้าไทยโดยอัตโนมัติ ก่อนนำไปเปรียบเทียบกับผลลัพธ์ของคุณ ให้หาให้เจอว่าตัวหารคืออะไร ใช้นโยบายสถานะการซื้อแบบใด ช่วงสังเกตนานเท่าไร ใช้วิธีระบุตัวตนลูกค้าแบบใด กลุ่มตัวอย่างคือใคร และอยู่ในตลาดไหน หากรายละเอียดเหล่านี้ไม่มี ให้ใช้อ่านบทความนั้นเพื่อช่วยตั้งคำถาม แทนที่จะหยิบตัวเลขของมันมาเป็นเป้าหมาย
การบอกว่าลูกค้าไม่ได้สั่งซื้อซ้ำภายในช่วงเวลาหนึ่ง ไม่ใช่หลักฐานว่าลูกค้าคนนั้นจะไม่กลับมาซื้ออีกเลย ในทำนองเดียวกัน all-time repeat share ก็ไม่สามารถนำไปเทียบกับอัตรา 30 วันของ first-purchase cohort ได้ ต้องทำให้คำนิยามตรงกันก่อนค่อยเปรียบเทียบขนาดของตัวเลข แม้สองเปอร์เซ็นต์นั้นจะบังเอิญดูใกล้เคียงกันก็ตาม
สำหรับคู่มือนี้ ผลลัพธ์สมมติ 25% ของเดือนมิถุนายนเป็นเพียงแบบฝึกหัดการคำนวณ ไม่ใช่ benchmark และไม่ใช่ผลลัพธ์ทั่วไปของร้านค้าไทย แหล่งอ้างอิงที่ให้มาอธิบายแนวคิดเรื่องเมตริกและคอร์ฮอร์ต แต่ไม่ได้ใช้เพื่อยืนยันเป้าหมายเฉพาะประเทศที่นำมาเทียบได้โดยตรงกับตัวอย่างเหล่านี้ หลีกเลี่ยงการนำค่าเฉลี่ยของผู้ให้บริการรายอื่นไปนำเสนอเหมือนเป็นผลลัพธ์ที่สัญญาได้
คอร์ฮอร์ตที่ครบช่วงสังเกตแล้วของร้านคุณเองสามารถใช้เป็นบริบทที่มีประโยชน์ได้ หากช่วงเวลา ขอบเขตข้อมูล และกติกาการนับตรงกัน ให้บันทึกการเปลี่ยนแปลงของ product mix แหล่งที่มาของการได้ลูกค้า สถานะสต็อก และนโยบายการติดตามผลไว้ข้างตัวเลขเหล่านั้น ความแตกต่างของตัวเลขบอกคุณได้ว่าควรเข้าไปตรวจสอบต่อ แต่ไม่ได้อธิบายสาเหตุด้วยตัวมันเอง
ข้อผิดพลาดที่พบบ่อย 6 ข้อ และคำมั่นสัญญา 3 ข้อที่ควรทำภายในสัปดาห์นี้
ใช้รายการตรวจสอบเหล่านี้ก่อนแชร์ผลการวัดการซื้อซ้ำ รายการนี้ตั้งขึ้นมาเพื่อจัดการความผิดพลาดที่ยกตัวอย่างไว้ในคู่มือนี้ ไม่ใช่การจัดอันดับความล้มเหลวที่พบบ่อยที่สุดในอุตสาหกรรม
ตรวจสอบข้อ 1: เปรียบเทียบหน้าต่างเวลาที่ครบถ้วนแล้วกับหน้าต่างเวลาที่ยังไม่ครบแยกออกจากกัน คงตัวส่วนฝั่งลูกค้าที่ได้มาทั้งหมดไว้ให้ครบ และระบุวันปิดรอบล่าสุดให้ชัดเจน สำหรับแท่ง Month C 11% ในตัวอย่างสมมติ สมาชิกประมาณครึ่งหนึ่งยังอยู่ในหน้าต่างเวลาที่เปิดค้างอยู่
ตรวจสอบข้อ 2: นับรหัสคำสั่งซื้อที่ไม่ซ้ำกันภายในขอบเขตของแหล่งข้อมูล โดยคงแถวสินค้าที่ถูกต้องตามจริงไว้ การนับตามจำนวนรายการสินค้าในคำสั่งซื้อ หรือการส่งออกข้อมูลซ้ำ ต้องไม่กลายเป็นการซื้อเพิ่มขึ้นอีกครั้งโดยผิดพลาด
ตรวจสอบข้อ 3: แยกความสัมพันธ์ที่สังเกตเห็นออกจากหลักฐานเชิงเหตุและผล ตัวอย่างแบบสุ่มที่แนะนำจะเปรียบเทียบการจัดกลุ่มเดิมภายใต้ช่วงเวลาสังเกตเดียวกัน แต่ก็ยังต้องตรวจสอบการดำเนินงาน และประเมินความไม่แน่นอนเพิ่มเติม อัตราที่สูงกว่าจากกลุ่มคนที่เลือกเข้าร่วมโปรแกรมด้วยตัวเอง ไม่ถือเป็นหลักฐานแบบเดียวกัน
ตรวจสอบข้อ 4: อ่านค่า RFM ตามกติกาจริงของระบบ CasperBrain ใช้อันดับการซื้อแบบ 1 ดีที่สุด และ 4 แย่ที่สุด สเกลและเกณฑ์ของผู้ให้บริการแต่ละรายใช้แทนกันไม่ได้ หากยังไม่ได้ตรวจสอบหรือคำนวณนิยามใหม่ให้ตรงกัน และอันดับก็ไม่สามารถใช้แทนเงื่อนไขเรื่องคำสั่งซื้อไม่ซ้ำและวันที่ของเมตริกการซื้อซ้ำที่คุณเลือกใช้ได้
ตรวจสอบข้อ 5: อย่าประกาศว่าแคมเปญได้รับการพิสูจน์แล้วจากความต่าง 6 จุดเปอร์เซ็นต์ในตัวอย่างเพื่อการสอน ให้รายงานตามตรงว่าเป็น 20 จาก 100 เทียบกับ 14 จาก 100 ใช้กรอบเวลา 30 วันเดียวกัน และมีการประเมินความไม่แน่นอนตามแผน ที่นี่ไม่ได้ให้ข้ออ้างเรื่องนัยสำคัญทางสถิติ หรือช่วงความเชื่อมั่นเชิงตัวเลข
ข้อผิดพลาดข้อ 6 — ใช้ค่าเฉลี่ยแบบผสมทั้งก้อน ทั้งที่รูปแบบระดับคอร์ฮอร์ตกำลังแยกไปคนละทาง สัดส่วนการซื้อซ้ำสะสมตลอดช่วงเวลาที่คงที่ที่ 19% อาจบดบังความจริงที่ว่าคอร์ฮอร์ตจาก 2 ไตรมาสล่าสุดกำลังมีแนวโน้มสวนทางกัน การมองเห็นในระดับคอร์ฮอร์ตคือวิธีแก้ปัญหานี้
คำมั่นสัญญา 3 ข้อสำหรับสัปดาห์นี้: (1) เขียนการตัดสินใจกติกาการนับทั้ง 5 ข้อจากส่วนที่ 2 ลงในเอกสารกลางที่ทั้งทีมข้อมูลของคุณมองเห็นได้ — ทำวันนี้ก่อนดึงรายงานใหม่ใด ๆ (2) เปิดตารางติดตามคอร์ฮอร์ตของคุณ แล้วระบุว่าคอร์ฮอร์ตใดสุกงอมพอที่จะรายงานอย่างมั่นใจ และคอร์ฮอร์ตใดยังมีหน้าต่างเวลาที่เปิดอยู่ จากนั้นทำเครื่องหมายกลุ่มหลังให้ชัดเจน (3) หากคุณกำลังวางแผนแคมเปญด้านการรักษาลูกค้า ให้กำหนดขนาดตัวอย่างและเกณฑ์ความสำเร็จไว้ก่อนเริ่ม เพื่อเมื่อผลลัพธ์ออกมาแล้ว คุณจะประเมินเทียบกับความคาดหวังที่ประกาศไว้ล่วงหน้าได้ แทนที่จะหาเหตุผลเข้าข้างตัวเลขอะไรก็ตามที่โผล่ขึ้นมา
แหล่งข้อมูลและวิธีจัดทำ
ตัวอย่างในบทความเป็นข้อมูลสมมติ ไม่มีข้อมูลลูกค้าจริง บทความจัดทำโดยทีม CasperBrain โดยใช้ AI ช่วยร่าง ตรวจข้อเท็จจริงและภาษาก่อนเผยแพร่