ทักเข้ามาเยอะทุกวันแต่ไล่ไม่ทันว่าใครมาจากแคมเปญไหน แก้ยังไง

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

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

บทความนี้จะพาดูว่า LINE Messaging API Tracking ควรวางโครงสร้างยังไง ตั้งแต่การผูก Identifier ต้นทาง ไปจนถึงการอ่านรายงานที่แยกตามแคมเปญได้จริง ไม่ใช่แค่รู้ยอดแชทรวมทั้งหมดแบบเดิม

LINE Messaging API คืออะไร และไม่ใช่อะไร

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

สิ่งที่ Messaging API ไม่ใช่คือระบบ Tracking ที่รู้ที่มาของแคมเปญให้อัตโนมัติ มันแค่ส่งข้อมูลดิบอย่าง User ID เนื้อหาข้อความ และเวลามาให้ ส่วนการจะรู้ว่า User ID นั้นมาจากแคมเปญไหน ต้องอาศัยการออกแบบและเชื่อมข้อมูลเพิ่มเติมจากฝั่งธุรกิจเองทั้งหมด

ออกแบบ Identifier ให้ผูกตั้งแต่ต้นทางถึง User ID

จุดเริ่มต้นคือต้องมี Identifier เฉพาะให้แต่ละแคมเปญตั้งแต่ Landing Page หรือ LIFF ตามแนวทางที่ใกล้เคียงกับการวางระบบรองรับหลายแคมเปญใน LIFF แล้วเก็บ Identifier นี้ไว้ในช่วงที่ผู้ใช้ยังไม่เป็นเพื่อน เพื่อผูกเข้ากับ User ID ที่ได้ตอนเกิด Follow Event หรือ Message Event แรกจาก Messaging API

จุดที่ทีมมักพลาดคือรอผูก Identifier ตอนที่ User ID ส่งข้อความเข้ามาแล้วเท่านั้น ทั้งที่ในความเป็นจริงต้องเตรียมการเชื่อมโยงนี้ไว้ตั้งแต่ก่อนผู้ใช้เพิ่มเพื่อน ไม่เช่นนั้นจะมีช่วงเวลาที่ข้อมูลขาดหายจนผูกย้อนหลังไม่ได้ โดยเฉพาะถ้าผู้ใช้ปิดแอปไปนานก่อนจะทักข้อความแรก

แยกรายงานตามแคมเปญให้อ่านง่ายขึ้น

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

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

ตัวอย่างรายงานแยกตามแคมเปญ (ตัวอย่างสมมติ)

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

ลำดับตั้งค่า LINE Messaging API Tracking ให้ใช้งานได้จริง

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

1. กำหนด Identifier เฉพาะให้ทุกแคมเปญตั้งแต่ Landing Page หรือ LIFF ก่อนพาไปเพิ่มเพื่อน
2. เก็บ Identifier นี้ไว้ชั่วคราวในระบบหลังบ้าน รอผูกกับ User ID ที่ได้จาก Follow Event หรือ Message Event แรก
3. ตั้ง Webhook รับทั้ง Follow Event และ Message Event ผ่าน Messaging API แล้วผูก User ID เข้ากับ Identifier ที่เก็บไว้
4. ออกแบบรายงานให้แยกตามแคมเปญ ไม่ใช่ดูแค่ยอดรวมของ LINE OA เดียว
5. ทดสอบเส้นทางทั้งหมดด้วยบัญชีทดสอบก่อนเปิดงบจริง เพื่อยืนยันว่า Identifier ผูกกับ User ID ถูกต้องทุกครั้ง

โครงสร้าง Event จริงจาก Messaging API ที่ต้องอ่านให้เป็น

ทุก Event ที่ Messaging API ส่งเข้ามาทาง Webhook มีฟิลด์ชุดเดียวกันที่ต้องรู้จักก่อนจะออกแบบการผูก Identifier ได้ถูก เริ่มจาก `type` ที่บอกว่าเป็น Event ประเภทไหน เช่น `message`, `follow`, `unfollow` หรือ `postback` ตามด้วย `source.userId` ซึ่งเป็น User ID เฉพาะตัวของผู้ใช้คนนั้นในบริบทของ LINE OA นั้น ๆ ไม่ใช่ ID กลางที่ใช้ข้าม OA ได้ ถ้าเป็น Event ประเภทข้อความจะมี `message.id` และ `message.text` แนบมาด้วย ส่วน `timestamp` บอกเวลาที่ Event เกิดขึ้นเป็น Unix time มิลลิวินาที

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

ตัวอย่าง Payload ของ Message Event ที่ Messaging API ส่งมาจริงจะมีหน้าตาประมาณนี้ ซึ่งทีมพัฒนาควรเก็บ `source.userId` คู่กับ `webhookEventId` ไว้ในตารางแยกต่างหากทุกครั้งก่อนเริ่มผูกกับ Identifier ต้นทาง:

ตัวอย่างโค้ดผูก Identifier จากฟิลด์ใน Event จริง

ตัวอย่างด้านล่างจำลอง Payload จริงของ Message Event หนึ่งรายการ และวิธีดึงฟิลด์ที่จำเป็นออกมาเพื่อผูกกับ Identifier ที่เก็บไว้ตั้งแต่ก่อนผู้ใช้เพิ่มเพื่อน โค้ดฝั่งรับ Webhook ควรเช็ค `deliveryContext.isRedelivery` ก่อนเสมอ ถ้าเป็น true และมี `webhookEventId` ซ้ำกับที่เคยบันทึกแล้ว ให้ตอบ HTTP 200 กลับไปทันทีโดยไม่ประมวลผลซ้ำ

ทำแบบนี้แล้วพัง เพราะ… เคสนับ Lead ซ้ำจน Conversion เพี้ยนทั้งเดือน

ทีมหนึ่งตั้ง Webhook รับ Message Event แล้วบันทึกทุก Event ที่เข้ามาลงฐานข้อมูลทันทีโดยไม่เช็ค `webhookEventId` ซ้ำเลย ปกติไม่มีปัญหาเพราะเซิร์ฟเวอร์ตอบ HTTP 200 กลับให้ LINE เร็วพอ แต่ในช่วงที่เซิร์ฟเวอร์โหลดสูงจากแคมเปญโปรโมชันใหญ่ การตอบกลับช้าเกินเวลาที่ LINE รอ ทำให้ LINE ส่ง Event เดิมซ้ำมาอีกครั้งพร้อม `deliveryContext.isRedelivery` เป็น true ระบบที่ไม่เช็คฟิลด์นี้จึงบันทึกเป็น Lead ใหม่อีกรายการ ทำให้ยอดคนทักของวันนั้นพองขึ้นเกือบ 20% เมื่อเทียบกับยอดจริงที่นับจากแดชบอร์ดของ LINE OA เอง

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

ข้อจำกัดที่ยังต้องยอมรับ แล้วก้าวต่อไปควรทำอะไร

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

เมื่อแยกรายงานตามแคมเปญได้แล้ว ขั้นต่อไปที่ควรทำคือเชื่อมข้อมูลนี้ต่อไปถึง Order และยอดขายจริง ไม่ใช่หยุดแค่ระดับ Lead ระบบอย่าง linli ช่วยในส่วนของการเก็บ Identifier ต่อจากแคมเปญเข้า LINE และผูกกับ User ID ที่ได้จาก Messaging API ในระดับหนึ่งตามการตั้งค่าที่เปิดใช้งาน แต่การออกแบบว่าแต่ละแคมเปญควรตั้ง Identifier แบบไหน และการอ่านรายงานเพื่อตัดสินใจเรื่องงบ ยังเป็นงานที่ทีมการตลาดหรือเอเจนซี่ต้องทำต่อเนื่อง ควบคู่กับการดูภาพรวมตั้งแต่ Add Friend ไปจนถึง Lead

สรุป

LINE Messaging API เป็นแค่สะพานเชื่อมข้อมูลระหว่างระบบธุรกิจกับ LINE ไม่ได้ผูกที่มาของแคมเปญให้อัตโนมัติ ธุรกิจที่ยิงหลายแคมเปญพร้อมกันต้องออกแบบ Identifier ตั้งแต่ต้นทางเพื่อผูกกับ User ID ที่ได้จาก API เอง ถึงจะไล่ได้ว่าแชทแต่ละวันมาจากแคมเปญไหน

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

• LINE Messaging API รับส่งข้อมูลได้ แต่ไม่ผูกที่มาของแคมเปญให้อัตโนมัติ
• ต้องออกแบบ Identifier ตั้งแต่ต้นทางแคมเปญให้ผูกกับ User ID ก่อนผู้ใช้เพิ่มเพื่อน
• แยกรายงานตามแคมเปญเพื่อเห็นว่าแคมเปญไหนปริมาณมากแต่คุณภาพต่ำ หรือปริมาณน้อยแต่ปิดการขายได้ดีกว่า

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