Event Deduplication: กัน Pixel + Server นับ Conversion ซ้ำ
สรุปสั้น ๆ
เมื่อคุณส่ง Conversion ทั้งจาก Pixel ในเบราว์เซอร์และจาก Server-Side พร้อมกัน เหตุการณ์เดียวอาจถูกนับสองรอบ ทำให้ยอดในรายงานพองเกินจริง วิธีแก้คือให้ทั้งสองทางส่ง "รหัสเหตุการณ์เดียวกัน" (Event ID) ไปด้วย เพื่อให้แพลตฟอร์มรู้ว่าเป็นเหตุการณ์เดียว แล้วนับแค่ครั้งเดียว ตัวเลขจึงกลับมาตรงกับความจริง
มีปรากฏการณ์ประหลาดที่หลายคนเจอหลังติดตั้ง Server-Side คือ "จู่ ๆ ยอด Conversion ดีขึ้นเยอะผิดปกติ" ตอนแรกดูเหมือนข่าวดี แต่พอเทียบกับยอดขายจริงในบัญชีกลับพบว่ามันพองเกินความจริงไปมาก ต้นเหตุมักไม่ใช่ว่าขายดีขึ้น แต่เป็นเพราะเหตุการณ์เดียวถูกนับซ้ำสองรอบ
เรื่องนี้เกิดเพราะแนวทางที่ถูกต้องคือใช้ทั้ง Pixel และ Server-Side ควบคู่กัน แต่พอทั้งคู่ต่างคนต่างส่งเหตุการณ์เดียวกันโดยไม่ได้บอกให้แพลตฟอร์มรู้ว่ามันคืออันเดียวกัน แพลตฟอร์มก็นับเป็นสองอย่างซื่อ ๆ ตัวเลขเลยเบิ้ล การกันนับซ้ำ หรือ Event Deduplication จึงเป็นงานที่ต้องทำคู่กับการมี Server-Side เสมอ ไม่ใช่ทางเลือก
บทความนี้ผมจะอธิบายว่าการนับซ้ำเกิดขึ้นได้ยังไง แนวคิดของการกันซ้ำด้วยรหัสเหตุการณ์ทำงานยังไง ต้องระวังอะไร และจะตรวจยังไงว่าตัวเลขของคุณกำลังโดนนับซ้ำอยู่หรือเปล่า ทั้งหมดอธิบายแบบไม่ต้องเขียนโค้ดเป็นก็ตามได้
ทำไมเหตุการณ์เดียวถึงถูกนับสองรอบ
ลองนึกภาพลูกค้าคนหนึ่งซื้อของหนึ่งครั้ง เหตุการณ์ "ซื้อ" นี้ควรถูกนับหนึ่ง แต่ในระบบที่มีทั้ง Pixel และ Server-Side สิ่งที่เกิดคือ Pixel ในเบราว์เซอร์ยิงบอกแพลตฟอร์มว่า "มีการซื้อ" หนึ่งครั้ง แล้วเซิร์ฟเวอร์ของคุณก็ยิงบอกอีกครั้งว่า "มีการซื้อ" เช่นกัน กลายเป็นสองสัญญาณสำหรับการซื้อครั้งเดียว
ถ้าแพลตฟอร์มไม่มีทางรู้ว่าสองสัญญาณนี้พูดถึงเหตุการณ์เดียวกัน มันก็จะนับเป็นสอง Conversion อย่างซื่อสัตย์ พอเกิดแบบนี้กับทุกออเดอร์ ยอดรวมในรายงานก็พองขึ้นเกือบเท่าตัว ทำให้คุณเข้าใจผิดว่าแอดทำงานดีกว่าความจริง แล้วอาจตัดสินใจเทงบผิด
อาการนี้ต่างจากการนับซ้ำแบบอื่นที่เกิดจากติดโค้ดหลายรอบในหน้าเดียว ซึ่งเป็นคนละสาเหตุกัน ถ้าคุณเคยเจอปัญหาConversion ซ้ำจากการติดแท็กเบิ้ลมาก่อน อันนั้นแก้ที่การติดตั้ง ส่วนอันนี้แก้ด้วยการทำ deduplication ระหว่าง Pixel กับ Server ซึ่งเป็นเทคนิคเฉพาะกว่า
แนวคิดกันซ้ำ: ให้สองทางถือรหัสเหตุการณ์เดียวกัน
วิธีแก้ที่แพลตฟอร์มออกแบบไว้เรียบง่ายกว่าที่คิด คือให้ทั้ง Pixel และ Server ส่ง "รหัสเหตุการณ์" หรือ Event ID เดียวกันไปพร้อมกับเหตุการณ์นั้น พอแพลตฟอร์มได้รับสองสัญญาณที่มีรหัสเดียวกัน มันก็รู้ทันทีว่าเป็นเหตุการณ์เดียว แล้วเลือกนับแค่ครั้งเดียว
เปรียบเทียบเหมือนออเดอร์ในร้านอาหารที่มีเลขโต๊ะกำกับ ต่อให้พนักงานสองคนเดินมาบอกครัวว่า "โต๊ะ 5 สั่งข้าวผัด" ครัวก็ทำจานเดียว เพราะรู้ว่าเป็นออเดอร์โต๊ะเดียวกัน Event ID ก็ทำหน้าที่เป็นเลขโต๊ะนั้น มันคือตัวบอกว่าสองสัญญาณนี้พูดเรื่องเดียวกัน
หัวใจที่ห้ามพลาดคือรหัสนี้ต้อง "ตรงกันเป๊ะ" ทั้งสองทาง ถ้า Pixel ส่งรหัสหนึ่ง แต่ Server ส่งอีกรหัส แพลตฟอร์มจะมองว่าเป็นคนละเหตุการณ์แล้วนับซ้ำอยู่ดี เพราะฉะนั้นต้องออกแบบให้รหัสนี้ถูกสร้างที่จุดเดียวแล้วส่งต่อให้ทั้งสองทางใช้ค่าเดียวกัน ไม่ใช่ต่างคนต่างสร้าง
แพลตฟอร์มใช้อะไรบ้างในการจับว่าเป็นเหตุการณ์เดียว
นอกจากรหัสเหตุการณ์แล้ว แพลตฟอร์มยังดูปัจจัยประกอบเพื่อยืนยันว่าสองสัญญาณคือเหตุการณ์เดียวกันจริง ตารางนี้สรุปสิ่งที่ควรส่งให้สอดคล้องกันทั้งสองทาง:
| สิ่งที่ส่ง | ควรตรงกันไหม | ถ้าไม่ตรงจะเกิดอะไร |
|---|---|---|
| รหัสเหตุการณ์ (Event ID) | ต้องตรงเป๊ะ | ระบบนับซ้ำ |
| ชื่อเหตุการณ์ | ควรตรงกัน | จับคู่ไม่ติด |
| เวลาเกิดเหตุการณ์ | ควรใกล้กัน | อาจมองเป็นคนละครั้ง |
| ข้อมูลระบุตัวตน (hash) | ยิ่งตรงยิ่งแม่น | ความมั่นใจในการจับคู่ลด |
ลำดับการตั้งค่าให้กันซ้ำได้จริง
ถ้าจะทำให้ deduplication ทำงานถูก ต้องวางลำดับให้รหัสถูกสร้างครั้งเดียวแล้วแชร์กัน นี่คือลำดับที่เข้าใจง่าย:
- สร้างรหัสเหตุการณ์หนึ่งค่าต่อหนึ่งเหตุการณ์จริง เช่นต่อหนึ่งออเดอร์ ไม่ใช่ต่อหนึ่งการยิงสัญญาณ
- ส่งรหัสเดียวกันนี้ให้ Pixel ในเบราว์เซอร์ใช้ ตอนที่เหตุการณ์เกิดบนหน้าเว็บ
- ส่งรหัสเดียวกันนี้ให้ฝั่ง Server ใช้ ตอนที่เซิร์ฟเวอร์ยิงเหตุการณ์กลับแพลตฟอร์ม
- ตั้งชื่อเหตุการณ์และข้อมูลประกอบให้สอดคล้องกันทั้งสองทาง อย่าให้ฝั่งหนึ่งเรียกอย่างอีกฝั่งเรียกอีกอย่าง
- ทดสอบด้วยเครื่องมือตรวจเหตุการณ์ของแพลตฟอร์มว่ามันจับคู่และตัดซ้ำให้จริง ก่อนปล่อยใช้งานเต็ม
วิธีรู้ว่าตัวเลขคุณกำลังโดนนับซ้ำอยู่
ก่อนจะแก้ ต้องรู้ก่อนว่ามีปัญหา สัญญาณเตือนของการนับซ้ำมักชัดถ้ารู้ว่ามองตรงไหน:
- ยอด Conversion ในรายงานสูงกว่ายอดขายจริงมาก — ถ้ารายงานบอกปิดได้เยอะกว่าออเดอร์จริงในระบบหลังบ้านอย่างมีนัย ให้สงสัยการนับซ้ำไว้ก่อน
- ยอดพุ่งขึ้นทันทีหลังเปิด Server-Side — ถ้ากราฟกระโดดพอดีกับวันที่เริ่มใช้ Server โดยที่ค่าแอดและยอดขายจริงไม่ได้เปลี่ยน นั่นคือกลิ่นของการนับซ้ำ
- อัตราส่วน Conversion ต่อคลิกดูดีเกินจริง — ตัวเลขที่สวยจนไม่น่าเชื่อ มักไม่ใช่เพราะเก่งขึ้น แต่เพราะตัวตั้งถูกนับเบิ้ล
- เครื่องมือตรวจของแพลตฟอร์มเตือนเรื่อง deduplication — หลายแพลตฟอร์มมีหน้าตรวจสอบที่บอกว่าเหตุการณ์ถูกจับคู่และตัดซ้ำได้กี่เปอร์เซ็นต์ ถ้าตัวเลขนี้ต่ำแปลว่ากันซ้ำยังไม่เวิร์ก
สรุป
Event Deduplication ไม่ใช่ของแถมที่มีก็ดีไม่มีก็ได้ แต่มันคืองานคู่แฝดของการใช้ Server-Side ตราบใดที่คุณส่งเหตุการณ์ทั้งจาก Pixel และจากเซิร์ฟเวอร์ คุณต้องบอกแพลตฟอร์มให้ได้ว่าอันไหนคือเหตุการณ์เดียวกัน ด้วยรหัสเหตุการณ์ที่ทั้งสองทางถือค่าเดียวกันเป๊ะ ไม่งั้นตัวเลขจะพองจนหลอกทั้งตัวคุณและอัลกอริทึม
ลองตั้งคำถามกับตัวเองวันนี้ว่า ยอด Conversion ในรายงานของคุณสอดคล้องกับยอดขายจริงในระบบหลังบ้านไหม ถ้าตัวเลขในรายงานสูงกว่าจนน่าสงสัย โดยเฉพาะหลังเพิ่งเปิด Server-Side นั่นอาจเป็นสัญญาณว่าคุณกำลังนับซ้ำอยู่ และเป็นจุดแรกที่ควรไปตรวจก่อนจะเชื่อตัวเลขใด ๆ ในการตัดสินใจ
- ใช้ทั้ง Pixel + Server แต่ไม่กันซ้ำ = เหตุการณ์เดียวถูกนับสองรอบ ยอดพองเกินจริง
- แก้ด้วยการให้ทั้งสองทางส่งรหัสเหตุการณ์เดียวกันเป๊ะ (Event ID)
- สัญญาณเตือน: รายงานสูงกว่ายอดจริง หรือยอดพุ่งทันทีหลังเปิด Server-Side
คำถามที่พบบ่อย
ถ้าใช้ Server-Side อย่างเดียวไม่ต้องมี Pixel ก็ไม่ต้องกันซ้ำใช่ไหม
ถูกต้องในแง่ที่ว่าถ้ามีทางส่งทางเดียวก็ไม่มีอะไรมานับซ้ำกัน แต่แนวทางที่แพลตฟอร์มแนะนำคือใช้ทั้งคู่ควบคู่กันเพื่อเก็บข้อมูลให้ครบที่สุด เมื่อใช้ทั้งคู่จึงต้องทำ deduplication เสมอ ไม่งั้นข้อดีของการเก็บครบจะถูกกลบด้วยปัญหานับซ้ำ
รหัสเหตุการณ์ Event ID สร้างยังไง ต้องใช้ข้อมูลลูกค้าไหม
ไม่จำเป็นต้องใช้ข้อมูลลูกค้า มันเป็นแค่ค่าระบุที่ไม่ซ้ำต่อหนึ่งเหตุการณ์ เช่นเลขออเดอร์ที่ระบบสร้างขึ้น สิ่งสำคัญไม่ใช่ว่ามันคือค่าอะไร แต่คือทั้ง Pixel และ Server ต้องใช้ค่าเดียวกันเป๊ะสำหรับเหตุการณ์เดียวกัน
ตั้งค่ากันซ้ำแล้วแต่ยอดยังพองอยู่ เพราะอะไร
สาเหตุที่พบบ่อยคือรหัสเหตุการณ์สองทางไม่ตรงกันจริง เช่นต่างคนต่างสร้างรหัสคนละค่า หรือชื่อเหตุการณ์ที่ส่งไม่ตรงกันจนแพลตฟอร์มมองเป็นคนละอย่าง ลองใช้เครื่องมือตรวจของแพลตฟอร์มดูว่าอัตราการจับคู่และตัดซ้ำเป็นเท่าไหร่ ถ้าต่ำแปลว่ารหัสยังไม่ตรง
การนับซ้ำมีผลเสียแค่ตัวเลขสวยเกินจริงหรือเปล่า
ไม่ใช่แค่นั้น ผลเสียที่หนักกว่าคืออัลกอริทึมเรียนรู้จากข้อมูลที่ผิด เมื่อมันเห็น Conversion พองเกินจริง มันอาจประเมินว่ากลุ่มเป้าหมายหรือช่วงเวลานั้นดีกว่าความจริง แล้วเทงบไปผิดจุด สุดท้ายคือเสียเงินเพราะตัดสินใจจากตัวเลขที่หลอกตัวเอง
ควรตรวจ deduplication บ่อยแค่ไหน
ควรตรวจตอนตั้งค่าครั้งแรกให้ผ่านก่อนปล่อยใช้จริง แล้วตรวจซ้ำทุกครั้งที่มีการเปลี่ยนแปลง เช่นเปลี่ยนหน้าเว็บ เปลี่ยนวิธีสร้างเลขออเดอร์ หรืออัปเดตระบบ เพราะการเปลี่ยนเหล่านี้ทำให้รหัสสองทางหลุดจากกันได้ง่าย นอกจากนั้นควรชำเลืองดูเดือนละครั้งว่ายอดยังสมเหตุสมผลกับยอดขายจริง
ธุรกิจที่ปิดการขายในแชท LINE ต้องกังวลเรื่องนี้ไหม
ต้อง เพราะพอปิดการขายในแชทแล้วส่งกลับด้วย Server-Side ควบคู่กับ Pixel บนหน้าเว็บ ก็มีโอกาสนับซ้ำเหมือนกัน โดยเฉพาะถ้ามีหน้ายืนยันบนเว็บที่ยิง Pixel ด้วย การวางรหัสเหตุการณ์ให้สองทางใช้ค่าเดียวกันจึงสำคัญไม่ต่างจากอีคอมเมิร์ซทั่วไป
บทความที่เกี่ยวข้อง


