Campañas in-app

Muestra mensajes segmentados a los usuarios mientras usan activamente tu aplicación. Los mensajes in-app no requieren permiso, pueden incluir contenido enriquecido e interactivo, y conviven con Push y Email en el asistente unificado de campañas.

Resumen

Las campañas in-app te permiten:

• Incorporar usuarios nuevos con consejos y tutoriales útiles.
• Anunciar funciones y actualizaciones de producto.
• Impulsar la interacción con indicaciones y CTA.
• Promocionar ofertas con mensajes contextuales.
• Ejecutar experimentos con variantes A/B y grupos de control.

Ventajas principales:

• No requiere permiso, a diferencia de Push.
• Contenido enriquecido e interactivo.
• Se contextualiza con la actividad actual del usuario.
• Tasas de interacción más altas que Push o Email.
• Se muestra con las fuentes, los colores y el modo oscuro de la propia app (mensajes nativos).

Requisitos previos

Asegúrate de haber integrado primero el SDK:

• SDK de iOS.
• SDK de Android.
• SDK Web.

El SDK sincroniza las campañas aptas y las muestra cuando los usuarios cumplen tus criterios de disparador y segmentación.

Tipos de mensaje

Elige uno de los diseños según tu caso de uso:

Tipo	Diseño	Ideal para
Modal	Centro de la pantalla con fondo superpuesto	Anuncios importantes y lanzamientos de funciones
Banner	Franja superior o inferior	Consejos rápidos y ofertas urgentes
Deslizante	Aparece desde la parte inferior	Indicaciones sutiles y logros desbloqueados
Pantalla completa	Ocupa toda la pantalla	Onboarding y actualizaciones importantes
Personalizado	Renderizado definido por desarrollo, configurado por API	Requisitos de interfaz únicos

Crear una campaña in-app

Las campañas in-app usan el mismo asistente de seis pasos que cualquier otro canal. Consulta Creación de campañas para la estructura compartida. Los dos pasos que difieren son Redactar y Entrega.

Paso Redactar

El paso Redactar usa VariantTabs con un selector de tres métodos, igual que Email:

• Crear con arrastrar y soltar: editor visual para quienes no desarrollan.
• Crear con HTML: vista dividida con editor de código a la izquierda y vista previa en directo en un iframe aislado a la derecha.
• Crear desde plantilla: elige una de tus plantillas in-app guardadas.

Sea cual sea el método, el HTML creado se guarda en el customContent de la variante. Una vez redactada una variante, se contrae en una tarjeta AuthoredSummary con una miniatura iframe de 200 × 220 del mensaje renderizado. Haz clic para volver a abrir el editor.

Los mensajes HTML requieren que la app lo habilite

Los tres métodos anteriores producen HTML, que la app muestra dentro de un web view. Los scripts escritos en el mensaje no se ejecutan ahí - el propio puente del SDK gestiona botones y formularios - pero un web view dentro de la app sigue siendo decisión de sus desarrolladores, así que el SDK no mostrará un mensaje HTML salvo que lo hayan habilitado explícitamente (allowHtmlJsInAppMessages).

Una app que no lo ha habilitado omite las campañas HTML en silencio: el usuario no ve nada. Si no estás seguro, consúltalo con los desarrolladores antes de programar una campaña HTML, o usa un mensaje nativo.

Ancho máximo y HTML adaptable

Un Modal o un Slide-up creado con Drag & drop, HTML o una plantilla tiene un ajuste de Ancho máximo, en píxeles. Lo encuentras en la tarjeta de la variante una vez redactado el mensaje, en la barra de herramientas del editor junto al fondo del mensaje, en el editor HTML sobre el código, en el paso in-app de un journey y en la propia plantilla in-app. Déjalo vacío para usar el valor predeterminado - 600 px para un modal, 400 px para un slide-up - o escribe un número entero entre 240 y 1200. Banner y Fullscreen ocupan toda la pantalla y no tienen ancho máximo; los mensajes nativos dibujan su propia tarjeta.

El mensaje recibe su ancho antes de que su contenido se maquete: el menor entre el Ancho máximo y el ancho de la pantalla menos un pequeño margen (16 px por lado en la web; los márgenes propios de la app en iOS y Android). Solo la altura sigue al contenido. Un diseño de 680 px se muestra a 680 px en un navegador de escritorio y se ajusta a la pantalla en un teléfono.

Escribe HTML adaptable. Tus media queries ven el ancho real del mensaje, hasta el Ancho máximo: @media (max-width: 560px) dentro del mensaje se cumple cuando el propio mensaje mide 560 px o menos, sea cual sea el tamaño del navegador. Diseña para el Ancho máximo como el caso más ancho y deja que tus media queries apilen las columnas por debajo. Da al contenedor exterior width: 100% o un max-width en lugar de un ancho fijo mayor que un teléfono pequeño (unos 320 px).

La Vista previa de los editores usa la misma regla en las superficies App y Web, así que los breakpoints se activan ahí exactamente donde se activan en un dispositivo.

Cuándo se aplica: en la web en cuanto se actualiza el backend. En iOS y Android con la próxima versión del SDK; hasta entonces las apps mantienen su maquetación actual (el ancho de la pantalla menos los márgenes, así que en una tableta un modal se muestra a todo el ancho). Las apps de React Native y Unity dibujan ellas mismas los mensajes: a partir de esa versión reciben el valor como maxWidth / MaxWidth para dimensionar su web view.

Mensajes nativos

Un mensaje nativo es contenido estructurado - titular, texto, imagen y hasta tres botones - que la app dibuja con sus propios componentes. No interviene ningún web view ni se omite nada, así que se muestra en cualquier app independientemente del ajuste anterior, coincide con las fuentes, los colores y el modo oscuro de la app, y funciona con lectores de pantalla.

La contrapartida es el control: tú eliges las palabras, la imagen y los botones; la app decide cómo se ven.

	Nativo	HTML
Se muestra sin que la app lo habilite	Sí	No
Coincide con el estilo de la app	Sí	Solo si lo reconstruyes en CSS
Control total de la maquetación	No	Sí
Funciona donde no hay web view (por ejemplo, tvOS)	Sí	No

El contenido nativo se crea en el mosaico App style del paso Compose, junto a Drag & Drop y HTML. Si creas campañas mediante la API, consulta Campaigns API para la referencia de campos.

Colores, tipografía y CSS personalizado

En Style (optional) puedes sobrescribir el fondo de la tarjeta, el color del texto, el relleno del botón principal y su etiqueta, y el radio de las esquinas. Deja un campo vacío y el mensaje hereda ese valor de la aplicación - que es justo lo que hace que un mensaje nativo parezca parte de ella, así que cambia algo solo cuando la campaña necesite un momento de marca.

Si defines un color de botón y ningún color de etiqueta, la etiqueta se elige automáticamente - negro o blanco, el que siga siendo legible sobre tu relleno.

Dos controles son solo para web:

• Tipografía - una aplicación solo puede mostrar las fuentes que incluye, así que nombrar una que no tiene acabaría en algo que se ve mal. Los móviles conservan su propia tipografía.
• CSS personalizado, en Advanced - para lo que los campos no pueden expresar. Cada selector que escribas se reescribe para quedar dentro de este mensaje antes de aplicarse, así que ninguna regla llega al resto de la página, y las reglas de aquí tienen prioridad sobre los campos de color anteriores. Los móviles no tienen motor CSS y lo ignoran.

Qué puedes seleccionar: la propia tarjeta, h2 (titular), p (mensaje), button.primary y button.secondary. Los campos de color también se exponen como variables CSS - --joryio-inapp-bg, --joryio-inapp-fg, --joryio-inapp-primary, --joryio-inapp-primary-fg, --joryio-inapp-radius, --joryio-inapp-font - para que puedas redefinirlas dentro de una media query.

