เปิดแคมเปญพร้อมกันสามหน้า Landing Page แต่แยกไม่ออกว่าอันไหนขายได้ แก้ยังไง

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

ผ่านไปหนึ่งสัปดาห์ ทีมเปิดรายงานดูแล้วพบว่า Lead ที่เข้ามาในแชททั้งหมดถูกจัดกลุ่มเป็นก้อนเดียว แยกไม่ออกเลยว่าใครมาจากหน้าไหน ทั้งที่แต่ละหน้ามีกลุ่มเป้าหมายและข้อความที่ต่างกันโดยสิ้นเชิง สุดท้ายต้องมานั่งไล่ถามลูกค้าทีละคนในแชทว่าเห็นโฆษณาตัวไหน ซึ่งทำได้ไม่ครบและไม่แม่นยำ

ปัญหานี้ไม่ได้เกิดเพราะ LIFF ใช้งานไม่ได้ แต่เกิดเพราะไม่ได้ออกแบบให้ Parameter จากแต่ละ Landing Page เดินทางไปถึงจุดที่ LIFF เปิดขึ้นจริง บทความนี้จะพาดูว่าจะวางระบบยังไงให้รองรับหลายแคมเปญและหลาย Landing Page พร้อมกันได้โดยไม่ปนกัน

ทำไม Lead จากหลาย Landing Page ถึงมาปนกันใน LIFF

LIFF (LINE Front-end Framework) คือหน้าเว็บที่เปิดอยู่ภายในแอป LINE ซึ่งโดยตัวมันเองไม่ได้รู้ว่าผู้ใช้มาจาก Landing Page หน้าไหน มันรู้แค่ว่าตอนนี้มีคนเปิดหน้านี้อยู่ ถ้าไม่มีการส่งข้อมูลต้นทางแนบไปด้วย LIFF ก็จะไม่มีทางแยกได้เองว่าคนที่เข้ามาแต่ละคนมาจากแคมเปญไหน

สิ่งที่มักเกิดขึ้นคือทุก Landing Page ลิงก์ไปยัง LIFF URL เดียวกันแบบเปล่า ๆ ไม่มีการแนบพารามิเตอร์ใด ๆ ต่อท้าย พอผู้ใช้กดปุ่มจากหน้าไหนก็ตาม ปลายทางที่ LIFF เห็นจะเหมือนกันหมด ทำให้ข้อมูลทุกแคมเปญไหลมารวมเป็นก้อนเดียวโดยไม่มีทางแยก

กำหนด Identifier เฉพาะให้แต่ละ Landing Page ก่อนเข้า LIFF

วิธีแก้เริ่มจากตั้งพารามิเตอร์เฉพาะให้แต่ละ Landing Page เช่น campaign_id หรือ source_page แล้วแนบไปกับลิงก์ที่พาไปยัง LIFF แทนที่จะใช้ลิงก์เปล่า วิธีนี้ทำให้ LIFF รับรู้ตั้งแต่ต้นว่าเซสชันนี้มาจากหน้าไหน

จุดที่ต้องระวังคือพารามิเตอร์เหล่านี้ต้องส่งผ่านช่องทางที่ LIFF อ่านได้จริง เช่น Query String บน LIFF URL หรือ State ที่ส่งผ่าน LINE Login เพราะถ้าฝากไว้แค่ในตัวแปร JavaScript ฝั่งหน้าเว็บต้นทางเฉย ๆ ข้อมูลจะไม่เดินทางต่อไปถึง LIFF เลย

รักษาความต่อเนื่องของ Session ระหว่างเว็บกับ LIFF

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

แนวทางที่ใช้ได้จริงคือสร้างหน้าคั่นกลางสั้น ๆ ก่อนพาไป LIFF เพื่อบันทึกค่าพารามิเตอร์ลง Token หนึ่งตัว แล้วส่ง Token นั้นต่อไปให้ LIFF อ่านค่าออกมาอีกที วิธีนี้ลดความเสี่ยงที่พารามิเตอร์จะหายระหว่างการ Redirect ข้ามแอป

โครงสร้างตั้งค่าที่รองรับหลายแคมเปญพร้อมกัน

ตารางนี้เป็นตัวอย่างโครงสร้างที่ใช้แยกทั้งสามแคมเปญออกจากกันได้ โดยยึดหลักว่าแต่ละ Landing Page ต้องมี Identifier ของตัวเองที่ไม่ซ้ำกับหน้าอื่น

รับมือกรณีลูกค้าเปิดจากลิงก์ที่แชร์ต่อกันเอง

ในความเป็นจริงจะมีลูกค้าบางส่วนที่ไม่ได้เปิดลิงก์จากแคมเปญโดยตรง แต่เปิดจากลิงก์ที่เพื่อนแชร์ต่อมาอีกที กรณีนี้พารามิเตอร์ต้นทางอาจติดมาด้วยถ้าเพื่อนแชร์ลิงก์แบบเต็ม แต่ถ้าเพื่อนพิมพ์บอกปากเปล่าหรือแคปภาพมาเปิดเอง ก็จะไม่มีทางรู้ที่มาได้เลย

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

ลำดับตั้งค่าให้ LIFF รองรับหลายแคมเปญตั้งแต่วันแรก

ก่อนเปิดแคมเปญใหม่แต่ละครั้ง ควรไล่ตามลำดับนี้เพื่อลดโอกาสข้อมูลปนกันตั้งแต่ต้น

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

ฟิลด์จริงจาก liff.init และ liff.getProfile ที่ใช้ผูก Identifier ได้

ในทางเทคนิค การผูก Identifier เข้ากับผู้ใช้จริงต้องอาศัย LIFF SDK สองคำสั่งหลัก เริ่มจาก `liff.init({ liffId: "xxxx-xxxxxxxx" })` ที่ต้องเรียกก่อนใช้งานฟังก์ชันอื่นเสมอ เพื่อให้ SDK เชื่อมกับ Context ของแอป LINE ที่เปิด LIFF อยู่ ณ ตอนนั้น หลัง init สำเร็จ ค่อยเรียก `liff.getProfile()` ซึ่งคืนค่าออบเจกต์ที่มี `userId`, `displayName` และ `pictureUrl` ของผู้ใช้คนนั้น

ค่าที่สำคัญที่สุดสำหรับงาน Tracking คือ `userId` ที่ได้จาก `liff.getProfile()` เพราะเป็นค่าเดียวกับ `source.userId` ที่ Messaging API จะส่งมาทาง Webhook ในภายหลังเมื่อผู้ใช้คนเดียวกันทักแชทเข้ามา การเก็บคู่ `userId` นี้ไว้พร้อมกับ Identifier ที่อ่านได้จาก Query String ตอนโหลดหน้า LIFF จึงเป็นจุดเชื่อมที่แท้จริงระหว่างฝั่ง Landing Page กับฝั่งแชท ไม่ใช่แค่การส่งพารามิเตอร์ผ่านไปเฉย ๆ โดยไม่มีอะไรมายืนยันว่าถึงปลายทางจริง

อีกจุดที่ต้องระวังคือ `liff.getProfile()` ต้องขอ Scope `profile` ตอนสร้าง LIFF App ไว้ล่วงหน้า ถ้าลืมเปิด Scope นี้ คำสั่งจะโยน Error กลับมาแทนที่จะได้ข้อมูลผู้ใช้ ทำให้ระบบผูก Identifier ล้มเหลวเงียบ ๆ โดยที่หน้าเว็บยังใช้งานต่อได้ปกติจนกว่าจะไปเช็ค Log ถึงจะรู้ว่าไม่มีการบันทึก userId เลยสักรายการ

ตัวอย่างเดินระบบจริง จากคลิกโฆษณาถึงบันทึก Identifier

สมมติผู้ใช้กดโฆษณาแคมเปญ premium-course ลิงก์พาไปหน้า Landing Page ที่มี URL ต่อท้ายด้วย `?campaign=premium-course` หน้าเว็บอ่านค่านี้ด้วย JavaScript แล้วเก็บไว้ใน Token ชั่วคราวก่อนพาไป LIFF ตามรูปแบบที่อธิบายไว้ในหัวข้อก่อนหน้า

เมื่อ LIFF โหลดขึ้นมา โค้ดฝั่ง Client จะเรียก `liff.init()` ก่อน แล้วเรียก `liff.getProfile()` เพื่อดึง `userId` ของผู้ใช้คนนั้นออกมา จากนั้นส่ง `userId` คู่กับค่า Token ที่ถอดรหัสได้เป็น `campaign=premium-course` กลับไปบันทึกที่เซิร์ฟเวอร์ทันทีก่อนที่ผู้ใช้จะกดปุ่มเพิ่มเพื่อนด้วยซ้ำ พอผู้ใช้กดเพิ่มเพื่อนจริง Messaging API จะส่ง Follow Event ที่มี `source.userId` ตรงกับค่าที่บันทึกไว้แล้ว ระบบจึงผูกได้ทันทีว่าคนที่เพิ่มเพื่อนคนนี้มาจากแคมเปญ premium-course โดยไม่ต้องเดาหรือรอให้เขาพิมพ์อะไรมาก่อน

