Comment éviter que les messages soient regroupés

Dans les scénarios de notifications push sur applications mobiles, le regroupement des messages affecte directement l'expérience utilisateur et l'efficacité de diffusion. Basé sur le produit AppPush, cet article explique en détail comment obtenir un affichage des messages sans regroupement grâce à une configuration technique, en couvrant à la fois les types Notification et Custom Message.

1. Comparaison des types de messages et des règles d'affichage

Notification

• Comportement par défaut du système :

• Scénarios applicables : Notifications push standard qui doivent atteindre les utilisateurs via la barre de notifications du système.

Custom Message

• Avantage principal :
  Que l'application soit au premier plan, en arrière-plan ou qu'elle ait été fermée, le format d'affichage du message peut être entièrement contrôlé via le code côté client, y compris la position de la fenêtre contextuelle et la logique de regroupement.

• Scénarios applicables :
  Messages à haute priorité nécessitant une interaction personnalisée, comme les rappels de statut de commande et les messages de chat instantané.

2. Deux solutions pour éviter que les messages soient regroupés

Solution 1 : utiliser Notification

(Pour le canal FCM, l'application doit être au premier plan ; le canal EngageLab ne distingue pas le premier plan de l'arrière-plan.)

Principe d'implémentation

Utilisez le champ group_id pour contrôler la logique de regroupement des messages :

• Pas de regroupement : attribuez un group_id unique à chaque message.

Étapes

Versions prises en charge : Android SDK V5.0.1 et versions ultérieures

Exemple de configuration des paramètres de l'API push (corps de requête) :

              
              {
  "notification": {
    "android": {
      "group_id": "UNIQUE_GROUP_123"  // Utilisez une valeur unique pour éviter le regroupement
    }
  }
}

            

Notes de compatibilité

• Seuls les canaux push FCM et EngageLab sont pris en charge.
• Si l'application s'exécute en arrière-plan, l'affichage des messages reste soumis aux restrictions du système.

Solution 2 : utiliser Custom Message (prise en charge dans tous les scénarios)

Principe d'implémentation

Appelez activement l'API showNotification côté client pour contrôler entièrement la logique de rendu du message et éviter les restrictions du système.

Étapes

1. Envoyer un message personnalisé

              
              {
  "message": {
    "msg_content": "Your order has been shipped",
    "content_type": "text",
    "extras": {
      "type": "priority_alert",
      "style": "popup_bottom"  // Style d'affichage personnalisé
    }
  }
}

            

2. Traiter le message côté client (exemple Android)

              
              public class UserReceiver extends MTCommonReceiver {
    @Override
    public void onCustomMessage(Context context, CustomMessage customMessage) {
        ExampleLogger.i(TAG, "onCustomMessage:" + customMessage.toString());
        showNotification(context, customMessage); // Appeler la logique d'affichage
    }
}

            

3. Exemple de logique d'affichage personnalisée (pour éviter le regroupement)

              
              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()); // Champ clé pour éviter le regroupement

    MTPushPrivatesApi.showNotification(context, notificationMessage);
}

            

Comparaison des avantages

3. Notes

1. Compatibilité des canaux

   • La fonctionnalité group_id prend actuellement en charge uniquement les canaux FCM et EngageLab. Les autres canaux ne sont pas pris en charge à ce stade.

2. Optimisation des performances

   • Lors de l'envoi fréquent de messages avec des valeurs group_id distinctes, surveillez la pression sur le cache de la barre de notifications côté système (recommandation : ≤ 30 messages par appareil et par heure).

4. Résumé

• Besoins légers : privilégiez l'utilisation de group_id pour contrôler la logique de regroupement des notifications, car cela implique un coût de développement plus faible.
• Besoins fortement personnalisés : choisissez la solution Custom Message pour obtenir un affichage entièrement contrôlable dans tous les scénarios via le code côté client.
• Stratégie hybride : utilisez les messages personnalisés pour les notifications importantes (comme les confirmations de paiement), et utilisez la gestion via group_id pour les notifications régulières.

En choisissant la solution appropriée, vous pouvez améliorer de manière significative le taux de diffusion des messages critiques et renforcer l'expérience d'interaction utilisateur.