Las mismas pestañas de variantes A/B funcionan para in-app, incluidos los grupos de control.

Hacer que los botones funcionen

Un mensaje con HTML personalizado se ejecuta dentro de un marco aislado (sandbox) en web y dentro del web view de la app en iOS y Android, una vez que el SDK de la app ha habilitado los mensajes HTML. No puede acceder directamente ni a tu página ni a la nuestra; en su lugar, Joryio le proporciona un pequeño puente.

Estilos: solo en línea. Pon tu CSS en un bloque <style> al inicio del HTML o en atributos style. Las apps muestran el mensaje con una política de seguridad estricta que permite estilos en línea, imágenes, fuentes y multimedia por https, y nada más: una hoja de estilos de un CDN con <link> no se carga en ningún dispositivo, así que copia lo que necesites en el bloque <style>.

Qué se ejecuta en el dispositivo. Joryio guarda tu marcado tal como lo escribiste (solo se quitan <base> y <meta http-equiv="refresh">, y se repara el marcado mal formado), pero las apps lo ejecutan con esa política de seguridad: tus bloques <script>, los manejadores onclick en línea y los <iframe> incrustados (un video de YouTube) no se ejecutan en web, iOS ni Android. Los botones, enlaces, atributos data-joryio-action y formularios data-jry-form funcionan a través del puente de Joryio (ver abajo) y no necesitan script. Los valores de personalización siempre se escapan como HTML, así que un campo del perfil nunca se convierte en código (añade | raw a propósito cuando necesites marcado de un campo). La Vista previa de la campaña muestra el diseño y lista las acciones del puente que disparan tus botones; no garantiza que un script se ejecute en un dispositivo.

data-joryio-action - la forma habitual

<button data-joryio-action="requestPushPermission">Activar notificaciones</button>
<button data-joryio-action="closeMessage">No, gracias</button>

Acción	Qué hace
requestPushPermission	Muestra la solicitud de notificaciones del navegador
closeMessage	Cierra el mensaje
logConversion	Registra una conversión de esta campaña

logConversion acepta un nombre mediante data-joryio-event; si lo omites, la conversión se registra como in_app_conversion.

Todo esto está también en el panel de propiedades del editor - On click, Conversion event (optional) y Click name (reports) - así que la mayoría de los mensajes no necesitan tocar el HTML.

Los clics se registran solos

Cualquier clic en <a> o <button> se informa automáticamente. Para nombrar un clic en los informes, añade data-action:

<a href="/pricing" data-action="pricing_cta">Ver planes</a>

Los enlaces http(s) y los relativos a la raíz se abren desde la página anfitriona; las anclas, mailto: y tel: se comportan con normalidad.

window.joryioBridge - lo que llaman tus botones

Detrás de data-joryio-action está el puente del SDK, window.joryioBridge. El script del SDK es el único script que se ejecuta en el mensaje, y ejecuta estos métodos por ti:

Método	Propósito
logCustomEvent(name, properties)	Registrar un evento del usuario
setCustomUserAttribute(key, value)	Escribir un atributo en el perfil
logConversion(event)	Registrar una conversión de esta campaña
logClick(action)	Registrar un clic con nombre
changeUser(userId)	Identificar al visitante
requestPushPermission()	Mostrar la solicitud de notificaciones
navigate(url, target)	Abrir una URL desde la página anfitriona
closeMessage()	Cerrar el mensaje

data-joryio-action puede nombrar cualquiera de ellos y pasar un argumento en data-joryio-event - por ejemplo data-joryio-action="logCustomEvent" data-joryio-event="size_selected". Un método que necesita dos argumentos, como setCustomUserAttribute, no se puede invocar desde el marcado. Un bloque <script> o un onclick="joryioBridge.closeMessage()" en línea escrito en el mensaje no se ejecuta, así que tampoco puede llamar al puente.

El puente completo está disponible en web, iOS y Android (desde las versiones del SDK de iOS y Android que lo incluyen - logCustomEvent, setCustomUserAttribute, changeUser, requestPushPermission, logConversion, logClick, navigate, closeMessage, submitForm; las versiones nativas anteriores exponen solo closeMessage, navigate y el registro de clics). Las apps React Native y Unity muestran los mensajes a través de los SDK nativos de iOS y Android, así que aplica el mismo puente. Una app que dibuja los mensajes en su propio web view (onInAppMessage en React Native, SetInAppMessageHandler en Unity) decide qué se ejecuta ahí y envía formularios con submitInAppForm / SubmitInAppForm. Los mensajes nativos usan los botones de la propia app, así que conecta sus CTA mediante la configuración de botones de la campaña y no mediante marcado.

Paso Entrega

El paso Entrega de las campañas in-app está diseñado específicamente para ellas. En vez del selector de tipo de envío de los demás canales, obtienes lo siguiente:

Selector principal de disparador

Una fila de cinco tarjetas, con Al ocurrir un evento marcado como RECOMENDADO:

Disparador	Cuándo se muestra el mensaje
Inmediato	En la siguiente sesión apta del usuario.
Al ocurrir un evento (recomendado)	Cuando se registra un evento para el usuario.
Toque en notificación Push	Después de que tocar una notificación Push lleve al usuario a tu aplicación.
Cambio de atributo	Cuando cambia el valor de un atributo observado.
Umbral de atributo	Cuando un atributo numérico cruza un umbral.

Cada tarjeta tiene un subtítulo de una línea y una descripción más larga. Al elegir una tarjeta aparece la configuración de ese modo en un panel gris suave debajo:

• Inmediato: sin configuración adicional, solo el retraso de visualización compartido que se explica abajo.
• Al ocurrir un evento: selector de evento con búsqueda y alternativa + Crear evento, además de condiciones de propiedad opcionales.
• Toque en notificación Push: un fragmento para copiar y pegar que muestra cómo conectar el SDK a este ID de campaña.
• Cambio de atributo: selector de atributo y campos de valor anterior y valor nuevo.
• Umbral de atributo: selector de atributo, operador (>, <, ≥, ≤, =) y valor de umbral.

Retraso de visualización

Un único campo Retraso de visualización se comparte en todos los modos de disparador. Introduce la duración en segundos, minutos u horas mediante el selector de unidad. El mensaje espera ese tiempo después de que se active el disparador antes de aparecer.

Programación

Elige las fechas empieza el y caduca el con zonas horarias separadas. El selector de zona horaria fija arriba el valor predeterminado del espacio de trabajo, después la hora local del destinatario y luego toda la lista IANA, de modo que los casos habituales aparecen primero. Escribe en el campo para buscar por ciudad, país o desfase UTC; las flechas recorren los resultados y Enter elige uno.

La hora que eliges se interpreta en la zona que eliges: 09:00 con America/New_York inicia la campaña a las 09:00 hora de Nueva York estés donde estés al guardarla, y el editor muestra esas mismas 09:00 a quien la abra después. La hora local del destinatario interpreta la hora en el atributo timezone de cada persona: la campaña empieza a las 09:00 para un contacto en Tokio y, horas más tarde, a las 09:00 para uno en Nueva York; un contacto sin atributo de zona horaria usa la zona horaria del espacio de trabajo. El selector de fin sigue la zona de inicio salvo que le des una propia.

Límite de frecuencia

Una tarjeta reúne los controles de frecuencia:

• Máximo de impresiones por usuario: por ejemplo, 3 veces.
• Ventana de tiempo: 1 h / 24 h / 7 días / 30 días / 90 días / durante toda la vida, o una ventana personalizada.
• Retraso mínimo entre impresiones: intervalo mínimo entre apariciones consecutivas.