ทำแบบนี้แล้วพัง เพราะ… ลืมเปิด Scope profile ตอนสร้าง LIFF App

ทีมหนึ่งเปิดแคมเปญใหม่โดยสร้าง LIFF App ตัวใหม่แยกจากเดิม แต่ตอนตั้งค่าใน LINE Developers Console ลืมติ๊กเปิด Scope `profile` เหมือนที่ตัวเดิมเคยตั้งไว้ พอแคมเปญรันไปได้สามวัน ทีมเปิดรายงานมาดูแล้วพบว่าไม่มี userId ถูกบันทึกเข้าระบบเลยสักรายการ ทั้งที่มีคนคลิกเข้า LIFF และเพิ่มเพื่อนตามปกติ

สาเหตุคือ `liff.getProfile()` โยน Error กลับมาเงียบ ๆ ทุกครั้งที่ถูกเรียก เพราะไม่มีสิทธิ์เข้าถึงข้อมูลโปรไฟล์ผู้ใช้ตาม Scope ที่ตั้งไว้ โค้ดฝั่ง Client ที่ไม่ได้ดัก Error นี้ไว้ก็แค่ล้มเหลวแบบไม่มีอะไรแจ้งเตือน หน้าเว็บยังใช้งานต่อได้ปกติ ผู้ใช้ไม่รู้สึกว่ามีอะไรผิดพลาด แต่เบื้องหลังไม่มีการผูก Identifier เกิดขึ้นเลยตลอดสามวันนั้น กว่าจะรู้ตัวก็สูญเสียข้อมูลต้นทางของ Lead ไปเกือบทั้งหมดของแคมเปญนั้น สิ่งที่ควรทำตั้งแต่แรกคือดัก Error จาก `liff.getProfile()` แล้วส่ง Log แจ้งเตือนทันทีถ้าพบว่าเรียกไม่สำเร็จ ไม่ใช่ปล่อยให้ล้มเหลวแบบเงียบ ๆ อย่างที่เกิดขึ้น

ข้อจำกัดที่ต้องยอมรับก่อนเชื่อรายงานเต็มร้อย

ต่อให้ตั้งค่าครบทุกจุด ก็จะยังมีความคลาดเคลื่อนหลงเหลืออยู่บ้าง โดยเฉพาะจากพฤติกรรมที่ควบคุมไม่ได้ เช่น การแชร์ลิงก์ต่อ หรือการที่ผู้ใช้ปิดแอป LINE ระหว่างโหลด LIFF แล้วเปิดใหม่ผ่านทางอื่น ตัวเลขที่ได้จึงควรมองเป็นภาพส่วนใหญ่ที่ใกล้เคียงความจริง ไม่ใช่ยอดที่ครบทุกคน

ระบบที่ช่วยเก็บ Identifier ต่อจาก Landing Page เข้า LIFF อย่าง linli ช่วยลดงานฝั่งเทคนิคได้ระดับหนึ่งตามการตั้งค่าที่เปิดใช้งานจริง แต่การออกแบบว่าแต่ละแคมเปญควรตั้ง Identifier แบบไหนยังเป็นงานที่ทีมการตลาดต้องวางแผนเอง

สรุป

ปัญหา Lead ปนกันเมื่อเปิดหลาย Landing Page พร้อมกันแก้ได้ด้วยการกำหนด Identifier เฉพาะให้แต่ละหน้าตั้งแต่ต้น แล้วออกแบบให้พารามิเตอร์นั้นเดินทางไปถึง LIFF ได้จริงโดยไม่หายระหว่างทาง

ควรยอมรับว่าจะมีสัดส่วนหนึ่งที่ไม่ทราบที่มาแน่นอนเสมอ และไม่ควรเดาปนเข้ากับแคมเปญใดแคมเปญหนึ่ง เพราะจะทำให้การตัดสินใจเรื่องงบผิดพลาดตามไปด้วย

• กำหนด Identifier เฉพาะให้ทุก Landing Page ก่อนพาไป LIFF ไม่ใช้ลิงก์เปล่า
• ใช้หน้าคั่นกลางหรือ Token เพื่อรักษาความต่อเนื่องของข้อมูลระหว่างเว็บกับแอป LINE
• แยกรายงานตาม Landing Page ทุกสัปดาห์ในช่วงแรก และแยกกลุ่ม ‘ไม่ทราบที่มา’ ออกต่างหาก

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