Envío en la página equivocada
Si el mensaje se está enviando en la URL del sitio web equivocada:
Asegúrate de que tus reglas de audiencia o de página estén configuradas con la lógica correcta. Por ejemplo, si estás combinando varias reglas negativas ('is not', 'does not contain'), casi siempre querrás separarlas con 'AND', no con 'OR'. Y si estás usando un filtro de coincidencia exacta "URL is", deberás asegurarte de haber incluido la URL completa, incluyendo la parte
https://y cualquier barra final. Puedes ver más orientación sobre cómo configurar tus filtros efectivamente aquí.¿El user lo recibió inicialmente en la página correcta y luego navegó a otra página? Debido al comportamiento de 'follow page', si un mensaje dentro de la aplicación no se interactúa (no se hace clic ni se cierra), permanece mientras el usuario navega a otras páginas —incluidas páginas excluidas explícitamente de tus reglas de URL— hasta que interactúe con él. Intenta comprobar las "Recent page views" del user en su página de perfil y compara las marcas de tiempo con la marca de tiempo de recepción del mensaje.
Al configurar las reglas de URL de página, usa solo el segmento de ruta relevante (por ejemplo,
/dashboard) en lugar de la dirección completa. Usar URLs completas puede causar desajustes debido a variaciones de domain, parámetros de consulta o barras finales.
El activador de evento no funciona
Si un mensaje con un activador de evento no se está enviando:
Si acabas de publicar el mensaje, ten en cuenta que las personas en la audiencia necesitarán conectarse en línea y activar el evento después de que el mensaje esté activo para recibirlo. No se enviará si activaron el evento antes de que el mensaje estuviera activo. Puedes poner el evento en las reglas de la Audience en lugar de los Triggers para capturar eventos pasados.
¿Emparejaste un activador de evento con una regla de audiencia del mismo evento? Al combinar activadores y reglas, las reglas de segmentación deben haberse cumplido en el momento de activar el evento, ya que el activador de evento no actualizará al user instantáneamente en la misma solicitud. Por ejemplo, si quieres enviar un mensaje solo la primera vez que un user active un evento purchased-item y no en compras posteriores, usarías un recuento de 0 (es decir, users que nunca han activado el evento antes) ya que no se actualizará a 1 hasta la siguiente solicitud.
¿Necesitas un activador de evento o podrías segmentarlo como una regla de audiencia? La sección "Triggers" (When to send / Where to send) es opcional, por lo que no necesitas incluir un evento en cada mensaje, a menos que necesites asegurarte de que solo se envíe cuando un user realice una acción específica.
No aparece en pantalla completa
Si tu mensaje dentro de la aplicación se está enviando como una notificación con insignia roja en el icono del Messenger pero no aparece en pantalla:
¿El user tiene otros mensajes pendientes enviándose al mismo tiempo? Varios mensajes se mostrarán como una insignia roja en el icono del Messenger, para que no se saturen con demasiados pop-ups a la vez. Puedes comprobar el "Recent content" en la página de perfil del user para ver qué mensajes recibieron alrededor de la misma hora.
¿El contenido de tu Chat o Post está configurado como "Sent as: Badge"? Estos siempre se enviarán como una notificación con insignia, a menos que lo cambies a "Snippet" o "Show the full message".
Mensajes de chat que no aparecen en una aplicación móvil basada en web
Si tu aplicación móvil usa el Messenger basado en web (en lugar del SDK nativo de iOS o Android), los chats coincidentes en pings apiUpdate no aparecerán automáticamente como snippet o ventana emergente de mensaje completo. Esto es intencional: Intercom omite deliberadamente la búsqueda de mensajes no leídos en pings de actualización porque se ejecutan constantemente, y hacerlo cada vez ralentizaría el Messenger para todos. Los chats configurados para activarse en la carga de la página aparecen de inmediato.
Nota: Este comportamiento solo afecta a las apps móviles que usan el Messenger basado en web. Las apps que usan el SDK nativo de iOS o Android no se ven afectadas.
Para forzar la actualización del estado de mensajes no leídos, puedes llamar a Intercom('shutdown') seguido de Intercom('boot', { ...same user data... }). Esto provoca un ping apiBoot, que sí realiza la comprobación de mensajes no leídos. Ejecuta esto mientras el Messenger esté cerrado; llamar a shutdown con una conversación abierta la cerrará e interrumpirá al usuario.
Podrías activar esto con un temporizador o siempre que la app vuelva al primer plano.
La tasa de apertura de Post no es del 100%
Si tu Post está configurado para "mostrar el mensaje completo" pero la tasa de apertura no es del 100%:
¿Se editó el Post y originalmente se envió como "Snippet" o "Badge" a los users antes del cambio?
¿El user tenía otros mensajes pendientes al mismo tiempo que se envió el Post? Si varios mensajes intentan enviarse al mismo tiempo, el Post se enviará como una notificación con insignia roja en su lugar, para que puedan ver primero sus mensajes de mayor prioridad. Necesitarán abrir la notificación en su Messenger para que se registre como 'Open' en las estadísticas del mensaje.
Normalmente, la tasa de apertura de los Posts enviados en su totalidad debería estar por encima del 90%, y a menudo por encima del 95%. Pero si el user tenía otros mensajes pendientes, o si un user navega fuera de una página en el breve intervalo entre cuando el mensaje se les envía y cuando se muestra automáticamente, el mensaje podría no marcarse como abierto.
Si ves una tasa de apertura drásticamente inferior al 90%, intenta recibir el Post como un usuario final en tu sitio y abre la consola del navegador para capturar cualquier error en la página. En algunas circunstancias, un error de página podría evitar que el Post se muestre correctamente.
No se puede volver a activar un mensaje pausado
Si has pausado un mensaje dentro de la aplicación y no puedes volver a activarlo:
¿Tiene un tipo de Audience "Fixed"? Los mensajes Fixed no pueden volver a activarse una vez que se detienen, ya que solo se envían a users que coinciden en un momento dado, y ese momento ya ha pasado. Tendrás que duplicar tu mensaje y publicar una nueva versión.
¿Había una fecha de finalización en el mensaje? Si esa fecha está en el pasado, tendrás que actualizarla o eliminarla para que pueda enviarse de nuevo.
Si el botón "▶️ Set live" está grisado, puedes pasar el cursor sobre él para ver una descripción emergente que explica por qué no puede activarse. O edita el mensaje para ver si aparecen errores rojos en alguna de las secciones, con una explicación de lo que debe corregirse.
El mensaje pausado sigue enviándose a los users
Si has pausado un mensaje y los users aún lo están recibiendo:
¿Realmente lo recibieron antes de que se pausara, pero no interactuaron con él (no hicieron clic ni lo cerraron) por lo que permaneció emergido la próxima vez que visitaron tu plataforma? Puedes comprobar el "Recent content" en la página de perfil del user para ver la marca de tiempo de cuándo recibieron el mensaje, y compararla con cuándo se pausó el mensaje.
Si notas esto en el Help Desk cuando un user responde al mensaje saliente, comprueba la marca de tiempo de cuándo se envió el mensaje saliente (en la parte inferior del primer mensaje), ya que podrían estar respondiendo a un mensaje que recibieron hace algún tiempo.
¿Tienes varios mensajes similares en ejecución? Es posible que recibieran un mensaje de apariencia similar que no está pausado. Puedes hacer clic en el mensaje que recibieron desde el "Recent content" en el perfil del user para confirmar qué mensaje saliente fue.
User que coincide no lo recibió
Si tienes un usuario de ejemplo que debería recibir el mensaje pero no lo hizo:
¿El user se ha conectado en línea desde que se publicó? Los users necesitarán conectarse en línea para recibir un mensaje dentro de la aplicación. Puedes comprobar el valor "Last seen" en la página de perfil del user para ver cuándo estuvieron en línea por última vez.
¿Es un mensaje fijo/estático? Los users coinciden para mensajes fijos en el momento en que se publican, por lo que un user que coincida con los criterios ahora puede no haber coincidido en el momento en que se envió inicialmente.
¿Hay un activador de evento o una regla de URL? Los users necesitarán activar el evento o visitar la URL después de que esté activa, además de coincidir con las reglas de la audiencia, para recibirlo. Puede que aparezcan en la vista previa de la audiencia si coinciden con las reglas de audiencia, pero esto no tiene en cuenta si visitarán la URL o activarán el evento necesario para recibirlo.
¿Qué canales estás segmentando en "Show first on" en la sección de contenido? Si está configurado como "Show first on web" pero el user solo está activo en móvil, no recibirán el mensaje hasta que visiten en web.
¿Tiene el mensaje una fecha de inicio o de finalización, y el user ha estado en línea después de la fecha de inicio y antes de la fecha de finalización?
¿Tiene el mensaje horarios personalizados para enviar solo a ciertas horas? Ten en cuenta que los mensajes dentro de la aplicación se envían en el timezone del usuario final, por lo que deberán haber estado en línea durante esos horarios programados en su timezone.
También puedes usar la herramienta de coincidencia de mensajes para determinar por qué un user no es elegible para recibir tu mensaje.
Si estás teniendo un problema diferente, prueba estas preguntas frecuentes específicas por canal: