Access Token ของ Conversion API หมดอายุแบบไม่มีเตือน แล้วใครจะรู้ก่อนลูกค้า
สรุปสั้น ๆ
Access token ที่ใช้ยิง Conversion API มีอายุการใช้งานจำกัดแตกต่างกันไปตามประเภท บางแบบหมดอายุใน 60 วัน บางแบบยาวกว่านั้น แต่ทุกแบบมีจุดร่วมเดียวกันคือมักไม่มีการแจ้งเตือนล่วงหน้าจากแพลตฟอร์มเอง การรู้ตัวก่อนหมดอายุต้องอาศัยระบบเตือนที่ทีมตั้งขึ้นเอง ไม่ใช่รอให้แพลตฟอร์มเตือนให้
เอเจนซี่แห่งหนึ่งเจอเหตุการณ์ที่ผมได้ยินซ้ำแล้วซ้ำเล่าในรูปแบบต่าง ๆ กัน คือช่วงเช้าวันจันทร์ ลูกค้าโทรมาถามว่าทำไมแคมเปญที่เคยได้ผลดีจู่ ๆ ก็แย่ลงตั้งแต่วันศุกร์ที่แล้ว เช็คแล้วพบว่า access token ที่ผูกกับ Conversion API หมดอายุไปตั้งแต่เช้าวันศุกร์ นั่นแปลว่า event ทุกตัวหายไปตั้งแต่ก่อนเข้าวันหยุดสุดสัปดาห์ แต่ไม่มีใครรู้จนกว่าลูกค้าจะโทรมาถาม
จุดที่ทำให้เรื่องนี้เกิดขึ้นซ้ำ ๆ ไม่ใช่เพราะทีมประมาท แต่เพราะ token หมดอายุเป็นเรื่องที่ไม่มีใครนึกถึงจนกว่าจะเจอปัญหา มันไม่เหมือนบั๊กที่เห็นผลทันทีตอน deploy แต่เป็นเหมือนระเบิดเวลาที่ตั้งไว้ตั้งแต่วันแรกที่สร้าง token แล้วรอวันระเบิดแบบเงียบ ๆ
ประเภท Token ที่ต้องรู้จัก และอายุการใช้งานโดยประมาณ
| ประเภท Token | อายุการใช้งานโดยประมาณ | ข้อสังเกต |
|---|---|---|
| Short-lived token | ไม่กี่ชั่วโมงถึง 1-2 วัน | เหมาะกับทดสอบ ไม่ควรใช้ใน production |
| Long-lived token | ประมาณ 60 วัน (แล้วแต่แพลตฟอร์ม) | ต้องมีระบบต่ออายุก่อนหมด ไม่ใช่รอให้หมดแล้วค่อยแก้ |
| System user token | ไม่มีวันหมดอายุตายตัว จนกว่าจะถูกเพิกถอน | เหมาะกับระบบอัตโนมัติระยะยาว แต่ต้องดูแลเรื่องสิทธิ์การเข้าถึงให้ดี |
อาการที่บอกว่า Token หมดอายุ ไม่ใช่ปัญหาอื่น
จุดสังเกตที่ชัดที่สุดคือ event หยุดส่งแบบทันที ‘ทุกตัวพร้อมกัน’ ไม่ใช่หายบางส่วนหรือหายเฉพาะบางเงื่อนไข ต่างจากปัญหา event ID ไม่ตรงกันที่มักหายเฉพาะบางเคส หรือปัญหา event ไม่ยิงจากหลายสาเหตุที่มักมีอาการปนกัน เพราะ token หมดอายุกระทบการเชื่อมต่อทั้งหมดพร้อมกันในคราวเดียว
อีกจุดคือเวลาที่หายมักตรงกับวันครบกำหนดพอดี ถ้าลองไล่ดูว่า token นี้สร้างขึ้นเมื่อไหร่แล้วบวกอายุการใช้งานเข้าไป จะเจอว่าตรงกับวันที่ event เริ่มหายพอดิบพอดี นี่คือสัญญาณที่ชัดเจนกว่าการเดาสาเหตุอื่น
ขั้นตอนต่ออายุและตั้งระบบเตือนล่วงหน้า
- บันทึกวันที่สร้าง token และวันที่คาดว่าจะหมดอายุไว้ในที่ที่ทีมเข้าถึงได้ง่าย ไม่ใช่รู้อยู่คนเดียวในหัวของคนที่สร้างมัน
- ตั้งการแจ้งเตือนล่วงหน้าอย่างน้อย 1-2 สัปดาห์ก่อนวันหมดอายุ เพื่อให้มีเวลาต่ออายุก่อนเกิดปัญหาจริง
- พิจารณาเปลี่ยนไปใช้ system user token สำหรับระบบที่ต้องทำงานต่อเนื่องระยะยาว แทน long-lived token ที่ต้องคอยต่ออายุซ้ำ ๆ
- หลังต่ออายุทุกครั้ง ให้ทดสอบยิง event จริงหนึ่งตัวเพื่อยืนยันว่า token ใหม่ใช้งานได้จริง ไม่ใช่แค่เปลี่ยนแล้วสมมติว่าใช้ได้เลย
- ทำเอกสารสั้น ๆ บันทึกว่า token แต่ละตัวผูกกับ integration ไหนบ้าง เพื่อไม่ให้ต้องไล่หาว่าตัวไหนเชื่อมกับอะไรตอนเกิดปัญหาฉุกเฉิน
เฝ้าดูสุขภาพของ Token อย่างต่อเนื่อง
นอกจากตั้งเตือนล่วงหน้าตามวันหมดอายุแล้ว ควรมีการตรวจสอบเชิงรุกด้วยว่า token ยังใช้งานได้จริงอยู่หรือไม่ เพราะบางครั้ง token อาจถูกเพิกถอนก่อนกำหนดจากการเปลี่ยนแปลงสิทธิ์บัญชี ไม่ใช่แค่หมดอายุตามเวลาเพียงอย่างเดียว
วิธีที่ทำได้ง่ายคือยิง request ทดสอบเบา ๆ เป็นระยะเพื่อยืนยันสถานะ ด้วยtest event tool แล้วแจ้งเตือนทันทีถ้าพบว่า token ใช้งานไม่ได้ ไม่ว่าจะจากสาเหตุหมดอายุหรือถูกเพิกถอนก็ตาม
สรุป
token ก็เหมือนกุญแจที่ต้องเช็ควันหมดอายุเป็นประจำ ไม่ใช่เสียบไว้แล้วลืมไปเลยจนกว่าประตูจะล็อกตัวเองในวันที่ไม่คาดคิด
ความเสียหายจาก token หมดอายุมักไม่ได้มาจากตัว token เอง แต่มาจากการไม่มีระบบเตือนล่วงหน้าที่ทำให้ทีมรู้ตัวทันเวลา
- บันทึกวันสร้างและวันหมดอายุของทุก token ไว้ในที่ทีมเข้าถึงได้ง่าย
- ตั้งแจ้งเตือนล่วงหน้าอย่างน้อย 1-2 สัปดาห์ก่อนหมดอายุ
- พิจารณาใช้ system user token สำหรับระบบที่ต้องทำงานต่อเนื่องระยะยาว
- ทดสอบยิง event จริงทุกครั้งหลังต่ออายุ token เพื่อยืนยันว่าใช้งานได้
คำถามที่พบบ่อย
ทำไม token ถึงไม่มีอีเมลแจ้งเตือนก่อนหมดอายุเหมือนบัตรเครดิต
แต่ละแพลตฟอร์มมีนโยบายต่างกัน บางแพลตฟอร์มมีการแจ้งเตือนในหน้าจัดการระบบแต่ไม่ได้ส่งอีเมลโดยตรง ทำให้ทีมที่ไม่ได้เข้าไปเช็คหน้านั้นเป็นประจำพลาดการแจ้งเตือนไปได้ง่าย จึงควรตั้งระบบเตือนของตัวเองแทนที่จะพึ่งพาแพลตฟอร์มอย่างเดียว
system user token ดีกว่า long-lived token เสมอไปไหม
ไม่เสมอไป system user token เหมาะกับระบบอัตโนมัติที่ต้องทำงานต่อเนื่องระยะยาวโดยไม่มีคนคอยต่ออายุ แต่ต้องดูแลเรื่องสิทธิ์การเข้าถึงให้รัดกุมกว่า เพราะไม่มีวันหมดอายุตายตัวช่วยจำกัดความเสี่ยงเหมือน token ที่มีอายุจำกัด
ต่ออายุ token แล้วต้องแก้โค้ดตรงไหนบ้าง
โดยทั่วไปแค่เปลี่ยนค่า token ในที่เก็บ config หรือ environment variable ที่ระบบอ้างอิงอยู่ ไม่ต้องแก้โค้ดส่วนอื่น แต่ควรทดสอบยิง event จริงหลังเปลี่ยนทุกครั้งเพื่อยืนยันว่าใช้งานได้จริง
ถ้ามีหลาย integration ใช้ token เดียวกัน เสี่ยงอะไรเป็นพิเศษไหม
เสี่ยงตรงที่ถ้า token ตัวนั้นมีปัญหา ทุก integration ที่พึ่งพามันจะล่มพร้อมกันหมด ควรพิจารณาแยก token ตาม integration ที่สำคัญ เพื่อจำกัดผลกระทบให้อยู่ในวงแคบเวลาเกิดปัญหา
ใช้บริการอย่าง linli ช่วยเรื่องการจัดการ token ได้ไหม
ช่วยรวมสถานะการเชื่อมต่อของแต่ละ integration ไว้ให้ดูในที่เดียว ทำให้เห็นได้เร็วขึ้นว่า token ตัวไหนเริ่มมีปัญหา แต่การต่ออายุ token เองยังต้องทำผ่านหน้าจัดการของแพลตฟอร์มโฆษณาต้นทางโดยตรง
อ่านต่อแบบเจาะลึก
รู้ว่าโฆษณาเข้า LINE ทำยอดขายจริงแค่ไหน
linli ติดตามลูกค้าตั้งแต่คลิกโฆษณา กดเพิ่มเพื่อน ทักแชท จนปิดการขาย พร้อมส่ง Conversion กลับแพลตฟอร์มโฆษณา เริ่มฟรี 14 วัน
ทดลองใช้ฟรี 14 วันบทความที่เกี่ยวข้อง
ใช้ Test Event Tool ให้เป็น ก่อนจะเสียเวลาไล่บั๊กผิดจุดไปหลายวัน
Event ID ไม่ตรงกัน ทำให้ระบบ Dedup พังทั้งสองทาง นับซ้ำหรือหายไปเลยก็เป็นได้
