ใช้ LINE Login บนเว็บ ผูกคนคนเดียวกันตั้งแต่หน้าเว็บจนถึงห้องแชท
สรุปสั้น ๆ
LINE Login ให้ userId ของลูกค้าตั้งแต่ตอนอยู่บนเว็บ ถ้า Login channel กับ Messaging API channel อยู่ใน Provider เดียวกัน userId นั้นจะเป็นค่าเดียวกับที่ webhook ส่งมาตอนลูกค้าทักแชท ทำให้ผูกคนเดียวกันได้โดยไม่ต้องเดาจากเวลาหรือ UTM แต่แลกกับขั้นตอนล็อกอินที่ทำให้คนบางส่วนเลิกกลางทาง จึงควรขอเฉพาะจุดที่ลูกค้าได้ประโยชน์ชัด
เว็บของร้านวันหนึ่งมีคนกดปุ่ม ‘ทัก LINE’ 500 ครั้ง ในแชทมีคนใหม่เข้ามา 340 ราย ตัวเลขสองชุดนี้ใกล้กันแต่ไม่เท่ากัน และไม่มีใครบอกได้ว่าคนไหนคือคนไหน ทีมที่ผมรู้จักเลยจับคู่ด้วยเวลา ใครกดปุ่มก่อนก็ใกล้กับแชทที่เข้าก่อน วิธีนี้ใช้ได้ตอนวันเงียบ ๆ แต่พังทันทีที่ทราฟฟิกเข้าพร้อมกัน
LINE Login เป็นทางที่ให้ตัวระบุของคนเดียวกันตั้งแต่หน้าเว็บ แต่มีเงื่อนไขที่หลายทีมไม่รู้จนเขียนโค้ดเสร็จแล้ว
LINE Login ให้อะไรที่ UTM ให้ไม่ได้
UTM บอกว่าคลิกมาจากแหล่งไหน แต่ไม่ได้บอกว่าคนที่คลิกคือใคร ส่วน LINE Login เป็นการยืนยันตัวตนผ่านมาตรฐานแบบ OAuth 2.0 กับ OpenID Connect เมื่อลูกค้าอนุญาต คุณจะได้ userId (สตริงขึ้นต้นด้วย U ตามด้วยตัวอักษรฐานสิบหก) ชื่อที่แสดง และรูปโปรไฟล์ ส่วนอีเมลต้องขอสิทธิ์เพิ่มและให้ลูกค้ายินยอม ตรวจเงื่อนไขล่าสุดในเอกสาร LINE Developers
ค่า userId นี้คือสิ่งที่ปรากฏใน webhook ตอนลูกค้าส่งข้อความหา OA ของคุณด้วย ถ้า channel ทั้งสองอยู่ใน Provider เดียวกัน นั่นคือเหตุผลทั้งหมดที่ทำให้ผูกกันได้
สิ่งที่ LINE Login ไม่ให้ก็ควรรู้ไว้ มันไม่ได้ให้เบอร์โทร และไม่ได้บอกว่าลูกค้าซื้ออะไรมาก่อน มันบอกเพียงว่าคนที่อยู่หน้าเว็บตอนนี้คือเจ้าของ userId ตัวนี้ ส่วนการเอา userId ไปผูกกับออเดอร์ ประวัติแชท และแหล่งที่มา เป็นงานของตารางข้อมูลฝั่งเราเอง
เส้นทางจากหน้าเว็บจนถึงห้องแชท
- ลูกค้าเข้าเว็บจากแอด ฝั่งเซิร์ฟเวอร์เก็บ click id และ UTM ไว้กับเซสชันของเราก่อน ตามหลักใน ผูก first-party ID ตั้งแต่ต้นทาง
- ลูกค้ากดปุ่ม Login เซิร์ฟเวอร์สร้างค่า state กับ nonce เก็บผูกกับเซสชัน แล้วส่งไปหน้าอนุญาตของ LINE
- ลูกค้ายืนยัน LINE ส่งกลับมาที่ callback ของเราพร้อม code และ state เซิร์ฟเวอร์เทียบ state ก่อนทำอย่างอื่น
- เซิร์ฟเวอร์แลก code เป็น token ที่ฝั่งหลังบ้านเท่านั้น และตรวจ id_token ก่อนเชื่อ (วิธีตรวจ ผมแยกอธิบายไว้ในบทความเฉพาะ)
- ได้ userId แล้วบันทึกคู่กับ click id, UTM และออเดอร์ที่เกิดในเซสชันนี้
- ชวนลูกค้าเพิ่ม OA เป็นเพื่อน เพราะการล็อกอินไม่ได้ทำให้เขาเป็นเพื่อนโดยอัตโนมัติ LINE มีตัวเลือกให้ชวนเพิ่มเพื่อนตอนล็อกอิน ต้องผูก OA กับ Login channel ในคอนโซลก่อน ชื่อพารามิเตอร์ตรวจในเอกสารล่าสุด
- เมื่อลูกค้าทักแชท webhook ส่ง userId มา เทียบกับตารางที่บันทึกไว้ ได้ที่มาของลูกค้าทันที
เงื่อนไข Provider ที่ทำให้การจับคู่ล้มทั้งระบบ
userId ของ LINE ออกให้ต่อ Provider คนเดียวกันจะมี userId ต่างกันถ้าเข้าผ่านคนละ Provider ถ้า Login channel ถูกสร้างใน Provider หนึ่งและ Messaging API channel ของ OA อยู่อีก Provider หนึ่ง ล็อกอินจะสำเร็จทุกครั้ง แต่ userId ที่ได้ไม่ตรงกับในแชทสักราย ตรวจก่อนเขียนโค้ด โดยเปิดคอนโซลดูว่าสอง channel อยู่ภายใต้ Provider เดียวกันหรือไม่ แล้วทดสอบด้วยบัญชีของคุณเอง ทักแชทแล้วเทียบ userId ทั้งสองฝั่ง
อาการที่เจอบ่อยคือ ทดสอบล็อกอินสำเร็จ 200 ครั้ง แต่ค้นหา userId เหล่านั้นในตารางผู้ที่ทักแชทแล้วพบ 0 ราย ทีมมักเสียเวลาไล่ตรวจโค้ดหลายวัน ทั้งที่ต้นเหตุคือ channel อยู่คนละ Provider วิธีแก้คือสร้างหรือย้าย channel ให้อยู่ Provider เดียวกัน (ตรวจเงื่อนไขการย้ายในเอกสารก่อน) แล้วล้างข้อมูลทดสอบเดิมทิ้ง อย่าพยายามแมปชุดเก่ากับชุดใหม่
ควรให้ล็อกอินตรงจุดไหนของเว็บ
ตัวเลขการเลิกกลางทางในตารางด้านล่างเป็นระดับเชิงเปรียบเทียบ ไม่ใช่ข้อมูลวัดจริง ให้ทดสอบกับเว็บของคุณเอง
| จุดที่ขอล็อกอิน | ผลต่อคนที่เลิกกลางทาง | ลูกค้าได้อะไร |
|---|---|---|
| ก่อนดูสินค้า | สูงมาก | ไม่ได้อะไรเลย จึงไม่ควรขอ |
| ตอนรับคูปองหรือส่วนลด | ต่ำถึงปานกลาง | ได้ส่วนลดทันที |
| ตอนจองคิวหรือสั่งซื้อ | ปานกลาง | ได้ใบยืนยันในแชท ไม่ต้องกรอกเบอร์ |
| ตอนติดตามสถานะ | ต่ำ | ได้ข้อมูลล่าสุดไม่ต้องถามแอดมิน |
ความยินยอมและข้อมูลที่ไม่ควรเก็บเกินจำเป็น
- บอกหน้าล็อกอินให้ชัดว่าเก็บ userId เพื่ออะไร และเชื่อมกับประวัติการใช้เว็บหรือไม่ รายละเอียดเรื่องนี้อยู่ใน เรื่องเก็บ LINE User ID ตาม PDPA
- เก็บเฉพาะ userId กับที่มา ไม่ต้องเก็บรูปโปรไฟล์หรืออีเมลถ้าไม่มีเหตุผลทางธุรกิจ
- ตั้งอายุการเก็บและช่องทางให้ลูกค้าขอลบ
- ถ้าต้องการให้ออเดอร์ย้อนกลับไปหาคนที่สั่ง ใช้หลักใน ผูกออเดอร์กับ LINE user ต่อจากนี้
สรุป
ก่อนเริ่มทำ ให้ตอบสามเรื่องให้ได้ในกระดาษแผ่นเดียว คือ channel ทั้งสองอยู่ Provider เดียวกันหรือยัง จะขอล็อกอินที่จุดไหนของเว็บ และลูกค้าได้อะไรตอบแทน ถ้าตอบข้อสุดท้ายไม่ได้ ปุ่มล็อกอินจะกลายเป็นกำแพง
- LINE Login ให้ userId ตัวเดียวกับในแชท เมื่ออยู่ Provider เดียวกัน
- ล็อกอินไม่ได้ทำให้เป็นเพื่อน OA ต้องชวนเพิ่มเพื่อนแยกต่างหาก
- ขอล็อกอินเฉพาะจุดที่ลูกค้าได้ของตอบแทนทันที
- เก็บเท่าที่จำเป็นและแจ้งวัตถุประสงค์ให้ชัด
- ใช้คู่กับ UTM และ click id ไม่ใช่แทนที่
คำถามที่พบบ่อย
LINE Login ทำให้ลูกค้าเป็นเพื่อน OA ทันทีไหม
ไม่ทันที การล็อกอินกับการเป็นเพื่อนเป็นคนละเรื่อง LINE มีตัวเลือกให้ชวนเพิ่มเพื่อนระหว่างล็อกอิน ต้องผูก OA กับ Login channel ก่อน ตรวจวิธีตั้งค่าล่าสุดในเอกสาร
ลูกค้าที่ไม่ยอมล็อกอินจะวัดผลยังไง
ยังวัดด้วยวิธีเดิมได้ เช่น เก็บ click id ก่อนกดไป LINE และใช้รหัสในข้อความตั้งต้น LINE Login เป็นชั้นเสริมสำหรับกลุ่มที่ยินดีล็อกอิน ไม่ใช่ทางเดียว
ใช้ LINE Login อย่างเดียวแทน UTM ได้ไหม
ไม่ได้ เพราะ UTM ยังบอกแหล่งที่มาของคลิก ส่วน LINE Login บอกว่าคนคือใคร สองอย่างทำงานคู่กัน
LINE Login ใช้ได้กับเว็บที่ไม่ได้ขายของไหม
ใช้ได้กับเว็บที่ต้องการยืนยันตัวตนทั่วไป เช่น เว็บจองคิวหรือเว็บสมาชิก แต่ต้องมีเหตุผลชัดให้ลูกค้ากดอนุญาต ไม่เช่นนั้นอัตราที่เลิกกลางทางจะสูง
มีค่าใช้จ่ายสำหรับ LINE Login ไหม
ผมไม่ทราบเงื่อนไขราคาล่าสุดที่ยืนยันได้ ให้ตรวจหน้าข้อกำหนดและเอกสารของ LINE Developers ก่อนวางแผนงบ
อ่านต่อแบบเจาะลึก
รู้ว่าโฆษณาเข้า LINE ทำยอดขายจริงแค่ไหน
linli ติดตามลูกค้าตั้งแต่คลิกโฆษณา กดเพิ่มเพื่อน ทักแชท จนปิดการขาย พร้อมส่ง Conversion กลับแพลตฟอร์มโฆษณา เริ่มฟรี 14 วัน
ทดลองใช้ฟรี 14 วันบทความที่เกี่ยวข้อง
ผูกบัญชี LINE กับรหัสสมาชิกเดิม ด้วย Account Link แทนการให้ลูกค้าพิมพ์เบอร์
LINE MINI App กับ LIFF ต่างกันตรงไหน และงานแบบไหนควรใช้ตัวไหน