Solo cuenta lo que se muestra: una impresión que el dispositivo informa (mostrada, o descartada por un cliente que solo informa el descarte). Una página que cargó el mensaje pero se abandonó antes de que apareciera no consume el límite. Para que dos dispositivos no muestren a la vez un mensaje de una sola vez, el mensaje entregado a un dispositivo reserva su lugar durante dos minutos hasta que ese dispositivo confirme que lo mostró. Un dispositivo informa un mensaje como mostrado solo después de que haya estado en pantalla alrededor de un segundo, o cuando la persona lo toca o lo cierra antes, así que un mensaje que apareció un instante durante una redirección o un cambio de pantalla tampoco consume el límite.

Debajo, una tarjeta independiente de Reglas de contacto del espacio de trabajo ofrece el interruptor Ignorar reglas de contacto. Omitir estas reglas puede ser adecuado para mensajes transaccionales o críticos, pero nunca debería ser la opción predeterminada.

Prácticas recomendadas de frecuencia

• No abrumes a los usuarios con varios mensajes in-app por sesión.
• Separa las impresiones: un intervalo de 24 h o más es un buen valor predeterminado.
• Reserva «Ignorar reglas de contacto» para mensajes realmente críticos.

Modo de evaluación

Un selector de dos tarjetas, no un menú desplegable, porque las compensaciones son demasiado importantes como para ocultarlas:

Modo	Latencia	Qué obtienes	A qué renuncias
Sincronización diferencial (recomendado)	~80 ms	Campañas ilimitadas. Segmentación completa por segmento, entidad y comportamiento. Datos de entidades en plantillas.	Una ida y vuelta al servidor cuando cambian atributos observados.
Solo al inicio de sesión	<10 ms	Se evalúa una vez al iniciar la sesión.	Los cambios no se reflejan hasta que el usuario inicie una sesión nueva.

Ambos modos mantienen las campañas sincronizadas en el dispositivo y disparan sus activadores localmente, así que un mensaje aparece sin una llamada de red en el momento de mostrarlo.

Un panel descriptivo debajo de las tarjetas amplía el modo seleccionado. Sincronización diferencial es la opción correcta para la mayoría de usos de producción.

Renderizado en servidor

En los modos Sincronización diferencial y Solo al inicio de sesión, el contenido del mensaje se renderiza en el servidor antes de llegar al dispositivo. Los tokens de personalización, los bloques de contenido y los datos de catálogo se resuelven del lado del servidor. Esto da a los mensajes in-app la misma potencia de renderizado que Email: funcionan los datos de entidades, fragmentos blocks.* y búsquedas en el catálogo de productos.

Usa el botón Probar renderizado en servidor del creador de campañas in-app para renderizar el mensaje en servidor con un usuario elegido y ver exactamente lo que recibirá el SDK. Comprueba la personalización, los bloques y el resultado de catálogo antes de activar la campaña.

Configuración avanzada

Es un panel contraído bajo la tarjeta de evaluación. Al abrirlo:

Modo de observación: controla cuándo el SDK vuelve a evaluar si una campaña es apta después de cambios de atributos:

• Auto (recomendado): el SDK detecta automáticamente de qué atributos dependen la segmentación y las plantillas de campaña, y vuelve a evaluar cuando cambian.
• Siempre: vuelve a evaluar en cada cambio de atributo.
• Nunca: solo al inicio de sesión.

Desempate de prioridad: se usa cuando dos campañas aptas comparten la misma prioridad:

• Más reciente (predeterminado): muestra primero la campaña creada más recientemente.
• Más antigua: muestra primero la campaña más antigua (FIFO).
• Aleatorio: selección aleatoria entre las campañas aptas.

Diferencias en el paso Audiencia

El paso Audiencia funciona como en cualquier otro canal - el mismo selector de modo y creador de filtros v2 - con una parte oculta:

• La tarjeta Opciones de envío está oculta. Los mensajes in-app no tienen concepto de suscripción: el SDK los muestra con independencia del estado de aceptación de Email, SMS o Push.

El aviso ámbar «Enviar a todos» también usa un texto diferente: los riesgos de in-app son la fatiga por modales y agotar el límite de frecuencia, no la entregabilidad. Por eso los ejemplos de filtros usan last_seen within 7 days y plan = free.

