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

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

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

สรุปสั้น ๆ

Conversion Deduplication คือกลไกที่ทำให้แพลตฟอร์มโฆษณานับ Event เดียวกันเพียงครั้งเดียว แม้จะถูกส่งเข้ามาจากหลายเส้นทางพร้อมกัน เช่น ทั้งจาก Pixel ฝั่งเบราว์เซอร์และ Conversion API ฝั่งเซิร์ฟเวอร์ โดยอาศัยตัวระบุร่วม เช่น event_id เพื่อให้แพลตฟอร์มรู้ว่าสอง Event นี้คือเหตุการณ์เดียวกัน ไม่ใช่สอง Conversion แยกกัน

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

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

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

Conversion Deduplication คืออะไรกันแน่

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

กลไกนี้สำคัญมากขึ้นเรื่อย ๆ เพราะธุรกิจจำนวนมากไม่ได้ใช้แค่ Pixel ฝั่งเบราว์เซอร์อีกต่อไป แต่เริ่มเสริม Conversion API ฝั่งเซิร์ฟเวอร์เข้ามาด้วยเพื่อลดปัญหาข้อมูลหายจากการถูกบล็อก ซึ่งหมายความว่า Event เดียวกันหนึ่งเหตุการณ์อาจถูกส่งเข้ามาสองครั้งจากสองเส้นทางพร้อมกันโดยไม่ได้ตั้งใจ ปัญหานี้มักเกิดควบคู่ไปกับความสับสนเรื่อง GA4 กับ Direct/Referral Traffic จาก LINE ที่ทำให้ทีมการตลาดเข้าใจตัวเลขในหลายรายงานคลาดเคลื่อนไปพร้อมกัน

ทำไมถึงเกิด Event ซ้ำตั้งแต่แรก

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

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

แพลตฟอร์มรู้ได้อย่างไรว่า Event ไหนคือตัวเดียวกัน

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

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

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

ผลกระทบต่อการ Optimize แคมเปญเมื่อไม่ทำ Deduplication

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

ในทางกลับกัน ต้นทุนต่อ Conversion (Cost per Result) ที่แสดงในรายงานก็จะต่ำกว่าความเป็นจริงตามไปด้วย เพราะตัวหารคือจำนวน Conversion ที่ถูกนับพองขึ้น เมื่อทีมนำตัวเลขนี้ไปเทียบกับต้นทุนต่อออเดอร์จริงจากระบบขาย ก็จะสรุปผิดว่าแคมเปญมีประสิทธิภาพดีกว่าความเป็นจริงมาก การวางแนวคิดเรื่อง LTV ต่อ CAC บนตัวเลขที่พองอยู่แบบนี้จึงยิ่งทำให้ทิศทางการลงทุนงบผิดเพี้ยนไปไกลกว่าที่คิด

เทียบสถานการณ์ที่มี Deduplication กับไม่มี

เพื่อให้เห็นผลต่างชัดขึ้น ลองเทียบสองสถานการณ์ที่มีสองเส้นทางส่งข้อมูล Conversion เดียวกัน:

ประเด็นไม่มี Deduplication (event_id ไม่ตรงกัน)มี Deduplication ทำงานถูกต้อง
จำนวน Conversion ที่นับได้อาจนับซ้ำ 2 เท่าจากทั้งสองเส้นทางนับเหตุการณ์เดียวเพียงครั้งเดียว
ต้นทุนต่อ Conversion ที่แสดงต่ำกว่าความเป็นจริง ทำให้ดูดีเกินจริงใกล้เคียงต้นทุนต่อออเดอร์จริงมากขึ้น
ผลต่อ Auto-biddingระบบอาจเพิ่มงบให้สิ่งที่ไม่ได้ผลจริงระบบเรียนรู้จากข้อมูลที่ใกล้เคียงความจริง
ความน่าเชื่อถือของรายงานต้องเทียบกับยอดขายจริงทุกครั้งก่อนเชื่อเชื่อถือได้มากขึ้นโดยไม่ต้องเทียบทุกครั้ง

สิ่งที่ต้องตั้งค่าเพื่อให้ Deduplication ทำงานถูกต้อง

ก่อนอื่นธุรกิจต้องแน่ใจว่าระบบที่สร้าง event_id ใช้ตัวเดียวกันในทุกเส้นทาง ไม่ใช่ให้ทีมพัฒนาเว็บสร้างค่าหนึ่งฝั่ง Pixel และให้ทีมระบบหลังบ้านสร้างอีกค่าหนึ่งฝั่ง Conversion API แยกกันโดยไม่ประสานงานกัน เพราะจะทำให้ event_id ไม่มีทางตรงกันเลย

ถัดมาคือการตรวจสอบว่า Event Name ที่ใช้ในทั้งสองเส้นทางตรงกันด้วย เช่น ถ้าฝั่งหนึ่งใช้ชื่อ Purchase แต่อีกฝั่งใช้ชื่อ CompletePayment แม้ event_id จะตรงกัน แพลตฟอร์มบางแห่งก็อาจไม่ถือว่าเป็น Event เดียวกันตามเงื่อนไขของตัวเอง จึงควรกำหนดมาตรฐานชื่อ Event ร่วมกันตั้งแต่ต้น

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

วิธีตรวจสอบว่า Deduplication ทำงานถูกต้องจริง

หลังตั้งค่าเสร็จ ไม่ควรสรุปทันทีว่าใช้งานได้เพราะไม่มี Error ปรากฏขึ้นมา ควรใช้เครื่องมือตรวจสอบ Event ที่แพลตฟอร์มโฆษณาให้มา ซึ่งมักแสดงสถานะว่า Event คู่ไหนถูกจับคู่กันสำเร็จ (Matched) และคู่ไหนยังถูกนับแยกกันอยู่ (Unmatched)

  1. ทำรายการทดสอบ 1 คำสั่งซื้อจริงหรือจำลอง แล้วบันทึกเวลาและรายละเอียดที่ควรเกิดขึ้นทั้งฝั่ง Pixel และ Conversion API
  2. เปิดเครื่องมือตรวจสอบ Event ของแพลตฟอร์ม แล้วดูว่า event_id ที่ส่งมาจากทั้งสองเส้นทางตรงกันหรือไม่
  3. ตรวจสถานะการจับคู่ว่าระบบแสดงผลเป็น Matched หรือยังคงแยกเป็นสอง Event
  4. หากยังไม่ Matched ให้ตรวจ Event Name และรูปแบบเวลาที่ส่งไปว่าตรงตามมาตรฐานที่แพลตฟอร์มกำหนดหรือไม่
  5. ทำซ้ำหลายเคสในหลายช่วงเวลา เพราะบางปัญหาจะเกิดเฉพาะตอนที่ระบบหลังบ้านทำงานล่าช้ากว่าปกติ ไม่ใช่ทุกครั้งที่ทดสอบ

ข้อผิดพลาดที่พบบ่อยเมื่อทำ Deduplication

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

อีกข้อผิดพลาดคือการปล่อยให้ตัวแทนหรือ Third-party Tool หลายตัวยิง Event เดียวกันเข้าแพลตฟอร์มพร้อมกันโดยไม่รู้ตัว เช่น ทั้งปลั๊กอินอีคอมเมิร์ซ ทั้งระบบ CRM และทั้งเครื่องมือ Marketing Automation ต่างส่ง Purchase Event ของออเดอร์เดียวกันเข้าไปแยกกันโดยไม่มีใครประสาน event_id ให้ตรงกัน ทำให้เกิดการนับซ้ำจากมากกว่าสองเส้นทางพร้อมกัน

หลายทีมยังมองข้ามการรีวิวการตั้งค่าเป็นระยะ เพราะเมื่อทีมพัฒนาเปลี่ยนระบบหลังบ้านหรืออัปเดตปลั๊กอินใหม่ รูปแบบการสร้าง event_id อาจเปลี่ยนไปโดยไม่มีใครแจ้งทีมการตลาด ทำให้ปัญหาการนับซ้ำกลับมาอีกครั้งหลังจากที่เคยแก้ไปแล้ว การตรวจสอบ Deduplication จึงควรเป็นงานที่ทำเป็นรอบ ไม่ใช่ทำครั้งเดียวแล้วจบ เช่นเดียวกับการนำเข้าข้อมูลผ่าน Offline Conversion Import ที่ต้องตรวจสอบทุกรอบว่าไฟล์ที่นำเข้าไม่ได้ทับซ้อนกับ Event ที่ถูกส่งไปแล้วจากช่องทางอื่น

