User ID ของ LINE ใช้ข้ามบัญชี OA ไม่ได้ ถ้าไม่ได้อยู่ Provider เดียวกัน

นักพัฒนาของเอเจนซี่คนหนึ่งทำระบบล็อกอินด้วย LINE ให้เว็บลูกค้าเสร็จ ทดสอบแล้วล็อกอินผ่านทุกครั้ง แต่พอเอา userId ที่ได้ไปค้นในตารางลูกค้าที่มาจากแชท ไม่เจอเลยสักรายจากที่ทดสอบ 200 ราย เขาไล่ตรวจโค้ดสองวัน สุดท้ายพบว่าโค้ดไม่ผิด Login channel ถูกสร้างอยู่ใน Provider คนละอันกับ OA

เรื่องนี้เกิดเงียบ ๆ เพราะไม่มี error ไม่มี warning ข้อมูลแค่ไม่เคยแมตช์กัน

userId ผูกกับ Provider ไม่ได้ผูกกับคน

Provider คือขอบเขตที่ LINE ใช้ออก userId ภายใต้ Provider เดียวกัน คนคนหนึ่งจะมี userId ค่าเดียว (สตริงขึ้นต้นด้วย U ตามด้วยตัวอักษรฐานสิบหก) ไม่ว่าจะเข้าผ่าน channel ไหนของ Provider นั้น แต่ถ้าเข้าผ่าน Provider อื่น ค่าจะเป็นคนละตัว

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

• ผมสรุปจากหลักการของเอกสาร ไม่ได้ทดสอบกับบัญชีของท่าน จึงขอให้ทดสอบจริงก่อนพึ่งพาตาราง

ผลกระทบกับเอเจนซี่และธุรกิจหลายแบรนด์

เอเจนซี่ที่ดูแลหลายลูกค้าควรตัดสินใจก่อนว่าจะสร้าง Provider แยกต่อลูกค้า หรือรวมทุกอย่างไว้ Provider ของเอเจนซี่ การแยกต่อลูกค้าทำให้ข้อมูลของแต่ละเจ้าไม่ปนกัน ตามแนวคิดใน วัดผลหลายลูกค้าและหลาย LINE OA ไม่ให้ปนกัน ส่วนการรวมไว้ที่เดียวทำให้เห็นคนเดียวกันข้ามแบรนด์ได้ แต่ต้องมีฐานความยินยอมรองรับ

สำหรับกลุ่มธุรกิจที่มีหลายแบรนด์ ทางเลือกคล้ายกัน ดูตัวอย่างโครงสร้างได้ใน รวมศูนย์ดูข้อมูล 5 แบรนด์ 5 OA ถ้าสร้าง Provider ด้วยอีเมลส่วนตัวของพนักงานแล้วเขาออก ก็เสี่ยงเสียสิทธิ์จัดการ ควรสร้างด้วยบัญชีขององค์กร

ในเอกสารส่งมอบงานให้ลูกค้าควรระบุชื่อ Provider ใครเป็นเจ้าของ และมี channel ไหนอยู่ใต้มันบ้าง เพราะเมื่อเปลี่ยนเอเจนซี่ ผู้ที่เข้ามาใหม่ต้องรู้ว่าจะสร้าง channel เพิ่มตรงไหน มิฉะนั้นจะได้ userId ชุดใหม่ที่ไม่ตรงกับฐานเดิม

ตรวจก่อนเขียนโค้ดรวมข้อมูล

1. เปิดคอนโซล LINE Developers แล้วจดว่าแต่ละ channel อยู่ Provider ไหน
2. ทดสอบด้วยบัญชีของคุณเอง ล็อกอินบนเว็บแล้วทักแชทหา OA จากนั้นเทียบ userId สองฝั่ง
3. เก็บชื่อหรือรหัส Provider ไว้คู่กับ userId ทุกแถวในฐานข้อมูล
4. ถ้าต้องย้ายหรือสร้าง channel ใหม่ใต้ Provider อื่น ให้ตรวจเอกสารว่าทำได้หรือไม่ และสมมติว่า userId ชุดเดิมจะใช้ต่อไม่ได้จนกว่าจะยืนยัน

ออกแบบตารางให้รองรับหลาย Provider

ปัญหา ‘ทักมาสองชื่อ แต่เป็นคนเดิม’ ก็มีพื้นฐานจากโครงสร้างนี้ ดูเพิ่มที่ เรื่องบัญชี LINE สองชื่อของคนเดียวกัน

• ใช้คู่ (Provider, userId) เป็นคีย์ของตัวตนจาก LINE ไม่ใช้ userId เดี่ยว
• แยกตาราง person (คนในระบบเรา) ออกจากตาราง identity (ตัวตนจากแต่ละช่องทาง) แล้วเชื่อมกัน
• เก็บที่มาของการเชื่อมว่ามาจากการล็อกอิน การผูกบัญชีของ LINE หรือเบอร์ที่ยืนยันแล้ว
• อย่าเชื่อมคนสองแถวด้วยชื่อโปรไฟล์ เพราะชื่อซ้ำกันได้และเปลี่ยนได้
• ในรายงานรวม ให้แสดงจำนวนตัวตนที่เชื่อมเป็นคนเดียวกันแล้วแยกจากที่ยังไม่เชื่อม ไม่เช่นนั้นยอดลูกค้าใหม่จะดูสูงเกินจริงทันทีที่เพิ่ม channel ใหม่ เพราะคนเดิมถูกนับเป็นคนใหม่อีกครั้ง

เมื่อข้ามกันจริง ต้องจับคู่ด้วยอะไร

ใช้ตัวตนที่คุณเป็นเจ้าของและลูกค้ายืนยันแล้ว เช่น รหัสสมาชิกที่ผูกผ่านการล็อกอินของร้านเอง อีเมลหรือเบอร์ที่ผ่านการยืนยัน หรือเลขออเดอร์ที่ลูกค้ากรอกเอง ข้อมูลเหล่านี้ไม่เปลี่ยนตาม Provider และผูกตามหลักของ PDPA ได้ ส่วนการเดาจากชื่อโปรไฟล์ให้หลีกเลี่ยง

สรุป

ก่อนสร้าง channel ใหม่ทุกครั้ง ให้ถามว่าจะต้องจับคู่กับ channel ไหนในอนาคต แล้วสร้างให้อยู่ Provider เดียวกันตั้งแต่ต้น การแก้ทีหลังมักแพงกว่าที่คิด

ถ้าข้ามกันไปแล้ว อย่าพยายามเดา ให้สร้างจุดยืนยันตัวตนที่ลูกค้าเป็นฝ่ายทำเอง

• userId ผูกกับ Provider ไม่ใช่ตัวคน
• เก็บ Provider คู่กับ userId ทุกแถว
• สร้าง channel ที่ต้องจับคู่กันให้อยู่ Provider เดียวกันตั้งแต่ต้น
• ข้ามกันแล้วให้จับคู่ด้วยตัวตนที่ลูกค้ายืนยัน ไม่เดาจากชื่อ
• ทดสอบด้วยบัญชีของตัวเองก่อนเชื่อตารางสรุป

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