ลูกค้าโอนแล้วขอคืนเงินในอีกสามวัน แต่ Conversion ที่ส่งเข้า Meta ไปแล้วไม่มีวันลบออก ต้องออกแบบ Event ปรับยอดแทน

ร้านขายของออนไลน์ที่ผมช่วยตรวจระบบให้ เจอเคสที่ลูกค้าโอนเงินซื้อสินค้าราคาสามพันบาท แอดมินยืนยันออเดอร์และระบบยิง Purchase event เข้า Meta ทันทีตามปกติ แต่สองวันถัดมาลูกค้าติดต่อขอคืนเงินเพราะสินค้าไม่ตรงกับที่คาดหวัง ร้านคืนเงินให้และปิดออเดอร์ในระบบภายในของตัวเองเรียบร้อย แต่ event มูลค่าสามพันบาทที่เคยยิงเข้า Meta ไปแล้วยังคงอยู่ในนั้นเหมือนเดิม ไม่มีใครไปแก้ไขอะไรเลย

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

หลายทีมเข้าใจผิดว่า conversion ที่ส่งไปแล้วแก้ไขไม่ได้เลยจึงปล่อยผ่านไป ซึ่งจริง ๆ แล้วแพลตฟอร์มโฆษณาหลักมีกลไกสำหรับสถานการณ์นี้อยู่ในบางรูปแบบ เพียงแต่ backend ต้องออกแบบมารองรับตั้งแต่แรก บทความนี้จะเจาะแนวทางออกแบบ event ปรับยอดที่ใช้ได้จริงเมื่อออเดอร์เปลี่ยนสถานะภายหลัง

ทำไม conversion ที่ส่งไปแล้วถึงลบทิ้งตรง ๆ ไม่ได้

แนวคิดพื้นฐานของ conversion tracking คือการบันทึกเหตุการณ์ที่เกิดขึ้น ณ ช่วงเวลาหนึ่ง ไม่ใช่สถานะปัจจุบันของออเดอร์ เมื่อ event ถูกส่งและถูกประมวลผลโดยแพลตฟอร์มไปแล้ว มันจะถูกใช้ในการคำนวณรายงานย้อนหลังและอาจถูกใช้เป็นสัญญาณป้อนเข้าโมเดล bidding ไปแล้วด้วย การลบ event ออกตรง ๆ จึงไม่ใช่กลไกที่แพลตฟอร์มส่วนใหญ่ออกแบบมาให้ทำได้ง่าย ๆ

สิ่งที่แพลตฟอร์มรองรับแทนคือการส่งข้อมูลเพิ่มเติมที่บอกว่า ‘เหตุการณ์นี้มีการเปลี่ยนแปลงภายหลัง’ ซึ่งอาจอยู่ในรูปแบบของ event ใหม่ที่ระบุมูลค่าเป็นลบ event ที่มี event name บ่งบอกการยกเลิกโดยเฉพาะ หรือกลไก conversion adjustment ที่บางแพลตฟอร์มมีให้ ต้องตรวจสอบเอกสารล่าสุดของแต่ละแพลตฟอร์มว่ารองรับรูปแบบไหน เพราะวิธีการไม่เหมือนกันทุกเจ้า และอาจเปลี่ยนแปลงตามเวอร์ชัน API

backend ต้องรู้ก่อนว่าออเดอร์ไหนถูกยกเลิกหรือคืนเงิน

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

จุดนี้เชื่อมโยงกับเรื่องsales operations ที่ต้องมีวินัยในการอัปเดตสถานะเพราะถ้าไม่มีการบันทึกว่าออเดอร์ถูกคืนเงินในระบบ ก็ไม่มีทางที่ backend จะรู้ตัวเพื่อไปยิง event ปรับยอดกลับได้เลย การแก้ปัญหานี้จึงไม่ใช่แค่เรื่องเทคนิคอย่างเดียว แต่ต้องออกแบบ workflow ให้แอดมินมีขั้นตอนกดยืนยันการคืนเงินในระบบทุกครั้ง ไม่ว่าเงินจะโอนคืนผ่านช่องทางไหนก็ตาม

รูปแบบการส่ง event ปรับยอดที่ใช้ได้จริง

เก็บ mapping ระหว่างออเดอร์กับ event_id ไว้ตั้งแต่วันแรก

หัวใจสำคัญที่ทำให้การส่ง event ปรับยอดทำได้จริงคือ ต้องมีตารางในฐานข้อมูลที่บันทึกว่าออเดอร์แต่ละรายการเคยส่ง event_id อะไรไปให้แพลตฟอร์มไหนบ้าง พร้อมมูลค่าที่ส่งไป ณ ตอนนั้น ถ้าไม่มี mapping นี้ตั้งแต่แรก เมื่อถึงเวลาต้องปรับยอดภายหลังจะไม่มีทางรู้เลยว่าต้องอ้างอิงถึง event ตัวไหน

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

ระหว่างที่ยังไม่มีระบบปรับยอด ควรสื่อสารกับทีมการตลาดยังไง

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

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

ธุรกิจแบบไหนควรลงทุนสร้างระบบนี้ก่อน

ไม่ใช่ทุกธุรกิจต้องรีบสร้างระบบ event ปรับยอดทันที ธุรกิจที่มีอัตราการคืนเงินต่ำมาก (เช่น ต่ำกว่าสองสามเปอร์เซ็นต์ของออเดอร์ทั้งหมด) อาจยังไม่คุ้มที่จะลงทุนสร้างระบบซับซ้อนตั้งแต่วันแรก แต่ธุรกิจที่มีอัตราการคืนเงินสูง เช่น สินค้าแฟชั่นที่ลูกค้ามักขอเปลี่ยนไซส์หรือคืนเพราะไม่ถูกใจ ควรให้ความสำคัญกับเรื่องนี้เป็นลำดับต้น ๆ

อีกปัจจัยที่ต้องพิจารณาคือ ธุรกิจที่ใช้ Purchase value เป็น primary conversion สำหรับ Smart Bidding ควรระวังเป็นพิเศษ เพราะถ้ามูลค่า conversion ที่ระบบเห็นสูงกว่าความเป็นจริงต่อเนื่อง อาจส่งผลต่อการเรียนรู้ของโมเดล bidding ในระยะยาว ซึ่งเป็นความเสี่ยงที่มากกว่าแค่ตัวเลขรายงานผิด

ถ้ายิงแอดหลายแพลตฟอร์มพร้อมกัน event ปรับยอดต้องส่งครบทุกที่ ไม่ใช่แค่ที่เดียว

ธุรกิจที่ยิงแอดพร้อมกันหลายช่องทาง เช่น Meta, Google และ TikTok มักเจอปัญหาเพิ่มเติมเมื่อต้องส่ง event ปรับยอด เพราะออเดอร์เดียวกันเคยถูกส่งเป็น Purchase event ไปทุกแพลตฟอร์มพร้อมกันตอนขาย เมื่อลูกค้าคืนเงินภายหลัง event ปรับยอดก็ต้องถูกส่งไปครบทุกแพลตฟอร์มเช่นกัน ไม่ใช่แก้แค่ปลายทางเดียวแล้วปล่อยให้ปลายทางอื่นมีตัวเลขที่สูงเกินจริงค้างอยู่ต่อไป

จุดนี้เชื่อมโยงโดยตรงกับการออกแบบevent_id แยกตามปลายทางในสถาปัตยกรรม fan-out เพราะถ้าตอนส่ง Purchase event มีการเก็บ mapping ว่าออเดอร์นี้เคยส่ง event_id อะไรไปแพลตฟอร์มไหนบ้าง ตอนต้องส่ง event ปรับยอดกลับก็จะรู้ทันทีว่าต้องอ้างอิงถึง event_id ตัวไหนของแต่ละแพลตฟอร์ม การออกแบบ mapping ตั้งแต่ต้นทางจึงมีประโยชน์ทั้งตอนส่งครั้งแรกและตอนต้องย้อนแก้ไขภายหลัง

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

สรุป

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

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

• event ที่ส่งเข้า CAPI แล้วลบทิ้งตรง ๆ ไม่ได้ ต้องใช้ event ปรับยอดตามที่แต่ละแพลตฟอร์มรองรับ
• ต้องมีตาราง mapping ระหว่างออเดอร์กับ event_id ตั้งแต่วันแรก ไม่งั้นจะย้อนแก้ไม่ได้เมื่อถึงเวลาต้องใช้
• ระหว่างที่ยังไม่มีระบบอัตโนมัติ ให้ทำรายงานคืนเงินแยกให้ทีมการตลาดหักลบเองเพื่อไม่ให้ตัดสินใจจากตัวเลขที่สูงเกินจริง

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