ทำไมยอด Lead ใน Google Sheets ไม่เท่ากับจำนวนแชทจริงใน LINE OA

ทีมการตลาดเปิด Google Sheets ที่เชื่อมกับ LINE webhook เพื่อดูรายชื่อ Lead ประจำวัน เห็นตัวเลขรวม 42 แถวในวันนี้ แต่พอเข้าไปเช็คในหน้าแชท LINE Official Account Manager กลับนับได้ 58 การสนทนาใหม่ ตัวเลขสองฝั่งต่างกันเกือบ 30% ทั้งที่ควรจะเป็นข้อมูลชุดเดียวกัน คำถามที่ตามมาคือ Google Sheets รายงานตกหล่นหรือ LINE OA นับเกินกันแน่

ความจริงแล้วทั้งสองฝั่งอาจไม่ได้ผิดเลยสักฝั่ง เพราะ 'จำนวนแชท' ที่เห็นใน LINE OA กับ 'จำนวน Lead' ที่ควรบันทึกใน Google Sheets เป็นคนละนิยามกันตั้งแต่ต้น การสนทนาบางอย่างอาจไม่ควรนับเป็น Lead เช่นข้อความสแปมหรือคนที่บล็อกบัญชีไปแล้วกลับมาทัก ในขณะที่บางแถวใน Sheets อาจถูกเขียนซ้ำโดยไม่ตั้งใจจากการที่ Webhook ยิงมาซ้ำมากกว่าหนึ่งครั้ง

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

ทำไมนิยาม 'แชท' กับ 'Lead' ถึงไม่ใช่สิ่งเดียวกัน

หน้าแชทใน LINE Official Account Manager นับทุกการสนทนาที่เกิดขึ้น ไม่ว่าจะเป็นคนที่ตั้งใจสอบถามสินค้าจริง คนที่ทักผิดบัญชี หรือแม้แต่ข้อความอัตโนมัติบางประเภทที่ระบบสร้างขึ้นเอง ในขณะที่ Google Sheets ที่เชื่อมผ่าน Webhook ควรถูกออกแบบให้บันทึกเฉพาะ Event ที่ตรงกับนิยาม Lead ของธุรกิจ เช่นข้อความแรกจากผู้ใช้ใหม่ที่ไม่เคยเพิ่มเพื่อนมาก่อน

ถ้าระบบที่รับ Webhook ไม่ได้กรอง Event ให้ตรงกับนิยามนี้ตั้งแต่ต้น จำนวนแถวใน Sheets กับจำนวนแชทใน LINE OA จะไม่มีวันตรงกันเป๊ะ ซึ่งเป็นเรื่องปกติที่ต้องยอมรับ ไม่ใช่สัญญาณว่าระบบพัง แต่ก็ต้องเข้าใจให้ชัดว่าความต่างนี้มาจากนิยามที่ต่างกัน ไม่ใช่ข้อมูลตกหล่นเสมอไป

สาเหตุที่พบบ่อยที่สุดของความคลาดเคลื่อนระหว่าง Sheets กับ LINE OA

• Webhook ยิง Event เดิมซ้ำมากกว่าหนึ่งครั้งเมื่อเซิร์ฟเวอร์ปลายทางตอบกลับช้าหรือมีปัญหาชั่วคราว ทำให้ Google Sheets เขียนแถวซ้ำสำหรับเหตุการณ์เดียวกัน
• ระบบไม่ได้กรอง Event ประเภทที่ไม่ควรนับเป็น Lead เช่นข้อความจากบัญชีที่บล็อกไปแล้ว หรือ Event ประเภท Postback ที่เกิดจากปุ่มในเมนูซึ่งไม่ใช่การเริ่มสนทนาจริง
• มีคนในทีมแก้ไขหรือลบแถวใน Google Sheets ด้วยมือโดยตรง โดยไม่ผ่านระบบที่ควบคุมไว้ ทำให้ข้อมูลเบี่ยงเบนจากสิ่งที่ Webhook ส่งมาจริง
• Time Zone ของ Timestamp ที่บันทึกใน Sheets ไม่ตรงกับ Time Zone ที่ใช้ดูรายงานใน LINE OA ทำให้เมื่อกรองข้อมูล 'วันนี้' ได้ตัวเลขที่ต่างกันทั้งที่ข้อมูลจริงเหมือนกัน
• Google Sheets มีข้อจำกัดเรื่องจำนวนแถวและความเร็วในการเขียนข้อมูลพร้อมกันหลายรายการ ถ้า Lead เข้ามาพร้อมกันจำนวนมากในเวลาสั้น ๆ อาจมีบางรายการเขียนไม่ทันหรือเกิดข้อผิดพลาดโดยไม่มีใครสังเกต

