ลูกค้าบล็อกหรือเลิกติดตามเราไปแล้ว จะรู้ได้ยังไงว่าใครหายไปบ้าง

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

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

บทความนี้จะพาดูว่า LINE Webhook Unfollow Event ทำงานยังไง จับเหตุการณ์นี้ได้ครบแค่ไหน แล้วเอาข้อมูลนี้ไปวิเคราะห์อะไรต่อได้บ้างเพื่อไม่ให้เป็นแค่ตัวเลขที่รู้แล้วก็จบ

Unfollow Event ครอบคลุมเหตุการณ์อะไรบ้าง

Unfollow Event คือเหตุการณ์ที่ LINE ส่งมาให้ระบบหลังบ้านทราบเมื่อผู้ใช้บล็อกบัญชี LINE OA หรือลบบัญชีนั้นออกจากรายชื่อเพื่อน ข้อมูลที่ได้ส่วนใหญ่มีแค่ User ID กับเวลาที่เกิดเหตุการณ์ ไม่มีเหตุผลหรือรายละเอียดอื่นแนบมาด้วย

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

ทำไมต้องสนใจว่าใครบล็อกหรือลบเพื่อนไปบ้าง

การรู้ยอดสุทธิของเพื่อนอย่างเดียวไม่พอสำหรับการวิเคราะห์ เพราะยอดสุทธิที่โตขึ้นอาจซ่อนปัญหาไว้ เช่น ได้เพื่อนใหม่ 200 คนต่อเดือน แต่เสียเพื่อนเก่าไป 150 คนในเดือนเดียวกัน ยอดสุทธิที่เห็นคือเพิ่มแค่ 50 คน ซึ่งดูน้อยกว่าที่ควรจะเป็นมากถ้าไม่รู้ว่ามีการสูญเสียเกิดขึ้นคู่ขนานไปด้วย

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

เอา Unfollow Event ไปวิเคราะห์ร่วมกับประวัติสถานะ Lead

การเห็นแค่ Unfollow Event เฉย ๆ บอกได้แค่ว่าคนคนนี้จากไป แต่ถ้าผูกกับประวัติสถานะ Lead ของคนนั้นก่อนหน้า เช่น เคยเป็น Qualified Lead ที่ยังไม่ปิดการขาย หรือเป็นลูกค้าเก่าที่เคยซื้อไปแล้ว จะช่วยให้เห็นภาพว่าการสูญเสียนี้กระทบมากน้อยแค่ไหน ไม่ใช่ทุกคนที่บล็อกจะมีความหมายเท่ากันในมุมธุรกิจ

ถ้าพบว่าคนที่บล็อกส่วนใหญ่เป็นกลุ่มที่เคยติด Lost Reason ว่า ‘ยังไม่พร้อม’ หรือ ‘รอดูก่อน’ นั่นอาจแปลว่าการตามหรือ Broadcast ที่ส่งไปหลังจากนั้นทำให้เขารำคาญจนตัดสินใจบล็อกไปเลย ซึ่งเป็นข้อมูลที่ช่วยปรับความถี่และเนื้อหาการตามลูกค้าในอนาคตได้

ตัวอย่างช่วงเวลาที่มักเกิดการบล็อกหรือลบเพื่อน (ตัวอย่างสมมติ)

การดูว่าการบล็อกมักเกิดขึ้นช่วงไหนของ Journey ช่วยชี้เป้าได้ว่าควรปรับอะไร ตัวเลขในตารางนี้เป็นตัวอย่างประกอบกรอบวิเคราะห์ ไม่ใช่ผลจริงของธุรกิจใดธุรกิจหนึ่ง

วางระบบรับ Unfollow Event ให้เอาไปใช้ต่อได้จริง

ลำดับนี้ช่วยให้ Unfollow Event ที่เก็บมาไม่ใช่แค่ตัวเลขที่รู้แล้วผ่านไป

