Ir al contenido

Esta página fue traducida automáticamente y puede contener errores. Para informar de un error de traducción, usa el componente de comentarios situado bajo el sumario, a la derecha de la página.

Preguntas frecuentes

Este artículo ofrece respuestas a algunas preguntas frecuentes sobre los mensajes dentro de la aplicación.

¿Qué es un mensaje en el explorador y en qué se diferencia de un mensaje dentro de la aplicación?

Los mensajes en el explorador son mensajes dentro de la aplicación que se envían a navegadores web. Para crear un mensaje en el explorador, asegúrate de seleccionar Navegador web en el campo Enviar a al crear tu Campaign o Canvas de mensajes dentro de la aplicación.

¿Se muestra un mensaje dentro de la aplicación si un dispositivo está sin conexión?

Depende. Como los mensajes dentro de la aplicación se entregan al inicio de la sesión, si el dispositivo puede descargar la carga útil antes de quedarse sin conexión, el mensaje dentro de la aplicación puede mostrarse igualmente sin conexión. Si la carga útil no se descarga, el mensaje dentro de la aplicación no se muestra.

Si un usuario ya tiene una carga útil de mensaje dentro de la aplicación en su dispositivo y se cambia la caducidad del mensaje, ¿se actualiza la caducidad en su dispositivo?

Cuando un usuario inicia una sesión, Braze comprueba si se han hecho cambios en algún mensaje dentro de la aplicación para el que sea elegible y los actualiza en consecuencia. Así que, si la caducidad ha cambiado y el usuario registra una sesión, el mensaje dentro de la aplicación se envía al dispositivo con la información actualizada.

¿Cómo configuro las horas tranquilas para una Campaign de mensajes dentro de la aplicación?

La característica de horas tranquilas no está disponible para las Campaigns de mensajes dentro de la aplicación. Esta característica evita que se envíen mensajes a tus usuarios durante determinadas horas. En las Campaigns de mensajes dentro de la aplicación, tus usuarios solo reciben mensajes dentro de la aplicación si están activos en ella.

Como alternativa para enviar mensajes dentro de la aplicación durante un horario concreto, usa el siguiente código Liquid de ejemplo. Este código cancela el mensaje si el mensaje dentro de la aplicación se muestra después de las 19:59 o antes de las 8:00 en la zona horaria especificada.

{% assign time = 'now' | time_zone: ${time_zone} %}{% assign hour = time | date: '%H' | plus: 0 %}
{% if hour > 19 or hour < 8 %}
{% abort_message("Outside allowed time window") %}
{% endif %}
MESSAGE HERE

¿Pueden los usuarios volver a recibir un mensaje dentro de la aplicación después de descartarlo?

Campaigns

En las Campaigns de mensajes dentro de la aplicación, puedes permitir que los usuarios vuelvan a ser elegibles para recibir la Campaign activando la reelegibilidad en Controles de entrega (Permitir que los usuarios vuelvan a ser elegibles para recibir la campaña). El momento en que pueden volver a recibirla depende de la ventana de reelegibilidad que configures y de cómo Braze registró el envío anterior. Consulta Reelegibilidad para Campaigns y Canvas para conocer el comportamiento de las Campaigns, incluida la relación entre la reelegibilidad y la recepción de mensajes.

Si la reelegibilidad está desactivada, por lo general los usuarios no volverán a recibir esa misma Campaign solo por cumplir los criterios de calificación después de haberla recibido.

Canvas

En los mensajes dentro de la aplicación enviados desde un Canvas, que un usuario pueda volver a ver el mensaje depende de los controles de entrada del Canvas (como permitir que los usuarios vuelvan a entrar en el Canvas) y de la configuración de tus pasos, no solo de los controles de entrega de la Campaign.

¿Cuándo se calcula la elegibilidad para un mensaje dentro de la aplicación?

Campaigns

En las Campaigns de mensajes dentro de la aplicación, Braze comprueba si un usuario forma parte de tu público objetivo cuando su dispositivo descarga los mensajes dentro de la aplicación. Esto suele ocurrir al inicio de la sesión. El dispositivo almacena los mensajes elegibles y muestra cada uno cuando se produce su desencadenante, aunque sea más adelante en la sesión.

