ยิงแอดไปเว็บ แต่ Tag ไม่ยิง Event กลับ Ads Manager ตอนกดปุ่ม LINE วิธี Debug ทำยังไง

มีเคสคลาสสิกที่ผมเจอเวอร์ชันต่าง ๆ ซ้ำแล้วซ้ำเล่า: เจ้าของธุรกิจโทรมาเสียงเครียด ‘แอดไม่เวิร์กเลย ยิงมาสองอาทิตย์ conversion เป็นศูนย์’ พอถามว่าแล้วมีคนทักไลน์เพิ่มไหม — ‘มีนะ วันละสิบกว่าคน ปิดยอดได้ด้วย’ … นั่นไม่ใช่แอดไม่เวิร์ก นั่นคือแอดเวิร์กแต่คนวัดตาบอด เพราะ tag ที่ควรรายงานเหตุการณ์ ‘คนกดปุ่มไป LINE’ กลับไม่เคยส่งอะไรกลับไปเลย

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

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

บันไดสี่ขั้น: ไล่จากตื้นไปลึก อย่าข้ามขั้น

1. ขั้นที่ 1 — tag อยู่บนหน้าจริงไหม: เปิดหน้าเว็บที่แอดพาไป ใช้เครื่องมือตรวจของแต่ละค่าย (Meta Pixel Helper, Google Tag Assistant) ดูว่า tag พื้นฐานโหลดขึ้นหรือเปล่า ถ้าไม่ขึ้นเลย จบตรงนี้ — มักเป็นเพราะติด tag ไว้คนละหน้า/คนละโดเมนกับที่แอดพาไปจริง หรือธีม/ปลั๊กอินอัปเดตแล้วโค้ดหาย
2. ขั้นที่ 2 — trigger ยิงตอนกดปุ่มไหม: เปิดโหมด debug (เช่น Preview ใน Tag Manager) แล้วกดปุ่มทัก LINE เองจริง ๆ ดูว่า event ที่ตั้งไว้เด้งขึ้นไหม จุดนี้คือที่ที่เคสส่วนใหญ่ตาย — ปุ่มถูกเปลี่ยน id/class ตอนแก้เว็บ, trigger ตั้งเงื่อนไขผูกกับ URL เก่า, หรือปุ่มเป็น element ที่โหลดทีหลังทำให้ตัวจับคลิกหาไม่เจอ
3. ขั้นที่ 3 — event เดินทางถึงปลายทางไหม: เปิด Events Manager / รายงาน conversion ฝั่งแพลตฟอร์ม ใช้เครื่องมือ test events ยิงทดสอบจากเครื่องตัวเอง ถ้าขั้น 2 ผ่านแต่ขั้นนี้ไม่ถึง ผู้ต้องสงสัยคือ ad blocker/เบราว์เซอร์บล็อก, ระบบ consent ที่กั้น tag ไว้จนกว่าจะกดยอมรับ (แล้วผู้ใช้ส่วนใหญ่ไม่กด), หรือ event ถูกส่งไป pixel id ผิดตัว — เช็ก id ให้ตรงตัวอักษรต่อตัวอักษร
4. ขั้นที่ 4 — แคมเปญมองเห็น event นั้นไหม: event มาถึงแล้วแต่แคมเปญนับศูนย์ มักเพราะชื่อ event ไม่ตรงกับที่แคมเปญตั้งเป้าไว้ (ยิง ‘click_line’ แต่แคมเปญรอ ‘Lead’), event ยังไม่ถูก verify/จัดลำดับความสำคัญตามที่แพลตฟอร์มกำหนด, หรือหน้าต่างเวลารายงานคนละช่วงกัน เทียบชื่อและการตั้งค่าเป้าหมาย conversion ของแคมเปญกับ event จริงให้ตรงกันเป๊ะ

แฟ้มผู้ต้องสงสัยยอดฮิต เรียงจากเจอบ่อยสุด

• เว็บถูกแก้แล้วไม่มีใครบอกคนดูแล tag — เปลี่ยนธีม เปลี่ยนปุ่ม ย้ายหน้า แล้ว trigger ที่ผูกกับ id/URL เดิมตายเงียบ เคสอันดับหนึ่งตลอดกาล ทางกันคือกติกาทีม: แก้เว็บเมื่อไหร่ ทดสอบ tag เมื่อนั้น
• ปุ่ม LINE เป็นลิงก์ออกนอกเว็บทันที — บางเว็บทำปุ่มเป็น redirect ตรง เบราว์เซอร์ออกจากหน้าก่อน tag ส่งข้อมูลทัน ต้องตั้งการส่งแบบรอ (หรือ beacon) ให้ event ออกก่อนหน้าเปลี่ยน
• Consent banner กั้นไว้ — ตั้งระบบขอความยินยอมแบบเข้มจน tag ไม่ทำงานกับผู้ใช้เกือบทั้งหมด เจตนาดีแต่ตั้งค่าผิดสมดุล ตรวจว่าหมวด tag การตลาดถูกปล่อยเมื่อผู้ใช้ยอมรับจริง
• ทดสอบจากเครื่องที่มองไม่เห็นตัวเอง — นักการตลาดทดสอบด้วยเบราว์เซอร์ที่ลง ad blocker ไว้เอง แล้วสรุปว่า tag พัง ทั้งที่ผู้ใช้จริงยิงปกติ เช็กจากหลายเครื่อง/หลายเครือข่ายก่อนตัดสิน
• หลาย tag ตีกันเอง — ติดทั้งโค้ดตรงและผ่าน Tag Manager ซ้ำซ้อน event เบิ้ลบ้าง หายบ้าง ระบบ dedup งง จัดบ้านให้เหลือทางเดินเดียวต่อแพลตฟอร์ม