1. รับ Unfollow Event ผ่าน Webhook เดียวกับที่รับ Follow Event แล้วผูกกับ User ID ของคนคนนั้น
2. เก็บ Timestamp ของ Unfollow Event ไว้เทียบกับเหตุการณ์ก่อนหน้า เช่น Broadcast ล่าสุดหรือการตามครั้งสุดท้าย
3. ผูกกับสถานะ Lead ล่าสุดของคนนั้นก่อนบล็อก เพื่อดูว่าเป็นกลุ่มที่ยังมีมูลค่าหรือเป็นกลุ่มที่จบ Journey ไปแล้ว
4. สรุปเป็นรายเดือนว่าการบล็อกมักเกิดขึ้นช่วงไหนของ Journey มากที่สุด แล้วนำไปปรับเนื้อหาหรือความถี่ในจุดนั้น

ข้อจำกัดที่ต้องยอมรับก่อนสรุปสาเหตุการบล็อก

ต่อให้เก็บ Unfollow Event ครบและผูกกับประวัติ Lead ได้ดีแค่ไหน ก็ยังไม่มีทางรู้เหตุผลที่แท้จริงของแต่ละคนได้ 100% เพราะ Event นี้ไม่มีช่องให้ระบุเหตุผล การวิเคราะห์ที่ทำได้คือการหารูปแบบร่วมจากหลายคนที่พฤติกรรมคล้ายกัน ไม่ใช่การรู้เหตุผลของแต่ละคนแบบเจาะจง

ธุรกิจที่ต้องการเข้าใจเหตุผลจริงมากขึ้นอาจต้องอาศัยช่องทางอื่นเสริม เช่น แบบสอบถามความพึงพอใจหรือการสังเกตพฤติกรรมก่อนบล็อกจากแอดมิน ควบคู่กับข้อมูลจาก Unfollow Event เพราะการพึ่งข้อมูลอัตโนมัติอย่างเดียวยังตอบคำถามเรื่อง ‘ทำไม’ ได้ไม่สมบูรณ์

โครงสร้าง Payload จริงของ Unfollow Event ที่ต้องอ่านให้เป็น

Unfollow Event ที่ Messaging API ส่งเข้ามาทาง Webhook มี `type` เป็น `"unfollow"` พร้อม `source.userId` ของคนที่บล็อกหรือลบเพื่อน และ `timestamp` บอกเวลาที่เกิดเหตุการณ์เป็น Unix time มิลลิวินาที ต่างจาก Message Event ตรงที่ Unfollow Event ไม่มีออบเจกต์ `message` หรือ `replyToken` แนบมาด้วยเลย เพราะเป็น Event ที่ไม่ต้องการการตอบกลับใด ๆ

ฟิลด์ที่ต้องเช็คก่อนบันทึกเสมอคือ `webhookEventId` กับ `deliveryContext.isRedelivery` เหมือนกับ Event ประเภทอื่น เพราะถ้าเซิร์ฟเวอร์ตอบ LINE ช้าในช่วงที่มีคนบล็อกพร้อมกันหลายคน เช่น หลังส่ง Broadcast ที่เนื้อหาไม่ตรงใจ LINE อาจส่ง Unfollow Event ซ้ำมาอีกครั้งพร้อม `deliveryContext.isRedelivery` เป็น true ถ้าระบบไม่เช็คและบันทึกซ้ำ ตัวเลขสัดส่วนการบล็อกในตารางเปรียบเทียบตามช่วง Journey ที่อธิบายไว้ก่อนหน้าจะคลาดเคลื่อนสูงกว่าความจริง

ตัวอย่างเดินระบบจริง จาก Broadcast ถึงเห็นสัญญาณบล็อกเป็นกลุ่ม

สมมติร้านส่ง Broadcast โปรโมชันตอนสามทุ่มของวันศุกร์ ภายในสิบนาทีถัดมา Webhook เริ่มได้รับ Unfollow Event หลายสิบรายการต่อเนื่องกัน แต่ละรายการมี `source.userId` ต่างกัน แต่ `timestamp` กระจุกตัวอยู่ในช่วงเวลาใกล้เคียงกันมาก ระบบหลังบ้านที่เก็บ `timestamp` ของทุก Unfollow Event ไว้เทียบกับเวลาที่ส่ง Broadcast ล่าสุด จะเห็นสัญญาณนี้ได้ทันทีว่ามีความเชื่อมโยงกันสูง