En las Campaigns con una hora de inicio futura, Braze también envía el mensaje a los dispositivos que inician una sesión hasta una hora antes de la hora de inicio. Así, el mensaje está listo para mostrarse a tiempo. Por ejemplo, un usuario que inicia una sesión a las 6:30 a. m. recibe una Campaign que empieza a las 7 a. m. Braze comprueba su elegibilidad a las 6:30 a. m. y el mensaje se muestra cuando se produce su desencadenante después de las 7 a. m.

Elegibilidad durante una sesión

Los usuarios que pasan a ser elegibles durante una sesión reciben el mensaje al inicio de su siguiente sesión.

Para volver a comprobar la elegibilidad justo antes de que se muestre el mensaje, selecciona Volver a evaluar la elegibilidad de la campaña antes de mostrarla. Si el usuario ya no cumple los requisitos, el mensaje no se muestra. Esta configuración no envía el mensaje a los usuarios que pasaron a ser elegibles después de iniciar su sesión. Para más información, consulta Elegir a qué usuarios dirigirse.

Canvas

En los mensajes dentro de la aplicación de un Canvas, Braze comprueba la audiencia del paso cuando el usuario llega a ese paso. Después, el mensaje se descarga al inicio de la siguiente sesión del usuario.

¿Por qué mi Campaign archivada de mensajes dentro de la aplicación sigue generando impresiones de mensajes dentro de la aplicación?

Esto puede ocurrir con usuarios que cumplían los criterios del Segment cuando la Campaign de mensajes dentro de la aplicación estaba activa.

Para evitarlo, durante la configuración de tu Campaign, selecciona Volver a evaluar la elegibilidad para la campaña antes de mostrarla.

¿Por qué no veo aperturas en los mensajes dentro de la aplicación?

Los mensajes dentro de la aplicación no utilizan una métrica de Aperturas. Braze registra Impresiones cuando el mensaje se vuelve visible en la pantalla y Clics cuando los usuarios interactúan con el cuerpo del mensaje o con sus botones. Si una exportación o un informe multicanal incluye filas de mensajes dentro de la aplicación, compara las Impresiones y los Clics en lugar de las aperturas propias del correo electrónico. Para ver las definiciones, consulta Informes de mensajes dentro de la aplicación.

¿Se pueden mostrar varios mensajes dentro de la aplicación en la misma sesión?

Sí, pero solo se puede mostrar un mensaje dentro de la aplicación cada vez que se produce un evento desencadenante. Si varias Campaigns de mensajes dentro de la aplicación comparten el mismo desencadenante (por ejemplo, el inicio de sesión), solo se muestra el mensaje de mayor prioridad cada vez que se produce ese desencadenante. Para los desencadenantes de inicio de sesión, esto significa que solo se puede mostrar un mensaje por sesión, y la siguiente oportunidad de mostrar otro mensaje elegible es la siguiente sesión.

Cuando varios mensajes comparten el mismo nivel de prioridad, se muestra primero el mensaje creado más recientemente. Para los desencadenantes de inicio de sesión, el siguiente mensaje más reciente se muestra en una sesión posterior; para otros tipos de desencadenantes, el siguiente mensaje más reciente se muestra la próxima vez que se produzca ese evento desencadenante, lo que puede ocurrir en la misma sesión o en una sesión posterior.

Para controlar el orden de visualización dentro de un contenedor de prioridad, ve a la configuración de entrega de cualquiera de las Campaigns y selecciona Set Exact Priority; luego, arrastra y suelta las Campaigns en el orden que quieras. Para más información, consulta Elegir una prioridad.

¿Cómo se registran las impresiones y los clics de los mensajes dentro de la aplicación?

Consulta Informes de mensajes dentro de la aplicación para saber cómo se registran las impresiones y los clics según la acción del usuario. Para ver ejemplos específicos de mensajes a pantalla completa creados con el editor tradicional, consulta Métricas de mensajes a pantalla completa por acción del usuario.

¿Cómo calcula Braze la caducidad de un mensaje dentro de la aplicación configurada en «después de 1 día(s)»?