แก้ที่เบราว์เซอร์อย่างเดียวไม่พอ: เพดานของ tag ฝั่งหน้าบ้าน

ต่อให้ debug จนเขียวทุกขั้น tag ฝั่งเบราว์เซอร์ก็มีเพดานของมัน — ad blocker, การจำกัด cookie ของเบราว์เซอร์ยุคใหม่, และ iOS ที่ตัดการติดตามข้ามแอป ทำให้ event หายไปส่วนหนึ่งเสมอโดยที่ไม่มีอะไร ‘พัง’ ให้แก้ นี่คือเหตุผลที่การวัดสาย server-side โตขึ้นเรื่อย ๆ: เหตุการณ์ถูกส่งจากเซิร์ฟเวอร์ของเราไปยังแพลตฟอร์มตรง ๆ ไม่ผ่านเบราว์เซอร์ที่ถูกบล็อกได้ แนวคิดเต็ม ๆ อยู่ในเรื่องการส่ง conversion แบบ server-to-server

สำหรับธุรกิจที่ปิดการขายใน LINE มีมุมได้เปรียบซ้อนอยู่: เหตุการณ์ที่มีค่าที่สุดของคุณ (เพิ่มเพื่อน ทักแชท ปิดดีล) เกิดหลังพ้นเบราว์เซอร์ไปแล้ว ซึ่งวัดจากฝั่งระบบแชทได้ตรง ๆ โดยไม่ง้อ tag หน้าเว็บเลย ระบบวัดผลที่ผูกคลิกเข้ากับตัวตน LINE อย่าง linli จึงทำหน้าที่เป็นแหล่งความจริงสำรองที่ ad blocker แตะไม่ถึง — เว็บ tag ไว้ใช้สอนอัลกอริทึม ส่วนตัวเลขจริงของธุรกิจอ่านจากฝั่งแชทเสมอ แล้วเทียบสองแหล่งกันเป็นระยะเพื่อดูว่าช่องว่างระหว่างคลิกกับคนถึง LINE จริงกว้างแค่ไหน

แก้แล้วอย่าให้กลับมาพังเงียบ: วินัยสามข้อ

ข้อแรก ทำ ‘คู่มือทดสอบห้านาที’ ของเว็บตัวเอง — ลิสต์ปุ่มสำคัญทุกจุด วิธีเปิด debug และหน้าตาที่ควรเห็นเมื่อปกติ ให้ใครในทีมก็ทำได้ ไม่ต้องรอคนเทคนิค ข้อสอง ผูกการทดสอบเข้ากับทุกการแก้เว็บ — กติกาเดียวสั้น ๆ: แตะเว็บเมื่อไหร่ รันคู่มือห้านาทีก่อนปิดงาน สาเหตุอันดับหนึ่งของ tag ตายคือการแก้เว็บที่ไม่มีใครตามทดสอบ

ข้อสาม ตั้งสัญญาณเตือนจากตัวเลข — ไม่ต้องมีระบบมอนิเตอร์หรู แค่ดูกราฟ event รายวันในแพลตฟอร์มสัปดาห์ละครั้ง ถ้า event ตกดิ่งผิดปกติทั้งที่งบแอดเท่าเดิม นั่นคือไซเรน อย่ารอให้รู้ตอนสรุปเดือน เพราะทุกวันที่ tag เงียบคือวันที่อัลกอริทึมอดอาหารและรายงานโกหก

สรุป

Tag ที่ตายเงียบอันตรายกว่าแอดที่แย่ เพราะแอดแย่มีตัวเลขฟ้อง แต่ tag ตายทำให้ตัวเลขทั้งกระดานโกหกพร้อมกัน — แคมเปญดีถูกปิด อัลกอริทึมอดอาหาร และทีมสรุปบทเรียนผิดไปอีกนาน บันไดสี่ขั้น (ติดไหม → ยิงไหม → ถึงไหม → ชื่อตรงไหม) วินิจฉัยเคสเก้าในสิบได้โดยไม่ต้องเดา

และเมื่อแก้เสร็จ งานจริงคือกันไม่ให้พังเงียบรอบหน้า: คู่มือทดสอบห้านาที กติกาทดสอบทุกครั้งที่แตะเว็บ และการชำเลืองกราฟ event รายสัปดาห์ ส่วนเกราะชั้นสุดท้ายคือมีแหล่งความจริงฝั่งแชทที่ไม่พึ่งเบราว์เซอร์ไว้เทียบเสมอ — เพราะระบบวัดที่ดีไม่ใช่ระบบที่ไม่มีวันพัง แต่คือระบบที่พังแล้วรู้ตัวภายในวันเดียว

• อาการชี้ตัว: หน้างานมีคนทักแต่แพลตฟอร์มโชว์ศูนย์ = การวัดพัง ไม่ใช่แอดพัง
• บันได 4 ขั้น: tag ติดไหม → trigger ยิงไหม → event ถึงไหม → ชื่อ event ตรงกับแคมเปญไหม
• สาเหตุอันดับหนึ่งคือแก้เว็บแล้วไม่ทดสอบ — ตั้งกติกา: แตะเว็บเมื่อไหร่ รันทดสอบห้านาทีเมื่อนั้น

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