Enviando na página errada
Se a mensagem estiver sendo enviada para o URL do site errado:
Garanta que suas regras de público ou de página estejam configuradas com a lógica correta. Por exemplo, se você estiver combinando várias regras negativas ('is not', 'does not contain'), você quase sempre vai querer separá‑las com 'AND', não com 'OR'. E se estiver usando um filtro de correspondência exata "URL is", você precisará garantir que incluiu a URL completa, incluindo a parte
https://e quaisquer barras finais. Você pode ver mais orientações sobre como configurar seus filtros efetivamente aqui.O usuário recebeu na página correta inicialmente e depois navegou para outra página? Devido ao comportamento de 'follow page', se uma mensagem in-app não for interagida (clicada ou fechada), ela persiste enquanto o usuário navega para outras páginas — incluindo páginas explicitamente excluídas das suas regras de URL — até que ele interaja com ela. Tente verificar os "Recent page views" do usuário na página de perfil e compare os carimbos de data/hora com o carimbo de quando a mensagem foi recebida.
Ao configurar regras de URL de página, use apenas o segmento de caminho relevante (por exemplo,
/dashboard) em vez do endereço completo. Usar URLs completas pode causar incompatibilidades por variações de domain, parâmetros de consulta ou barras finais.
Trigger de evento não está funcionando
Se uma mensagem com um trigger de evento não estiver enviando:
Se você acabou de ativar a mensagem, note que as pessoas no público precisarão entrar online e acionar o evento depois que ela for ativada para recebê‑la. Ela não será enviada se tiverem acionado o evento antes da mensagem ter sido ativada. Você pode colocar o evento nas regras do Audience em vez de nos Triggers para capturar eventos passados.
Você combinou um trigger de evento com uma regra de audience do mesmo evento? Ao combinar triggers e regras, as regras de segmentação devem ter sido satisfeitas no momento do acionamento do evento, pois o trigger do evento não atualizará o usuário instantaneamente na mesma requisição. Por exemplo, se quiser enviar uma mensagem apenas na primeira vez que um usuário acionar um evento purchased-item e não em compras subsequentes, você usaria uma contagem de 0 (ou seja, users que nunca acionaram o evento antes), pois ela não atualizará para 1 até a próxima requisição.
Você precisa de um trigger de evento, ou poderia segmentar como uma regra de audience? A seção "Triggers" (When to send / Where to send) é opcional, então não é necessário incluir um evento em toda mensagem, a menos que precise garantir que ela só seja enviada quando um usuário realizar uma ação específica.
Não aparece em tela inteira
Se sua mensagem in-app estiver sendo enviada como uma notificação de badge vermelha no ícone do Messenger, mas não estiver abrindo na tela:
O usuário tem outras mensagens pendentes sendo enviadas ao mesmo tempo? Múltiplas mensagens aparecem como um badge vermelho no ícone do Messenger, para que não sejam inundados com muitos pop‑ups ao mesmo tempo. Você pode verificar o "Recent content" na página de perfil do usuário para ver quais mensagens eles receberam na mesma época.
O conteúdo do seu Chat ou Post está definido como "Sent as: Badge"? Estes sempre serão enviados como notificação de badge, a menos que você mude para "Snippet" ou "Show the full message".
Mensagens de Chat não aparecem em app móvel baseado na web
Se seu app móvel usa o Messenger baseado na web (em vez do SDK nativo iOS ou Android), chats correspondidos em pings apiUpdate não aparecerão automaticamente como snippet ou pop‑up de mensagem completa. Isso é intencional — o Intercom deliberadamente ignora a verificação de mensagens não lidas em pings de atualização porque eles rodam constantemente, e executar essa verificação toda vez deixaria o Messenger mais lento para todos. Chats configurados para acionar no carregamento da página aparecem imediatamente.
Observação: Esse comportamento afeta apenas apps móveis que usam o Messenger baseado na web. Apps usando o SDK nativo iOS ou Android não são afetados.
Para forçar a atualização do estado de mensagens não lidas, você pode chamar Intercom('shutdown') seguido de Intercom('boot', { ...same user data... }). Isso aciona um ping apiBoot, que realiza a verificação de mensagens não lidas. Execute isso enquanto o Messenger estiver fechado — chamar shutdown com uma conversa aberta irá fechá‑la e interromper o usuário.
Você pode acionar isso por um temporizador ou sempre que o app retornar ao primeiro plano.
Taxa de abertura do Post não é 100%
Se seu Post estiver configurado para "show the full message" mas a taxa de abertura não for 100%:
O Post foi editado e enviado originalmente como "Snippet" ou "Badge" para usuários antes da alteração?
O usuário tinha outras mensagens pendentes ao mesmo tempo em que o Post foi enviado? Se várias mensagens tentarem enviar ao mesmo tempo, o Post será enviado como notificação de badge vermelha em vez disso, para que possam ver primeiro suas mensagens de maior prioridade. Eles precisarão abrir a notificação no Messenger para que seja registrada como 'Open' nas estatísticas da mensagem.
Normalmente a taxa de abertura de Posts enviados na íntegra deve ficar acima de 90%, e frequentemente acima de 95%. Mas se o usuário tinha outras mensagens pendentes, ou se navegou para fora da página no curto intervalo entre quando a mensagem foi enviada e quando ela é automaticamente exibida, a mensagem pode não ser marcada como aberta.
Se você está vendo uma taxa de abertura drasticamente inferior a 90%, tente testar recebendo o Post como usuário final no seu site e abra o console do navegador para capturar quaisquer erros na página. Em algumas circunstâncias, um erro na página pode impedir que o Post seja exibido corretamente.
Não é possível ativar novamente uma mensagem pausada
Se você pausou uma mensagem in-app e não consegue ativá‑la novamente:
Ela tem um tipo de Audience "Fixed"? Mensagens Fixed não podem ser ativadas novamente depois de paradas, já que elas só enviam para users que correspondem em um ponto no tempo, e esse tempo agora está no passado. Você precisará duplicar sua mensagem e ativar uma nova versão.
Havia uma data de término na mensagem? Se essa data estiver no passado, você precisará atualizar ou remover a data de término para que ela possa enviar novamente.
Se o botão "▶️ Set live" estiver esmaecido, você pode passar o mouse sobre ele para ver uma dica explicando por que não pode ser ativado. Ou edite a mensagem para ver se aparecem erros em vermelho em alguma das seções, com uma explicação do que precisa ser corrigido.
Mensagem pausada ainda está sendo enviada para users
Se você pausou uma mensagem e os usuários ainda estão recebendo:
Eles realmente a receberam antes de ela ser pausada, mas não interagiram (clicaram ou fecharam) de modo que ela permaneceu aberta na próxima vez que visitaram sua plataforma? Você pode verificar o "Recent content" na página do perfil do usuário para ver o carimbo de quando receberam a mensagem, e compará‑lo com quando a mensagem foi pausada.
Se você está percebendo isso no Help Desk quando um usuário responde à mensagem de saída, verifique o carimbo de quando a mensagem de saída foi enviada para ele (na parte inferior da primeira mensagem), pois ele pode estar respondendo a uma mensagem que recebeu há algum tempo.
Você tem múltiplas mensagens similares rodando? É possível que tenham recebido uma mensagem de aparência semelhante que não está pausada. Você pode clicar na mensagem que eles receberam a partir do "Recent content" no perfil do usuário para confirmar qual mensagem de saída foi.
Usuário que corresponde não recebeu
Se você tem um usuário de exemplo que deveria receber a mensagem mas não recebeu:
O usuário entrou online desde que ela foi ativada? Usuários precisam entrar online para receber uma mensagem in-app. Você pode verificar o valor "Last seen" na página de perfil do usuário para ver quando ele esteve online pela última vez.
É uma mensagem fixed/static? Usuários match for fixed messages no momento em que ela é ativada, então um usuário que corresponde agora pode não ter correspondido na hora em que foi enviada inicialmente.
Há um trigger de evento ou regra de URL? Usuários precisarão acionar o evento ou visitar a URL depois que ela for ativada, além de corresponder às regras do público, para recebê‑la. Eles podem aparecer na pré‑visualização do público se corresponderem às regras, mas isso não leva em consideração se irão visitar a URL ou acionar o evento necessário para recebê‑la.
Quais canais você está segmentando em "Show first on" na seção de conteúdo? Se estiver definido para "Show first on web" mas o usuário só está ativo em mobile, ele não receberá a mensagem até visitar no web.
A mensagem tem uma data de início ou término, e o usuário esteve online após a data de início e antes da data de término?
A mensagem tem horário de envio personalizado para só enviar em certos horários? Observe que mensagens in-app são enviadas no fuso horário do usuário final, então ele precisará ter estado online durante esses horários agendados no fuso horário dele.
Você também pode usar a ferramenta de correspondência de mensagens para determinar por que um usuário não é elegível para receber sua mensagem.
Se você está enfrentando um problema diferente, tente estas FAQs específicas por canal: