ปุ่มใน Flex Message ควรใช้ Postback หรือ URL ถ้าอยากรู้ว่าใครกดอะไร

สมมติร้านส่ง Flex Message โปรโมชันหาลูกค้า 3,000 คน มีสามปุ่มคือ ‘ดูโปร’ ‘จองคิว’ ‘คุยกับแอดมิน’ และตั้งทั้งสามเป็นลิงก์ URL หมด วันรุ่งขึ้นหัวหน้าทีมขายถามว่า ‘ใครกดจองคิวบ้าง จะได้โทรตาม’ หน้าสถิติบอกได้แค่ว่าปุ่มนี้ถูกกด 212 ครั้ง ไม่บอกว่าใคร

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

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

ปุ่มใน Flex Message ทำอะไรได้สามแบบ และทิ้งร่องรอยต่างกัน

ตารางสรุปปุ่มที่ใช้บ่อยสามแบบ ยังมีชนิดอื่นอยู่อีก (เช่นตัวเลือกวันเวลา) ซึ่งชนิดและฟิลด์ที่รองรับให้ตรวจกับสเปก Messaging API ฉบับล่าสุดก่อนออกแบบ

ออกแบบ data ของ Postback ให้ยังอ่านออกในหกเดือนข้างหน้า

ฟิลด์ data คือข้อความที่คุณฝังไว้ในปุ่ม แล้วส่งกลับมาตรง ๆ เมื่อกด ความยาวสูงสุดมีเพดาน ตรวจตัวเลขล่าสุดในเอกสาร จึงควรสั้นและมีรูปแบบคงที่ ผมใช้คู่ key=value ต่อกันด้วย & ตามตัวอย่างสมมติ a=book&c=nov_promo&b=2&v=1

• a คือการกระทำที่ลูกค้าต้องการ เช่น book, quote, talk ตั้งเป็นคำสั้นที่ทีมอ่านแล้วเข้าใจตรงกัน
• c คือแคมเปญหรือรหัสบรอดแคสต์ เพื่อให้แยกโปรเดือนนี้ออกจากเดือนก่อน
• b คือตำแหน่งปุ่มในการ์ด ใช้เทียบว่าปุ่มบนหรือล่างถูกกดมากกว่า
• v คือเวอร์ชันของดีไซน์ ถ้าเปลี่ยนรูปแบบ data ในอนาคต ตัวนี้บอกให้ฝั่งรับรู้ว่าต้องอ่านแบบไหน

ปุ่ม Postback ที่กดแล้วไม่มีอะไรเกิดขึ้น ทำให้ลูกค้ากดซ้ำ

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

แก้สองชั้น ชั้นแรกให้ฝั่งรับตอบกลับทันทีด้วยข้อความยืนยัน เช่น ‘รับคิวแล้ว เดี๋ยวแอดมินทักเรื่องวันเวลา’ โดย reply token ใช้ได้ครั้งเดียวและหมดอายุเร็ว ตรวจรายละเอียดในเอกสาร ชั้นที่สองให้ตัดซ้ำที่ฝั่งเก็บข้อมูล นับ userId กับ data เดียวกันที่เข้ามาในช่วงสั้น ๆ เป็นหนึ่งครั้ง รายละเอียด event อยู่ในการติดตาม postback ผ่าน webhook

ปุ่ม URL วัดได้ถ้าลิงก์พกตัวตนไปด้วย

1. ใส่ utm และรหัสปุ่มลงในลิงก์ เช่น utm_content=btn2_book วิธีตั้งชื่อให้ไม่ยุ่งอยู่ในการสร้าง URL ติดตาม
2. ถ้าส่งข้อความเดียวกันให้ทุกคน ลิงก์จะเท่ากันทุกคน จึงวัดได้ระดับกลุ่มเท่านั้น ถ้าต้องรู้รายคน ให้เปิดผ่านหน้า LIFF ที่อ่าน userId ของคนกดได้ ดูวิธีในการวัดคลิกผ่าน LIFF
3. ทางเลือกสุดท้ายคือส่งแยกรายคนพร้อมลิงก์เฉพาะ แต่การส่งแยกอาจนับโควตาข้อความตามจำนวนที่ส่ง ตรวจเงื่อนไขนับของแผนบัญชีคุณก่อนตัดสินใจ
4. ให้หน้าตัวกลางจดคลิกลงฐานข้อมูลก่อนส่งต่อ (redirect) แล้วค่อยพาไปปลายทาง วิธีนี้ทำให้ได้ตัวเลขคลิกของคุณเอง ไม่ต้องพึ่งหน้าสถิติของแพลตฟอร์มอย่างเดียว

เลือกชนิดปุ่มตามปลายทางของมัน

• จองคิว ขอใบเสนอราคา ปลายทางอยู่ในแชท ใช้ Postback แล้วให้แอดมินหรือบอตตอบต่อ ได้ userId มาครบ
• ดูสินค้าหรือโปรบนเว็บ ปลายทางอยู่นอกแชท ใช้ URI ที่ผ่านหน้ากลางจดการกด
• ถามคำถามที่เจอบ่อย ใช้ Message เพราะลูกค้าเห็นว่าตัวเองถามอะไร และคำถามค้างอยู่ในประวัติแชท
• โทรหาร้าน ใช้ลิงก์โทรศัพท์ การวัดจะต้องไปดูฝั่งสายเข้า ซึ่งแอดแยกให้ไม่ได้ ดูแนวคิดในการแท็กแชทเพื่อบันทึกว่าใครมาจากช่องทางไหน

ต่อ Postback เข้ากับยอดขายด้วย userId

เก็บทุก postback ลงตารางพร้อม userId, data และเวลา จากนั้นเทียบกับใบสั่งซื้อด้วย userId ตัวอย่างสมมติ ส่งโปร 3,000 คน ปุ่มจองคิวถูกกดโดย 210 คน ในนั้น 90 คนคุยต่อกับแอดมิน และ 40 คนจองจริง ตัวเลขชุดนี้ตอบหัวหน้าทีมขายได้ว่าควรโทรตามใคร คือ 120 คนที่กดแล้วไม่คุยต่อ

สรุป

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

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

• Postback ให้ userId และ data รายคน URI ไม่ส่งอะไรกลับ
• ออกแบบ data เป็นรูปแบบคงที่ มีแคมเปญ ตำแหน่งปุ่ม และเวอร์ชัน
• ตอบยืนยันทันทีหลัง Postback และตัดซ้ำที่ฝั่งเก็บข้อมูล
• ปุ่ม URI ต้องพกรหัสหรือผ่าน LIFF จึงจะวัดรายคนได้
• เทียบ userId ของคนกดกับใบสั่งซื้อ เพื่อบอกได้ว่าปุ่มไหนพาไปถึงยอด

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