Scroll ลง เพื่อดูบทความ
เบื้องหลังเชิง Technical ของระบบรายงานผลเลือกตั้งร่วมกับ Workpoint News
โดย PanJ
การเลือกตั้งเมื่อวันที่ 24 มีนาคม ที่ผ่านมาหลาย ๆ คนน่าจะเคยได้ดูการรายงานผลแบบ Real-time ของ Workpoint News ที่เว็บ https://vote.workpointnews.com ซึ่งจัดทำโดยทีม Cleverse ของเรา บทความนี้ จะมาเล่าถึ ...
ไขปริศนา ความท้าทายต่าง ๆ ในการก้าวไปสู่ตำแหน่ง CTO
โดย PanJ
ในสายอาชีพ programmer/developer ตำแหน่งที่คนส่วนใหญ่คิดว่าสูงที่สุดแล้วน่าจะหนีไม่พ้น Chief Technology Officer หรือ CTO ซึ่งมีชื่อเรียกภาษาไทยเก๋ ๆ ว่าประธานเจ้าหน้าที่บริหารฝ่ายเทคโนโลยี เอาจริง ๆ แล ...
Solving BigData with BigQuery (3/3) — ใช้จริง
โดย SARIN
บทความนี้จะมีเนื้อหาเกี่ยวกับ Google BigQuery: Serverless Data Warehouse จาก Google ครับ บทความนี้เป็นเนื้อหาพาร์ทสุดท้ายจาก ซีรีส์แนะนำ Google BigQuery ของ Cleverse โดยบทความนี้จะเน้นไปที่แนวทางต่างๆ ...
Solving BigData with BigQuery (2/3) — ลองเล่น
โดย SARIN
คุณมีปัญหากับการวิเคราะห์ข้อมูลขนาดใหญ่ใช่ไหม? — ลองมาใช้ BigQuery ดูสิ 0) เกริ่นนำ หากคุณเป็นคนที่ทำงานในสายงาน Data Science หรือใกล้เคียง คุณอาจจะเคยได้ยินคนพูดถึง BigQuery มาบ้าง สรุปแบบสั้นๆเลยคือ ...
Solving BigData with BigQuery (1/3) — บทนำ
โดย SARIN
หลายๆคนอาจจะมองว่าการจัดการ Big Data เป็นเรื่องลำบาก — ตั้งแต่การวางแผนติดตั้งระบบ การนำข้อมูลเข้า จนถึงการ Query ข้อมูลแต่ละครั้งซึ่งทำได้ยากและใช้เวลานาน แถมพอใช้งานจริงก็ต้องคอยดูแลอีก วันนี้บล็อกน ...
ของโคตรดี! เมื่อแทนที่ GraphQL Backend ด้วย Graphcool!
โดย ชิน
สำหรับท่านที่ไม่เคยใช้ GraphQL มาก่อน น่าจะเคยใช้ชีวิตร่วมกับ REST มาก่อน ซึ่งตัว REST จะมีความต่างที่ชัดเจนจาก GraphQL คือ REST เราต้องกำหนด endpoint เต็มไปหมด ถ้า model เปลี่ยนไปเรื่อยๆต้องมาแก้ทีละ ...
ENGINEERING
DESIGN
CULTURE
Cleverse, a venture builder, with people who have fun building the future. If you also consider building the future a fun and meaningful purpose — let’s find a way we can work together.
121/75 RS TOWER 24th Floor
Ratchadaphisek Road
Dindaeng Bangkok 10400
Thailand
14.Feb.2019
โดย Kittichai

เราจะวัดความรัก(ของ user)ได้อย่างไร – Retention Rate พื้นฐาน

Scroll down

 “It’s better to have 100 people that love you than a million people that just sort of like you. Find 100 people that love you.” — Paul Graham

บริษัทใดที่มี user รักในสินค้า/บริการของเรา บริษัทนั้น ๆ จะมี “แฟนคลับ” ที่มีพลังช่วยโปรโมทเรา และเป็นอ้างอิงให้คนอื่นหันมาใช้สินค้า/บริการของเราเพิ่มขึ้น

แล้วเราจะวัดความรักได้อย่างไร?

มี Metrics 2 ตัว ที่เรานิยมใช้วัดผลความรักที่ user มีต่อสินค้า/บริการ (ในส่วนถัดไปจะขอย่อเหลือคำว่าบริการ) นั่นก็คือ Retention Rate กับ Net Promoter Score

Retention Rate คือ ตัวบ่งชี้ความต่อเนื่องการกลับมาใช้บริการของเรา ของ user

