การตรวจเทมเพลต Service Message ของ LINE MINI App: เช็กลิสต์ก่อนส่งรีวิว
ก่อนส่งเทมเพลต Service Message ของ LINE MINI App ให้ตรวจ เลือกเทมเพลตที่ LINE เตรียมไว้ให้ตรงกับงานที่สุด อธิบายการกระทำของผู้ใช้และลำดับการแจ้งเตือนใน Use Case ให้ชัด ทดสอบตัวแปรและ Permanent link ทุกจุด แล้วนำเนื้อหาโปรโมชันออก การส่งจริงต้องมีทั้ง MINI App ที่ผ่านการรับรองและเทมเพลตที่มี Published status เป็น PUBLISHING การส่งผ่าน simulator หรือสถานะ DEVELOPING ยังไม่ใช่การอนุมัติสำหรับ production
สรุปสำคัญ
- Service Message ใช้ยืนยันหรือตอบสนองการกระทำที่ผู้ใช้ทำใน MINI App เท่านั้น ส่วนลด รางวัลการซื้อสินค้า สินค้าใหม่ คูปอง โปรโมชัน โฆษณา และประกาศกิจกรรมทั่วไปไม่ได้รับอนุญาต
- LINE เป็นผู้จัดเตรียมรูปแบบเทมเพลต ทีมพัฒนาเลือกหมวดหมู่และภาษา กำหนดตัวแปร ลิงก์ และ Use Case ที่เกิดขึ้นจริง
- หนึ่ง channel เพิ่มเทมเพลตได้สูงสุด 20 รายการ ชื่อสำหรับ API อยู่ในรูป
{template name}_{BCP 47 language tag}และต้องตรงกับ LINE Developers Console - ระหว่างที่ channel ของ MINI App อยู่ระหว่างการตรวจ ยังดูรายละเอียดและใช้ simulator ได้ แต่เพิ่ม แก้ Use Case หรือลบเทมเพลตไม่ได้
- เมื่อ MINI App ผ่านการรับรองแล้ว การเปลี่ยนข้อมูล Service Message template ต้องรับการตรวจใหม่ จึงควรถือ Use Case ที่อนุมัติเป็นขอบเขต production
การตรวจเทมเพลต Service Message ของ LINE อนุมัติอะไร
เอกสารทางการเรื่อง Service Message แยกสามขั้นตอนที่มักสับสนออกจากกัน:
- คุณสมบัติของ MINI App: การส่ง Service Message บน production ใช้ได้เฉพาะ LINE MINI App ที่ผ่านการรับรอง แอปที่ยังไม่ผ่านส่งทดสอบได้เฉพาะ Developing channel ภายในกับบัญชี Admin หรือ Tester
- การตรวจเทมเพลต: เทมเพลตและ Use Case ที่ระบุต้องผ่านการตรวจของ LY Corporation ก่อนใช้จริง
- สิทธิ์ขณะทำงาน: แม้เทมเพลตผ่านแล้ว เซิร์ฟเวอร์ยังต้องมี service notification token ที่ผูกกับผู้ใช้และการกระทำนั้นก่อนเรียก API ส่ง
คู่มือเปรียบเทียบ MINI App ที่รับรองแล้วและยังไม่รับรอง ครอบคลุมข้อแรก ส่วน บทสอน service notification token ครอบคลุมข้อสาม บทความนี้เน้นส่วนกลางที่ยังขาด: การเตรียมเทมเพลตและกติกาการใช้งานก่อนส่งตรวจ
| สถานะ | ทำอะไรได้ | ยังพิสูจน์อะไรไม่ได้ |
|---|---|---|
DEVELOPING | Preview และทดสอบกับบัญชีนักพัฒนาที่มีสิทธิ์ใน Developing channel ภายใน | ผู้ใช้ production รับข้อความได้แล้ว |
| Channel ของ MINI App อยู่ระหว่างตรวจ | ดูรายละเอียดและส่งผ่าน simulator | เพิ่ม แก้ หรือลบเทมเพลตได้ระหว่างตรวจ |
PUBLISHING | ใช้เทมเพลตที่ผ่านตรวจใน production หลัง MINI App ผ่านการรับรอง | เปลี่ยน Use Case หรือใช้เป็นโปรโมชันได้ |
| แก้เทมเพลตหลังรับรอง | เตรียมข้อมูลใหม่เพื่อส่งตรวจอีกครั้ง | การอนุมัติเดิมครอบคลุมการเปลี่ยนแปลงอัตโนมัติ |
LINE ใช้ Published status PUBLISHING สำหรับเทมเพลตที่ผ่านการตรวจ อย่าสร้างสถานะ “พร้อม production” ขึ้นเองในระบบ ให้บันทึกสถานะที่เห็นจริงใน Console และหยุดงาน production ไว้จนกว่าทั้ง channel และเทมเพลตจะพร้อม
เช็กลิสต์ก่อนตรวจเทมเพลต Service Message ของ LINE MINI App
1. เริ่มจากการกระทำของผู้ใช้หนึ่งครั้ง
เขียน trigger ก่อน เช่น จองร้านอาหาร ลงทะเบียนคิว สั่งสินค้า เช็กอิน หรือขอจัดส่ง จากนั้นจึงระบุข้อความยืนยัน ผลลัพธ์ หรือการเตือนที่ผู้ใช้จำเป็นต้องได้รับเพราะการกระทำนั้น
โดยทั่วไป LINE อนุญาต Service Message สูงสุดห้าข้อความต่อหนึ่งการกระทำ แต่จำนวนที่อนุมัติอาจต่างกันตาม Use Case คำอธิบายจึงควรแสดงลำดับทั้งหมด เช่น ยืนยันทันทีหลังจอง เตือนหนึ่งวันก่อน และอัปเดตสถานะในวันนัด ไม่ควรอธิบายเป็นกลุ่มเป้าหมายการตลาดแบบต่อเนื่อง
2. เลือกเทมเพลตทางการและภาษาที่ตรงที่สุด
LINE มีเทมเพลตตามหมวด เช่น การจองร้าน การจัดการคิว และการแจ้งเตือนจัดส่ง รองรับภาษาญี่ปุ่น อังกฤษ จีนตัวเต็ม ไทย อินโดนีเซีย และเกาหลี สำหรับบริการในไทย ควรตรวจข้อความไทยและปุ่มใน LINE client จริง ไม่ใช่ยึดหน้าตัวอย่างภาษาอังกฤษเป็นหลัก
คัดลอกค่า Template name for API use จาก Console ตามที่แสดง ฟิลด์ request คือ templateName และค่าอยู่ในรูป {template name}_{BCP 47 language tag} อย่าประกอบ suffix ภาษาจากชื่อที่มองเห็นเอง
3. เขียน Use Case ให้ตรวจสอบได้
Use Case ต้องบอกว่าใครทำอะไร ที่ไหน แต่ละการแจ้งเตือนยืนยันอะไร และส่งเมื่อใด คำว่า “อัปเดตลูกค้า” กว้างเกินไป ตัวอย่างที่ตรวจได้คือ “ผู้ใช้จองการจัดส่งใน MINI App สำเร็จ ระบบส่งยืนยันทันที และส่งผลการจัดส่งเมื่อผู้ให้บริการขนส่งอัปเดตคำสั่งซื้อ”
LINE ระบุว่าการใช้เทมเพลตต่างจาก Use Case ที่แจ้งอาจทำให้ใช้งานเทมเพลตต่อไม่ได้ เก็บคำอธิบายที่ผ่านการอนุมัติไว้ข้างนิยาม job ใน runbook ภายใน เพื่อไม่ให้การเปลี่ยนผลิตภัณฑ์ภายหลังขยายขอบเขตโดยไม่ตั้งใจ
4. ตรวจตัวแปร ข้อจำกัดอักขระ และ Permanent link
ใน Console preview ให้ลองค่าที่สั้น ค่าปกติ และค่าที่ใกล้ขีดจำกัดสำหรับทุกตัวแปร วันที่ ชื่อ เลขคำสั่งซื้อ และข้อความแต่ละภาษาต้องอยู่ในค่าที่แนะนำและ hard limit ของเทมเพลต หากเทมเพลตไม่มีตัวแปร request ส่งยังต้องมี params: {}
ปุ่มต้องใช้ Permanent link ไปยังหน้าใน LINE MINI App ปุ่มแรกจำเป็น ส่วนปุ่มถัดไปขึ้นกับเทมเพลต ทดสอบปลายทางใน LINE client รวมถึงสถานะล็อกอินและหน้าคำสั่งซื้อหมดอายุ ไม่ใช่เพียงเปิด URL บนเบราว์เซอร์เดสก์ท็อป
5. ทดสอบ simulator ให้ครบก่อนล็อกชุดรีวิว
Console ส่งข้อความทดสอบไปยังบัญชี LINE ที่ผูกกับบัญชีนักพัฒนาที่ล็อกอินอยู่ได้ ตรวจ layout ลำดับตัวแปร ภาษา ปุ่ม และ footer ให้ครบ ความสำเร็จใน simulator พิสูจน์การแสดงผลเท่านั้น ไม่ได้พิสูจน์สิทธิ์ production
เตรียมเทมเพลตทั้งหมดก่อนส่ง channel ของ MINI App ให้ตรวจ ระหว่างตรวจเพิ่มเทมเพลตใหม่ แก้ Use Case หรือลบไม่ได้ เทมเพลตที่เพิ่มสำเร็จก่อนหน้ายังคงอยู่ แต่การเพิ่งพบว่าขาดการแจ้งเตือนในช่วงนี้จะทำให้การเปิดใช้ล่าช้า
6. กำหนดขอบเขตการเปลี่ยนหลังอนุมัติ
หลัง MINI App ผ่านการรับรอง การเปลี่ยนข้อมูล Service Message template ต้องรับการตรวจใหม่ตาม คำแนะนำการอัปเดตของ LINE นำการแก้เทมเพลตเข้า change control และเปรียบเทียบการกระทำ เนื้อหา ตัวแปร ลิงก์ และเวลาส่งกับเวอร์ชันที่อนุมัติก่อนปล่อยโค้ดที่อาศัยเทมเพลตนั้น
ขณะทำงานสามารถบันทึก templateName, action หรือ order ID, sessionId และ remainingCount ล่าสุดได้ แต่อย่าเขียน LIFF access token, channel access token หรือ service notification token ลง log การอนุมัติเทมเพลตไม่ได้แทนการจัดการอายุ token และการติดตาม delivery
UnifyPort เหมาะกับส่วนใด
UnifyPort ไม่ได้ยื่นหรืออนุมัติเทมเพลต LINE MINI App ไม่เปลี่ยน Published status ไม่ออก LINE service notification token และไม่ขยายประเภทเนื้อหาที่ LINE อนุญาต การแจ้งเตือนที่ผูกกับการจอง คำสั่งซื้อ คิว หรือการกระทำใน MINI App ต้องใช้ขั้นตอนทางการของ LINE
UnifyPort ดูแลอีกความต้องการหนึ่ง: รับข้อความลูกค้าแบบอิสระจากบัญชี LINE ทั่วไปที่เชื่อมต่อแล้ว การยืนยันบัญชีใช้ QR และข้อความขาเข้าที่รองรับจะมาถึงเป็นอีเวนต์มาตรฐาน message.received หาก webhook endpoint มี signing_secret การส่งจะมี X-Device-Timestamp และ X-Device-Signature สำหรับตรวจ HMAC-SHA256
เส้นแบ่งนี้สำคัญเมื่อผู้ใช้ได้รับ Service Message ทางการแล้วถามคำถามสนับสนุนต่อ เทมเพลตที่ตรวจแล้วดูแลการแจ้งเตือนเชิงธุรกรรม ส่วนเส้นทาง inbound แยกดูแลบทสนทนา คู่มือรับข้อความ LINE อธิบายสถาปัตยกรรมส่วนหลังโดยไม่เปลี่ยนเงื่อนไข MINI App
ข้อจำกัดและสิ่งที่ต้องแลก
- หาก MINI App ต้องส่งการแจ้งเตือนเชิงธุรกรรมที่ได้รับอนุมัติ ขั้นตอนทางการของ LINE คือทางเลือกที่ถูกต้อง อินเทอร์เฟซไม่เป็นทางการไม่สามารถให้สถานะรับรองหรืออนุมัติเทมเพลตได้
PUBLISHINGไม่ใช่สิทธิ์ส่งข้อความทั่วไป เนื้อหาต้องอยู่ใน Use Case และนโยบาย Service Message ที่อนุมัติ- การผ่านรีวิวไม่รับประกันว่า API call ทุกครั้งสำเร็จ token หมดอายุหรือหมุนเวียน
remainingCountเป็นศูนย์ และตัวแปรผิดยังทำให้ล้มเหลวได้ - Service Message ไม่ใช่กล่องข้อความฝ่ายบริการ หากผู้ใช้ต้องถามคำถามอิสระ ให้สร้างช่องทาง inbound แยก
FAQ
สถานะใดหมายถึงเทมเพลต Service Message ผ่านการตรวจแล้ว
LINE ใช้ Published status PUBLISHING สำหรับเทมเพลตที่ผ่านการตรวจและใช้ใน production ได้หลัง MINI App ผ่านการรับรอง
LINE MINI App ที่ยังไม่รับรองส่ง Service Message บน production ได้หรือไม่
ไม่ได้ แอปทดสอบได้เฉพาะ Developing channel ภายใน ส่วน production ต้องมี MINI App ที่รับรองและเทมเพลตที่ผ่านการตรวจ
Service Message ใส่คูปองหรือโปรโมชันได้หรือไม่
ไม่ได้ LINE ห้ามส่วนลด รางวัล สินค้าใหม่ คูปอง โปรโมชัน โฆษณา และประกาศกิจกรรมทั่วไป ข้อความต้องผูกกับการกระทำใน MINI App
แก้เทมเพลตระหว่างที่ channel ของ MINI App อยู่ระหว่างตรวจได้หรือไม่
ไม่ได้ ยังดูรายละเอียดและใช้ simulator ได้ แต่เพิ่มเทมเพลต แก้ Use Case หรือลบไม่ได้
เปลี่ยนเทมเพลตแล้วต้องตรวจใหม่หรือไม่
ต้องตรวจใหม่ LINE ระบุว่าข้อมูลทั้งหมดของ Service Message template เป็นการตั้งค่าที่ต้องรับการตรวจใหม่หลังอัปเดต MINI App ที่รับรองแล้ว
ขั้นตอนถัดไป
เตรียมเทมเพลต Use Case ตัวแปร และหลักฐานจาก simulator ตาม คู่มือ Service Message ทางการของ LINE หากความต้องการจริงคือรับข้อความลูกค้าแบบอิสระ ไม่ใช่การแจ้งเตือนเชิงธุรกรรม ให้ใช้ คู่มือยืนยันบัญชี LINE ของ UnifyPort เป็นเส้นทางแยก
แหล่งข้อมูล
ตรวจข้อมูลทางการของ LINE เมื่อวันที่ 28 กรกฎาคม 2026: