Exibir um in-app antes da solicitação de permissão de push

Um in-app de pré-permissão é uma mensagem que você exibe antes da solicitação de permissão de push do sistema. Use-o para explicar por que as notificações push são úteis e, em seguida, peça permissão somente depois que o usuário disser sim no seu in-app.

No iOS, a solicitação do sistema aparece apenas uma vez por instalação. Se o usuário tocar em Não Permitir, o aplicativo não poderá mostrar essa solicitação novamente. O push permanece desativado até que ele ative as notificações nas Configurações. Pedir primeiro no in-app significa que você gasta essa única chance apenas com usuários que já disseram sim para você.

Use este guia se você quiser criar uma única solicitação HTML multiplataforma no Painel de Controle e acioná-la por evento tanto no iOS quanto no Android.

Use um guia diferente se:

• Sua equipe for enviar uma solicitação apenas para iOS no código do aplicativo (não editável no Painel de Controle, não iniciada por um evento de Journey): Guia de push para iOS.
• Você precisar reengajar usuários que já desativaram o push ou nunca o concederam (apenas recuperação, não o primeiro pedido): Criar pop-ups de recuperação de opt-out.

Antes de começar

Assistência de desenvolvedor necessária

Você cria o modelo no Painel de Controle. Compartilhe o guia de eventos e o postEvent com sua equipe de desenvolvimento — eles cuidam dos dois pré-requisitos abaixo.

O Pushwoosh nunca exibe o diálogo de permissão do sistema por si só. Não há nada a configurar no Painel de Controle para adiá-lo. O diálogo aparece apenas quando o usuário toca no botão de aceitar no seu in-app.

Trabalhe com sua equipe de desenvolvimento nestes pré-requisitos:

1. Confirme que o aplicativo não solicita permissão de push antes (inclusive no primeiro lançamento).
2. Concorde em um nome de evento personalizado e quando acioná-lo, por exemplo, onboarding_completed logo após o onboarding, ou locked_feature_tapped quando o usuário toca em um recurso que precisa de notificações. Sua equipe chamará postEvent com esse nome. Saiba mais sobre eventos.

Crie o in-app

Os botões neste guia rodam em JavaScript personalizado, que só funciona em um modelo de in-app baseado em HTML. Um modelo de in-app nativo não pode executar este código, então não crie o modelo com In-app nativa.

1. Vá para Conteúdo → In-Apps e clique em Criar in-app para abrir diretamente o editor integrado.

2. Insira um nome para o modelo.

3. Abra a aba Blocos no painel direito e adicione um bloco de texto ou de título com seu argumento para ativar o push.

4. Adicione um bloco de botão para a ação de aceitar e outro para a ação de recusar. Ambos os botões podem executar seu JavaScript assim que o in-app carregar, sem precisar esperar por mais nada.

Dica

Para destacar o botão de aceitar como a ação principal, como na captura de tela acima, selecione o botão de recusar, ative Fundo em seu painel de Estilos e defina-o como transparent. Ative também a Cor do texto e escolha uma cor que ainda seja legível contra o fundo do modelo.

5. Selecione o botão de aceitar e defina o Tipo de ação como Javascript personalizado.
6. Cole apenas o código abaixo em onClick.

pushwoosh.registerForPushNotifications();
pushwoosh.closeInApp();

7. Selecione o botão de recusar e defina o Tipo de ação como Javascript personalizado.
8. Cole apenas isto em onClick:

pushwoosh.closeInApp();

Depois de salvar o modelo:

• Botão de aceitar: o diálogo de permissão do sistema aparece.
• Botão de recusar: o in-app fecha e nenhum diálogo do sistema aparece.

Um in-app de pré-permissão exibido antes da solicitação do sistema

Dica

Apenas para upload de ZIP / desenvolvedor: se você criar um arquivo HTML bruto para upload de ZIP, use as tags completas em vez do campo onClick do editor:

<button onclick="pushwoosh.registerForPushNotifications(); pushwoosh.closeInApp();">Ativar notificações</button>
<button onclick="pushwoosh.closeInApp();">Agora não</button>

Pular a solicitação para usuários que já optaram por receber

Adicione uma condição de exibição para que o in-app se oculte para usuários que já concederam o push, mesmo que um gatilho posterior mostre o modelo novamente. O status de consentimento de push vem de Push Alerts Enabled, uma tag booleana padrão que o SDK define a partir da permissão de notificação do sistema do dispositivo.