Net Promoter Score คือ อัตราส่วนของ user ที่มีแนวโน้มจะแนะนำบริการของเราให้เพื่อนหรือคนรู้จักสูง ลบด้วย คนที่มีแนวโน้มจะแนะนำบริการของเราต่ำ

บทความนี้จะขอกล่าวถึงพื้นฐานของ Retention Rate กัน

วิธีวัด Retention Rate

หลักการวัด Retention Rate ก็คือ user ที่ใช้บริการของเราใน period นี้ มีกี่ % ที่ใช้เราใน period ถัดไป เช่น

สมมติว่า เรามีการใช้งานของ user เป็นดังนี้

  • วันที่ 1 มี user A, B, C, D, E เข้ามาใช้บริการ
  • วันที่ 2 มี user A, B, F, G เข้ามาใช้บริการ

ถ้าเราวัดผลราย 1 วัน โดยเริ่มนับจากวันที่ 1 จะได้ผลดังนี้

  • วันที่ 1 = 100% เพราะถือเอา user วันนี้เป็นฐาน
  • วันที่ 2 = 40% เพราะมีเพียง A, B ที่กลับมาใช้บริการ จาก user 5 คนในวันแรก

Retention Rate vs Engagement Rate

Engagement เป็นอีกหนึ่ง metrics ที่นิยมพูดถึงร่วมกับ Retention

Engagement คือ ความถี่ในการใช้บริการของเรา ในขณะที่ Retention คือ ความต่อเนื่อง

ถ้าเปรียบเป็นการจีบกัน — engagement ก็คือ การนัดเจอ คุยโทรศัพท์ ส่วน retention คือ จะคบกันยาวแค่ไหน

ตัวอย่างเช่น ประกันรถยนต์​เป็นสินค้าที่ engagement ต่ำ (ซื้อปีละครั้ง อาจไม่มีการเคลมเลยเป็นเวลาหลายปี) แต่หาก user ยังซื้อต่อเนื่องทุกปี ก็สามารถมี retention ที่สูงได้

ในขณะที่ Diet plan มักเป็นสิ่งที่ engagement สูง (ในช่วงเห่อ) แต่ retention ต่ำ

นั่นทำให้หลาย ๆ กรณี เราจะสนใจ Retention มากกว่า Engagement เพราะ “ใช้ไม่บ่อย แต่เราอยู่ในใจเสมอ” ฟังดูดีกว่า “ใช้ซ้ำ ๆ แต่ไม่กลับมาใช้อีกเลย”

Interval ในการวัด Retention Rate

จากตัวอย่างข้างต้น หากเรามีข้อมูลวันที่ 3–4 เป็นดังนี้

  • วันที่ 3 มี user A, B, E, F เข้ามาใช้บริการ
  • วันที่ 4 มี user C, G เข้ามาใช้บริการ

หากเราเปลี่ยนมาวัดผลเป็นราย 2 วันแทน จะได้ว่า

  • วันที่ 1–2 มี user รวม A, B, C, D, E, F, G
  • วันที่ 3–4 มี user รวม A, B, C, E, F, G ได้ retention เป็น 6 ใน 7 = 85.71% ทั้ง ๆ ที่ user ในวันที่ 4 ลดน้อยลง แต่ retention ก็กลับสูงขึ้น

นั่นทำให้ระยะเวลาที่ใช้วัด มีผลต่อผลลัพท์เป็นอย่างมาก

เราควรเลือกระยะเวลาสั้นหรือยาว?

อยากให้กลับไปที่เจตนารมณ์ของการดู Retention Rate ก่อน — เราอยากรู้ว่า user รักเราหรือไม่? เราจะได้ปรับปรุงสินค้า/บริการของเราได้

ถ้าเราตั้งกติกาว่า user รัก คือ ต้องใช้เราทุกชั่วโมง เราก็คือคู่รักที่ demanding เกินไป สุดท้ายเราจะนึกว่าไม่มีใครรักเรา ทั้ง ๆ ที่จริง ๆ แล้วเขาอาจจะรัก

ถ้าเราตั้งกติกาไว้หย่อนเกินไป เช่น เจอกัน 2 ปีครั้งก็พอ เราก็จะเป็นคู่รักที่ประมาท รู้ตัวอีกทีเขาก็เลิกกับเราไปแล้ว

เราจึงควรเลือกระยะเวลาที่ใช้วัดผลให้ใกล้เคียงกับพฤติกรรมการใช้บริการที่เราคาดหวังให้ผู้ใช้เป็นให้มากที่สุด เช่น App Todo list อาจต้องวัดผลโดยใช้ระยะเวลาถี่กว่า App ซื้อตั๋วหนัง หรือ Google Maps ก็อาจตั้งเกณฑ์ห่างกว่า Uber เป็นต้น

สำหรับบริการใหม่ ๆ ที่ไม่มีข้อมูลว่า user จะใช้งานบ่อยแค่ไหน เราสามารถเลือกจากการดู user กลุ่มแรก ๆ ที่มีแนวโน้มการใช้งาน/feedback ที่ดี แล้วดูความถี่ของคนกลุ่มนี้เป็นเกณฑ์

 

Event ที่ไว้วัด Retention Rate

สิ่งที่ต้องคิดถึงในการวัดผลอีกอย่างหนึ่ง ก็คือ เราจะเลือกกิจกรรม (Event) อะไรมาใช้วัด ว่า user ยังอยู่กับเราหากคุณเปิดร้านกาแฟ เราควรวัดผลที่ user เข้ามาซื้อกาแฟ หรือ แค่แวะเข้ามาในร้านก็นับแล้ว?

แน่นอนว่า ในเคสร้านกาแฟข้างต้น คนส่วนใหญ่คงตอบว่า ซื้อกาแฟ

บางธุรกิจ การวัด retention อาจจะไม่ง่ายอย่างนั้น เช่น

  • Application ซื้อขายหุ้น — คุณจะนับที่คนเข้ามาเช็คราคาหุ้น หรือ ต้องเข้ามาส่งคำสั่งซื้อ/ขาย?
  • Tinder — คุณจะวัดผลที่ การเข้ามา swipe, จับคู่ได้ หรือ chat คุยกัน?

และมีเคสที่ซับซ้อนกว่านั้น เช่น

ตัวอย่าง: user สมัครสมาชิกบริการหนึ่งไว้ ซึ่งเป็นบริการแบบรายเดือน (นึกถึง Netflix หรือ ค่าโทรศัพท์) แต่เราออกโปรโมชั่นลดราคาให้ถ้าจ่ายรายปี — สมมติว่า user 50% ซื้อแบบรายปีไว้ (เพราะโปรโมชั่นเราคุ้มมาก) เราก็จะเหมือนมี Retention 1 ปีตุนไว้ก่อนแล้ว

แต่ ถ้าปรากฎว่า user เหล่านี้ไม่ใช้บริการเราเลย (Engagement ต่ำ) นั่นทำให้ชีวิตจริงหาก user รู้ตัวว่าไม่ได้ใช้ ก็จะมีแนวโน้มยกเลิกการใช้บริการเราในปีถัดไปสูงมาก เพราะรู้สึกตัวว่าไม่คุ้ม — หากเราใช้ การจ่ายค่าสมาชิก เป็น event ในการวัด Retention เราก็อาจจะหลอกตัวเองได้

บริษัท telecom บางแห่งจึง active โทรหา user ที่การใช้งานต่ำกว่า package ที่เลือกไว้ เพราะรู้ข้อนี้

นี่เป็นเหตุที่ว่า การเลือก Event ในการวัด Retention นั้น ต้องเลือกอย่างระมัดระวัง หรือ อาจต้องใช้มากกว่า 1 event ในการวัดผล

แนะนำเครื่องมือในการวัด Retention Rate สำหรับ (online product/service)

เครื่องมือ basic ที่สุดที่หลายท่านอาจนึกถึง ก็คือ Google Analytics ซึ่ง ณ วันที่เขียนบทความนี้ (14 กุมภาพันธ์ 2019) มี Cohort Analysis ให้ลองเล่น

อย่างไรก็ดี เราไม่แนะนำให้ใช้ Google Analytics! (อย่างน้อยก็ในขณะที่ features ยังมีอยู่แค่นี้)

เหตุเพราะ การเลือก event และดู user journey ของ Google Analytics นั้น มีข้อจำกัดเยอะมาก (หรือเราใช้ไม่เป็นก็ไม่รู้)

เช่น user 100% ในวันแรก ในความหมายของ Google Analytics คือ user ที่เราเลือกยิง event ใด ๆ เข้าไป และยังไม่มีวิธีให้เลือกเจาะจง event ซึ่งจะทำให้เราวัดผล Retention ได้ยากมาก เช่น สมมติว่าเรามี event ดังต่อไปนี้

  1. ใครก็ไม่รู้เข้ามา visit website
  2. เริ่ม sign up ใช้งานเป็น user
  3. เข้ามาใช้งาน features เป้าหมาย

 

สิ่งที่เราควรดู คือ Retention Rate ของ ข้อ 3 จาก user ทั้งหมดในข้อ 2 — ไม่ใช่เอาข้อ 1 มาเป็นฐาน เพราะข้อ 1 อาจเป็นใครก็ได้ที่ยังไม่ได้รู้จัก product เรา และอาจจะยังไม่ได้เริ่มใช้งาน

ถ้าเปรียบเป็นร้านกาแฟ ข้อ 1 ก็คือ แค่เดินผ่านร้าน ข้อ 2 คือ เข้ามาลองชิม ข้อ 3 คือ ซื้อ

ถ้าเราเอาจำนวนคนที่แค่เดินผ่านร้านมาเป็นฐาน ค่า Retention ของเราจะต่ำ จนยากที่จะวัดว่า กาแฟของเรารสชาติดีไหม การให้บริการของเราดีหรือไม่

วันนี้เราอยากจะแนะนำเครื่องมืออีกอันที่ Cleverse ใช้อยู่ในขณะนี้: Amplitude

Amplitude

 

 

Retention Analysis ของ Amplitude อนุญาตให้เราเลือก Event ตั้งต้นที่เรานับเป็นฐาน user ได้ (สังเกตจาก “First Event” ซ้ายบน) และ event ที่เราจะเลือกใช้วัดผล ว่า user ยังอยู่กับเรา (เช่น ถ้าเราเป็น App TODO List — เราอาจเลือก “First Event” เป็น “ลงทะเบียนสมาชิก” กับ “Return Event” เป็น “Create Task” เป็นต้น)

นอกจากนี้ ตัวเลือกด้านซ้ายมือที่เห็นข้างต้น ยังให้เราดู event แยกตาม user ที่เคยทำ​ action พิเศษอะไรบางอย่าง มาเปรียบเทียบกันได้ด้วย เช่น จากตัวอย่าง TODO List ข้างต้น เราอาจดึงข้อมูล User ที่เคยผ่าน event ที่ต่างกันมาเปรียบเทียบรวมกัน เช่น เลือก a) ที่เคยดู Tutorial b) ที่ไม่เคยดู c) ที่เคย redeem coupon ส่วนลด — เพื่อจะแยกดูได้ว่า กลุ่มไหนมีแนวโน้ม retention rate สูงกว่า ก็น่าจะแปลว่าเหตุการณ์นั้น ๆ อาจมีแนวโน้มจะดึงดูใจผู้ใช้งานได้

 

นอกจากนี้ Amplitude ยังให้เราเลือกช่วงวันที่ได้อย่างละเอียด ทั้งแบบมาตรฐาน คือ เป็นช่วงกี่วัน หรือแบบเจาะจงวัน (เช่น อยากเห็น user ที่กลับมาในวันที่ 3 หลังจากเริ่มใช้งาน) ได้อีกด้วย

 

ถ้าสังเกตขวาบน จะเห็นคำว่า “Since Feb 5, 2019” — Amplitude อนุญาตให้เลือกวันที่ ในแบบ “ตั้งแต่วันที่ …” ได้ด้วย ซึ่งมีประโยชน์มากในกรณีที่คุณมีการ launch features ใหม่ ๆ อยู่เรื่อย ๆ และอยากวัดผลแยกตามวันที่ launch

 

Amplitude ยังมี features อื่น ๆ อีกมาก ถ้าสนใจลอง comment ที่ post ของบทความนี้ใน Facebook page ของ Cleverse — ถ้ามีคนสนใจเยอะ เราจะเขียนให้อ่านกันครับ

Disclaimer: Amplitude ไม่ได้ sponsor บทความนี้แต่อย่างใด แต่เราให้ NPS กับ Amplitude สูงมาก เราเลยอยากมาแชร์ให้ฟัง


บทความนี้เป็นเพียงเรื่องพื้น ๆ เกี่ยวกับ Retention Rate เท่านั้น ยังมีหัวข้ออื่น ๆ ที่เกี่ยวข้องอีกพอสมควร หากมีคนสนใจอ่าน/แชร์กันเยอะ (engagement สูง) เราจะรวบรวมเนื้อหามาเขียนภาคต่อกันครับ

Kittichai
All-rounder
Kittichai Jirasukhanon worked at Cleverse, a venture builder, with people who have fun building the future. If you also consider building the future a fun and meaningful purpose — let’s find a way we can work together.
Next Article
เบื้องหลังเชิง Technical ของระบบรายงานผลเลือกตั้งร่วมกับ Workpoint News
สมัครงาน