Mostrar en. Cuando el espacio de trabajo tiene más de una app, el paso Audiencia también pregunta qué app muestra el mensaje: Todas las apps (por defecto) o una sola - por ejemplo solo la app web de tu tienda Magento, o solo la app iOS. El SDK de las demás apps nunca lo recibe. El paso in-app de un recorrido tiene el mismo ajuste Mostrar en.

Personalización con Liquid

Las plantillas in-app admiten la sintaxis completa de plantillas Liquid. En los modos Sincronización diferencial y Solo al inicio de sesión, la plantilla se renderiza en el servidor, por lo que también puede usar datos de entidades, bloques de contenido y datos de catálogo:

¡Hola, {{ user.firstName | default: "qué tal" }}!

¡Has conseguido {{ user.points }} puntos!

{% if user.plan == 'free' %}
  <p>Mejora tu plan para desbloquear más recompensas.</p>
{% else %}
  <p>¡Gracias por ser miembro {{ user.plan }}!</p>
{% endif %}

Último pedido: n.º {{ entities.order.id }} ({{ entities.order.total | currency }})

Los filtros disponibles incluyen date_format, pluralize, currency, truncate y default. Consulta Plantillas Liquid para ver la referencia completa.

Seguimiento de clics en enlaces

Los clics en enlaces dentro de mensajes in-app se miden automáticamente y se atribuyen a la campaña. No necesitas configuración adicional ni reescritura de etiquetas. Los recuentos de clics aparecen en la analítica de campaña junto a las impresiones, así que puedes medir el CTR y usar clics como señales de conversión en pruebas A/B.

Cada clic lleva además el nombre que le dio el mensaje: el data-action del elemento, una llamada logClick desde el puente, o el link_click / cta_click del propio SDK. Abre una variante desde la analítica de la campaña y cambia a Mapa de clics: cada botón y enlace del mensaje muestra las personas que lo tocaron y su proporción entre todos los que lo vieron, y la lista contigua ordena los clics por botón. Un mensaje nativo (sin HTML) muestra solo la lista. Los nombres requieren versiones del SDK del 26-09-2026 o posteriores; un SDK anterior informa cada toque como un clic sin nombre.

Pruebas A/B

In-app admite las mismas pestañas de variantes A/B que todos los demás canales, incluidos los grupos de control. La asignación de variante es determinista: la primera vez que se evalúa a un usuario, su ID se aplica a una función hash que lo coloca en un grupo de peso y se conserva esa asignación. Por tanto, el mismo usuario siempre ve la misma variante.

Los grupos de control no ven ningún mensaje: quedan retenidos por completo. Esto te permite medir la mejora incremental de la campaña frente a no hacer nada, comparando las tasas de conversión.

Variante A: 45 % - mostrar campaña
Variante B: 45 % - mostrar alternativa
Control:   10 % - no mostrar nada

Conversión de variante A: 5 %
Conversión de control:    2 %
Mejora: +150 %

Formularios dentro de mensajes

Un mensaje in-app puede llevar un formulario: en el editor de arrastrar y soltar, la categoría de bloques Form tiene un formulario de alta, campos de email, teléfono, texto, desplegable, opción y consentimiento, y un botón de envío (los mismos bloques que las páginas de destino). Da a cada campo una Field key (minúsculas, guiones bajos). La vista Formulario en la barra del editor muestra lo que declara el marcado y te deja decir adónde va cada valor: el atributo del perfil que escribe, la lista a la que suscribe una casilla de consentimiento, y qué pasa tras el envío (un mensaje en su lugar, o una URL).

