Cómo evitar que los mensajes se contraigan

En los escenarios de notificaciones push de aplicaciones móviles, la contracción de mensajes afecta directamente a la experiencia del usuario y a la eficiencia en la entrega de mensajes. Basándose en el producto AppPush, este artículo explica en detalle cómo lograr una visualización de mensajes no contraídos mediante configuración técnica, cubriendo tanto los tipos Notification como Custom Message.

1. Comparación de tipos de mensajes y reglas de visualización

Notification

• Comportamiento predeterminado del sistema:

• Escenarios aplicables: notificaciones push estándar que necesitan llegar a los usuarios a través de la barra de notificaciones del sistema.

Custom Message

• Ventaja principal:
  Tanto si la aplicación está en primer plano, en segundo plano o cerrada, el formato de visualización del mensaje puede controlarse completamente mediante código del lado del cliente, incluida la posición de la ventana emergente y la lógica de contracción.

• Escenarios aplicables:
  Mensajes de alta prioridad que requieren interacción personalizada, como recordatorios del estado de pedidos y mensajes de chat instantáneo.

2. Dos soluciones para evitar que los mensajes se contraigan

Solución 1: usar Notification

(Para el canal FCM, la aplicación debe estar en primer plano; el canal EngageLab no distingue entre primer plano y segundo plano).

Principio de implementación

Utilice el campo group_id para controlar la lógica de agrupación de mensajes:

• Sin contracción: asigne un group_id único a cada mensaje.

Pasos

Versiones compatibles: Android SDK V5.0.1 y posteriores

Ejemplo de configuración de parámetros de la API push (cuerpo de la solicitud):

              
              {
  "notification": {
    "android": {
      "group_id": "UNIQUE_GROUP_123"  // Utilice un valor único para evitar la contracción
    }
  }
}

            

Notas de compatibilidad

• Solo se admiten los canales push FCM y EngageLab.
• Si la aplicación se está ejecutando en segundo plano, la visualización de mensajes sigue estando sujeta a las restricciones del sistema.

Solución 2: usar Custom Message (compatible en todos los escenarios)

Principio de implementación

Llame activamente a la API showNotification en el lado del cliente para controlar por completo la lógica de renderizado del mensaje y evitar las restricciones del sistema.

Pasos

1. Enviar un mensaje personalizado

              
              {
  "message": {
    "msg_content": "Your order has been shipped",
    "content_type": "text",
    "extras": {
      "type": "priority_alert",
      "style": "popup_bottom"  // Estilo de visualización personalizado
    }
  }
}

            

2. Procesar el mensaje en el lado del cliente (ejemplo de Android)

              
              public class UserReceiver extends MTCommonReceiver {
    @Override
    public void onCustomMessage(Context context, CustomMessage customMessage) {
        ExampleLogger.i(TAG, "onCustomMessage:" + customMessage.toString());
        showNotification(context, customMessage); // Llamar a la lógica de visualización
    }
}

            

3. Ejemplo de lógica de visualización personalizada (para evitar la contracción)

              
              public void showNotification(Context context, CustomMessage customMessage) {
    NotificationMessage notificationMessage = new NotificationMessage()
        .setMessageId(customMessage.getMessageId())
        .setNotificationId("Defínelo tú mismo, pero asegúrate de que cada notificación sea diferente")
        .setTitle(customMessage.getTitle())
        .setContent(customMessage.getContent())
        .setgroup_id(customMessage.getMessageId()); // Campo clave para evitar la contracción

    MTPushPrivatesApi.showNotification(context, notificationMessage);
}

            

Comparación de ventajas

3. Notas

1. Compatibilidad de canales

   • La función group_id actualmente solo es compatible con los canales FCM y EngageLab. Otros canales no son compatibles por el momento.

2. Optimización del rendimiento

   • Al enviar mensajes con frecuencia con valores group_id independientes, supervise la presión de caché de la barra de notificaciones en el lado del sistema (recomendación: ≤30 mensajes por dispositivo por hora).

4. Resumen

• Requisitos ligeros: priorice el uso de group_id para controlar la lógica de contracción de las notificaciones, ya que tiene un menor coste de desarrollo.
• Requisitos altamente personalizados: elija la solución de mensajes personalizados para lograr una visualización totalmente controlable en todos los escenarios mediante código del lado del cliente.
• Estrategia híbrida: use mensajes personalizados para notificaciones importantes (como confirmaciones de pago) y utilice la gestión con group_id para las notificaciones normales.

Al elegir la solución adecuada, puede mejorar significativamente la tasa de entrega de los mensajes críticos y mejorar la experiencia de interacción del usuario.