Los campos dinámicos de las matrices de carga útil fallan en las notificaciones push de AJO
En Adobe Journey Optimizer (AJO), las notificaciones push no pueden procesar campos dinámicos desde matrices de carga útil como "callerName"
", aunque los mismos datos funcionen en correos electrónicos y SMS. Los campos pueden aparecer en blanco o mostrar caracteres especiales como códigos hexadecimales. Para solucionarlo, simplifique las expresiones, aplane la carga útil si es posible y asegúrese de que la codificación UTF-8 se conserva de principio a fin.
Descripción description
Entorno
Producto: Adobe Journey Optimizer (AJO)
Canales: push (iOS a través de APN, Android a través de FCM)
Problema/Síntomas
La personalización dinámica falla en los campos basados en matrices en las notificaciones push.
Pasos a seguir
-
Cree un recorrido en AJO que almacene en déclencheur una notificación push.
-
Pase una carga útil en la que el atributo de personalización forme parte de una matriz, por ejemplo:
code language-none { "attribute_list_group": [ { "name": "callerName", "value": "Bill Robert" } ] }
-
En el título/cuerpo de la notificación push, configure una expresión personalizada:
code language-none #each context.journey.events.[ eventId] ._tmobile.decision_detail_group.attribute_list_group as |container| {%#if contains(container.name, "callerName")%} container.value {%/if%} /each
-
Envíe la notificación.
Observado: en dispositivos móviles, el campo aparece en blanco o muestra códigos hexadecimales para caracteres especiales. La misma expresión funciona correctamente en los canales de correo electrónico y SMS.
Causa
- El analizador de canales push de AJO es más estricto que el correo electrónico y los SMS. Espera valores de cadena plana y tiene una compatibilidad limitada con bucles, expresiones complejas y tipos de datos que no son de cadena en el título o cuerpo.
- Es posible que la sintaxis de creación de plantillas y ayuda (Handlebars vs. Nunjucks/Liquid) no sea igual de compatible en los campos de notificaciones push.
- Los caracteres especiales de la carga útil se pueden codificar como hexadecimales (por ejemplo,
\u2019
) durante la serialización. Es posible que los servicios push y algunas aplicaciones de dispositivos no descodifican estas secuencias y, en su lugar, las muestren tal cual. - Los servicios push como APNS y FCM aplican la codificación UTF-8, rechazan los caracteres de control y pueden procesar incorrectamente, soltar o rechazar mensajes con secuencias mal formadas o de escape.
- AJO solo admite cadenas escritas correctamente. Si una expresión dinámica se resuelve en un objeto, una cadena o una matriz mal formados, el mensaje push puede fallar silenciosamente o truncarse.
Resolución resolution
- Elimine todos los espacios en blanco y las líneas nuevas de la expresión de bucle. Usar una versión compacta como esta:
#each context.journey.events.[ eventId] ._tmobile.decision_detail_group.attribute_list_group as |container|{%#if contains(container.name, "callerName")%}container.value{%/if%}/each
Esto resolvió el problema de los caracteres latinos en una implementación de cliente actual. - Si es posible, acople la carga moviendo
callerName
a un campo de nivel superior. A continuación, useevent.callerName
directamente en la plantilla push. - Si no se puede acoplar, asegúrese de que esté seleccionado el índice de matriz correcto y pruebe la previsualización de personalización en AJO para confirmar la renderización.
- Asegúrese de que la codificación UTF-8 se conserva en cada fase, desde el sistema de origen hasta el procesamiento de AJO y el servicio push. Evite la doble codificación o el escape de caracteres especiales.
- Si los caracteres especiales siguen apareciendo como hexadecimales, es probable que sea una limitación del canal push o del procesamiento de dispositivos. Actualmente, AJO no ofrece ninguna configuración para forzar la descodificación de estos caracteres en el dispositivo.
Lectura relacionada
- Personalization en notificaciones push en la guía de AJO
- Casos de uso de Personalization en la Guía de AJO