A sua app envia notificações. Mas consegue dizer quais ajudam realmente o seu negócio?
Antes de aprovar mais mensagens, peça uma resposta mais útil do que o número de envios: que ação pretende facilitar e como vai confirmar que aconteceu? Numa app de reservas, pode ser ocupar uma vaga libertada. Numa app de assistência, pode ser obter a aprovação de um orçamento.
A nossa recomendação é começar pela ação concluída e reconstruir o caminho até ao aviso. Isso permite decidir se precisa de melhorar a entrega, corrigir o ecrã de destino ou simplesmente deixar de enviar aquela mensagem.
Este trabalho deve fazer parte do desenvolvimento da app, não ficar reduzido a um relatório de campanhas. Exige decisões sobre os acontecimentos registados, o destino de cada aviso e a ligação aos dados que confirmam o resultado.
Um envio não é uma confirmação de entrega
Uma notificação push é um aviso enviado para o dispositivo através dos serviços de distribuição. Quando o Firebase Cloud Messaging aceita uma mensagem e devolve um identificador, isso não significa que ela já chegou ao telemóvel. A documentação distingue expressamente aceitação e entrega. (firebase.google.com)
Também não deve tratar receção, apresentação e abertura como sinónimos. Nos relatórios do Firebase, existem diferenças entre plataformas: os indicadores de receção e de apresentação descritos nessa ferramenta estão disponíveis para Android, enquanto as aberturas têm condições próprias de registo. Não há uma sequência de métricas automaticamente igual em iPhone e Android. (firebase.google.com)
Por isso, proponha à equipa duas perguntas separadas:
- Conseguimos observar o percurso técnico da mensagem? Aqui interessa localizar recusas, atrasos e pontos sem informação.
- Conseguimos confirmar a ação de negócio? Aqui interessa saber se a reserva ficou concluída ou se o orçamento foi aprovado.
Não aceite que uma coluna chamada «sucesso» responda às duas. Peça a definição exata dessa coluna e um exemplo do registo que a alimenta.
Escolha uma notificação que mereça ser medida
Imagine uma empresa portuguesa de atividades desportivas com uma app própria. Um cliente pede para ser avisado quando surgir uma vaga numa aula. Este é um exemplo hipotético, mas permite tornar a decisão concreta.
O objetivo não deve ser «aumentar as aberturas». Deve ser ajudar clientes em lista de espera a reservar lugares disponíveis, sem os levar a ecrãs onde já não podem fazer nada.
Antes de pedir alterações à app, preencha esta ficha. As respostas propostas são apenas um ponto de partida para esse exemplo.
| Campo de decisão | Resposta a definir pela empresa |
|---|---|
| Acontecimento que justifica o aviso | Libertação de uma vaga numa aula com lista de espera |
| Destinatário elegível | Cliente que pediu esse aviso e continua interessado |
| Ação pretendida | Concluir uma reserva válida |
| Destino ao tocar | Detalhe da aula com disponibilidade atualizada |
| Fim da utilidade | Aula iniciada ou oportunidade de reserva terminada |
| Confirmação do resultado | Reserva aceite pelo sistema de reservas |
| Situação a evitar | Mostrar disponibilidade que já não existe |
| Decisão após a análise | Manter, alterar ou retirar este tipo de aviso |
A ficha obriga a escolher. Se a equipa não conseguir preencher o campo «ação pretendida», adie o desenvolvimento dessa notificação.
Para um aviso puramente informativo, escolha outro resultado verificável. Não force uma compra ou uma abertura como objetivo quando o serviço consiste apenas em comunicar uma alteração.
Meça o percurso sem fingir que vê tudo
Peça um pequeno dicionário de acontecimentos: o que se regista, em que momento e com que significado. Para o exemplo da aula, recomendamos esta sequência de observação:
1. Oportunidade criada: o sistema confirma uma vaga disponível.
2. Destinatário selecionado: as regras identificam quem pode receber o aviso.
3. Pedido de envio aceite ou recusado: fica registada a resposta do serviço de distribuição.
4. Abertura identificada: quando observável, a app reconhece que foi aberta através daquele aviso.
5. Reserva confirmada: o sistema de reservas aceita a operação.
Acrescente os sinais de entrega que a solução disponibilizar, mas mantenha explícitas as lacunas. A API de dados agregados do Firebase para Android não cobre todos os cenários e pode apresentar dados com atraso. Serve para analisar tendências, não para provar que cada pessoa viu uma mensagem. (firebase.google.com)
Para relacionar os acontecimentos, peça identificadores técnicos da oportunidade e da mensagem. Evite colocar nomes, contactos ou o texto integral do aviso nos registos de medição quando não são necessários à análise.
Defina ainda a unidade de contagem. Neste exemplo, recomendamos contar reservas únicas, não toques nem dispositivos. Se a mesma pessoa tocar duas vezes e concluir uma reserva, o resultado de negócio continua a ser uma reserva.
Escreva o denominador ao lado da percentagem
Uma «taxa de conversão» sem definição é insuficiente para tomar decisões. Pode estar a dividir reservas por envios, por aberturas ou por clientes elegíveis.
Para avaliar o percurso após o toque, proponha:
Reservas confirmadas associadas ao percurso ÷ oportunidades únicas abertas através do aviso.
Para avaliar o resultado global de uma experiência, use a proporção de clientes elegíveis que concluiu a ação em cada grupo.
São perguntas diferentes. Mantenha-as em linhas separadas e não compare percentagens calculadas sobre populações distintas.
A permissão faz parte da análise
No iPhone, a app tem de obter autorização para apresentar alertas, sons ou indicadores no ícone. A Apple recomenda pedir essa autorização num contexto em que a pessoa perceba o benefício e recorda que as definições podem mudar posteriormente. (developer.apple.com)
Em Android 13 e versões posteriores, as notificações não abrangidas por exceções dependem da permissão de notificações. Numa instalação nova, estão desativadas até essa autorização ser concedida. A documentação Android também recomenda contextualizar o pedido. (developer.android.com)
No exemplo da lista de espera, recomendamos apresentar o pedido quando o cliente escolhe «Avisar quando houver vaga», em vez de o colocar sem explicação na primeira abertura da app.
No relatório, separe quem pediu o aviso de quem tem autorização técnica conhecida para o receber. Não classifique automaticamente uma ausência de abertura como desinteresse.
Peça também um percurso utilizável para quem recusa: consultar a lista de espera e a disponibilidade dentro da app, sem insistências sucessivas para ativar notificações.
Um aviso fora de prazo não deve contar como oportunidade útil
A vaga pode desaparecer enquanto a mensagem aguarda entrega. O Firebase permite definir a duração máxima das mensagens em Android e configurar a expiração para iOS através do parâmetro correspondente do serviço Apple. Uma mensagem aceite pode ser guardada para entrega posterior, dependendo das condições. (firebase.google.com)
A decisão empresarial é definir até quando vale a pena tentar avisar. A equipa técnica traduz depois essa regra para cada plataforma.
Para este projeto, recomendamos que tocar na notificação provoque uma consulta ao estado atual da aula. Se a vaga já tiver sido ocupada, a app deve explicar isso e oferecer uma alternativa adequada, como manter o interesse numa próxima disponibilidade.
Registe este desfecho separadamente. Uma abertura que termina em «já não disponível» não deve desaparecer dentro de uma média de conversão.
Antes de lançar, peça uma demonstração com a vaga disponível, ocupada e com a aula já iniciada. O objetivo é verificar se a promessa do aviso corresponde ao que o cliente encontra.
Como perceber se a notificação acrescentou resultado
Uma reserva posterior ao aviso não prova, por si só, que o aviso a provocou. Para avaliar esse efeito, recomendamos uma experiência com distribuição aleatória entre grupos elegíveis: um recebe a comunicação opcional e o outro mantém a experiência habitual sem esse envio adicional. O Firebase disponibiliza experiências de mensagens com variantes e objetivos de avaliação. (firebase.google.com)
Não use este método para retirar comunicações essenciais ou avisos que prometeu enviar. No caso da lista de espera, pode ser mais adequado comparar duas versões do aviso do que omitir o serviço solicitado.
Antes da experiência, deixe escrito:
- Qual a única diferença que vai testar: texto, momento ou outro elemento concreto.
- Qual o resultado principal e durante quanto tempo será observado.
- Que situações obrigam a interromper o teste, como reservas incorretas ou reclamações.
- Quem avalia se existe informação suficiente para decidir.
Não estabelecemos aqui uma dimensão universal de amostra. Peça que a equipa a justifique em função do volume disponível e da diferença que pretende detetar. Se houver poucos casos, use a observação para encontrar problemas, sem anunciar uma versão vencedora.
Transforme os resultados numa encomenda de trabalho
No final, o relatório deve permitir escolher uma intervenção. Propomos esta grelha para a reunião entre o responsável do negócio e a equipa de desenvolvimento:
| O que observa | O que pedir para investigar | Decisão possível |
|---|---|---|
| Muitos pedidos recusados pelo serviço | Erros de integração e destinatários inválidos | Corrigir o envio antes de alterar o texto |
| Aberturas que levam a oportunidades terminadas | Prazo de validade e atualização do destino | Rever expiração e percurso na app |
| Clientes chegam à aula, mas não concluem | Disponibilidade, regras e erros da reserva | Corrigir o processo de reserva |
| Mais aberturas sem melhoria nas reservas | Correspondência entre promessa e conteúdo | Rever ou retirar a variante |
| Reservas adicionais com resultado consistente | Condições em que o efeito foi observado | Alargar de forma controlada |
Trate estas linhas como hipóteses de investigação, não como diagnósticos automáticos.
Ao pedir uma proposta para melhorar as notificações da sua app para iPhone e Android, inclua a ficha preenchida e peça entregas verificáveis: acontecimentos documentados, exemplos de registos, testes dos destinos e um relatório com limitações explícitas.
Comece por um aviso com valor claro. Se conseguir acompanhar a oportunidade até à ação concluída, terá uma base para decidir onde investir. Se só conseguir contar envios, o próximo trabalho deve ser tornar o percurso observável — não aumentar o número de mensagens.