จ่ายค่าแอดวันละ 2 พัน แต่ไม่รู้ว่ากี่คนกดปุ่มจริงก่อนหลุดหายไป

เจ้าของร้านขายอุปกรณ์ออกกำลังกายรายหนึ่งจ่ายค่าแอดวันละราว 2,000 บาทเป็นตัวอย่างสมมติ ยอด Click เข้าเว็บมาอยู่ที่ราว 150 ครั้งต่อวัน แต่พอถามว่ามีกี่คนที่กดปุ่ม ‘คุยกับแอดมิน’ บนหน้าเว็บจริง ๆ ก่อนจะไปเปิด LIFF เขาตอบไม่ได้เลยสักครั้ง เพราะไม่เคยมีอะไรวัดจุดนี้ไว้

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

บทความนี้จะพาไล่ดูว่าควร Track Event อะไรบ้างใน LIFF เพื่อให้เห็นว่า Missing Data เกิดขึ้นตรงไหนกันแน่ ระหว่างเว็บไซต์กับ LINE ไม่ใช่แค่รู้ว่ามีคนหายไป แต่รู้ว่าหายไปตอนไหน

วัดแค่ ‘เข้าเว็บ’ กับ ‘Add Friend สำเร็จ’ ไม่พอ

ถ้าวัดแค่สองจุดปลายทาง คุณจะรู้แค่ว่า ‘มีคนหายไประหว่างทาง’ แต่ไม่รู้เลยว่าหายไปตอนไหน หายก่อนกดปุ่มเข้า LIFF หรือหายหลังจากเปิด LIFF แล้วแต่ไม่กด Add Friend ต่อ ซึ่งสองกรณีนี้มีสาเหตุและวิธีแก้ที่ต่างกันโดยสิ้นเชิง

การมี Event ย่อยระหว่างทางช่วยให้เห็นว่าปัญหาอยู่ที่ตัวเว็บไซต์ที่ปุ่มไม่ชัดจนคนไม่กด หรืออยู่ที่ตัว LIFF เองที่โหลดช้าจนคนปิดหน้าทิ้งก่อนเห็นปุ่ม Add Friend

Event หลักที่ควรวัดตลอดเส้นทางเข้า LIFF

ต่อไปนี้คือ Event ระดับพื้นฐานที่ควรมีไว้ครบ เพื่อให้เห็นเส้นทางเต็มตั้งแต่คนเข้าเว็บจนถึงกลายเป็น Lead ในแชท

• Page View — คนเข้าหน้าเว็บที่มีปุ่มพาไป LINE
• Button Click — คนกดปุ่ม ‘คุยกับแอดมิน’ หรือปุ่มที่คล้ายกันบนหน้าเว็บ
• LIFF Opened — LIFF โหลดสำเร็จและแสดงผลให้ผู้ใช้เห็น
• LIFF Login Completed — ผู้ใช้ล็อกอินผ่าน LINE สำเร็จภายใน LIFF
• Add Friend Completed — ผู้ใช้กดเพิ่มเพื่อนสำเร็จหลังจากอยู่ใน LIFF แล้ว

แต่ละ Event ผูกกับ LIFF SDK คำสั่งไหนบ้าง

ในทางปฏิบัติ Event เหล่านี้ไม่ได้ลอยมาเอง แต่ผูกกับจังหวะที่ LIFF SDK ทำงานจริง เริ่มจาก liff.init({ liffId }) ที่ต้องเรียกก่อนใช้ฟังก์ชันอื่นทุกตัว ถ้า liff.init() สำเร็จและ Promise resolve ได้ปกติ ตรงนี้คือจังหวะที่ควรยิง Event LIFF Opened เพราะแปลว่าหน้าเริ่มพร้อมทำงานแล้วจริง ไม่ใช่แค่โหลด HTML เสร็จ

ขั้นถัดไปคือเช็กสถานะล็อกอินด้วย liff.isLoggedIn() ถ้ายังไม่ล็อกอินและอยู่นอก LINE ในตัว SDK จะพาผู้ใช้ไปหน้า Login ผ่าน liff.login() เมื่อกลับมาสำเร็จค่อยเรียก liff.getProfile() เพื่อดึง userId, displayName และ pictureUrl มาใช้งาน จังหวะที่ liff.getProfile() คืนค่ากลับมาโดยไม่ error คือจุดที่ควรยิง LIFF Login Completed พร้อมแนบ userId ที่ได้ไปเป็นส่วนหนึ่งของ Identifier ด้วย เพราะเป็นค่าที่จะไปตรงกับ source.userId ใน Follow Event ฝั่ง Webhook ทีหลัง

อีกจุดที่มักถูกลืมคือ liff.isInClient() ซึ่งบอกว่าหน้าเว็บนี้ถูกเปิดอยู่ในแอป LINE จริงหรือเปิดผ่านเบราว์เซอร์ทั่วไป พฤติกรรมของผู้ใช้สองกลุ่มนี้ต่างกันมาก กลุ่มที่เปิดนอกแอป LINE มักมีอัตราหลุดสูงกว่าเพราะต้องสลับแอปไปมา ถ้าไม่แยก Event ตามค่า isInClient() ไว้ด้วย จะเห็นแค่ตัวเลขรวมที่ปนกันจนวิเคราะห์สาเหตุจริงไม่ได้

จุดที่คนมักหายไประหว่างเปิด LIFF

จุดแรกคือช่วงโหลด LIFF เอง ถ้าใช้เวลานานเกินไปบนเน็ตมือถือที่สัญญาณไม่ดี ผู้ใช้จำนวนหนึ่งจะปิดหน้าทิ้งก่อนที่ LIFF จะแสดงผลเสร็จด้วยซ้ำ กรณีนี้จะไม่มี Event ใดเกิดขึ้นเลยนอกจาก Button Click ที่กดมาจากเว็บ

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

จุดที่สามคือหลังล็อกอินสำเร็จแล้วแต่ยังไม่กด Add Friend เพราะหน้าที่แสดงต่อไม่ชัดเจนพอ หรือมีขั้นตอนเยอะเกินไปก่อนถึงปุ่มเพิ่มเพื่อน กรณีนี้ตัวเลข LIFF Login Completed จะสูงแต่ Add Friend Completed จะต่ำผิดปกติ

ตัวอย่างตาราง Funnel ที่ควรดูทุกสัปดาห์ (ตัวอย่างสมมติ)

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

วางระบบ Track Event ให้ครอบคลุมได้ยังไง

ฝั่งเว็บไซต์ควรใส่ Event Listener ไว้ที่ปุ่มพาไป LINE โดยตรง ไม่ใช่วัดแค่ Page View เฉย ๆ ส่วนฝั่ง LIFF ต้องเรียก SDK เพื่อยิง Event ตอน LIFF โหลดสำเร็จ ตอนล็อกอินสำเร็จ และตอน Add Friend สำเร็จ โดยแนบ Identifier ต้นทางเดียวกับที่ใช้ตั้งแต่หน้าเว็บไปด้วยทุกครั้ง ถ้าเว็บไซต์ต้องพาไป LIFF ข้าม Domain ควรอ่านแนวทางส่งต่อข้อมูลข้าม Domainประกอบ เพราะเป็นจุดที่พารามิเตอร์หลุดหายง่ายอีกจุดหนึ่ง

สิ่งที่ต้องระวังคือชื่อ Event ต้องสอดคล้องกันทั้งฝั่งเว็บและฝั่ง LIFF ถ้าตั้งชื่อไม่ตรงกันหรือใช้ Identifier คนละชุด จะทำให้เอาข้อมูลสองฝั่งมาต่อเป็น Funnel เดียวกันไม่ได้ในภายหลัง ถ้าต้องการส่ง Event ชุดเดียวกันเข้า GA4 ด้วย ควรศึกษาแนวทางแบบMeasurement Protocolประกอบ เพราะวิธีส่งข้อมูลจาก LIFF ต่างจากการติด Tag บนเว็บปกติ

ในทางปฏิบัติ หลายทีมเลือกยิง Event ผ่าน dataLayer.push() ในรูปแบบเดียวกับที่ใช้บน Google Tag Manager อยู่แล้ว เช่น dataLayer.push({ event: 'liff_login_completed', userId, campaignId, timestamp }) แล้วให้ Tag Manager ดักจับต่อไปยังปลายทางที่ต้องการ วิธีนี้ทำให้ทีมการตลาดปรับปลายทางของ Event ได้เองบางส่วนโดยไม่ต้องแก้โค้ดฝั่ง LIFF ทุกครั้ง แต่ต้องตกลงชื่อ Event และชื่อ Field ให้ตรงกันตั้งแต่วันแรก ไม่งั้นจะเจอปัญหาคนละชื่อคนละความหมายระหว่างทีมพัฒนากับทีมการตลาดในภายหลัง

ขั้นตอนตรวจสอบก่อนเชื่อว่า Event ยิงครบจริง

ก่อนสรุปว่า Funnel ที่เห็นสะท้อนความจริง ควรทดสอบตามลำดับนี้ทุกครั้งที่มีการเปลี่ยนหน้าเว็บหรือ LIFF

1. เปิดเส้นทางทั้งหมดด้วยอุปกรณ์จริงทั้ง iOS และ Android แล้วดูว่า Event แต่ละตัวยิงตามลำดับหรือไม่
2. ตรวจว่า Identifier ต้นทางติดไปกับทุก Event ไม่ใช่แค่บาง Event
3. ลองปิดหน้าก่อนทำเหตุการณ์เสร็จ แล้วดูว่า Event ก่อนหน้ายังถูกบันทึกอยู่หรือหายไปด้วย
4. เทียบจำนวน Event ที่เห็นในระบบกับจำนวนที่ทดสอบจริงว่าตรงกันหรือขาดหาย

เอาช่องว่างที่เห็นไปแก้อะไรต่อ

ถ้าเห็นว่าคนหายไปมากช่วง Button Click ถึง LIFF Opened ปัญหามักอยู่ที่ความเร็วในการโหลดหรือปุ่มไม่ชัดพอ ถ้าหายมากช่วง LIFF Login ปัญหามักอยู่ที่ข้อความอธิบายก่อนขอสิทธิ์ยังไม่น่าเชื่อถือพอ และถ้าหายมากช่วงหลังล็อกอินแล้วแต่ยังไม่ Add Friend ปัญหามักอยู่ที่ขั้นตอนหลังจากนั้นซับซ้อนเกินไป

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

ข้อจำกัดของการวัด Event ใน LIFF

แม้จะวางระบบครบทุก Event ก็ยังมีบางส่วนที่วัดไม่ได้ เช่น คนที่ปิดแอปทันทีก่อน Event ทันเวลาที่จะส่งข้อมูลออกไป หรือกรณีเน็ตหลุดกลางทางทำให้ Event ค้างไม่ถูกส่ง สภาพแบบนี้ใกล้เคียงกับการสูญเสียข้อมูล First-party ที่เกิดขึ้นได้ทุกระบบ ตัวเลขที่ได้จึงควรใช้เป็นแนวทางเทียบสัดส่วนระหว่างช่วงเวลา ไม่ใช่ยึดเป็นตัวเลขสัมบูรณ์ และควรตรวจแบบเดียวกับการตรวจช่องว่างข้อมูลระหว่าง Pixel กับ CAPI เป็นระยะ

อีกข้อจำกัดที่พบบ่อยคือเบราว์เซอร์บางตัวบนมือถือ โดยเฉพาะ In-app Browser ของแพลตฟอร์มโฆษณาบางเจ้า มีการจำกัดการทำงานของ JavaScript บางฟังก์ชันหรือปิดกั้นการยิง Event แบบ Beacon ทำให้ Event ที่ควรส่งก่อนปิดหน้าไปไม่ถึงปลายทาง กรณีแบบนี้แก้ได้บางส่วนด้วยการเปลี่ยนไปใช้ sendBeacon API แทนการยิง Event แบบ fetch ธรรมดา เพราะ sendBeacon ถูกออกแบบมาให้ทำงานต่อได้แม้หน้าเว็บกำลังจะปิดไปแล้ว แต่ก็ยังไม่ครอบคลุมทุกกรณี 100% เช่นเดิม

สรุป

การวัดแค่ ‘เข้าเว็บ’ กับ ‘Add Friend สำเร็จ’ บอกได้แค่ว่ามีคนหายไป แต่ไม่บอกว่าหายไปตอนไหน การใส่ Event ย่อยระหว่างทางใน LIFF ช่วยให้เห็นจุดที่ควรแก้ไขก่อนอย่างมีลำดับความสำคัญ

เมื่อรู้ว่าจุดไหนคือจุดที่คนหายมากที่สุด การแก้ปัญหาจะตรงจุดกว่าการเดาแก้ทุกอย่างพร้อมกัน และช่วยให้ค่าแอดที่จ่ายไปแต่ละวันคุ้มค่ากว่าเดิม เหมือนที่ทีมควรตรวจสอบ Endpoint URL และลำดับคำสั่ง SDK ให้ครบก่อนเชื่อตัวเลข Login ในรายงาน

• วัดแค่สองจุดปลายทางไม่พอ ต้องมี Event ย่อยระหว่างทางใน LIFF ด้วย
• จุดที่คนหายบ่อยคือช่วงโหลด LIFF ช่วงขอสิทธิ์ Login และช่วงหลังล็อกอินก่อน Add Friend
• เรียง Event เป็น Funnel รายสัปดาห์เพื่อจับจุดที่ควรแก้ก่อน ไม่ใช่แก้ทุกอย่างพร้อมกัน
• ผูก userId จาก liff.getProfile() กับ Identifier ต้นทางตั้งแต่ในเบราว์เซอร์ ก่อนที่ผู้ใช้จะกด Add Friend เพื่อให้จับคู่กับ Follow Event ฝั่ง Webhook ได้แม่นยำในภายหลัง

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