วิธีป้องกันไม่ให้ข้อความถูกรวม

ในสถานการณ์การส่ง AppPush บนแอปมือถือ การรวมข้อความส่งผลโดยตรงต่อประสบการณ์ผู้ใช้และประสิทธิภาพในการส่งข้อความ บทความนี้อ้างอิงจากผลิตภัณฑ์ AppPush เพื่ออธิบายโดยละเอียดว่าทำอย่างไรจึงจะแสดงข้อความแบบไม่ถูกรวมผ่านการกำหนดค่าทางเทคนิค โดยครอบคลุมทั้งประเภท Notification และ Custom Message

1. การเปรียบเทียบประเภทข้อความและกฎการแสดงผล

Notification

• พฤติกรรมเริ่มต้นของระบบ:

• สถานการณ์ที่เหมาะสม: การแจ้งเตือนแบบพุชมาตรฐานที่ต้องส่งถึงผู้ใช้ผ่านแถบการแจ้งเตือนของระบบ

Custom Message

• ข้อได้เปรียบหลัก:
  ไม่ว่าแอปจะอยู่เบื้องหน้า เบื้องหลัง หรือถูกล้างออกด้วยการแตะครั้งเดียว ก็สามารถควบคุมรูปแบบการแสดงข้อความได้อย่างสมบูรณ์ผ่านโค้ดฝั่งไคลเอนต์ รวมถึงตำแหน่งป๊อปอัปและตรรกะการรวมข้อความ

• สถานการณ์ที่เหมาะสม:
  ข้อความที่มีลำดับความสำคัญสูงและต้องการการโต้ตอบแบบกำหนดเอง เช่น การแจ้งเตือนสถานะคำสั่งซื้อและข้อความแชทแบบเรียลไทม์

2. สองวิธีในการป้องกันไม่ให้ข้อความถูกรวม

วิธีที่ 1: การใช้ Notification

(สำหรับช่องทาง FCM แอปต้องอยู่เบื้องหน้า ส่วนช่องทาง EngageLab ไม่ได้แยกระหว่างเบื้องหน้าและเบื้องหลัง)

หลักการทำงาน

ใช้ฟิลด์ group_id เพื่อควบคุมตรรกะการจัดกลุ่มข้อความ:

• ไม่รวมข้อความ: กำหนด group_id ที่ไม่ซ้ำกันให้แต่ละข้อความ

ขั้นตอน

เวอร์ชันที่รองรับ: Android SDK V5.0.1 ขึ้นไป

ตัวอย่างการกำหนดค่าพารามิเตอร์ของ Push API (request body):

              
              {
  "notification": {
    "android": {
      "group_id": "UNIQUE_GROUP_123"  // ใช้ค่าที่ไม่ซ้ำกันเพื่อป้องกันการรวม
    }
  }
}

            

หมายเหตุด้านความเข้ากันได้

• รองรับเฉพาะช่องทางพุช FCM และ EngageLab เท่านั้น
• หากแอปทำงานอยู่เบื้องหลัง การแสดงข้อความยังคงอยู่ภายใต้ข้อจำกัดของระบบ

วิธีที่ 2: การใช้ Custom Message (รองรับในทุกสถานการณ์)

หลักการทำงาน

เรียกใช้ API showNotification บนฝั่งไคลเอนต์โดยตรง เพื่อควบคุมตรรกะการเรนเดอร์ข้อความได้อย่างสมบูรณ์ และหลีกเลี่ยงข้อจำกัดของระบบ

ขั้นตอน

1. ส่ง Custom Message

              
              {
  "message": {
    "msg_content": "Your order has been shipped",
    "content_type": "text",
    "extras": {
      "type": "priority_alert",
      "style": "popup_bottom"  // รูปแบบการแสดงผลแบบกำหนดเอง
    }
  }
}

            

2. ประมวลผลข้อความบนฝั่งไคลเอนต์ (ตัวอย่าง Android)

              
              public class UserReceiver extends MTCommonReceiver {
    @Override
    public void onCustomMessage(Context context, CustomMessage customMessage) {
        ExampleLogger.i(TAG, "onCustomMessage:" + customMessage.toString());
        showNotification(context, customMessage); // เรียกใช้ตรรกะการแสดงผล
    }
}

            

3. ตัวอย่างตรรกะการแสดงผลแบบกำหนดเอง (เพื่อป้องกันการรวม)

              
              public void showNotification(Context context, CustomMessage customMessage) {
    NotificationMessage notificationMessage = new NotificationMessage()
        .setMessageId(customMessage.getMessageId())
        .setNotificationId("Define this yourself, but make sure each notification is different")
        .setTitle(customMessage.getTitle())
        .setContent(customMessage.getContent())
        .setgroup_id(customMessage.getMessageId()); // ฟิลด์สำคัญสำหรับป้องกันการรวม

    MTPushPrivatesApi.showNotification(context, notificationMessage);
}

            

การเปรียบเทียบข้อดี

3. หมายเหตุ

1. ความเข้ากันได้ของช่องทาง

   • ฟีเจอร์ group_id ปัจจุบันรองรับเฉพาะช่องทาง FCM และ EngageLab เท่านั้น ช่องทางอื่นยังไม่รองรับในขณะนี้

2. การเพิ่มประสิทธิภาพ

   • เมื่อส่งข้อความบ่อยครั้งโดยใช้ค่า group_id แบบอิสระ ควรตรวจสอบภาระของแคชในแถบการแจ้งเตือนทางฝั่งระบบ (แนะนำ: ≤30 ข้อความต่ออุปกรณ์ต่อชั่วโมง)

4. สรุป

• ความต้องการแบบเบา: แนะนำให้ใช้ group_id เพื่อควบคุมตรรกะการรวมของการแจ้งเตือน เนื่องจากมีต้นทุนการพัฒนาต่ำกว่า
• ความต้องการที่ปรับแต่งได้สูง: เลือกโซลูชัน Custom Message เพื่อให้ได้การแสดงผลที่ควบคุมได้อย่างสมบูรณ์ในทุกสถานการณ์ผ่านโค้ดฝั่งไคลเอนต์
• กลยุทธ์แบบผสม: ใช้ Custom Message สำหรับการแจ้งเตือนสำคัญ (เช่น การยืนยันการชำระเงิน) และใช้การจัดการ group_id สำหรับการแจ้งเตือนทั่วไป

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