LINE Pixel ไม่ยิง Event เลยสักตัว: ไล่ดีบักทีละชั้นก่อนจะโทษระบบ
สรุปสั้น ๆ
ถ้ายอด Conversion จาก LINE OA เป็นศูนย์ทั้งกระดาน ปัญหาแทบไม่เคยอยู่ที่ ‘ระบบพัง’ แต่อยู่ที่จุดใดจุดหนึ่งใน 5 จุดที่เจอบ่อย — token หมดอายุ, webhook URL เปลี่ยนไม่อัปเดต, event schema ผิด, env variable หลุดหลัง deploy หรือโดน rate limit ไล่ทีละจุดตามลำดับ อย่าเดาสุ่ม
ลูกค้าเอเจนซี่รายหนึ่งส่งข้อความมาหาผมตอนเช้าวันจันทร์ว่า ‘พี่ครับ สัปดาห์ที่แล้วแอดมินปิดออเดอร์ในไลน์ไป 40 กว่าเคส แต่เปิด Ads Manager มาดู Conversion ขึ้นเลข 0 มา 9 วันติดกัน โฆษณาที่เคย optimize ได้ดีจู่ ๆ ก็แพงขึ้นทุกวัน’ ผมถามกลับไปคำแรกว่า ‘0 ทั้งหมดเลยไหม หรือมีบ้างแต่น้อยผิดปกติ’ เพราะคำตอบของคำถามนี้บอกทิศทางการไล่บั๊กได้เกินครึ่งแล้ว
หลายคนเจออาการแบบนี้แล้วรีบสรุปว่า ‘ระบบ tracking พังทั้งระบบ’ ทั้งที่ในทางเทคนิค event ไม่ได้ ‘พัง’ แบบเหวี่ยงแหเสมอไป ส่วนใหญ่มันหยุดที่จุดเล็ก ๆ จุดเดียวในเส้นทางที่ event ต้องเดินผ่าน แล้วจุดนั้นก็บล็อกทุกอย่างที่ตามมาเงียบ ๆ โดยไม่มี error แจ้งใครเลย
บทความนี้จะพาไล่ทีละชั้นแบบที่ผมใช้จริงกับลูกค้ารายนั้น ตั้งแต่เข้าใจก่อนว่า event เดินทางผ่านจุดไหนบ้าง ไปจนถึง 6 ขั้นตอนดีบักที่ทำเองได้โดยไม่ต้องรอทีมเทคนิค
ก่อนไล่บั๊ก ต้องรู้ก่อนว่า Event เดินทางผ่านจุดไหนบ้าง
คำว่า ‘pixel’ ที่ใช้เรียกกันติดปากมาจากยุคที่ต้องฝังโค้ด JavaScript ไว้บนหน้าเว็บ แต่ LINE OA เป็นแชทในแอป ไม่มีหน้าเว็บให้ฝังโค้ดแบบนั้น สิ่งที่ยิง event จริง ๆ จึงเป็นการเรียกจากฝั่งเซิร์ฟเวอร์ผ่าน การส่งข้อมูลแบบ server-to-server ไม่ใช่โค้ดที่วิ่งอยู่ในเบราว์เซอร์ของลูกค้า
เส้นทางคร่าว ๆ คือ: แอดมินปิดการขายในแชท → ระบบหลังบ้านแท็กว่านี่คือ conversion → ยิง request ไปหา Conversion API ของ Meta/Google → ปลายทางรับ, ตรวจสอบ token และ schema, แล้วบันทึกเป็น event ที่เห็นใน Ads Manager จุดไหนในเส้นทางนี้สะดุด event ทั้งหมดที่ตามมาก็หายไปเงียบ ๆ ไม่มีป็อปอัปแจ้งเตือนใคร
5 จุดที่เป็นต้นตอบ่อยที่สุดตอน Event เงียบทั้งกระดาน
จากเคสที่เจอมา อาการ ‘0 ทั้งหมด’ มักไม่ได้มาจากหลายสาเหตุพร้อมกัน แต่มาจากจุดใดจุดหนึ่งใน 5 จุดนี้:
- Access token หมดอายุแบบไม่มีแจ้งเตือน — token บางประเภทมีอายุจำกัดและไม่มี pop-up เตือนล่วงหน้า วันที่หมดอายุคือวันที่ event หายทันที (อ่านเพิ่มเรื่องtoken หมดอายุ)
- Webhook URL เปลี่ยนแต่ลืมอัปเดตใน LINE Developers Console — เจอบ่อยหลังย้ายเซิร์ฟเวอร์หรือเปลี่ยน domain แล้วลืมไปตั้งค่าใหม่ในฝั่ง LINE
- Event ไม่ตรง schema ที่ปลายทางต้องการ — เช่นขาด field บังคับ หรือส่งรูปแบบวันที่ผิด ปลายทางจะ reject เงียบ ๆ โดยไม่มี error โผล่ที่หน้าจอผู้ใช้
- Deploy โค้ดใหม่แล้วลืมตั้งค่า environment variable บน production — โค้ดรันได้ปกติบนเครื่อง dev แต่บน production ไม่มี key ที่ต้องใช้ ทำให้ทุก request เงียบพร้อมกันทันทีหลัง deploy
- โดน rate limit เพราะยิง event ผิดจังหวะซ้ำ ๆ — เกิดจากบั๊กที่ทำให้ระบบยิง event เดิมซ้ำถี่เกินไปจนปลายทางเริ่มบล็อกชั่วคราว
ไล่ดีบัก 6 ขั้น ก่อนจะสรุปว่า ‘ระบบพัง’
ลำดับนี้เรียงจากจุดที่เช็คง่ายและถูกที่สุดไปหายาก อย่าข้ามขั้นแรก ๆ เพราะบางทีสาเหตุมันตื้นกว่าที่คิดมาก:
- เช็ค log ฝั่งเซิร์ฟเวอร์ก่อนว่ามีการยิง request ออกไปจริงไหม ถ้าไม่มี log เลย ปัญหาอยู่ที่ต้นทางไม่ใช่ปลายทาง
- เช็ค response code ที่ได้กลับมาให้ละเอียด อย่าดูแค่ว่ามี response — code 200 บางกรณีก็ยังแปลว่า ‘รับแล้วแต่ปฏิเสธข้อมูล’ ไม่ใช่ ‘สำเร็จ’ เสมอไป
- เปิดtest event toolของปลายทางแล้วยิง event ทดสอบดูสด ๆ เพื่อตัดว่าปัญหาอยู่ที่การตั้งค่าฝั่งเรา หรืออยู่ที่ปลายทางจริง ๆ
- เทียบ timestamp ของ event ที่ยิงออกไป กับเวลาที่ปิดการขายจริงในแชท ถ้าห่างกันผิดปกติ อาจมีคิวค้างอยู่ระหว่างทาง
- เช็คว่า token/permission ที่ผูกกับ integration นี้ยังใช้งานได้อยู่ ไม่ expired และยังมีสิทธิ์ระดับที่ส่ง conversion event ได้
- ลองยิง event ทดสอบหนึ่งตัวแบบ manual จากปลายทาง (ไม่ผ่านระบบอัตโนมัติ) เพื่อตัดตัวแปรว่าปัญหาอยู่ที่ ‘โค้ดที่เขียนไว้’ หรือ ‘การตั้งค่าบัญชี’
อาการที่เห็น เทียบกับจุดที่ควรเช็คก่อน
| อาการที่เห็น | จุดที่ควรเช็คก่อน | ความเร่งด่วน |
|---|---|---|
| Conversion เป็น 0 ทันทีทุกอีเวนต์ | Token หมดอายุ / Webhook URL ผิด | สูง |
| Conversion หายเป็นบางช่วงเวลา | Rate limit หรือคิวล้น | กลาง |
| ขึ้นบางแพลตฟอร์ม ไม่ขึ้นอีกแพลตฟอร์ม | Event schema เฉพาะปลายทางนั้น ๆ | กลาง |
| หายทันทีหลัง deploy โค้ดใหม่ | Environment variable หลุดบน production | สูง |
กันไม่ให้เงียบซ้ำแบบไม่รู้ตัวอีก
ปัญหาของเคสแบบนี้ไม่ใช่แค่ ‘มันพังตอนไหน’ แต่คือ ‘กว่าจะรู้ว่ามันพังใช้เวลากี่วัน’ ลูกค้าที่ผมเล่าถึงตอนต้นกว่าจะสังเกตได้ก็ปาไป 9 วัน เท่ากับงบโฆษณาเกือบสองสัปดาห์ optimize บนสัญญาณเปล่า
ทางที่ผมแนะนำเสมอคือตั้งการแจ้งเตือนแบบง่าย ๆ เทียบยอด conversion รายวันกับยอดปิดการขายจริงในแชท ถ้าห่างกันเกินเกณฑ์ที่ตั้งไว้ให้แจ้งทันที ไม่ต้องรอให้ทีมขายมาบ่นว่าโฆษณาแพงขึ้นก่อนถึงจะรู้ตัว เพราะตอนนั้นมักสายไปแล้วหลายวัน
สรุป
ตัวเลข 0 ที่เห็นใน Ads Manager แทบไม่เคยหมายความว่า ‘ระบบพังทั้งหมด’ มันมักหมายถึง ‘มีจุดเดียวในเส้นทางที่สะดุด’ และจุดนั้นบล็อกทุกอย่างที่ตามมาแบบเงียบ ๆ
สิ่งที่ทำให้ทีมเสียเวลาที่สุดไม่ใช่การแก้บั๊ก แต่คือการเดาสุ่มว่าปัญหาอยู่ตรงไหนโดยไม่มีลำดับการเช็คที่ชัดเจน ถ้าไล่ตามขั้นตอนอย่างมีระบบ ส่วนใหญ่หาต้นตอเจอภายในไม่กี่ชั่วโมง ไม่ใช่หลายวัน
- อาการ 0 ทั้งกระดานมักมาจากจุดเดียว ไม่ใช่หลายจุดพร้อมกัน
- ไล่จากจุดเช็คง่ายที่สุดก่อนเสมอ (log, response code) ก่อนไปจุดที่ซับซ้อนกว่า
- response 200 ไม่ได้แปลว่าสำเร็จเสมอไป ต้องอ่าน body ประกอบ
- ตั้งแจ้งเตือนเทียบยอดจริงกับยอดที่ระบบยิง อย่ารอให้ทีมขายมาบ่นก่อน
คำถามที่พบบ่อย
Pixel ของ LINE คืออะไรกันแน่ ในเมื่อไม่มีโค้ดฝังหน้าเว็บแบบ Facebook Pixel
เป็นคำเรียกติดปากที่สืบทอดมาจากยุค browser pixel จริง ๆ แล้วสิ่งที่ทำงานอยู่คือการส่งข้อมูล conversion จากเซิร์ฟเวอร์ไปหาแพลตฟอร์มโฆษณาโดยตรง ไม่ได้พึ่งโค้ดที่รันในเบราว์เซอร์ของลูกค้าเลย
เช็คยังไงว่า event หายเพราะ token หมดอายุ ไม่ใช่เพราะแพลตฟอร์มปลายทางบล็อก
ดูที่ response code และข้อความ error ที่เซิร์ฟเวอร์บันทึกไว้ตอนยิง request ถ้าเป็นเรื่อง token มักได้ error เกี่ยวกับสิทธิ์การเข้าถึงหรือหมดอายุตรง ๆ ต่างจากกรณีถูกบล็อกที่มักมาพร้อมข้อความเกี่ยวกับ rate limit หรือ policy
ทำไม response code 200 แล้ว event ก็ยังไม่ขึ้นใน Ads Manager
code 200 บอกแค่ว่าปลายทาง ‘รับคำขอถึงแล้ว’ ไม่ได้แปลว่า ‘บันทึกสำเร็จ’ เสมอไป บาง API ตอบ 200 พร้อม error body ที่บอกว่าปฏิเสธข้อมูลเพราะ schema ไม่ตรง ต้องอ่าน response body ทั้งก้อน ไม่ใช่ดูแค่ status code
ควรตั้งการแจ้งเตือนแบบไหนถึงจะทันเวลา ไม่ต้องรอให้เห็นด้วยตาเปล่า
เทียบยอด conversion ที่ระบบยิงออกไป กับยอดปิดการขายจริงในแชทเป็นรายวัน ถ้าห่างกันเกินเกณฑ์ที่ยอมรับได้ให้ส่งแจ้งเตือนอัตโนมัติทันที การรอสังเกตด้วยตาในแดชบอร์ดมักช้าเกินไปหลายวัน
แพลตฟอร์มแบบ linli ช่วยเรื่องนี้ตรงไหน
ช่วยให้เห็นสถานะการส่ง event และ log ของแต่ละ request ในที่เดียว แทนที่จะต้องไล่ดู log กระจายอยู่หลายระบบ ทำให้หาจุดที่สะดุดได้เร็วขึ้น แต่ยังต้องมีคนตรวจสอบและตัดสินใจแก้ไขตามขั้นตอนอยู่ดี
ถ้า event หายไปแล้วหลายวัน ย้อนส่งย้อนหลังได้ไหม
แพลตฟอร์มโฆษณาส่วนใหญ่รับข้อมูลย้อนหลังได้ในกรอบเวลาจำกัด (มักไม่เกินไม่กี่วันถึงสัปดาห์ ขึ้นกับแต่ละแพลตฟอร์ม) ควรรีบส่งทันทีที่พบปัญหา แต่ต้องเข้าใจว่าช่วงที่ optimize ผิดพลาดไปแล้วจะย้อนแก้ผลกระทบด้านการเรียนรู้ของอัลกอริทึมไม่ได้เต็มร้อย
บทความที่เกี่ยวข้อง