ขั้นตอนตั้งค่า Webhook ให้เข้ากับ Google Sheets อย่างถูกต้อง

1. กำหนด Event ประเภทที่ควรบันทึกเป็นแถวใหม่ใน Sheets ให้ชัดเจนตั้งแต่ต้น เช่นเฉพาะข้อความแรกจากผู้ใช้ใหม่ ไม่ใช่ทุกข้อความที่ส่งเข้ามา
2. สร้างกลไกตรวจสอบความซ้ำก่อนเขียนแถวใหม่ เช่นเช็คว่า LINE user id กับช่วงเวลาที่ใกล้เคียงกันมีแถวอยู่แล้วหรือยัง ก่อนเพิ่มแถวใหม่ทุกครั้ง
3. บันทึก Timestamp ด้วย Time Zone เดียวกับที่ทีมใช้ดูรายงานเสมอ และระบุ Time Zone นั้นไว้ในหัวตารางให้ชัดเจน เพื่อไม่ให้เกิดความสับสนภายหลัง
4. จำกัดสิทธิ์การแก้ไข Google Sheets ให้เฉพาะระบบที่เขียนผ่าน Webhook เท่านั้น หากต้องการแก้ไขข้อมูลด้วยมือ ควรทำในคอลัมน์แยกต่างหากที่ไม่ปนกับข้อมูลดิบจาก Webhook
5. ตั้งระบบแจ้งเตือนเมื่อ Webhook เขียนข้อมูลล้มเหลว เพื่อให้รู้ทันทีว่า Google Sheets เริ่มไม่สะท้อนความจริงแล้ว

Google Sheets เหมาะกับงานแบบไหน เมื่อไหร่ควรย้ายไประบบอื่น

ตัวอย่างสมมติ: ไล่หาว่าตัวเลขที่หายไปอยู่ตรงไหน

สมมติวันหนึ่งมีการสนทนาใหม่ใน LINE OA รวม 58 รายการ แต่ Google Sheets บันทึกไว้เพียง 42 แถว เมื่อไล่ตรวจทีละสาเหตุ พบว่า 9 รายการเป็น Event ประเภท Postback จากปุ่มใน Rich Menu ที่ไม่ควรนับเป็น Lead ตั้งแต่ต้น อีก 4 รายการเป็นข้อความซ้ำจากผู้ใช้เดิมที่เคยทักไปแล้วก่อนหน้านี้ในวันเดียวกัน และอีก 3 รายการหายไปจริงเพราะ Webhook เขียนข้อมูลไม่สำเร็จในช่วงเวลาสั้น ๆ ที่ระบบมีปัญหา

เมื่อหักส่วนที่ไม่ควรนับเป็น Lead ออกไป ตัวเลขที่ควรจะมีจริงอยู่ที่ 49 รายการ ไม่ใช่ 58 หรือ 42 ซึ่งหมายความว่ามีเพียง 3 รายการเท่านั้นที่เป็นข้อมูลตกหล่นจริง ส่วนที่เหลือคือความต่างของนิยามที่ต้องเข้าใจให้ถูกต้อง ตัวเลขนี้เป็นตัวอย่างสมมติเพื่ออธิบายกรอบวิเคราะห์เท่านั้น

บทเรียนจากตัวอย่างนี้คือ ก่อนสรุปว่าระบบมีปัญหาข้อมูลตกหล่น ควรไล่แยกสาเหตุทีละกลุ่มก่อนเสมอ เพราะถ้ารีบสรุปว่า Webhook พังทั้งหมด อาจเสียเวลาไปกับการแก้ปัญหาผิดจุด

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่เจอซ้ำกับ Google Sheets