เมื่อดึง `userId` ของกลุ่มที่บล็อกช่วงนั้นไปเทียบกับประวัติสถานะ Lead จะพบว่าส่วนใหญ่เป็นกลุ่มที่เคยติด Lost Reason ‘ยังไม่พร้อม’ มาก่อน ซึ่งตรงกับรูปแบบที่อธิบายไว้ในหัวข้อการวิเคราะห์ร่วมกับประวัติ Lead ทีมการตลาดจึงสรุปได้ว่า Broadcast ตัวนั้นน่าจะเป็นตัวกระตุ้นให้คนกลุ่มนี้ตัดสินใจบล็อก ไม่ใช่เรื่องบังเอิญที่กระจายตัวตลอดเดือน

ทำแบบนี้แล้วพัง เพราะ… นับ Unfollow ซ้ำจนสรุปสาเหตุผิดตัว

ทีมหนึ่งตั้ง Webhook รับทั้ง Follow และ Unfollow Event ไว้ในจุดเดียวกัน แต่ตรวจสอบการซ้ำของ `webhookEventId` เฉพาะฝั่ง Follow Event เท่านั้น เพราะมองว่า Unfollow Event ไม่น่าจะมีผลกระทบมากเท่า พอถึงช่วงที่เซิร์ฟเวอร์โหลดสูงจากแคมเปญใหญ่พร้อมกับมีคนบล็อกจำนวนมากในเวลาไล่เลี่ยกัน LINE ส่ง Unfollow Event บางตัวซ้ำมา ระบบก็บันทึกซ้ำโดยไม่รู้ตัว

ผลคือยอดบล็อกของช่วงเวลานั้นในรายงานสูงกว่าความจริงเกือบเท่าตัว ทำให้ทีมสรุปผิดว่า Broadcast ตัวนั้นสร้างความเสียหายรุนแรงกว่าที่เกิดขึ้นจริงมาก จนถึงขั้นตัดสินใจหยุดส่ง Broadcast ทั้งหมดไปพักหนึ่งทั้งที่ตัวเลขจริงไม่ได้เลวร้ายขนาดนั้น กว่าจะรู้ตัวว่านับซ้ำก็ตอนที่ลองไล่นับ `userId` ที่ไม่ซ้ำกันจริงเทียบกับยอด Event ทั้งหมดแล้วพบว่าตัวเลขไม่ตรงกัน วิธีป้องกันคือเช็ค `webhookEventId` ซ้ำให้ครบทุกประเภท Event ที่รับผ่าน Webhook เดียวกัน ไม่ใช่เช็คเฉพาะ Event ที่คิดว่าสำคัญกว่าเท่านั้น

สรุป

LINE Webhook Unfollow Event ช่วยให้ธุรกิจเห็นว่ามีคนบล็อกหรือลบเพื่อนไปเมื่อไหร่ แต่ไม่บอกเหตุผลโดยตรง การใช้ข้อมูลนี้ให้เกิดประโยชน์ต้องผูกกับประวัติสถานะ Lead และช่วงเวลาของเหตุการณ์ก่อนหน้า เพื่อหารูปแบบร่วมที่พออนุมานสาเหตุได้

การรู้ว่าฐานเพื่อนสูญเสียไปตรงไหนของ Journey มากที่สุด ช่วยให้ธุรกิจปรับเนื้อหาหรือความถี่ในการสื่อสารได้ตรงจุด แทนที่จะเห็นแค่ยอดเพื่อนสุทธิที่โตช้าโดยไม่รู้สาเหตุ

• Unfollow Event บอกแค่ว่าใครและเมื่อไหร่ที่บล็อกหรือลบเพื่อน ไม่บอกเหตุผลโดยตรง
• ผูกกับประวัติสถานะ Lead และช่วงเวลาของ Broadcast หรือการตามครั้งล่าสุด เพื่อหารูปแบบร่วม
• ยอดเพื่อนสุทธิที่โตช้าอาจซ่อนการสูญเสียคู่ขนานอยู่ ต้องแยกดู Unfollow Event ต่างหากจึงจะเห็นภาพจริง

คำถามที่พบบ่อย