เปลี่ยนเว็บใหม่แล้ว Purchase Event หายทั้งหมด กู้คืนยังไงให้ทัน

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

สิ่งที่เกิดขึ้นคือ Script ที่เคยยิง Event ตอนลูกค้ากดยืนยันคำสั่งซื้อ ผูกอยู่กับโครงสร้างหน้าเว็บเดิมที่เพิ่งถูกแทนที่ทั้งหมด ปุ่ม 'ยืนยันคำสั่งซื้อ' ในเว็บใหม่มี ID ต่างจากเดิม ทำให้ Script เก่าหาปุ่มไม่เจอและไม่เคยถูกเรียกใช้งานเลยตั้งแต่เว็บใหม่เปิดตัว เป็นปัญหาที่ไม่มี Error แจ้งเตือนใด ๆ เพราะในสายตาของ Developer เว็บทำงานปกติดีทุกอย่าง

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

ทำไมแค่เปลี่ยนหน้าตาเว็บถึงทำให้ Purchase Event หายได้ทั้งหมด

การ track purchase ผ่าน LINE API ส่วนใหญ่ไม่ได้เกิดขึ้นจาก LINE โดยตรง แต่เกิดจาก Script บนเว็บไซต์หรือระบบหลังบ้านที่ตรวจจับว่าลูกค้ากดยืนยันคำสั่งซื้อสำเร็จ แล้วส่งข้อมูลนั้นต่อไปยังระบบที่เชื่อมกับ LINE เพื่อผูกกับ Lead เดิมและส่ง Conversion กลับแพลตฟอร์มโฆษณา จุดที่ Script นี้ยึดเกาะอยู่ เช่น ID ของปุ่ม โครงสร้าง URL หน้ายืนยันคำสั่งซื้อ หรือ Element บนหน้าเว็บที่บอกว่า 'คำสั่งซื้อสำเร็จ' ล้วนเป็นสิ่งที่เปลี่ยนไปเมื่อทีมออกแบบเว็บใหม่ทั้งหมด

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

ก่อนเปิดเว็บใหม่ ควรตรวจอะไรบ้างเพื่อไม่ให้ Purchase Event หลุด

1. ทำรายการจุดยึดเกาะทั้งหมดที่ Script การ track ใช้อ้างอิงในเว็บเดิม เช่น ID ของปุ่ม Class ของ Element หรือ URL Pattern ของหน้ายืนยันคำสั่งซื้อ แล้วเทียบกับเว็บใหม่ว่าจุดเหล่านี้เปลี่ยนไปหรือไม่
2. ทดสอบ Journey การสั่งซื้อแบบเต็มรูปแบบบนเว็บใหม่ในสภาพแวดล้อมทดสอบ (Staging) ก่อนเปิดใช้งานจริง ไม่ใช่ทดสอบแค่ว่าเว็บโหลดได้ แต่ต้องกดจนถึงขั้นยืนยันคำสั่งซื้อจริงแล้วดูว่า Event ถูกยิงหรือไม่
3. ตรวจสอบว่า Webhook หรือ Credential ที่เชื่อมกับระบบ LINE ยังอ้างอิง Domain หรือ Endpoint ที่ถูกต้องอยู่ เพราะบางครั้งการย้ายเว็บมาพร้อมกับการย้าย Hosting หรือเปลี่ยน Domain ซึ่งกระทบการตั้งค่าที่อ้างอิง URL เดิม
4. เตรียมแผนสำรองไว้ล่วงหน้าว่าถ้า Purchase Event หยุดทำงานหลังเปิดเว็บใหม่ จะทราบได้เร็วแค่ไหน เช่นตั้ง Alert ให้แจ้งเตือนถ้าจำนวน Event ต่อวันตกลงต่ำกว่าค่าเฉลี่ยอย่างมีนัยสำคัญ แทนที่จะรอให้มีคนสังเกตเห็นเองในรายงานประจำเดือน
5. นัดหมายให้มีคนตรวจรายงาน Purchase Event ภายใน 24 ชั่วโมงแรกหลังเปิดเว็บใหม่โดยเฉพาะ ไม่ใช่ปล่อยรวมไปกับงานตรวจสอบทั่วไปที่อาจไม่ได้ให้ความสำคัญกับจุดนี้เป็นพิเศษ

Purchase Event ที่ผูกกับ LINE จริง ๆ แล้วอยู่ตรงไหนบ้างในระบบ

ถ้าพบว่า Purchase Event หยุดทำงานไปแล้วหลายวัน ควรกู้คืนยังไง

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

1. แก้จุดยึดเกาะของ Script การ track ให้ตรงกับโครงสร้างเว็บใหม่ แล้วทดสอบ Journey เต็มรูปแบบอีกครั้งก่อนถือว่าแก้เสร็จ ไม่ใช่แก้โค้ดแล้วสรุปว่าใช้ได้โดยไม่ทดสอบจริง
2. ตรวจสอบว่าคำสั่งซื้อที่เกิดขึ้นในช่วงที่ Event หยุดทำงาน มีข้อมูลเพียงพอให้บันทึกย้อนหลังหรือไม่ เช่นมีเลขที่คำสั่งซื้อ วันเวลา และ LINE user id ของลูกค้าครบถ้วนในระบบบัญชีหรือ CRM
3. ถ้าแพลตฟอร์มโฆษณาที่เชื่อมต่ออยู่รองรับการนำเข้า Offline Conversion ย้อนหลัง ให้ตรวจสอบเงื่อนไขเรื่องระยะเวลาย้อนหลังสูงสุดที่แพลตฟอร์มนั้นยอมรับตามเอกสารล่าสุด ก่อนเตรียมข้อมูลนำเข้า เพราะแต่ละแพลตฟอร์มมีข้อกำหนดต่างกันและอาจเปลี่ยนแปลงได้
4. บันทึกเหตุการณ์นี้ไว้เป็นกรณีศึกษาภายใน ระบุวันที่เกิดปัญหา สาเหตุ และวิธีแก้ เพื่อให้ทีมที่ดูแลเว็บไซต์ในอนาคตรู้ว่าต้องตรวจอะไรก่อนเปลี่ยนแปลงเว็บครั้งต่อไป

ตัวอย่างสมมติ: Purchase Event หายไปสี่วัน กระทบตัวเลขแค่ไหน

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

เมื่อไล่ตรวจข้อมูลย้อนหลัง พบว่า 29 รายการมีข้อมูล LINE user id และเลขที่คำสั่งซื้อครบถ้วนพอจะนำเข้าย้อนหลังได้ ส่วนอีก 5 รายการเป็นคำสั่งซื้อที่ลูกค้าโอนเงินตรงโดยไม่ผ่านขั้นตอนที่ระบบ track ครบ ทำให้ไม่มีข้อมูลเพียงพอจะย้อนกลับไปผูกกับ Journey เดิมได้ สุดท้ายธุรกิจนี้กู้คืนข้อมูลได้ 29 จาก 34 รายการ คิดเป็นราว 85% ของยอดขายที่เกิดขึ้นจริงในช่วงที่ระบบมีปัญหา ตัวเลขทั้งหมดนี้เป็นกรณีสมมติเพื่ออธิบายกรอบวิเคราะห์เท่านั้น

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

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่เจอซ้ำตอนเปลี่ยนเว็บไซต์

• ทำแบบนี้แล้วพัง — เปิดเว็บใหม่โดยไม่ทดสอบ Journey การสั่งซื้อเต็มรูปแบบก่อน เพราะ… ทีมออกแบบเน้นทดสอบว่าเว็บโหลดเร็วและหน้าตาถูกต้อง แต่ไม่ได้ทดสอบว่า Event เบื้องหลังยังทำงานอยู่ ทางแก้คือเพิ่มการทดสอบ Journey เต็มเส้นเป็นขั้นตอนบังคับก่อนเปิดใช้งานจริงทุกครั้ง
• ทำแบบนี้แล้วพัง — ไม่มีระบบแจ้งเตือนเมื่อจำนวน Event ต่อวันตกลงผิดปกติ เพราะ… ไม่มีใครตั้งค่าไว้ตั้งแต่ต้น ทำให้กว่าจะรู้ว่า Event หยุดทำงานต้องรอถึงรอบรายงานถัดไป ทางแก้คือตั้ง Alert อัตโนมัติเทียบค่าเฉลี่ยรายวันไว้ล่วงหน้า
• ทำแบบนี้แล้วพัง — ทีมออกแบบเว็บกับทีมที่ดูแลระบบ Tracking ทำงานแยกกันโดยไม่สื่อสารกันก่อนเปิดเว็บใหม่ เพราะ… ต่างฝ่ายต่างคิดว่าอีกฝ่ายจะจัดการเรื่องนี้เอง ทางแก้คือกำหนดขั้นตอนตรวจสอบ Tracking เป็นส่วนหนึ่งของ Checklist ก่อนเปิดเว็บใหม่ทุกครั้งอย่างเป็นทางการ
• ทำแบบนี้แล้วพัง — ไม่บันทึกข้อมูลคำสั่งซื้อที่เพียงพอสำหรับนำเข้าย้อนหลังในระบบบัญชี เพราะ… คิดว่าระบบ Tracking จะทำงานตลอดไปโดยไม่มีวันพัง ทางแก้คือเก็บ LINE user id และเลขที่คำสั่งซื้อไว้ในระบบบัญชีหรือ CRM เสมอ ไม่ว่าระบบ Tracking หลักจะทำงานปกติหรือไม่ก็ตาม

ข้อจำกัดของการนำเข้า Offline Conversion ย้อนหลังที่ต้องรู้ก่อน

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

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

ก่อนถือว่าระบบ track purchase กลับมาใช้งานได้ปกติแล้ว

หลังแก้ไขจุดที่ Script ยึดเกาะแล้ว ควรทดสอบ Journey จริงอย่างน้อยสามรอบ โดยจำลองสถานการณ์ต่างกัน เช่นสั่งซื้อจากมือถือ สั่งซื้อจากคอมพิวเตอร์ และสั่งซื้อผ่านโปรโมชันพิเศษที่มีหน้าชำระเงินต่างจากปกติ เพื่อให้มั่นใจว่าทุกเส้นทางยิง Event ได้ถูกต้องเหมือนกัน ไม่ใช่แค่เส้นทางหลักเส้นเดียว

การ track purchase ให้แม่นยำต้องอาศัยการ track lead status ที่ถูกต้องมาตั้งแต่ต้นด้วย เพราะ Purchase Event ต้องผูกกลับไปหา Lead เดิมที่มี LINE user id ตรงกัน อ่านเพิ่มเติมเรื่อง LINE API track lead status ประกอบ เพราะเป็นรากฐานเดียวกัน และหากธุรกิจต้องการเข้าใจภาพรวมของการเชื่อมข้อมูลตั้งแต่คลิกโฆษณาจนถึงยอดขาย ควรอ่านเรื่อง LINE webhook ส่งเข้า data warehouse ประกอบด้วย

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

สรุป

Purchase Event ที่หายไปหลังเปลี่ยนเว็บไซต์ ส่วนใหญ่เกิดจาก Script ที่ยึดเกาะโครงสร้างหน้าเว็บเดิมซึ่งไม่มีอยู่แล้วในเว็บใหม่ ไม่ใช่ปัญหาที่ LINE หรือระบบเบื้องหลังอื่นเสียหาย การป้องกันที่ดีที่สุดคือทดสอบ Journey เต็มรูปแบบก่อนเปิดใช้งานจริงทุกครั้ง

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

• Purchase Event มักหายเงียบ ๆ หลังเปลี่ยนเว็บ เพราะ Script ยึดเกาะ ID หรือโครงสร้างหน้าเว็บเดิมที่ไม่มีอยู่แล้ว
• ต้องทดสอบ Journey การสั่งซื้อเต็มรูปแบบใน Staging ก่อนเปิดเว็บใหม่ทุกครั้ง ไม่ใช่แค่ตรวจว่าเว็บโหลดได้
• ตั้งระบบแจ้งเตือนความผิดปกติของจำนวน Event และเก็บข้อมูลคำสั่งซื้อสำรองในระบบบัญชีเสมอ เพื่อกู้คืนได้เร็วเมื่อเกิดปัญหา

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