LINE Pixel ไม่ยิง Event เลยสักตัว ไล่ดีบักทีละชั้นก่อนจะโทษระบบดีกว่า

ทีมบรรณาธิการ linli12 ก.ค. 04:23อัปเดต 12 ก.ค. 04:23อ่าน 3 นาที

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

สรุปสั้น ๆ

ถ้ายอด 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 ผิดพลาดไปแล้วจะย้อนแก้ผลกระทบด้านการเรียนรู้ของอัลกอริทึมไม่ได้เต็มร้อย

อ่านต่อแบบเจาะลึก

รู้ว่าโฆษณาเข้า LINE ทำยอดขายจริงแค่ไหน

linli ติดตามลูกค้าตั้งแต่คลิกโฆษณา กดเพิ่มเพื่อน ทักแชท จนปิดการขาย พร้อมส่ง Conversion กลับแพลตฟอร์มโฆษณา เริ่มฟรี 14 วัน

ทดลองใช้ฟรี 14 วัน