Cuando alguien envía, el SDK manda los valores con la identidad que tiene: el perfil de un usuario conocido se actualiza (un email o un teléfono solo donde el perfil no tiene ninguno - un formulario nunca los reemplaza), un visitante anónimo se convierte en perfil en cuanto el formulario lo nombra (email o teléfono), las listas marcadas se suscriben, y se registra In-App Form Submitted con campaignId, campaignName, variantId, las claves de campo, listsSubscribed, y el email y el phone propios del formulario con phoneUpdated (false cuando el perfil conservó un teléfono distinto propio), así que journeys, campañas disparadas y segmentos pueden actuar. El envío aparece también como clic (form_submit) en el mensaje.

Las plantillas guardan su formulario con la plantilla; una campaña que usa la plantilla lo hereda. Disponible en el Web SDK y, desde las versiones que incluyen el puente completo, en los SDK de iOS y Android; una app React Native que renderiza el HTML por sí misma llama a submitInAppForm; Unity muestra solo mensajes nativos.

El mismo editor y la misma vista Formulario están en el paso in-app de un journey: un formulario en un mensaje que el paso lleva por sí mismo, o en la plantilla que usa, se envía igual que el de una campaña, y el campaignId del envío es el del paso (journey:<id del journey>:<id del paso>). Quitar el formulario del diseño quita también la configuración de sus campos; un formulario que se vuelve a añadir empieza con los valores por defecto.

Prácticas recomendadas

Empieza con Sincronización diferencial

La mayoría de las campañas deberían usar el modo Sincronización diferencial: ofrece el mejor equilibrio entre funciones y rendimiento.### Usa el modo de observación Auto

Deja que el SDK detecte las dependencias de atributos. Cambia a Siempre solo si necesitas observar atributos que no se usan directamente en la segmentación; cambia a Nunca solo para mensajes de bienvenida estáticos.

Implementa límites de frecuencia

De forma predeterminada, cada usuario ve una campaña una sola vez. La repetición es algo que activas: marca Allow this campaign to show more than once per user en Frequency Capping. Si lo dejas desactivado, el mensaje se muestra una vez por persona, para siempre: sin ventana y sin caducidad.

Con la opción activada, deja el límite vacío para ilimitado, o indica un número y una ventana (minutos, horas, días, semanas o meses). La ventana solo afecta al recuento; el Min Delay de debajo es un tiempo de espera aparte entre dos apariciones.

Evita la fatiga por mensajes:

• Interacción alta: 3 impresiones cada 7 días.
• Moderada: 2 impresiones cada 14 días.
• Frecuencia baja: 1 impresión cada 30 días.

Prueba con variantes A/B

Incluye siempre grupos de control al medir el impacto en conversiones. Distribución recomendada: 45 % / 45 % / 10 % de control.

Solución de problemas

La campaña no se muestra

Comprueba, en este orden:

1. Que el estado de campaña sea active, no draft.
2. Que la programación incluya la hora actual, entre startsAt y expiresAt.
3. Que el usuario cumpla los filtros de segmentación.
4. Que no se haya superado el límite de frecuencia para este usuario.
5. Que no la esté bloqueando una campaña de prioridad más alta.
6. Que el usuario no esté en un grupo de control.

Errores de plantilla Liquid

• Atributos ausentes: envuélvelos con | default: "valor alternativo".
• Sintaxis incorrecta: comprueba que coincidan {% endif %} y {% endfor %}.

Problemas de rendimiento

• Simplifica la lógica de segmentación.
• Optimiza las plantillas Liquid y evita bucles costosos.
• Usa Solo al inicio de sesión para mensajes estáticos.

In-app frente a Push

Función	In-app	Push
Permiso	No requerido	Requerido
Cuándo se muestra	Mientras la aplicación está abierta	En cualquier momento
Contenido enriquecido	Sí	Limitado
Interactividad	Alta	Limitada
Alcance	Solo usuarios activos	Todos los usuarios con el SDK instalado
Ideal para	Interacción contextual	Reactivación

Usa los dos juntos: Push para impulsar aperturas de aplicación e in-app para interactuar con usuarios activos.

Próximos pasos

• Creación de campañas: referencia del asistente compartido.
• Notificaciones Push.
• Pruebas A/B.
• Plantillas Liquid.