งบโฆษณาวันละสองพัน แต่ตัวเลข Conversion ในระบบบวมจนไม่กล้าเชื่อ

เจ้าของร้านขายของออนไลน์รายหนึ่งเปิดแดชบอร์ดให้ผมดูด้วยสีหน้างุนงง งบโฆษณาที่ใช้อยู่วันละสองพันบาท แต่ตัวเลข Conversion ที่ระบบรายงานกลับสูงจนไม่น่าเชื่อ มากกว่าจำนวนออร์เดอร์ที่ปิดได้จริงในเดือนนั้นเสียอีก เขาถามผมตรง ๆ ว่า ‘นี่ผมกำลังจ่ายเงินให้ตัวเลขปลอมอยู่หรือเปล่า’

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

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

อาการ Conversion บวมเกินจริงที่พบบ่อย

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

อีกอาการหนึ่งคือตัวเลขพุ่งสูงผิดปกติเฉพาะบางวัน โดยไม่มีเหตุผลด้านยอดขายมารองรับ ซึ่งมักเกิดจากพฤติกรรมผู้ใช้ที่กดรีเฟรชหน้าขอบคุณซ้ำ ๆ หรือกดปุ่มย้อนกลับแล้วเข้าหน้าเดิมใหม่ ทำให้ Conversion Code ยิงซ้ำโดยไม่มีการซื้อเพิ่มขึ้นจริง

Custom Conversion คืออะไร ต่างจาก Conversion Code มาตรฐานยังไง

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

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

สาเหตุที่ Event ยิงซ้ำ

• ผู้ใช้กดรีเฟรชหน้าขอบคุณ หรือกดปุ่มย้อนกลับแล้วเข้าหน้าเดิมซ้ำ ทำให้โค้ดที่ฝังอยู่บนหน้านั้นทำงานซ้ำทุกครั้งที่โหลด
• ติดโค้ดซ้ำสองทาง เช่น ฝังตรงในหน้าเว็บและติดผ่าน GTM พร้อมกันโดยไม่รู้ตัว ทำให้ Event เดียวกันยิงสองครั้งในเหตุการณ์เดียว
• Trigger ผูกกับปุ่มหรือ Element ที่ถูกเรียกซ้ำในหน้าเดียว เช่น ปุ่มเดียวกันที่แสดงทั้งบนมือถือและเดสก์ท็อปโดยไม่ได้กรองให้เหลือตัวเดียว
• ไม่มีการกำหนด Deduplication Key ทำให้ระบบไม่มีวิธีแยกว่า Event ที่เข้ามาซ้ำเป็นการกระทำเดียวกันหรือการกระทำใหม่

วิธีป้องกัน Event ซ้ำ

1. กำหนด Deduplication Key ให้กับ Event สำคัญ เช่น ผูกกับหมายเลขคำสั่งซื้อ เพื่อให้ระบบรู้ว่า Event ที่มีหมายเลขเดียวกันคือเหตุการณ์เดียวกัน ไม่ใช่การซื้อใหม่
2. ตรวจสอบให้แน่ใจว่าติดโค้ดเพียงทางเดียว ไม่ว่าจะฝังตรงหรือผ่าน GTM เลือกทางใดทางหนึ่งเท่านั้นสำหรับ Event เดียวกัน
3. ตั้งเงื่อนไขให้ Trigger ยิงเฉพาะครั้งแรกที่หน้าโหลด ไม่ยิงซ้ำเมื่อผู้ใช้กดรีเฟรชหรือย้อนกลับมาที่หน้าเดิม
4. ทดสอบด้วยการทำธุรกรรมจำลองสักสองสามครั้งก่อนใช้งานจริง แล้วเช็กว่าจำนวน Event ที่ขึ้นในระบบตรงกับจำนวนการกระทำจริงหรือไม่

ทดสอบก่อนปล่อยใช้จริงยังไง

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

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

เมื่อไหร่ควรสร้าง Custom Conversion เพิ่ม เมื่อไหร่ไม่ควร

ควรสร้างเพิ่มเมื่อมีพฤติกรรมที่สะท้อนความสนใจจริงแต่ไม่มี Event มาตรฐานรองรับ เช่น การกดดูแคตตาล็อกสินค้าจนจบ หรือการกรอกแบบฟอร์มขอใบเสนอราคา สิ่งเหล่านี้ช่วยให้ระบบโฆษณาเรียนรู้กลุ่มเป้าหมายที่แม่นขึ้น

ไม่ควรสร้างเพิ่มเพียงเพราะอยากได้ตัวเลข Event เยอะ ๆ ให้ดูดีในรายงาน เพราะ Event ที่ไม่มีความหมายทางธุรกิจจริงจะทำให้ข้อมูลรกและอาจไปรบกวนการเรียนรู้ของอัลกอริทึมถ้าเผลอตั้งเป็น Primary Conversion

ตัวอย่างการตั้งชื่อ Custom Conversion ให้เป็นระบบ

การตั้งชื่อที่เป็นระบบช่วยลดความสับสนเมื่อมี Event หลายตัว โดยเฉพาะทีมที่มีคนดูแลมากกว่าหนึ่งคน:

ขั้นตอนตั้ง Custom Conversion ใน LINE Ads Manager

