ตรวจ duplicate conversion LINE ทำไมยอด Lead ในรายงานถึงเบิ้ลจนวางแผนงบผิด

เดือนที่แล้วทีมการตลาดของร้านหนึ่งรายงานว่า Lead จาก LINE เพิ่มขึ้น 40% ทั้งที่งบโฆษณาเท่าเดิมเป๊ะ ทุกคนดีใจกันใหญ่ จนแอดมินหน้างานทักท้วงว่า จำนวนคนที่ทักเข้ามาจริงไม่ได้เพิ่มขนาดนั้น พอไล่ดูในระบบถึงรู้ว่า Lead หนึ่งคนถูกสร้างซ้ำสองถึงสามรายการ เพราะมีทั้ง Event จาก LINE Tag บนเว็บและการบันทึกมือของแอดมินเข้าไปพร้อมกัน

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

บทความนี้จะพาไล่ดูว่า Event ซ้ำเกิดจากจุดไหนได้บ้างในระบบ LINE Conversion Tracking วิธีตรวจให้เจอโดยไม่ต้องเดา และจะวาง Deduplication Key แบบไหนถึงจะกันซ้ำได้จริงโดยไม่ทำให้ Lead ที่ควรนับหายไปด้วย

จุดที่ Event เดิมถูกยิงซ้ำโดยไม่มีใครตั้งใจ

Duplicate ส่วนใหญ่ไม่ได้เกิดจากบั๊กใหญ่โต แต่เกิดจากหลายระบบพยายามทำหน้าที่เดียวกันพร้อมกันโดยไม่รู้ตัว เช่น เว็บไซต์มี LINE Tag ที่ยิง Event 'เพิ่มเพื่อน' อัตโนมัติทุกครั้งที่คนกดปุ่ม แต่แอดมินก็เปิดหน้าจอเห็นแชทใหม่แล้วเข้าไปสร้าง Lead ในระบบ CRM ด้วยมืออีกที ทั้งสองฝั่งไม่เคยคุยกันว่าใครควรเป็นคนสร้าง Record ตัวจริง

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

กรณีที่สามคือคนคนเดียวเพิ่มเพื่อนใหม่หลังจากบล็อกแล้วเพิ่มใหม่ หรือใช้อุปกรณ์คนละเครื่องทักเข้ามา ระบบที่ผูก Identity ด้วย LINE User ID อย่างเดียวอาจมองว่าเป็นคนละคนกับ Record เดิม ทำให้เกิด Lead ใหม่ทั้งที่จริงคือคนเดิมที่กลับมาใหม่

วิธีตรวจให้เจอว่าตรงไหนกำลังนับซ้ำ

วิธีที่ตรงที่สุดไม่ใช่การไล่อ่านทีละแถวในสเปรดชีต แต่คือการจัดกลุ่ม Lead ตาม Identifier เดียวกัน เช่น LINE User ID หรือเบอร์โทร แล้วดูว่าในช่วงเวลาสั้น ๆ (เช่นภายใน 5-10 นาที) มี Record ถูกสร้างมากกว่าหนึ่งครั้งหรือไม่ ถ้าเจอกลุ่มที่ซ้ำถี่ผิดปกติ นั่นคือสัญญาณของ Duplicate ไม่ใช่ลูกค้าใหม่จริง

1. ดึงรายการ Lead ทั้งหมดในช่วง 7 วันล่าสุด พร้อมคอลัมน์ Timestamp และ LINE User ID หรือเบอร์โทร
2. จัดกลุ่มตาม Identifier เดียวกัน แล้วเรียงตามเวลา ดูว่ามีคู่ไหนห่างกันน้อยกว่า 10 นาทีบ้าง
3. เปิด Record คู่ที่สงสัยไปดูแหล่งที่มา (Source System) ว่ามาจาก Tag อัตโนมัติ, Webhook หรือแอดมินกรอกมือ
4. นับสัดส่วน Duplicate ต่อ Lead ทั้งหมดในสัปดาห์นั้น ถ้าเกิน 5-10% ถือว่าสูงพอที่ต้องแก้ระดับระบบ ไม่ใช่แค่ลบทิ้งรายตัว

ออกแบบ Deduplication Key ที่ครอบคลุมทุกจุดยิง Event

Deduplication Key ที่ดีต้องตอบให้ได้ว่า 'Event นี้กับ Event นั้นคือเหตุการณ์เดียวกันหรือคนละเหตุการณ์' ไม่ใช่แค่ใช้ Timestamp เพราะสองคนละคนก็อาจทักเข้ามาพร้อมกันได้ และไม่ใช่ใช้ LINE User ID อย่างเดียว เพราะคนเดิมอาจมีเหตุการณ์ที่ควรนับใหม่จริง เช่น ซื้อซ้ำในเดือนถัดไป

