Perguntas frequentes

Este artigo fornece respostas para algumas perguntas frequentes sobre mensagens no app.

O que é uma mensagem no navegador e qual é a diferença em relação a uma mensagem no app?

Mensagens no navegador são mensagens no app enviadas para navegadores web. Para criar uma, selecione Navegador web no campo Enviar para ao criar sua Campaign ou seu Canvas de mensagem no app.

Uma mensagem no app é exibida se o dispositivo estiver offline?

Depende. As mensagens no app são entregues no início da sessão. Portanto, se o dispositivo conseguir baixar a carga útil antes de ficar offline, a mensagem no app ainda poderá ser exibida offline. Se a carga útil não for baixada, a mensagem no app não será exibida.

Se um usuário já tiver a carga útil de uma mensagem no app no dispositivo e a expiração da mensagem for alterada, a expiração será atualizada no dispositivo?

Quando um usuário inicia uma sessão, a Braze verifica se houve alterações em alguma mensagem no app para a qual ele é elegível e faz as atualizações necessárias. Então, se a expiração tiver sido alterada e o usuário registrar uma sessão, a mensagem no app será enviada ao dispositivo com as informações atualizadas.

Como configuro o horário de silêncio para uma campanha de mensagem no app?

O recurso de horário de silêncio não está disponível para campanhas de mensagens no app. Esse recurso serve para evitar que mensagens sejam enviadas aos seus usuários em horários específicos. Nas campanhas de mensagens no app, seus usuários só recebem mensagens no app se estiverem ativos no app.

Como alternativa para enviar mensagens no app em um horário específico, use o exemplo de código Liquid a seguir. Com ele, a mensagem é interrompida se a mensagem no app for exibida depois das 19h59 ou antes das 8h no fuso horário especificado.

1
2
3
4
5