Braze calcula un tiempo de caducidad de un día como 24 horas después de que los usuarios sean elegibles para recibir un mensaje.

¿Qué son los mensajes dentro de la aplicación con plantilla?

Los mensajes dentro de la aplicación se entregan como mensajes dentro de la aplicación con plantilla cuando está seleccionada la opción Volver a evaluar la elegibilidad de la campaña antes de mostrarla o si el mensaje contiene alguna de las siguientes etiquetas de Liquid:

canvas_entry_properties
connected_content
Variables de SMS, como {sms.${*}}
catalog_items
catalog_selection_items
event_properties

Braze también usa la entrega con plantilla para las Campaigns de mensajes dentro de la aplicación inactivas (Campaigns que siguen activas, pero que ya no se envían o ya no son necesarias). Estas Campaigns siguen respetando las reglas de audiencia y de desencadenamiento que tengan configuradas.

Braze también puede usar la entrega con plantilla para proteger el rendimiento de la aplicación. Si la preparación del contenido de Liquid retrasa la respuesta de una sesión más de unos segundos, Braze aplaza el trabajo restante. Esos mensajes se representan cuando se desencadenan.

Esto significa que, al iniciarse la sesión, el dispositivo recibe el desencadenante de ese mensaje dentro de la aplicación en lugar del mensaje completo. Cuando el usuario desencadena el mensaje dentro de la aplicación, su dispositivo hace una solicitud de red para obtener el mensaje real.

Nota

El mensaje no se entrega si el dispositivo no tiene acceso a Internet. Es posible que el mensaje no se entregue si la lógica de Liquid tarda demasiado en resolverse.

Para reducir la cantidad de Liquid que Braze procesa al iniciarse la sesión, consulta Optimizar el rendimiento de los mensajes dentro de la aplicación.

¿Cómo funciona la cancelación en los mensajes dentro de la aplicación?

En Braze, una cancelación ocurre cuando un usuario realiza una acción que lo hace elegible para recibir un mensaje, pero no lo recibe porque la lógica de Liquid del mensaje lo marca como no elegible. Por ejemplo:

Sam realiza una acción que debería desencadenar una Campaign de correo electrónico.
El cuerpo del correo electrónico contiene lógica de Liquid que indica que, si la puntuación de un atributo personalizado es inferior a 50, no se envíe este correo.
La puntuación del atributo personalizado de Sam es 20.
Braze reconoce que Sam no debería recibir este correo electrónico, y el correo se cancela.
Se registra un evento de cancelación.

Sin embargo, como los mensajes dentro de la aplicación son un canal de extracción (pull), las cancelaciones funcionan de forma un poco distinta para ellos.

Comportamiento de cancelación de los mensajes dentro de la aplicación estándar

El dispositivo extrae los mensajes dentro de la aplicación al inicio de la sesión y los almacena en caché, de modo que, independientemente de la calidad de la conexión a Internet, el mensaje puede entregarse al usuario al instante. Por ejemplo, si un usuario recibe cinco mensajes dentro de la aplicación durante su sesión, recibe los cinco al inicio de la sesión. Los mensajes se almacenan en caché localmente y aparecen cuando se producen sus eventos desencadenantes definidos (inicio de sesión, el usuario hace clic en un botón que registra un evento personalizado, u otros).

En otras palabras, la lógica que determina si un mensaje dentro de la aplicación debe cancelarse se ejecuta antes de que se produzca el desencadenante. Para demostrarlo, supongamos que Sam, del ejemplo del correo electrónico, está suscrito a notificaciones push.

Sam inicia una sesión al abrir en su teléfono una aplicación que funciona con Braze.
Según los criterios de audiencia de las Campaigns activas en el espacio de trabajo, Sam podría ser elegible para cinco Campaigns distintas. Las cinco se extraen a su teléfono y se almacenan en caché.
Sam no ha realizado ninguna acción que desencadene estos mensajes, pero podría recibirlos durante la sesión.
El Liquid de dos de los mensajes dentro de la aplicación tiene reglas que excluyen a Sam de recibir el mensaje (por ejemplo, que su atributo personalizado de puntuación no sea lo bastante alto).
A Sam no se le envían los dos mensajes dentro de la aplicación que lo excluyen, pero sí los otros tres.
No se registra ningún evento de cancelación.

Braze no registra ningún evento de cancelación en el caso de Sam porque no se cumple la definición de cancelación: Sam no realizó ninguna acción que desencadenara los mensajes. En los mensajes dentro de la aplicación, los usuarios nunca llegan a realizar el desencadenante antes de que Braze determine que no deben ver el mensaje.

Comportamiento de cancelación de los mensajes dentro de la aplicación con plantilla

Los mensajes dentro de la aplicación con plantilla obligan al SDK a volver a evaluar si un mensaje debe mostrarse cuando se produce el evento desencadenante. Esto implica un comportamiento de cancelación distinto. Para demostrarlo, observa este ejemplo:

Sam inicia una sesión de Braze al abrir en su teléfono una aplicación que funciona con Braze.
Los criterios de audiencia de las Campaigns activas indican que Sam podría ser elegible para un mensaje dentro de la aplicación con plantilla, así que la información del desencadenante se envía a su dispositivo sin la carga útil del mensaje.
Sam selecciona un botón que registra un evento personalizado, lo que desencadena el mensaje dentro de la aplicación con plantilla.
El dispositivo de Sam realiza una solicitud de red para obtener el mensaje dentro de la aplicación.
La lógica de Liquid del mensaje provoca una cancelación, así que Braze la registra como tal; Sam realizó la acción desencadenante antes de esta evaluación.

Comparación del comportamiento de cancelación de los mensajes dentro de la aplicación

Esta tabla compara los flujos de mensajes dentro de la aplicación que experimentó Sam:

Mensaje dentro de la aplicación	Comportamiento de cancelación
Estándar	No se registró un evento de cancelación porque Sam no realizó ninguna acción que desencadenara un mensaje. Los mensajes dentro de la aplicación estándar no registran cancelaciones porque la definición de cancelación es “no vio el mensaje a pesar de realizar la acción desencadenante”. Como los mensajes dentro de la aplicación se entregan al dispositivo antes de que se produzcan las acciones desencadenantes, no tiene sentido considerar omitidos los mensajes dentro de la aplicación por la lógica de Liquid.
Con plantilla	Se registró un evento de cancelación porque Sam realizó la acción desencadenante del mensaje dentro de la aplicación con plantilla, pero recibió una cancelación en la plantilla de Liquid. Los mensajes dentro de la aplicación con plantilla registran cancelaciones porque la evaluación de Liquid se produce después de realizar la acción desencadenante.

Mensaje dentro de la aplicación

Comportamiento de cancelación

Estándar

No se registró un evento de cancelación porque Sam no realizó ninguna acción que desencadenara un mensaje.

Los mensajes dentro de la aplicación estándar no registran cancelaciones porque la definición de cancelación es “no vio el mensaje a pesar de realizar la acción desencadenante”. Como los mensajes dentro de la aplicación se entregan al dispositivo antes de que se produzcan las acciones desencadenantes, no tiene sentido considerar omitidos los mensajes dentro de la aplicación por la lógica de Liquid.

Con plantilla

Se registró un evento de cancelación porque Sam realizó la acción desencadenante del mensaje dentro de la aplicación con plantilla, pero recibió una cancelación en la plantilla de Liquid.

Los mensajes dentro de la aplicación con plantilla registran cancelaciones porque la evaluación de Liquid se produce después de realizar la acción desencadenante.

¿Cuándo se ejecuta el contenido conectado en los mensajes dentro de la aplicación?

En los mensajes dentro de la aplicación con plantilla, el contenido conectado y otras etiquetas de Liquid se resuelven cuando se produce el evento desencadenante y el dispositivo solicita la carga útil del mensaje, no cuando el usuario hace clic en un botón dentro del mensaje. Cada obtención con plantilla puede incluir llamadas de contenido conectado para esa visualización.

Si tu HTML hace referencia a datos REST devueltos por el contenido conectado, esos datos están disponibles durante la sesión en la que se aplicó la plantilla al mensaje. Varios botones pueden hacer referencia a la misma respuesta de contenido conectado sin desencadenar llamadas adicionales al hacer clic.

