← กลับไปหน้าบทความ
ขั้นสูง (MarTech)

Event Deduplication: กัน Pixel + Server นับ Conversion ซ้ำ

02 ส.ค. 04:06 · อ่าน 2 นาที
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 ทำงานถูก ต้องวางลำดับให้รหัสถูกสร้างครั้งเดียวแล้วแชร์กัน นี่คือลำดับที่เข้าใจง่าย:

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

วิธีรู้ว่าตัวเลขคุณกำลังโดนนับซ้ำอยู่

ก่อนจะแก้ ต้องรู้ก่อนว่ามีปัญหา สัญญาณเตือนของการนับซ้ำมักชัดถ้ารู้ว่ามองตรงไหน:

  • ยอด 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 ด้วย การวางรหัสเหตุการณ์ให้สองทางใช้ค่าเดียวกันจึงสำคัญไม่ต่างจากอีคอมเมิร์ซทั่วไป

อยากวัดผลโฆษณาเข้า LINE ให้ถึงยอดขาย?

ทดลองใช้ linli ฟรี 14 วัน ไม่ต้องใช้บัตรเครดิต

เริ่มทดลองใช้ฟรี

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

คู่มือเริ่มต้น LINE Conversion Tracking ในไทย ตั้งแต่ติดตั้งจนวัดยอดขายจริง
คู่มือเริ่มต้น LINE Conversion Tracking ในไทย ตั้งแต่ติดตั้งจนวัดยอดขายจริง
สำหรับคนที่เพิ่งเริ่มทำ LINE Conversion Tracking บทความนี้รวมทุกขั้นตอนตั้งแต่นิยาม Funnel ติดตั้งระบบ เชื่อมแพลตฟอร์ม จนถึงวางแผนช่วงทดลองใช้ให้ตัดสินใจได้จริงก่อนหมด Trial
LINE Tracking กับ PDPA ธุรกิจไทยควรเก็บข้อมูลอย่างไรให้เหมาะสม
LINE Tracking กับ PDPA ธุรกิจไทยควรเก็บข้อมูลอย่างไรให้เหมาะสม
ระบบ Tracking ไม่ได้ทำให้ธุรกิจผ่าน PDPA โดยอัตโนมัติ บทความนี้อธิบายว่าธุรกิจยังต้องรับผิดชอบอะไรเองบ้าง ตั้งแต่ Legal Basis ไปจนถึงการจำกัดข้อมูลที่ส่งไปแพลตฟอร์มโฆษณา
วิธีติดตั้ง Tracking Link และ Tracking Script สำหรับปุ่ม LINE บนเว็บไซต์
วิธีติดตั้ง Tracking Link และ Tracking Script สำหรับปุ่ม LINE บนเว็บไซต์
ก่อนติดตั้ง Tracking Link หรือ Script บนปุ่ม LINE ต้องเตรียมอะไรบ้าง บทความนี้เล่าขั้นตอนจริงตั้งแต่สิทธิ์เข้าถึงเว็บ ไปจนถึง Test Journey ก่อนเปิดใช้งาน ไม่ใช่แค่ก็อปโค้ดไปวาง