← กลับไปหน้าบทความ
ส่ง Conversion กลับ

เงินคืนลูกค้าไปแล้วหนึ่งราย แต่ Ads Manager ยังนับว่าขายได้เหมือนเดิม

ทีมบรรณาธิการ linli12 ส.ค. 04:53อัปเดต 12 ส.ค. 04:53อ่าน 2 นาที
เงินคืนลูกค้าไปแล้วหนึ่งราย แต่ Ads Manager ยังนับว่าขายได้เหมือนเดิม
บทความนี้จัดทำเพื่อความรู้ ชื่อธุรกิจ ตัวเลข หรือบทสนทนาที่ไม่มีแหล่งอ้างอิงกำกับเป็นกรณีตัวอย่างเพื่ออธิบายแนวคิด ดูรายละเอียดที่ นโยบายกองบรรณาธิการ

สรุปสั้น ๆ

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

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

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

บทความนี้จะอธิบายว่า Refund Conversion Adjustment คืออะไร ควรทำเมื่อไร และวางระบบยังไงให้การคืนเงินไม่ทำให้ข้อมูลที่ใช้วัดผลโฆษณาผิดเพี้ยนไปจากความเป็นจริง

ทำไมยอดคืนเงินถึงทำให้ตัวเลขใน Ads Manager ผิดเพี้ยน

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

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

แยก Gross Revenue กับ Net Revenue ก่อนตัดสินใจว่าจะปรับหรือไม่

ก่อนวางกระบวนการปรับ Conversion ธุรกิจต้องตกลงกันก่อนว่าตัวเลขที่ส่งกลับแพลตฟอร์มโฆษณาควรเป็น Gross Revenue หรือ Net Revenue Gross Revenue คือยอดขายรวมก่อนหักคืนเงินหรือส่วนลดใด ๆ ส่วน Net Revenue คือยอดที่หักคืนเงิน ยกเลิก หรือส่วนลดออกแล้ว ธุรกิจส่วนใหญ่ที่ต้องการให้ตัวเลขที่ใช้ตัดสินใจงบสะท้อนความจริงมากที่สุดมักเลือกใช้ Net Revenue เป็นฐาน แล้วปรับ Conversion ทุกครั้งที่มีการคืนเงินเกิดขึ้นจริง

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

เมื่อไรควรปรับ Conversion ย้อนหลัง ไม่ใช่แค่บันทึกคืนเงินในบัญชี

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

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

กลไก Conversion Adjustment ทำงานยังไงในภาพรวม

โดยทั่วไปแพลตฟอร์มโฆษณาที่รองรับการปรับ Conversion จะต้องอาศัยรหัสอ้างอิงเดิมที่เคยใช้ตอนส่ง Conversion ครั้งแรก เพื่อให้ระบบรู้ว่ากำลังแก้ไขเหตุการณ์ไหน ไม่ใช่สร้างเหตุการณ์ใหม่ นี่คือเหตุผลที่การมี Order ID ที่สม่ำเสมอตั้งแต่ต้นมีความสำคัญมาก เพราะถ้าไม่มีรหัสอ้างอิงที่ตรงกัน การปรับ Conversion ย้อนหลังจะทำแทบไม่ได้เลย อ่านเพิ่มเติมเรื่องการวางระบบรหัสอ้างอิงได้ที่ Order ID Attribution ซึ่งเป็นพื้นฐานที่ต้องมีก่อนจะพูดถึงเรื่องการปรับ Conversion

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

เทียบ 3 สถานการณ์คืนเงินที่พบบ่อย และวิธีจัดการต่างกัน

สถานการณ์การคืนเงินไม่ได้เหมือนกันทุกครั้ง ตารางนี้เป็นตัวอย่างกรอบวิเคราะห์ที่ช่วยแยกว่าแต่ละสถานการณ์ควรจัดการต่างกันยังไง (ตัวเลขเป็นตัวอย่างประกอบกรอบวิเคราะห์เท่านั้น ไม่ใช่สถิติจริง):

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

ใครต้องเป็นคนกดปรับ Conversion เมื่อมีการคืนเงินเกิดขึ้น

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

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

ข้อผิดพลาดที่ทำให้ปรับ Conversion แล้วยังไม่ตรง

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

สร้างบันทึกคืนเงินที่ใช้ตรวจสอบย้อนหลังได้จริง

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

เมื่อมีบันทึกนี้แล้ว การตรวจสอบสิ้นเดือนจะง่ายขึ้นมาก แทนที่จะต้องไล่เทียบยอดขายในระบบโฆษณากับยอดเงินในบัญชีทีละรายการ สามารถดูจากบันทึกคืนเงินได้เลยว่ามีรายการไหนที่ยังไม่ได้ปรับ Conversion บ้าง วิธีนี้ยังช่วยให้เห็นแนวโน้มด้วยว่าสินค้าหรือแคมเปญไหนมีอัตราคืนเงินสูงผิดปกติ ซึ่งเป็นข้อมูลที่มีประโยชน์มากกว่าแค่การแก้ไขตัวเลขให้ถูกต้อง เพราะช่วยตั้งคำถามต่อได้ว่าทำไมสินค้านั้นถึงถูกคืนบ่อย เรื่องการผูกยอดขายกับต้นทางแคมเปญตั้งแต่แรกก็มีส่วนช่วยให้ตรวจสอบง่ายขึ้น อ่านเพิ่มเติมได้ที่ การผูกสลิปโอนเงินกับ Conversion Tracking และเรื่องการนำเข้ายอดขายนอกเว็บไซต์กลับระบบที่ Offline Conversion Import