• ทำแบบนี้แล้วพัง — ให้หลายคนในทีมแก้ไข Google Sheets ตรงได้อิสระโดยไม่มีการควบคุม เพราะ… ข้อมูลดิบจาก Webhook ถูกทับหรือแก้ไขโดยไม่ตั้งใจ ทำให้ไม่สามารถย้อนกลับไปดูข้อมูลต้นฉบับได้อีก ทางแก้คือแยกคอลัมน์สำหรับข้อมูลดิบออกจากคอลัมน์ที่ทีมแก้ไขเพิ่มเติม
• ทำแบบนี้แล้วพัง — ไม่มีกลไกตรวจสอบความซ้ำก่อนเขียนแถวใหม่ เพราะ… เมื่อ Webhook ยิงซ้ำจากปัญหาเครือข่ายชั่วคราว ระบบเขียนแถวซ้ำโดยไม่รู้ตัว ทำให้ยอด Lead ดูสูงเกินจริง ทางแก้คือเช็ค LINE user id กับช่วงเวลาก่อนเขียนแถวใหม่ทุกครั้ง
• ทำแบบนี้แล้วพัง — ใช้ Google Sheets เป็นระบบหลักต่อไปแม้ Lead เพิ่มขึ้นจนเกินความสามารถที่ Sheets รองรับได้ดี เพราะ… ทีมคุ้นเคยกับ Sheets จึงไม่อยากเปลี่ยน ทั้งที่เริ่มเห็นปัญหาการเขียนข้อมูลไม่ทันหรือไฟล์โหลดช้าลงเรื่อย ๆ ทางแก้คือประเมินปริมาณ Lead เป็นระยะ แล้ววางแผนย้ายไประบบที่รองรับได้ดีกว่าก่อนที่ปัญหาจะกระทบการทำงานจริง
• ทำแบบนี้แล้วพัง — ไม่เคยเทียบตัวเลขใน Sheets กับจำนวนแชทจริงใน LINE OA เลยตั้งแต่ติดตั้งระบบ เพราะ… ไม่มีใครรู้ว่าความคลาดเคลื่อนมีอยู่จนกว่าจะมีคนสงสัยโดยบังเอิญ ทางแก้คือกำหนดรอบตรวจสอบเทียบตัวเลขทั้งสองฝั่งเป็นประจำ เช่นทุกสัปดาห์ ไม่ใช่รอให้มีปัญหาก่อนถึงจะตรวจ

Apps Script มีโควตาและเวลาทำงานจำกัด ใช้ไปนาน ๆ แล้วเจอปัญหาอะไรได้บ้าง

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

ปัญหานี้ไม่ค่อยแสดงอาการตอนเริ่มติดตั้งใหม่ ๆ เพราะ Lead ยังน้อย แต่จะเริ่มโผล่เมื่อธุรกิจโตขึ้นและมีคนทักเข้ามาพร้อมกันหลายสิบคนในช่วงเวลาสั้น ๆ เช่นตอนมีโปรโมชันใหญ่หรือลงโฆษณาพร้อมกันหลายแคมเปญ ถ้าสคริปต์เขียนไม่รัดกุม การเขียนแถวลง Sheets แบบทีละครั้งอาจช้าลงเรื่อย ๆ เมื่อจำนวนแถวสะสมมากขึ้น เพราะ Apps Script ต้องเปิดไฟล์และอ่านโครงสร้างชีททั้งหมดทุกครั้งที่ทำงาน ไม่ใช่แค่เขียนแถวใหม่อย่างเดียว

สิ่งที่ควรทำเพื่อลดความเสี่ยงนี้คือแยก Trigger ให้ทำงานเป็นชุดแทนที่จะประมวลผลทีละ Event ทันที เช่นเก็บ Event ไว้ในคิวชั่วคราวก่อนแล้วค่อยเขียนลง Sheets เป็นแบตช์ทุกไม่กี่นาที และตั้งระบบแจ้งเตือนเมื่อสคริปต์ error หรือรันไม่ทัน เพราะ Apps Script จะไม่ retry ให้อัตโนมัติเสมอไปเมื่อชนโควตา บางกรณี Event นั้นจะหายไปเงียบ ๆ โดยไม่มีการแจ้งเตือนใด ๆ ถ้าไม่ได้ตั้งระบบตรวจสอบไว้เอง

Webhook ยิงซ้ำแล้วชีทเขียนแถวซ้ำ ป้องกันยังไงให้ตรงจุด

LINE จะส่ง Webhook Event ซ้ำเมื่อเซิร์ฟเวอร์ปลายทางไม่ตอบกลับด้วยสถานะสำเร็จภายในเวลาที่กำหนด ถ้า Apps Script กำลังทำงานช้าอยู่แล้วจากปัญหาโควตาในหัวข้อก่อนหน้า โอกาสที่จะตอบกลับไม่ทันแล้วโดน retry ก็ยิ่งสูงขึ้นตามไปด้วย ผลคือ Event เดียวกันถูกเขียนลง Sheets สองหรือสามครั้ง ทำให้ยอด Lead ที่นับได้สูงเกินจริง

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

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

ใครเห็น Google Sheets แผ่นนี้ได้บ้าง เกี่ยวอะไรกับ PDPA

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

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

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

รู้ได้ยังไงว่าถึงเวลาต้องย้ายออกจาก Google Sheets แล้ว

ย้ายออกจาก Sheets ไม่ต้องทำทีเดียวทั้งระบบ

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

การย้ายไม่จำเป็นต้องเปลี่ยนทั้งระบบในคราวเดียว หลายทีมเลือกใช้ฐานข้อมูลง่าย ๆ อย่าง Airtable หรือระบบ CRM ขนาดเล็กเป็นขั้นกลางก่อน แล้วค่อยพิจารณาระบบที่ซับซ้อนขึ้นเมื่อ Workflow การขายซับซ้อนตามไปด้วย สิ่งสำคัญคือให้ Webhook Event Schema ที่ออกแบบไว้ตั้งแต่ต้นรองรับการย้ายปลายทางได้โดยไม่ต้องเขียนระบบรับ Event ใหม่ทั้งหมด

ก่อนเชื่อตัวเลขใน Google Sheets ควรตรวจอะไรบ้าง

ก่อนนำตัวเลขจาก Google Sheets ไปใช้รายงานผลหรือคำนวณต้นทุนต่อ Lead ควรเทียบกับจำนวนแชทจริงใน LINE OA อย่างน้อยสัปดาห์ละครั้ง แล้วไล่แยกสาเหตุของความต่างตามแนวทางที่เล่ามาในบทความนี้ หากพบว่าสัดส่วนข้อมูลตกหล่นจริงสูงกว่าที่ยอมรับได้ ควรพิจารณาทั้งการปรับปรุงระบบ Webhook และพิจารณาย้ายไปใช้ระบบฐานข้อมูลที่รองรับได้ดีกว่า

การออกแบบ Event ที่ควรบันทึกเป็น Lead ควรทำให้สอดคล้องกับ Schema ที่ใช้ในระบบอื่นด้วย เพื่อให้เทียบข้อมูลข้ามระบบได้ง่าย อ่านเพิ่มเติมเรื่อง LINE webhook event schema ประกอบ เพราะเป็นรากฐานเดียวกับการออกแบบว่า Event ไหนควรนับเป็น Lead ที่พูดถึงในบทความนี้ และหากธุรกิจเริ่มมี Lead เยอะจนต้องขยายไปเก็บข้อมูลระยะยาว ควรอ่านเรื่อง LINE webhook ส่งเข้า data warehouse ประกอบด้วย

linli ช่วยในส่วนของการกรอง Event จาก LINE ให้ตรงกับนิยาม Lead ที่ตั้งไว้ ก่อนส่งต่อไปยังปลายทางที่ธุรกิจเลือกใช้ ทำให้ลดปัญหาการนับ Event ที่ไม่ควรเป็น Lead ปนเข้ามาในรายงาน แต่การตรวจสอบเทียบตัวเลขเป็นประจำและการตัดสินใจว่าเมื่อไหร่ควรย้ายจาก Sheets ไประบบอื่น ยังเป็นหน้าที่ของทีมธุรกิจที่ต้องประเมินเอง

สรุป

ความคลาดเคลื่อนระหว่าง Google Sheets กับจำนวนแชทจริงใน LINE OA ส่วนใหญ่ไม่ใช่เรื่องของข้อมูลตกหล่น แต่เป็นเรื่องของนิยามที่ต่างกันระหว่างสองระบบ การไล่แยกสาเหตุทีละกลุ่มตามที่เล่าในบทความนี้ จะช่วยให้รู้ว่าตัวเลขจริงที่ควรเชื่อได้คือเท่าไหร่

สิ่งที่ควรทำต่อจากนี้คือกำหนดรอบตรวจสอบเทียบตัวเลขทั้งสองฝั่งเป็นประจำ และเมื่อ Lead เริ่มมากขึ้นเรื่อย ๆ จนเกินกำลังที่ Google Sheets รองรับได้ดี ควรเริ่มวางแผนย้ายไประบบที่ออกแบบมาสำหรับข้อมูลปริมาณมากตั้งแต่เนิ่น ๆ

• ความต่างระหว่าง Sheets กับ LINE OA ส่วนใหญ่มาจากนิยาม Event ไม่ตรงกัน ไม่ใช่ข้อมูลหายทั้งหมด
• ต้องมีกลไกกันข้อมูลซ้ำและระบบแจ้งเตือนเมื่อ Webhook เขียนข้อมูลล้มเหลว
• เมื่อ Lead เยอะขึ้นจนเกินกำลัง Sheets ควรวางแผนย้ายไประบบฐานข้อมูลที่รองรับได้ดีกว่า

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