แล้วธุรกิจที่ขายผ่าน LINE ต้องกังวลเรื่องนี้แค่ไหน

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

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

สรุป

Conversion Deduplication ไม่ใช่ฟีเจอร์ที่ทำงานเองโดยอัตโนมัติเมื่อเปิดใช้หลายเส้นทางส่งข้อมูล แต่ต้องอาศัยการตั้งค่า event_id และ Event Name ให้ตรงกันตั้งแต่ต้นทาง ธุรกิจที่มองข้ามจุดนี้มักเห็นตัวเลขในรายงานสวยกว่าความเป็นจริงโดยไม่รู้ตัว

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

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

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

ถ้าไม่ทำ Deduplication เลย จะเกิดผลเสียร้ายแรงแค่ไหน

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

event_id ต้องมีรูปแบบตายตัวหรือไม่

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

Deduplication ทำงานได้กับทุกแพลตฟอร์มโฆษณาเหมือนกันหมดไหม

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

ธุรกิจขนาดเล็กที่ยังใช้แค่ Pixel อย่างเดียวต้องกังวลเรื่องนี้ไหม

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

จะรู้ได้อย่างไรว่าตัวเลข Conversion ที่เห็นตอนนี้มีการนับซ้ำอยู่หรือไม่

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

ลองตรวจด้วยตัวเอง

Event Deduplication Debugger

ใส่ browser event กับ server event ของคุณ แล้วดูว่าแพลตฟอร์มจะจับคู่ dedup ให้หรือนับซ้ำ

เช็ก dedup ฟรี

ใช้ฟรี ไม่ต้องสมัคร ไม่เก็บข้อมูลที่คุณกรอก

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

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

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

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

ปรับ Attribution Window จาก 7 วันเหลือ 1 วัน แล้ว ROAS ที่เห็นหายไปครึ่งหนึ่ง แก้อย่างไร

ปรับ Attribution Window จาก 7 วันเหลือ 1 วัน แล้ว ROAS ที่เห็นหายไปครึ่งหนึ่ง แก้อย่างไร

หลายทีมโฆษณาเคยเจอเหตุการณ์ที่แค่เปลี่ยนตัวเลือก Attribution Window แล้วรายงานผลลัพธ์เปลี่ยนไปทันทีโดยที่พฤติกรรมลูกค้าไม่ได้เปลี่ยนเลย บทความนี้อธิบายว่า Attribution Window คืออะไร ทำงานอย่างไร และควรตั้งค่าอย่างไรให้เหมาะกับธุรกิจที่ขายผ่าน LINE
ตั้งค่า Event ID ให้ตรงกันทุกจุดก่อนเชื่อม TikTok Events API เข้ากับพิกเซลบนเว็บ

ตั้งค่า Event ID ให้ตรงกันทุกจุดก่อนเชื่อม TikTok Events API เข้ากับพิกเซลบนเว็บ

ธุรกิจที่ยิงแอด TikTok แล้วเชื่อม Events API เข้าไปเสริมพิกเซลบนเว็บไซต์ มักเจอปัญหา Event ถูกนับซ้ำสองครั้งจากจุดเดียวกัน สาเหตุหลักอยู่ที่ event_id ไม่ตรงกันระหว่างสองช่องทาง
ร้านขายของออนไลน์ปิดออเดอร์วันละ 200 ใบ แต่ไม่เคยเช็คว่า Transaction ID ซ้ำหรือเปล่า

ร้านขายของออนไลน์ปิดออเดอร์วันละ 200 ใบ แต่ไม่เคยเช็คว่า Transaction ID ซ้ำหรือเปล่า

ยอด Purchase ใน GA4 ที่ดูสูงผิดปกติเมื่อเทียบกับยอดขายจริงในบัญชี มักมีสาเหตุมาจาก Transaction ID ที่ถูกส่งเข้าไปซ้ำมากกว่าหนึ่งครั้ง Transaction ID Deduplication คือกลไกที่ใช้ป้องกันปัญหานี้โดยตรง