แนวทางที่ใช้ได้จริงคือรวม Identifier กับ Business Meaning เข้าด้วยกัน เช่น 'LINE User ID + ประเภท Event + ช่วงเวลาที่ยอมรับได้ว่าเป็นเหตุการณ์เดียวกัน' อย่าง Add Friend ควรกันซ้ำได้ตลอดไปเพราะเพิ่มเพื่อนได้ครั้งเดียวจริง ๆ ในทางเทคนิค ส่วน Lead หรือ Order ควรกำหนดหน้าต่างเวลาที่เหมาะกับสินค้า เช่น 24-48 ชั่วโมง ไม่ให้คนเดิมทักซ้ำในวันเดียวกลายเป็น Lead ใหม่ทุกครั้ง

ตกลงกันก่อนว่าใครเป็นคนสร้าง Record ตัวจริง

ปัญหาโครงสร้างที่ทำให้ Duplicate เกิดซ้ำไม่จบคือไม่มีใครตัดสินว่าระบบไหนเป็นเจ้าของการสร้าง Lead ตัวจริง ถ้าทั้ง Tag อัตโนมัติและแอดมินต่างสร้าง Record ได้พร้อมกัน ต่อให้แก้ Deduplication Key ดีแค่ไหนก็จะมีเคสหลุดเสมอ วิธีที่ยั่งยืนกว่าคือกำหนดให้ระบบอัตโนมัติเป็นคนสร้าง Record เริ่มต้น แล้วให้แอดมินทำหน้าที่ 'อัปเดตสถานะ' ของ Record ที่มีอยู่แล้วแทนการสร้างใหม่ทุกครั้ง

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

Duplicate ส่งผลต่อรายงานแต่ละชั้นต่างกันแค่ไหน

Duplicate ไม่ได้แค่ทำให้ตัวเลข Lead ดูดีเกินจริง มันไหลไปกระทบชั้นอื่นด้วย ตารางนี้สรุปว่าผลกระทบต่างกันยังไงตามชั้นของรายงาน:

แก้ที่ต้นเหตุกับการล้างข้อมูลย้อนหลัง คนละงานกัน

• การล้าง Duplicate ที่เกิดไปแล้วในอดีต ควรทำแบบระบุ Record คู่ที่ซ้ำชัดเจนแล้ว Merge หรือ Archive ไม่ใช่ลบทิ้งดื้อ ๆ เพราะอาจมีข้อมูลการติดต่อที่ต่างกันในแต่ละ Record
• การแก้ต้นเหตุต้องเข้าไปที่ระบบที่ยิง Event เช่น ปรับ Tag ให้ยิงครั้งเดียวต่อ Session, เพิ่ม Event ID Check ที่ปลายทาง Webhook, หรือปิดสิทธิ์ให้แอดมินสร้าง Lead ใหม่เมื่อ Record เดิมยังเปิดอยู่
• ถ้าทำแค่ล้างข้อมูลเก่าโดยไม่แก้ต้นเหตุ Duplicate ชุดใหม่จะกลับมาสะสมอีกในเดือนถัดไป และทีมจะต้องมานั่งไล่ล้างซ้ำไปเรื่อย ๆ โดยไม่รู้ตัวว่าเป็นงานที่ไม่ควรต้องทำซ้ำเลย

ตัวอย่างสมมติ ลองไล่ตัวเลขให้เห็นภาพ

สมมติร้านค้าออนไลน์แห่งหนึ่งรายงานว่าสัปดาห์ที่แล้วมี Lead จาก LINE เข้ามา 210 รายการ ค่าแอดที่จ่ายไปช่วงเดียวกันอยู่ที่ 42,000 บาท คำนวณคร่าว ๆ ได้ต้นทุนต่อ Lead ราว 200 บาท ซึ่งดูดีกว่าเดือนก่อนหน้าที่อยู่ราว 260 บาทต่อ Lead อย่างชัดเจน ทีมเลยเตรียมเสนอเพิ่มงบในสัปดาห์ถัดไป

