Si un usuario que debería haber recibido un mensaje no lo ha hecho, puede haber varias razones. Esta guía de solución de problemas te ayudará a llegar al fondo del problema.
Nota: resolver problemas de entrega que impliquen llamar a métodos de la API de JavaScript de Intercom (como Intercom('shutdown')) requiere acceso al código de tu app, así que involucra a tu equipo de desarrollo si es necesario.
Primero, entiende cómo se entrega cada mensaje
Enviamos mensajes puntuales inmediatamente (a menos que los hayas programado). Esto significa que buscaremos todos los users que coincidan con tus filtros y lo enviaremos tan pronto los encontremos.
Para mensajes continuos, verificamos una vez por hora quién se ha vuelto elegible para recibir tus mensajes.
Para series, cada vez que un cliente inicia sesión en tu app o visita tu sitio web y es rastreado por Intercom, entrará en cualquier serie donde coincida con las reglas de entrada para un camino.
Si no han iniciado sesión, las reglas de entrada se verifican una vez por hora para cualquiera que deba entrar. Los bloques de reglas en medio de un camino (cuando el cliente ya ha entrado en la serie) se verifican aproximadamente cada 15 minutos.
Para mensajes in-app (chats, publicaciones, etc.), solo entregamos cuando un user está en línea para recibirlos. Solo haremos coincidir y enviaremos mensajes in-app cuando los users “pingueen”, es decir, cuando estén en línea y tu app nos envíe actualizaciones sobre ellos. El valor 'Última vez visto' te indica cuándo el user estuvo disponible por última vez en tu sitio para recibir un mensaje. Si tu app móvil usa el Messenger basado en web (en lugar del SDK nativo de iOS o Android), solo genera pings web, no pings de iOS o Android. Esto significa que configurar "Mostrar primero en" solo para iOS nunca coincidirá y los mensajes in-app no aparecerán. Incluye Web en la configuración "Mostrar primero en" para que los mensajes puedan coincidir con el Messenger basado en web que se ejecuta dentro de tu app móvil.
Los mensajes que tienen una notificación push adjunta se enviarán inmediatamente.
¿La sesión de Messenger del user sigue activa?
Para mensajes in-app, la entrega está controlada por la sesión de Messenger, no por el estado de inicio de sesión del user en la app anfitriona. Cuando un user es identificado vía Intercom('boot') con un JWT válido, se crea una cookie de sesión con una duración predeterminada de 7 días. Esta sesión persiste incluso después de que el user cierra sesión en tu app, hasta que llames explícitamente a Intercom('shutdown').
Esto significa que un user que ha cerrado sesión en tu app aún puede recibir mensajes in-app la próxima vez que se cargue el Messenger, si su cookie de sesión no ha expirado.
Importante: Las condiciones de audiencia se verifican cada vez que se carga el Messenger, no al cerrar sesión. Por lo tanto, los filtros de exclusión funcionarán, pero solo si el Messenger realmente se inicia mientras la sesión está activa.
Para evitar la entrega a users que han cerrado sesión o han sido excluidos:
Llama a
Intercom('shutdown')dentro del manejador de eventos de cierre de sesión. Esto borra la cookie de sesión inmediatamente y comienza una sesión anónima nueva para el siguiente visitante en ese dispositivo.Incluye cualquier estado de exclusión en el filtro de audiencia del mensaje (por ejemplo,
excluded_user is not true). Las condiciones se reevalúan en cada carga del Messenger, por lo que esto previene la entrega incluso si una sesión sigue técnicamente activa.Opcionalmente, reduce la duración máxima de la sesión en Configuración > Canales > Messenger > Mantén tu Messenger seguro para que coincida con la duración de sesión de tu app.
Nota: Este comportamiento aplica solo a users identificados. Los visitantes anónimos usan una sesión separada basada en cookies que no se ve afectada por la persistencia de sesión basada en JWT.
¿Está Messenger Security bloqueando la entrega a users con sesión iniciada?
Cuando Messenger Security está habilitado en tu espacio de trabajo, los mensajes de chat a users con sesión iniciada solo se entregan si se proporciona un token de seguridad válido durante la llamada de inicio del Messenger. Si el token falta o es inválido, el Messenger no completa un inicio seguro en esa página, por lo que no se envía ping, las páginas recientes del user permanecen vacías y los mensajes de chat in-app no pueden entregarse, incluso si el user está activo en la página.
Cómo verificar: En Configuración > Canales > Messenger > Seguridad, revisa cuáles de tus dominios de producción están pasando la verificación de seguridad. Un dominio que aparece como "no listo" significa que los pings de ese dominio no llevan un token válido, y el Messenger con sesión iniciada en él no completará un inicio seguro. Confirma con tus desarrolladores que un JWT nuevo (o hash de verificación de identidad, si usas el método antiguo) se genera del lado del servidor y se pasa a la llamada de inicio del Messenger para ese dominio exacto. Consulta Autenticación de users en el Messenger con JSON web tokens (JWTs) para los pasos de configuración.
Esta verificación de seguridad solo aplica a la instalación con sesión iniciada, donde el Messenger se inicia con una identidad conocida (user_id/email). Los Leads alcanzados a través de una instalación anónima en el sitio de marketing no están sujetos a esta verificación y pueden recibir mensajes de chat in-app siempre que el Messenger esté cargado en su página, la misma regla de entrega basada en sesión descrita arriba, sin necesidad de token.
A continuación, responde estas preguntas
Si aún no has descubierto por qué tu mensaje no se envía, deberás responder las siguientes preguntas:
¿Estás enviando el mensaje a una audiencia grande?
Los mensajes con una audiencia grande pueden tardar un poco en procesarse. Cuando activas un mensaje, verificamos todos los filtros del mensaje y vemos qué users coinciden con ellos. Cuanto más grande es el mensaje, más tiempo puede tardar este procesamiento en completarse.
¿Los users coinciden con los filtros que has establecido?
En Intercom, toda la mensajería es basada en disparadores. En otras palabras, los destinatarios deben coincidir con los filtros que has establecido en un mensaje antes de ser elegibles para recibirlo. Ejemplos de filtros serían “Registrado hace menos de 30 días” y “Plan es lite”.
Cuando agregas filtros a un mensaje, estos se convierten en los criterios que Intercom usa para verificar la elegibilidad de los users para el mensaje. Por ejemplo, si tienes un mensaje configurado con los filtros anteriores, se vería así:
Actualmente ningún user coincide con estos filtros, por lo que nadie recibirá el mensaje. Sin embargo, como es un mensaje continuo, Intercom verificará cada hora quién coincide con estos filtros y enviará el mensaje a los users que sí coincidan.
Si los users coinciden con los filtros de este mensaje, aparecerán en el lado derecho de la ventana. Así es como se ve el mensaje cuando las personas coinciden con los filtros:
¿Ese user se ha dado de baja?
Si un user se ha dado de baja de los mensajes por email de tu app, no recibirá más correos masivos tuyos. Sin embargo, aún puede recibir mensajes in-app y correos enviados solo a él, pero no recibirá mensajes manuales ni automáticos por email.
¿El mensaje ha rebotado?
Si Intercom intenta enviar un mensaje a un destinatario y hay un fallo permanente, también conocido como rebote duro, no intentaremos enviar más correos a ese destinatario. Esto se debe a que es peligroso intentar continuamente entregar a direcciones con rebote duro y puede dañar tu reputación como remitente y la capacidad de que los mensajes lleguen a la bandeja de entrada.
¿Ese user ha marcado el mensaje como spam?
Igualmente, si un destinatario marca uno de tus correos como spam, no podrás enviarle más correos desde tu app de Intercom.
Los users que están dados de baja, con rebote o que han marcado tus mensajes como spam serán eliminados automáticamente de la audiencia de mensajes masivos. Si intentas enviar un mensaje a alguien que previamente rebotó o se quejó, Intercom no intentará la entrega.
Ciertas direcciones no están destinadas a recibir correos de marketing y se consideran automáticamente inelegibles para recibir email. Ejemplos incluyen direcciones abuse@ y postmaster@.
Si intentas enviar un mensaje y todos los destinatarios son inelegibles para recibirlo, podrías ver un mensaje que dice: “estamos preparando este correo y comenzará a enviarse pronto.”
Nota: Si el atributo "marcado como spam" de un user o lead es 'true' pero has obtenido su consentimiento escrito o verbal para recibir correos tuyos nuevamente, contacta a nuestro equipo de soporte que puede ayudarte a actualizar al user. Es importante que obtengas el consentimiento del user/lead primero, ya que enviar correos a personas que continúan marcando tus correos como spam puede dañar tu reputación como remitente y aumentar la probabilidad de que tus correos sean dirigidos a los filtros de spam de los clientes.
¿Has programado tu mensaje para enviarlo dentro de una ventana de entrega?
Si has programado tus mensajes para enviarse a una hora determinada o dentro de una ventana de entrega, eso podría retrasar la entrega. Por ejemplo, podrías querer activar un mensaje a las 9 a. m. en otra zona horaria mientras duermes; puedes programar un mensaje para hacerlo.
También puedes configurar ventanas de entrega, que podrían afectar los tiempos de entrega de los mensajes. Si tienes un mensaje con una ventana de entrega de 9 a. m. a 5 p. m., se entregará cuando esté dentro de esa ventana horaria en la zona horaria del destinatario. Si no conocemos la zona horaria del destinatario, usaremos la zona horaria de la app.
Nota: Los mensajes con ventanas de entrega se envían según la zona horaria del destinatario, no la del remitente, a menos que no haya datos de ubicación disponibles para el destinatario, en cuyo caso usaremos la zona horaria de la app.