¿Cuál es el retraso máximo tras un desencadenante en las Campaigns de mensajes dentro de la aplicación?

Las Campaigns de mensajes dentro de la aplicación pueden retrasar la entrega tras el evento desencadenante hasta dos horas (7200 segundos). Las opciones de retraso son Inmediatamente y Después de un retraso. Para una espera más larga, añade un paso de Retraso antes de un paso de mensaje dentro de la aplicación en un Canvas. Para configurar el retraso, consulta Entrega basada en acciones.

¿Por qué hay un retraso antes de que se muestre mi mensaje dentro de la aplicación?

Los mensajes dentro de la aplicación estándar se muestran en cuanto la carga útil en caché está lista tras el evento desencadenante. En Android e iOS, las imágenes grandes u otros activos alojados en una CDN a los que hace referencia el mensaje pueden añadir un breve retraso mientras esos recursos terminan de descargarse antes de que aparezca el mensaje dentro de la aplicación.

Los mensajes dentro de la aplicación con plantilla y las Campaigns con la opción Volver a evaluar la elegibilidad de la campaña antes de mostrarla seleccionada requieren una solicitud de red adicional tras el desencadenante antes de que aparezca el mensaje. Esto puede añadir un breve retraso (normalmente inferior a 100 ms con una conexión estable). Para más información, consulta Elegir a qué usuarios dirigirse.

¿Por qué mi mensaje dentro de la aplicación se ve distinto de la vista previa del panel?

Los mensajes dentro de la aplicación entregados pueden diferir de la vista previa del panel cuando:

Tu integración aplica un estilo personalizado o anula la interfaz predeterminada de los mensajes dentro de la aplicación en determinadas plataformas
La vista previa usa un perfil de usuario de prueba con atributos distintos a los del destinatario
El contenido con plantilla se resuelve de forma distinta en el momento del envío que en el modo de vista previa

Usa Enviar mensajes de prueba con un usuario de prueba cuyo perfil coincida con tu público objetivo cuando valides el aspecto.

¿Por qué un mensaje dentro de la aplicación de varias páginas usa el mismo fondo en todas las páginas?

Cuando se habilita Imagen de fondo en una página de un mensaje dentro de la aplicación de varias páginas, ese fondo se aplica a todas las páginas del mensaje. Para usar fondos distintos en cada página, usa un bloque HTML personalizado con JavaScript que cambie las imágenes entre páginas.

¿Cómo pruebo los mensajes dentro de la aplicación web?

Los envíos de prueba de mensajes dentro de la aplicación web requieren que push esté habilitado en el dispositivo de prueba, porque el flujo de prueba entrega una notificación push que abre la aplicación o el sitio donde se muestra el mensaje dentro de la aplicación. La misma ruta de prueba basada en push se aplica en cualquier plataforma donde push no esté configurado con Braze, aunque la falta de push se da con más frecuencia en la web, ya que muchas integraciones móviles ya tienen push habilitado. En su lugar, usa una campaña en vivo dirigida a un segmento de prueba interno. Para ver los pasos, consulta Enviar mensajes de prueba.

¿Los mensajes dentro de la aplicación requieren integración push?

Los mensajes dentro de la aplicación no requieren notificaciones push para funcionar en producción. Los mensajes dentro de la aplicación se entregan a través del SDK de Braze y aparecen durante una sesión activa de la aplicación sin necesidad de integración push.

Sin embargo, los envíos de prueba de mensajes dentro de la aplicación sí requieren que push esté habilitado en tus dispositivos de prueba. Esto se debe a que los mensajes dentro de la aplicación de prueba se entregan mediante una notificación push que desencadena la visualización del mensaje dentro de la aplicación. El usuario de prueba debe tener push habilitado y debe tocar la notificación push de prueba para ver el mensaje dentro de la aplicación.

En las Campaigns de producción, los usuarios ven los mensajes dentro de la aplicación según los desencadenantes de tu Campaign (como el inicio de sesión o eventos personalizados), sin que intervenga push.

¿Por qué aparecen caracteres extra o sin representar en mi mensaje dentro de la aplicación?

Copiar texto de otra aplicación (como un procesador de textos o una página web) puede insertar caracteres invisibles o no imprimibles en el cuerpo de tu mensaje. Esos caracteres pueden aparecer como símbolos sueltos o romper el Liquid y el HTML en los mensajes personalizados.

Para corregir caracteres sueltos o sin representar, vuelve a escribir el texto afectado en el editor de Braze, o elimina directamente los caracteres no deseados en lugar de seleccionar y reemplazar solo el texto visible. En los mensajes HTML personalizados con caracteres especiales, añade <meta charset="UTF-8"> dentro del <head> de tu HTML. Consulta Codificación de caracteres para más detalles.

¿Por qué el botón de cierre está oculto en los mensajes dentro de la aplicación HTML a pantalla completa en Android?

En dispositivos con pantallas de borde a borde (incluido Android 15 y versiones posteriores), los mensajes dentro de la aplicación HTML a pantalla completa pueden dibujarse detrás de la barra de estado del sistema y ocultar un control de cierre situado en la parte superior del diseño.

Las versiones 37.0.0 y posteriores del SDK de Braze para Android aplican de forma predeterminada los márgenes de ventana (window insets) a los mensajes dentro de la aplicación HTML para que los controles permanezcan en el área segura. Si los usuarios siguen viendo superposiciones, actualiza a la última versión del SDK de Braze para Android.

En versiones anteriores del SDK, antes de que este comportamiento pasara a ser el predeterminado, los desarrolladores podían habilitar BrazeConfig.setIsHtmlInAppMessageApplyWindowInsetsEnabled(true).

¿Qué debo tener en cuenta al personalizar mensajes dentro de la aplicación de arrastrar y soltar?

El editor de arrastrar y soltar admite los tipos de visualización modal y de pantalla completa. Dentro de esos contenedores, creas el contenido con bloques de editor.

Ten en cuenta lo siguiente:

Enlaces y vínculos profundos: De forma predeterminada, cada acción al hacer clic tiene un único campo de URL. Usa Liquid en la URL para variar los enlaces según el dispositivo, el tipo de aplicación o los atributos del usuario. En el Contenedor de mensajes, también puedes activar un comportamiento al hacer clic específico para cada plataforma y así establecer enlaces diferentes por plataforma.
Opacidad y fondos: La opacidad del contenedor de mensajes afecta a todo el fondo del mensaje. Cada bloque puede tener sus propios colores de fondo. Para un control más preciso, añade CSS personalizado en un bloque de código personalizado.
Ancho del mensaje: En el editor, el ancho máximo del Contenedor de mensajes no puede ser inferior a 325 px, lo que mantiene el contenido legible en pantallas más pequeñas. Usa CSS personalizado si necesitas un diseño más estrecho.
Fondos específicos por plataforma: Un mismo mensaje usa la misma imagen y los mismos colores de fondo en la web y en dispositivos móviles. No puedes establecer fondos diferentes por plataforma en el editor.
Mensajes de varias páginas: Las imágenes de fondo y las acciones al hacer clic a nivel de mensaje se aplican en todas las páginas de un mensaje de varias páginas. Para usar imágenes completas diferentes en cada página, añade botones que enlacen a la página siguiente.
Estilos a nivel de mensaje: Los estilos a nivel de mensaje se aplican a todo el mensaje.
Imágenes de fondo: Las imágenes de fondo se estiran para ajustarse al modal.

Para conocer más consideraciones sobre el editor, consulta la Guía de preparación de mensajes dentro de la aplicación.

¿Qué significa “Event was published, but no subscribers were found” en los registros del SDK de Android?

Esta línea de registro normalmente no indica un error. Suele aparecer cuando Braze publica un evento interno (como NoMatchingTriggerEvent) y, en ese momento, no hay ningún agente de escucha de mensajes dentro de la aplicación ni de Content Cards suscrito.

Si ves este registro cuando esperas que un evento personalizado desencadene un mensaje dentro de la aplicación, confirma que el evento se registra, que el usuario está en la audiencia de la Campaign o del Canvas y que las Content Cards están sincronizadas cuando el mensaje depende de ellas.

New Stuff!