แต่พอเจ้าของร้านลองสุ่มไล่ดูรายการ Lead ตาม LINE User ID เดียวกัน กลับพบว่ามีอยู่ 38 รายการที่เกิดจากคนเดิมทักซ้ำภายใน 5 นาที เพราะแอดมินสร้าง Record ด้วยมือไปพร้อมกับที่ Tag บนเว็บไซต์ยิง Event อัตโนมัติ เท่ากับว่า Lead จริงมีเพียง 172 รายการ ไม่ใช่ 210 รายการ เมื่อคำนวณใหม่ ต้นทุนต่อ Lead ที่แท้จริงจึงขยับขึ้นไปอยู่ที่ราว 244 บาท ใกล้เคียงเดือนก่อนหน้ามากกว่า ไม่ได้ดีขึ้นแบบที่ตัวเลขดิบบอกไว้

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

ทำแบบนี้แล้วพัง เพราะ… บทเรียนจากทีมที่เจอปัญหาซ้ำ

• ปิด Duplicate ด้วยการลบ Record ใหม่ล่าสุดทิ้งเสมอ โดยไม่เช็กก่อนว่า Record ไหนมีข้อมูลติดต่อครบกว่ากัน — พังเพราะบางทีข้อมูลที่ถูกลบกลับเป็นชุดที่แอดมินกรอกเบอร์โทรและที่อยู่ไว้ครบแล้ว
• ตั้งกฎกันซ้ำแบบเดียวใช้กับทุก Event โดยไม่แยกว่าเป็น Add Friend หรือ Order — พังเพราะ Add Friend ควรกันซ้ำตลอดไป แต่ Order ควรนับใหม่ได้ทุกครั้งที่มีการซื้อจริง
• แก้ปัญหาด้วยการปิดสิทธิ์แอดมินไม่ให้สร้าง Lead เองเลยทันทีโดยไม่แจ้งล่วงหน้า — พังเพราะมีบางเคสที่ลูกค้าทักผ่านช่องทางที่ไม่มี Tag อัตโนมัติ เช่น โทรเข้ามาตรง ๆ แล้วแอดมินไม่มีทางบันทึกเข้าระบบได้เลย

ระวังอีกด้าน อย่ากันซ้ำจนลูกค้าใหม่หายไปด้วย

การกันซ้ำที่เข้มเกินไปก็เป็นปัญหาอีกแบบหนึ่ง เช่น ตั้งกฎว่า LINE User ID เดิมจะไม่ถูกนับเป็น Lead ใหม่อีกเลยตลอดไป ทั้งที่ในความเป็นจริง ลูกค้าคนเดิมอาจกลับมาซื้อสินค้าคนละหมวดในอีกหกเดือนถัดมา ถ้ากันซ้ำแบบนี้จะทำให้ Lead ที่ควรนับเป็นโอกาสขายใหม่หายไปจากรายงานทั้งที่ควรถูกนับ

หลักที่ปลอดภัยกว่าคือกำหนดหน้าต่างเวลาของการกันซ้ำให้เหมาะกับ Sales Cycle ของธุรกิจนั้น ๆ ธุรกิจที่ตัดสินใจซื้อเร็วอย่างร้านอาหารอาจใช้หน้าต่าง 24 ชั่วโมง ส่วนธุรกิจที่รอบการซื้อยาวอย่างอสังหาริมทรัพย์อาจต้องยาวเป็นสัปดาห์ ไม่มีตัวเลขตายตัวที่ใช้ได้กับทุกธุรกิจ

วางรอบตรวจ Duplicate เป็นงานประจำ ไม่ใช่ทำตอนมีปัญหา

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

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

สรุป

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

จุดสำคัญที่สุดไม่ใช่เครื่องมือ แต่คือการตกลงกันในทีมว่าใครเป็นเจ้าของการสร้าง Record ตัวจริง แล้วออกแบบ Deduplication Key ให้เหมาะกับรอบการตัดสินใจซื้อของธุรกิจตัวเอง ไม่ใช่ก็อปกฎจากธุรกิจอื่นมาใช้ตรง ๆ

• Duplicate มักเกิดจาก Tag อัตโนมัติกับแอดมินสร้าง Record ซ้ำกันโดยไม่รู้ตัว
• ตรวจด้วยการจัดกลุ่ม Lead ตาม Identifier เดียวกันแล้วดูความถี่ในช่วงเวลาสั้น ๆ
• แก้ที่ต้นเหตุ (สิทธิ์การสร้าง Record + Deduplication Key) ไม่ใช่แค่ล้างข้อมูลเก่า
• ควรตรวจ Event ID ซ้ำด้วยเทคนิคที่ละเอียดกว่านี้ ดูเพิ่มเติมได้ที่การตรวจจับ Event ซ้ำอย่างเป็นระบบ
• หากใช้ GA4 ร่วมด้วย ควรเช็กการกันซ้ำด้วย Transaction ID ใน GA4เพื่อไม่ให้ Order เดิมถูกนับซ้ำอีกชั้น

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