1. No painel Camadas, clique no primeiro bloco e, em seguida, clique com a tecla Shift em todos os outros blocos para selecionar o modelo inteiro de uma vez.
2. Ative Mostrar este bloco condicionalmente. A regra que você definir abaixo se aplica a toda a seleção de uma vez.
3. Defina a regra como Push Alerts Enabled é falso.
4. Em Se o valor for desconhecido, escolha Mostrar bloco. Uma instalação nova sem valor de tag ainda deve ver a solicitação.

Cuidado

Push Alerts Enabled é atualizado na próxima vez que o aplicativo do dispositivo for aberto, não no momento em que o usuário alterna a permissão nas Configurações do sistema. Um usuário que ativa o push a partir das Configurações ainda pode ver este bloco mais uma vez até reabrir o aplicativo.

Acione o in-app antes que a permissão seja solicitada

Um dispositivo que ainda não passou pelo registro não tem um token de push, então você não pode alcançá-lo com uma notificação push. Acione o in-app pelo evento personalizado que você combinou com o desenvolvimento.

1. Peça à sua equipe de desenvolvimento para chamar postEvent com o nome do evento combinado no momento em que você deseja fazer o pedido.
2. Vá para Customer Journey Builder → Criar Campanha e comece com uma Entrada baseada em gatilho que escuta por esse evento.
3. Adicione um elemento In-app e selecione o modelo que você criou. Saiba mais sobre o envio de in-apps via Customer Journey.
4. Inicie a jornada quando estiver pronto para mostrar a solicitação.

Nota

O in-app não aparece no instante em que o evento é acionado. A entrega ocorre na próxima abertura do aplicativo do dispositivo após isso.

Cenário de exemplo: pedir permissão de push logo após o onboarding

Imagine que você queira pedir permissão de push no momento em que um usuário termina o onboarding, em vez de interromper o próprio tutorial.

1. Crie o evento onboarding_completed e confirme que sua equipe de desenvolvimento o aciona quando o usuário termina o fluxo de onboarding. Saiba mais sobre a criação de eventos
2. Defina onboarding_completed como o gatilho para sua jornada, usando uma Entrada baseada em gatilho.
3. Adicione um elemento In-app e selecione o modelo de pré-permissão que você criou.
4. Inicie a jornada.

Todo usuário que completa o onboarding vê a solicitação uma vez. A condição de exibição de Pular a solicitação para usuários que já optaram por receber impede que ela seja acionada novamente para usuários que já concederam o push.

Verifique se funcionou

A solicitação do sistema é única, então testar ambos os botões requer dois dispositivos de teste (ou duas instalações novas) que ainda não concederam ou negaram o push, um para cada botão. Em cada dispositivo:

1. Acione o evento combinado a partir do aplicativo.
2. Reabra o aplicativo e confirme que a jornada entrega seu in-app.

Então:

3. No primeiro dispositivo, toque no botão de aceitar e confirme que o diálogo de permissão do sistema aparece.
4. No segundo dispositivo, toque no botão de recusar e confirme que o in-app fecha sem nenhum diálogo do sistema.
5. Após a próxima abertura do aplicativo, confirme que Push Alerts Enabled corresponde ao estado de permissão em cada dispositivo.

Crie um segmento de usuários que ainda têm o push desativado

Filtre por Push Alerts Enabled para encontrar usuários que recusaram ou nunca concederam a permissão. A tag é false quando o push ainda não é permitido, inclusive antes de o usuário ter visto o diálogo do sistema, então um dispositivo de pré-permissão já se enquadra neste segmento.

1. No construtor de segmentos, adicione um filtro pela tag Push Alerts Enabled.
2. Defina o operador como é falso. Saiba mais sobre a criação de segmentos por tags.

Use este segmento para reter uma solicitação repetida de usuários que ainda não têm o push ativado, ou para executar uma jornada periódica de reconquista. Veja o segmento de recuperação de opt-out para um exemplo prático com a mesma tag.

Veja também

• Guia de push para iOS: a alternativa nativa, apenas para iOS, a esta abordagem HTML multiplataforma.
• Criar pop-ups de recuperação de opt-out: recupere usuários que já desativaram o push (não o primeiro pedido), usando a mesma tag Push Alerts Enabled.
• Criar in-apps com JavaScript: a referência completa da ponte JavaScript.