{% 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

Os usuários podem receber uma mensagem no app novamente depois de dispensá-la?

Campaigns

Para Campaigns de mensagens no app, você pode permitir que os usuários se tornem elegíveis para receber a Campaign novamente ativando a reelegibilidade em Controles de entrega (Permitir que os usuários se tornem reelegíveis para receber a campanha). O tempo até que eles possam recebê-la de novo depende da janela de reelegibilidade que você definir e de como a Braze registrou o envio anterior. Consulte Reelegibilidade para campanhas e Canvas para entender o comportamento das Campaigns, incluindo como a reelegibilidade se relaciona com o recebimento da mensagem.

Se a reelegibilidade estiver desativada, em geral os usuários não vão receber a mesma Campaign novamente apenas por atenderem aos critérios de qualificação depois de já a terem recebido.

Canvas

Para mensagens no app enviadas por um Canvas, a possibilidade de um usuário ver a mensagem novamente depende dos controles de entrada do Canvas (como permitir que os usuários entrem novamente no Canvas) e da configuração da etapa. Os controles de entrega da Campaign não são o único fator.

Quando a elegibilidade para uma mensagem no app é calculada?

Campaigns

Em Campaigns de mensagens no app, a Braze verifica se o usuário está no seu público-alvo quando o dispositivo dele baixa as mensagens no app. Isso costuma acontecer no início da sessão. O dispositivo armazena as mensagens elegíveis e exibe cada uma quando o gatilho dela ocorre, mesmo que seja mais tarde na sessão.

Em Campaigns com horário de início no futuro, a Braze também envia a mensagem para dispositivos que iniciam uma sessão até uma hora antes do horário de início. Assim, a mensagem fica pronta para ser exibida no horário certo. Por exemplo, um usuário que inicia uma sessão às 6h30 recebe uma Campaign que começa às 7h. A Braze verifica a elegibilidade dele às 6h30, e a mensagem é exibida quando o gatilho ocorre depois das 7h.

Elegibilidade durante uma sessão

Usuários que se tornam elegíveis durante uma sessão recebem a mensagem no início da próxima sessão.

Para verificar a elegibilidade novamente logo antes da exibição da mensagem, selecione Reavaliar a elegibilidade da campanha antes da exibição. Se o usuário não se qualificar mais, a mensagem não será exibida. Essa configuração não envia a mensagem para usuários que se tornaram elegíveis depois do início da sessão. Para saber mais, consulte Escolha os usuários-alvo.

Canvas

Para mensagens no app em um Canvas, a Braze verifica o público da etapa quando o usuário chega a ela. A mensagem é então baixada no início da próxima sessão do usuário.

Por que minha Campaign de mensagem no app arquivada ainda está gerando impressões de mensagem no app?

Isso pode acontecer com usuários que atendiam aos critérios do Segment enquanto a Campaign de mensagem no app estava ativa.

Para evitar isso, selecione Reavaliar a elegibilidade da campanha antes de exibir ao configurar sua Campaign.

Por que não vejo aberturas para mensagens no app?

As mensagens no app não usam uma métrica de Aberturas. A Braze registra Impressões quando a mensagem aparece na tela e Cliques quando os usuários interagem com o corpo da mensagem ou com os botões. Se uma exportação ou um relatório multicanal incluir linhas de mensagens no app, compare Impressões e Cliques em vez das aberturas típicas de e-mail. Para ver as definições, consulte Relatórios de mensagens no app.

Várias mensagens no app podem ser exibidas na mesma sessão?

Sim, mas só uma mensagem no app pode ser exibida a cada ocorrência de um evento-gatilho. Se várias Campaigns de mensagens no app compartilharem o mesmo gatilho (por exemplo, início de sessão), apenas a mensagem de maior prioridade será exibida cada vez que esse gatilho ocorrer. Para gatilhos de início de sessão, isso significa que só uma mensagem pode ser exibida por sessão. Então, a próxima oportunidade de mostrar outra mensagem elegível é na sessão seguinte.

Quando várias mensagens têm o mesmo nível de prioridade, a mensagem criada mais recentemente é exibida primeiro. Para gatilhos de início de sessão, a próxima mensagem mais recente é exibida em uma sessão posterior. Para outros tipos de gatilho, a próxima mensagem mais recente é exibida na próxima vez que o evento-gatilho ocorrer, o que pode acontecer na mesma sessão ou em uma sessão posterior.

Para controlar a ordem de exibição dentro de um bucket de prioridade, acesse as configurações de entrega de qualquer uma das Campaigns e selecione Set Exact Priority. Depois, arraste e solte as Campaigns na ordem desejada. Para saber mais, consulte Escolher uma prioridade.

Como as impressões e os cliques de mensagens no app são registrados?

Consulte Relatórios de mensagens no app para entender como as impressões e os cliques são registrados conforme a ação do usuário. Para ver exemplos específicos de mensagens em tela inteira criadas com o editor tradicional, consulte Métricas de mensagens em tela inteira por ação do usuário.

Como a Braze calcula a expiração de uma mensagem no app definida como “after 1 day(s)”?

A Braze calcula um tempo de expiração de um dia como 24 horas após os usuários se tornarem elegíveis para receber uma mensagem.

O que são mensagens no app modeladas?

As mensagens no app são entregues como mensagens no app modeladas quando a opção Reavaliar a elegibilidade da campanha antes de exibir está selecionada ou quando alguma das seguintes Liquid tags existe na mensagem:

• canvas_entry_properties
• connected_content
• Variáveis de SMS, como {sms.${*}}
• catalog_items
• catalog_selection_items
• event_properties

A Braze também usa a entrega modelada para Campaigns de mensagens no app sem atividades. São Campaigns que ainda estão ativas, mas que não estão mais enviando ou não são mais necessárias. Essas Campaigns continuam seguindo as regras de público e de gatilho configuradas.

A Braze também pode usar a entrega modelada para proteger o desempenho do app. Se a preparação do conteúdo Liquid atrasar a resposta de uma sessão em mais de alguns segundos, a Braze adia o restante do processamento. Essas mensagens são renderizadas quando são disparadas.

Isso significa que, no início da sessão, o dispositivo recebe o gatilho da mensagem no app, e não a mensagem inteira. Quando o usuário dispara a mensagem no app, o dispositivo dele faz uma solicitação de rede para buscar a mensagem real.

Nota

A mensagem não é entregue se o dispositivo não tiver acesso à internet. A mensagem pode não ser entregue se a lógica Liquid demorar muito para ser resolvida.

Para reduzir a quantidade de Liquid que a Braze processa no início da sessão, consulte Otimizar o desempenho das mensagens no app.

Como funciona a interrupção de mensagens no app?

Na Braze, uma interrupção acontece quando um usuário realiza uma ação que o torna elegível para receber uma mensagem, mas a mensagem não é enviada porque a lógica Liquid dela marca o usuário como inelegível. Por exemplo:

1. Sam realiza uma ação que deveria disparar uma Campaign de e-mail.
2. O corpo do e-mail tem uma lógica Liquid que diz: se o atributo personalizado de pontuação for menor que 50, não envie este e-mail.
3. A pontuação de Sam no atributo personalizado é 20.
4. A Braze reconhece que Sam não deve receber este e-mail, e o e-mail é interrompido.
5. Um evento de interrupção é registrado.

No entanto, como as mensagens no app são um canal do tipo pull, as interrupções funcionam de um jeito um pouco diferente para elas.

Comportamento padrão de interrupção de mensagens no app

As mensagens no app são baixadas pelo dispositivo no início da sessão e armazenadas em cache no dispositivo. Assim, independentemente da qualidade da conexão com a internet, a mensagem pode ser entregue instantaneamente ao usuário. Por exemplo, se um usuário vai receber cinco mensagens no app durante a sessão, ele recebe as cinco no início da sessão. As mensagens ficam em cache localmente e aparecem quando os eventos-gatilho definidos acontecem (início da sessão, clique do usuário em um botão que registra um evento personalizado, entre outros).

Em outras palavras, a lógica que determina se uma mensagem no app deve ser interrompida é executada antes de o gatilho acontecer. Para demonstrar isso, imagine que Sam, do exemplo do e-mail, está inscrito para receber notificações por push.

1. Sam inicia uma sessão ao abrir um app com tecnologia da Braze no celular.
2. Com base nos critérios de público das Campaigns ativas no espaço de trabalho, Sam pode ser elegível para cinco Campaigns diferentes. As cinco são baixadas para o celular e armazenadas em cache.
3. Sam não realizou nenhuma ação que dispararia essas mensagens, mas pode recebê-las durante a sessão.
4. O Liquid de duas das mensagens no app tem regras que impedem Sam de receber a mensagem (por exemplo, o atributo personalizado de pontuação não é alto o suficiente).
5. Sam não recebe as duas mensagens no app que o excluem, mas recebe as outras três.
6. Nenhum evento de interrupção é registrado.

A Braze não registra nenhum evento de interrupção no caso de Sam porque a situação não se encaixa na definição de interrupção: Sam não realizou nenhuma ação que dispararia as mensagens. Nas mensagens no app, os usuários nunca chegam a realizar o gatilho antes de a Braze determinar que eles não devem ver a mensagem.

Comportamento de interrupção de mensagens no app modeladas

As mensagens no app modeladas obrigam o SDK a reavaliar se uma mensagem deve ser exibida no momento em que o evento-gatilho acontece. Por isso, o comportamento de interrupção é diferente. Veja este exemplo:

1. Sam inicia uma sessão da Braze ao abrir um app com tecnologia da Braze no celular.
2. Os critérios de público das Campaigns ativas indicam que Sam pode ser elegível para uma mensagem no app modelada. Então, as informações do gatilho são enviadas para o dispositivo sem a carga útil da mensagem.
3. Sam seleciona um botão que registra um evento personalizado, disparando a mensagem no app modelada.
4. O dispositivo de Sam faz uma solicitação de rede para buscar a mensagem no app.
5. A lógica Liquid da mensagem resulta em uma interrupção, e a Braze registra isso como interrupção, já que Sam realizou a ação-gatilho antes dessa avaliação.

Comparação do comportamento de interrupção de mensagens no app

Esta tabela compara os fluxos de mensagens no app que Sam vivenciou:

Quando o Connected Content é executado em mensagens no app?

Nas mensagens no app modeladas, o Connected Content e outras Liquid tags são resolvidos quando o evento-gatilho acontece e o dispositivo solicita a carga útil da mensagem, e não quando o usuário clica em um botão dentro da mensagem. Cada busca modelada pode incluir chamadas de Connected Content para aquela exibição.

Se o seu HTML faz referência a dados REST retornados pelo Connected Content, esses dados ficam disponíveis durante a sessão em que a mensagem foi modelada. Vários botões podem fazer referência à mesma resposta do Connected Content sem disparar chamadas adicionais ao clicar.

Qual é a postergação máxima após um gatilho em Campaigns de mensagens no app?

As Campaigns de mensagens no app podem postergar a entrega em até duas horas (7.200 segundos) após o evento-gatilho. As opções de postergação são Imediatamente e Após uma postergação. Para uma espera mais longa, adicione uma etapa de Postergação antes de uma etapa de mensagem no app em um Canvas. Para configurar a postergação, consulte Entrega baseada em ação.

Por que há uma postergação antes de minha mensagem no app ser exibida?

As mensagens no app padrão são exibidas assim que a carga útil em cache fica pronta após o evento-gatilho. No Android e no iOS, imagens grandes ou outros ativos hospedados em CDN referenciados na mensagem podem causar uma pequena postergação enquanto esses recursos terminam de ser baixados antes de a mensagem no app aparecer.

As mensagens no app modeladas e as Campaigns com a opção Reavaliar a elegibilidade da campanha antes da exibição selecionada exigem uma solicitação de rede adicional após o gatilho antes de a mensagem aparecer. Isso pode causar uma pequena postergação (normalmente menos de 100 ms em uma conexão estável). Para saber mais, consulte Escolher usuários para direcionar.

Por que minha mensagem no app está diferente da prévia do dashboard?

As mensagens no app entregues podem ficar diferentes da prévia do dashboard quando:

• Sua integração aplica estilos personalizados ou substitui a interface padrão de mensagens no app em determinadas plataformas
• A prévia usa um perfil de usuário teste com atributos diferentes dos do destinatário
• O conteúdo modelado é resolvido de forma diferente no momento do envio do que no modo de prévia

Use Enviar mensagens de teste com um usuário teste cujo perfil corresponda ao seu público-alvo ao validar a aparência.

Por que uma mensagem no app com várias páginas usa o mesmo fundo em todas as páginas?

Quando a Imagem de fundo é ativada em uma página de uma mensagem no app com várias páginas, esse fundo é aplicado a todas as páginas da mensagem. Para usar fundos diferentes em cada página, use um bloco de HTML personalizado com JavaScript para trocar as imagens entre as páginas.

Como faço para testar mensagens no app para web?

Os envios de teste de mensagens no app para web exigem que o push esteja ativado no dispositivo de teste, porque o fluxo de teste entrega uma notificação por push que abre o app ou o site onde a mensagem no app é exibida. O mesmo caminho de teste baseado em push vale para qualquer plataforma em que o push não esteja configurado com a Braze. Mesmo assim, a falta de push é mais comum na web, já que muitas integrações móveis já têm o push ativado. Como alternativa, use uma campanha ativa direcionada a um Segment de teste interno. Para ver as etapas, consulte Enviar mensagens de teste.

As mensagens no app exigem integração de push?

As mensagens no app não exigem notificações por push para funcionar em produção. Elas são entregues pelo SDK da Braze e aparecem durante uma sessão ativa no app, sem precisar de integração de push.

No entanto, os envios de teste de mensagens no app exigem que o push esteja ativado nos seus dispositivos de teste. Isso acontece porque as mensagens no app de teste são entregues por meio de uma notificação por push que dispara a exibição da mensagem no app. O usuário teste precisa ter o push ativado e tocar na notificação por push de teste para ver a mensagem no app.

Nas Campaigns em produção, os usuários veem as mensagens no app de acordo com os gatilhos da sua Campaign (como início de sessão ou eventos personalizados), sem envolvimento do push.

Por que aparecem caracteres extras ou não renderizados na minha mensagem no app?

Copiar texto de outro app (como um processador de texto ou uma página da web) pode inserir caracteres invisíveis ou não imprimíveis no corpo da mensagem. Esses caracteres podem aparecer como símbolos soltos ou quebrar o Liquid e o HTML em mensagens personalizadas.

Para corrigir caracteres soltos ou não renderizados, digite novamente o texto afetado no editor da Braze ou exclua diretamente os caracteres indesejados, em vez de selecionar e substituir apenas o texto visível. Para mensagens HTML personalizadas com caracteres especiais, adicione <meta charset="UTF-8"> dentro do <head> do seu HTML. Para saber mais, consulte Codificação de caracteres.

Por que o botão de fechar fica oculto em mensagens no app HTML em tela inteira no Android?

Em dispositivos com telas de ponta a ponta (incluindo o Android 15 ou superior), as mensagens no app HTML em tela inteira podem ser desenhadas atrás da barra de status do sistema. Com isso, um controle de fechar no topo do layout pode ficar oculto.

A partir da versão 37.0.0, o SDK da Braze para Android aplica window insets às mensagens no app HTML por padrão. Assim, os controles permanecem na área segura. Se os usuários ainda virem sobreposição, faça upgrade para a versão mais recente do SDK da Braze para Android.

Em versões mais antigas do SDK, os desenvolvedores podiam ativar BrazeConfig.setIsHtmlInAppMessageApplyWindowInsetsEnabled(true) antes de esse comportamento se tornar o padrão.

O que devo saber ao personalizar mensagens no app de arrastar e soltar?

O editor de arrastar e soltar oferece os tipos de exibição modal e tela inteira. Você cria o conteúdo dentro desses contêineres com os blocos do editor.

Lembre-se:

• Links e deep links: Por padrão, cada ação ao clicar tem um único campo de URL. Use Liquid na URL para variar os links por dispositivo, tipo de app ou atributos do usuário. No Contêiner de mensagem, você também pode ativar o comportamento ao clicar específico por plataforma para definir links diferentes para cada plataforma.
• Opacidade e planos de fundo: A opacidade do contêiner de mensagem afeta todo o plano de fundo da mensagem. Cada bloco pode ter a própria cor de fundo. Para ter mais controle, adicione CSS personalizado em um bloco de código personalizado.
• Largura da mensagem: No editor, não é possível definir a largura máxima do Contêiner de mensagem abaixo de 325 px. Isso mantém o conteúdo legível em telas menores. Se precisar de um layout mais estreito, use CSS personalizado.
• Planos de fundo por plataforma: Uma mesma mensagem usa a mesma imagem e as mesmas cores de fundo na web e no celular. Não é possível definir planos de fundo diferentes para cada plataforma no editor.
• Mensagens com várias páginas: As imagens de fundo e as ações ao clicar no nível da mensagem se aplicam a todas as páginas de uma mensagem com várias páginas. Para usar imagens completas diferentes em cada página, adicione botões com link para a próxima página.
• Estilos no nível da mensagem: Os estilos no nível da mensagem se aplicam à mensagem inteira.
• Imagens de fundo: As imagens de fundo são esticadas para se ajustar ao modal.

Para ver mais considerações sobre o editor, consulte o Guia de preparação de mensagens no app.

O que significa “Event was published, but no subscribers were found” nos logs do SDK para Android?

Essa linha de log geralmente não indica um erro. Ela costuma aparecer quando a Braze publica um evento interno (como NoMatchingTriggerEvent) e não há nenhum listener de mensagem no app ou de Content Cards inscrito naquele momento.

Se você vir esse log quando espera que um evento personalizado dispare uma mensagem no app, verifique se o evento está sendo registrado e se o usuário faz parte do público da Campaign ou do Canvas. Se a mensagem depender de Content Cards, confirme também que eles estão sincronizados.