อัตราคืนเงินสูงบอกอะไรมากกว่าแค่ตัวเลข Conversion ที่ต้องแก้

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

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

สรุป

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

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

  • ยอดคืนเงินที่ไม่ถูกแจ้งกลับแพลตฟอร์มโฆษณาทำให้ ROAS ดูดีกว่าความเป็นจริงตลอดเวลา
  • แยก Gross กับ Net Revenue ให้ชัดก่อนตัดสินใจว่าจะปรับ Conversion แบบไหน
  • ต้องมี Order ID อ้างอิงเดิมเสมอ ถึงจะปรับ Conversion ย้อนหลังได้ถูกเหตุการณ์
  • อัตราคืนเงินสูงผิดปกติในบางแคมเปญอาจเป็นสัญญาณปัญหาที่ลึกกว่าตัวเลข ไม่ใช่แค่เรื่องบัญชี

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

Conversion Adjustment ต่างจากการส่ง Conversion ปกติยังไง

Conversion ปกติคือการแจ้งแพลตฟอร์มว่ามีเหตุการณ์ใหม่เกิดขึ้น ส่วน Conversion Adjustment คือการแก้ไขหรือยกเลิกเหตุการณ์ที่เคยแจ้งไปแล้ว โดยต้องอ้างอิงถึง Conversion เดิมที่เคยส่งไป ไม่ใช่การสร้างเหตุการณ์ใหม่แยกต่างหาก

ถ้าคืนเงินบางส่วนเท่านั้น ต้องปรับ Conversion ยังไง

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

ถ้าไม่เคยปรับ Conversion หลังคืนเงินเลย จะเกิดผลอะไรตามมา

ตัวเลขยอดขายและ ROAS ที่แสดงในรายงานจะสูงกว่าความเป็นจริงเรื่อย ๆ ซึ่งอาจทำให้ตัดสินใจเพิ่มงบให้แคมเปญที่จริง ๆ แล้วมีอัตราคืนเงินสูงโดยไม่รู้ตัว และระบบ Bidding อาจเรียนรู้ผิดทิศทางไปด้วย

ควรปรับ Conversion ทันทีที่คืนเงิน หรือรอสรุปเป็นรอบ

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

Refund กับ Cancel ต้องปรับ Conversion เหมือนกันไหม

หลักการคล้ายกันคือต้องยกเลิกหรือลดมูลค่า Conversion ที่เคยส่งไป แต่ต้องตรวจสอบก่อนว่ากรณี Cancel นั้นเคยมีการส่ง Conversion ไปแล้วจริงหรือยัง เพราะบางครั้งการยกเลิกเกิดขึ้นก่อนที่จะมีการส่ง Conversion เสียอีก

มีเครื่องมือช่วยจัดการเรื่องนี้ให้อัตโนมัติทั้งหมดไหม

มีบริการอย่าง linli ที่ช่วยจัดระเบียบการบันทึกสถานะและยอดขายผ่าน LINE ซึ่งช่วยให้การอ้างอิง Order ID ระหว่างระบบขายกับ Conversion เป็นระบบมากขึ้น แต่การตัดสินใจว่าเคสไหนต้องปรับและปรับเมื่อไรยังต้องอาศัยกระบวนการภายในของธุรกิจร่วมด้วย

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

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

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

บทความที่เกี่ยวข้อง

ทำไมแคมเปญที่ Optimize ไปที่ข้อความถึงได้ Lead เยอะ แต่ปิดยอดขายได้น้อย

ทำไมแคมเปญที่ Optimize ไปที่ข้อความถึงได้ Lead เยอะ แต่ปิดยอดขายได้น้อย

แคมเปญ Click to Message ที่ตั้งให้ Optimize ไปที่การเริ่มแชท มักได้จำนวนคนทักเข้ามาเยอะ แต่ไม่ได้แปลว่าจะปิดยอดขายได้มากตาม บทความนี้อธิบายว่าทำไมต้องส่ง Purchase Event กลับไปให้แพลตฟอร์มโฆษณาเรียนรู้ และควรทำเมื่อข้อมูลพร้อมแค่ไหน
ยอดขายที่เกิดนอกเว็บไซต์ก็ป้อนกลับเข้าระบบโฆษณาได้ถ้าตั้งค่าถูกจุด

ยอดขายที่เกิดนอกเว็บไซต์ก็ป้อนกลับเข้าระบบโฆษณาได้ถ้าตั้งค่าถูกจุด

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

ยอด Conversion ในรายงานโฆษณาเพิ่มขึ้นสองเท่า แต่ออเดอร์จริงไม่ได้เพิ่มตาม เพราะอะไร

หลายธุรกิจที่เพิ่งเชื่อมทั้ง Pixel และ Conversion API เข้าด้วยกันมักเจอปัญหายอด Conversion ในรายงานพุ่งขึ้นผิดปกติ บทความนี้อธิบายว่า Conversion Deduplication คืออะไร ทำไมต้องมี และตั้งค่าอย่างไรให้แพลตฟอร์มนับ Event ซ้ำแค่ครั้งเดียว