ยอด Conversion ขึ้นสองเท่าในแดชบอร์ด ทั้งที่มีลูกค้าจริงแค่คนเดียว แก้ยังไง

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

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

บทความนี้จะอธิบายว่า server side deduplication conversion คืออะไร ทำไมปัญหานี้ถึงเกิดขึ้นบ่อยกับธุรกิจที่ปิดการขายผ่าน LINE และมีขั้นตอนอะไรบ้างที่ต้องเตรียมก่อนทำ Offline Conversion ให้กันซ้ำได้จริง

server side deduplication conversion คืออะไรกันแน่

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

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

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

ทำไม Conversion ถึงถูกนับซ้ำ ทั้งที่ลูกค้าจริงมีแค่คนเดียว

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

อีกสาเหตุคือระบบภายในของธุรกิจเองมีการอัปเดตสถานะ Lead หลายครั้ง เช่น เปลี่ยนจาก Proposal เป็น Order แล้วเปลี่ยนจาก Order เป็น Closed Sale ถ้าทุกครั้งที่เปลี่ยนสถานะมีการส่ง Conversion ออกไปโดยไม่เช็กว่าเคยส่งรายการนี้ไปแล้วหรือยัง ก็จะเกิดการส่งซ้ำหลายรอบสำหรับ Lead รายเดียวกัน

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

สิ่งที่ต้องเตรียมก่อนทำ Offline Conversion ให้กันซ้ำได้จริง

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

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

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

ตารางเทียบความเสี่ยงนับซ้ำของแต่ละช่องทางส่ง Conversion

เพื่อให้เห็นภาพว่าช่องทางไหนมีความเสี่ยงนับซ้ำมากน้อยแค่ไหนเมื่อใช้งานร่วมกัน:

Conversion Lag ทำให้การกันซ้ำพลาดได้อย่างไร แม้ Event ID จะตรงกัน

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

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

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

ตรวจสอบว่าการกันซ้ำทำงานจริงหรือไม่ หลังตั้งค่าเสร็จ

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

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

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

ทำแบบนี้แล้วพัง เพราะจุดเหล่านี้มักถูกมองข้าม

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

สรุป

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

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

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

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