1. เข้าเมนูการวัดผลใน LINE Ads Manager แล้วเลือกสร้าง Conversion ใหม่ จากนั้นเลือกประเภทเป็นแบบกำหนดเอง ไม่ใช่ Event มาตรฐานที่ระบบเตรียมไว้ให้
2. ตั้งชื่อ Event ให้สื่อความหมายชัดเจนตามหลักการตั้งชื่อที่เป็นระบบ ระบุว่าเป็น URL ที่ต้องมาถึง หรือเป็น Event ที่ยิงผ่านโค้ดกำหนดเอง เพราะสองแบบนี้ตั้งค่าไม่เหมือนกัน
3. ถ้าเลือกแบบอิง URL ให้ระบุเงื่อนไขให้แคบที่สุดเท่าที่ทำได้ เช่น URL ต้องมีคำว่า thank-you และมีพารามิเตอร์ order เพื่อลดโอกาสที่หน้าอื่นจะเข้าเงื่อนไขโดยไม่ตั้งใจ
4. กำหนดหน้าต่างเวลานับผล (Attribution Window) ให้เหมาะกับพฤติกรรมจริงของธุรกิจ สินค้าที่ตัดสินใจซื้อเร็วอาจตั้งสั้น ส่วนสินค้าที่ต้องพิจารณานานควรตั้งยาวกว่า ไม่ใช่ใช้ค่าเริ่มต้นเดียวกันทุกธุรกิจ
5. บันทึกและรอให้ระบบยืนยันสถานะ Active ก่อน แล้วค่อยไปตั้งฝั่งเว็บให้ยิง Event ตามเงื่อนไขที่ตั้งไว้ ไม่ใช่ตั้งฝั่งเว็บไปพร้อมกันก่อนที่ Ads Manager จะยืนยันสถานะ

ทำไม Tag ยิงจริงแล้ว แต่ระบบไม่บันทึกสักครั้ง

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

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

อีกสาเหตุคือตั้งเงื่อนไขแบบอิง URL ไว้ แต่ Trigger ที่ยิงจริงกลับผูกกับปุ่มโดยไม่ได้รอให้ URL เปลี่ยนไปตามที่กำหนด ทำให้ระบบเห็น Request แต่ไม่จับคู่กับ Conversion ที่ตั้งไว้ได้ เพราะเงื่อนไขที่ระบุใน Ads Manager ไม่ตรงกับพฤติกรรมที่เกิดขึ้นจริง

วิธีไล่หาสาเหตุที่เร็วที่สุดคือเปิดหน้าจัดการ Event ใน Ads Manager คู่กับแท็บ Network ไปพร้อมกัน แล้วเทียบชื่อ Event และค่าพารามิเตอร์ทีละตัวอักษร ไม่ใช่ดูแค่ผ่าน ๆ ว่า ‘น่าจะตรงกัน’

จัดการ Consent ก่อนยิง Event ยังไงไม่ให้ตัวเลขหาย

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

ปัญหาจะเกิดเมื่อไม่ได้ตั้งลำดับให้ถูก เช่น Custom Conversion ยิงไปก่อนที่ป๊อปอัป Consent จะแสดงผลเสร็จ ทำให้บาง Session ยิง Event ไปแล้วโดยที่ผู้ใช้ยังไม่ได้ตอบตกลงหรือปฏิเสธ เกิดความไม่สอดคล้องระหว่างสถานะ Consent ที่บันทึกไว้กับ Event ที่ยิงจริง

แนวทางที่ปลอดภัยกว่าคือให้ Trigger ของ Custom Conversion รอสถานะ Consent ให้ชัดเจนก่อนเสมอ ไม่ว่าจะผ่านการตั้งเงื่อนไขใน GTM หรือการเช็กค่าตัวแปรในโค้ดก่อนยิง เพื่อให้ตัวเลขที่นับได้สอดคล้องกับสิทธิ์ที่ผู้ใช้ให้ไว้จริง ไม่ใช่นับมั่วก่อนแล้วค่อยมาแก้ทีหลัง

ตั้งรอบทบทวน Custom Conversion เป็นระยะ ไม่ใช่ตั้งแล้วปล่อยลืม

หลายทีมตั้ง Custom Conversion เสร็จแล้วไม่เคยกลับมาดูอีกเลย ทั้งที่เว็บมีการอัปเดตอยู่เรื่อย ๆ เช่น เปลี่ยนปุ่ม เปลี่ยนโครงสร้างหน้า หรือย้ายตำแหน่ง Element ที่ Trigger เคยผูกไว้ การเปลี่ยนแปลงเหล่านี้ทำให้ Custom Conversion ที่เคยทำงานดีหยุดยิงไปเงียบ ๆ โดยไม่มีใครรู้ตัวจนกว่าจะมาเทียบตัวเลขย้อนหลังแล้วเจอว่าหายไปหลายสัปดาห์

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

สรุป

ตัวเลข Conversion ที่บวมเกินจริงไม่ใช่เรื่องของโชคร้าย แต่มักมีสาเหตุทางเทคนิคที่ชี้ชัดได้เสมอ ไม่ว่าจะเป็นการติดโค้ดซ้ำ การไม่มี Deduplication Key หรือ Trigger ที่ยิงซ้ำโดยไม่ตั้งใจ

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

• Custom Conversion ยืดหยุ่นแต่เสี่ยงยิงซ้ำถ้าไม่มี Deduplication Key
• สาเหตุหลักของ Event ซ้ำคือติดโค้ดสองทาง และ Trigger ที่ยิงซ้ำตอนรีเฟรช
• ทดสอบด้วยธุรกรรมจำลองก่อนเปิดงบจริงทุกครั้ง

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