Entenda a entrega de notificação push
Saiba mais sobre a entrega de notificação push, incluindo como ela é entregue e por que pode falhar.
Entrega de notificação push
A entrega de notificação push se refere a quando uma notificação push é entregue com sucesso ao dispositivo do destinatário.
Um perfil pode ter mais de 1 token de notificação push se você tiver seu aplicativo móvel instalado em vários dispositivos. As notificações push serão tentadas em todos os dispositivos com um token armazenado no perfil.
O conceito de entregabilidade não se aplica a notificação push como acontece com o e-mail, já que não há nenhuma classificação depois que o dispositivo do destinatário recebe a notificação com sucesso.
Quando você envia uma notificação push por meio de uma campanha ou fluxo, a Klaviyo verifica a notificação push e, em seguida, a envia ao Apple Push Notification Service (APNs) para iOS ou ao serviço de notificações push do Android, o Firebase Cloud Messaging (FCM), para entrega no dispositivo do destinatário. Você pode ver algumas notificações push ignoradas se houver um problema com a entrega.
O APNs e o FCM vão aceitar a notificação e tentar entregá-la no dispositivo do destinatário ou rejeitar a notificação com uma série de possíveis erros.
A Klaviyo só tem insights sobre se esses serviços aceitam a notificação ou a rejeitam. A Klaviyo não pode confirmar se a notificação falha depois que o APNs ou o FCM aceita o push.
Quer solicitar um recurso para as notificações push da Klaviyo? Preencha este formulário do Google para nos contar sobre isso!
Motivos da rejeição
Se a Klaviyo receber uma resposta de erro do APNs ou do FCM após enviar uma notificação, um evento chamado Push devolvido é criado para cada token afetado pela falha na entrega. Isso aparecerá no feed de atividades do perfil de recebimento junto com a atividade do destinatário do respectivo fluxo ou campanha de onde a notificação foi enviada.
O evento Notificação por push rejeitada inclui metadados que mostram a mensagem do código de erro (por exemplo, ExpiredToken) retornada pela APNs ou pelo Firebase. Se você estiver vendo problemas de entrega, trabalhe com seu desenvolvedor de aplicativos para resolver o erro com base na descrição no evento.
Para ver os metadados de um evento, clique em Detalhes da atividade do evento no registro de atividades do perfil.
Notificação push silenciosa
Você pode ver a taxa de entrega e a taxa de rejeição de uma notificação push silenciosa individual; no entanto, as notificações push silenciosas são excluídas de todos os relatórios de desempenho agregados no Klaviyo. Isso inclui coisas como a taxa de abertura do Push para celular ao longo do tempo, já que elas não têm aberturas nem conversões.
Observe que você verá eventos diferentes para push silencioso do que para push padrão, especificamente Push Silencioso Recebido e Push Silencioso com Bounce.
Se você estiver com problemas com a entrega de notificações push silenciosas no iOS, observe que o iOS não garante a entrega de notificações push silenciosas. Eles podem não entregá-las com base no estado atual do dispositivo, como nível de bateria e conexão de rede.
iOS
Para notificações push do iOS enviadas pelo APNs, pode haver rejeições por pelo menos um dos motivos listados na referência da Apple sobre como lidar com respostas de notificações do APNs.
Código do status | String de erro do APNs | Descrição do APNs |
400 | BadDeviceToken | O token do dispositivo especificado estava incorreto. Verifique se a solicitação contém um token válido e se o token corresponde ao ambiente. |
400 | BadTopic | O valor de apns-topic é inválido. |
400 | DeviceTokenNotForTopic | O token do dispositivo não corresponde ao tópico especificado. |
400 | DuplicateHeaders | Um ou mais cabeçalhos foram repetidos. |
400 | Tempo limite de inatividade | Tempo limite de inatividade. |
400 | InvalidPushType | O valor apns-push-type é inválido. |
400 | PayloadEmpty | O payload da mensagem estava vazio. |
403 | Certificado inválido | O certificado era inválido. |
403 | Ambiente de certificado inválido | O certificado de cliente era para o ambiente errado. |
403 | InvalidProviderToken | O token do provedor não é válido ou não foi possível verificar a assinatura do token. |
404 | CaminhoInválido | A solicitação continha um valor :path inválido. |
405 | MethodNotAllowed | O :method especificado não foi POST. |
410 | Token expirado | O token do dispositivo expirou. |
410 | Não registrado | O token do dispositivo está sem atividade para o tópico especificado. |
429 | Excesso de atualizações de token do provedor | O token do provedor está sendo atualizado com muita frequência. |
500 | InternalServerError | Ocorreu um erro interno do servidor. |
503 | Serviço indisponível | O serviço não está disponível. |
Android
Para notificações push do Android enviadas via FCM, as rejeições podem ocorrer por pelo menos um dos motivos listados na referência do Google para códigos de erro do FCM.
Código do status | String de erro do FCM | Descrição do FCM |
400 | INVALID_ARGUMENT | Verifique o formato do token de registro que você envia ao servidor. Confira se ele corresponde ao token de registro que o app cliente recebe ao se registrar no Firebase Notifications. Não trunque nem adicione caracteres extras. |
400 | INVALID_ARGUMENT | Verifique se a mensagem foi endereçada a um token de registro cujo nome do pacote corresponda ao valor passado na solicitação. |
400 | INVALID_ARGUMENT | Verifique se o tamanho total dos dados do payload incluídos em uma mensagem não excede os limites do FCM: 4096 bytes para a maioria das mensagens ou 2048 bytes no caso de mensagens para tópicos. Isso inclui tanto as chaves quanto os valores. |
400 | INVALID_ARGUMENT | Verifique se os dados do payload não contêm uma chave (como from, ou gcm, ou qualquer valor prefixado por google) que é usada internamente pelo FCM. Observe que algumas palavras (como collapse_key) também são usadas pelo FCM, mas são permitidas no payload; nesse caso, o valor do payload será substituído pelo valor do FCM. |
400 | INVALID_ARGUMENT | Verifique se o valor usado em ttl é um número inteiro que representa uma duração em segundos entre 0 e 2.419.200 (4 semanas). |
400 | INVALID_ARGUMENT | Verifique se os parâmetros fornecidos têm o nome e o tipo corretos. |
403 | SENDER_ID_MISMATCH | O ID do remetente autenticado é diferente do ID do remetente do token de registro. |
404 | NÃO REGISTRADO | A instância do app foi removida do registro no FCM. Isso geralmente significa que o token usado não é mais válido, e um novo precisa ser usado. |
429 | QUOTA_EXCEEDED | Limite de envio excedido para o destino da mensagem. Uma extensão do tipo google.rpc.QuotaFailure é retornada para especificar qual cota foi excedida. |
500 | INTERNAL | Ocorreu um erro interno desconhecido. |
503 | Indisponível | O servidor está sobrecarregado. |
Você também verá um evento de Notificação push rejeitada se o destinatário estiver ausente ou tiver um token de notificação push inválido.
Práticas recomendadas
Coletar consentimento do usuário
Para enviar uma notificação push padrão para um perfil, você deve primeiro coletar o consentimento explícito dele.
Para coletar o consentimento para notificações push, você precisa mostrar aos clientes uma solicitação de permissão na tela durante a primeira interação deles com seu app para dispositivos móveis.
Como prática recomendada, o prompt da tela de permissões deve incluir uma linguagem de consentimento que forneça as seguintes informações e permita que a pessoa aceite ou recuse:
- Que tipos de notificações sua marca envia
Inclua detalhes sobre as diferentes notificações push que sua marca planeja enviar (por exemplo, alterações na conta, alterações na conta, lembretes e descontos especiais). - Por que os usuários devem aceitar
Inclua informações sobre por que um cliente deve conceder permissões (por exemplo, para receber atualizações importantes ou acesso antecipado a promoções).
Saiba mais sobre como coletar o consentimento para notificação push.
Envie notificações relevantes
Ao enviar campanhas de notificação push, é importante aproveitar a segmentação da Klaviyo para enviar conteúdo personalizado e relevante para seus assinantes.
Por exemplo, se você sabe que tem um segmento de clientes recorrentes fiéis, você pode usar notificações push para alertá-los sobre novas ofertas ou promoções antes de qualquer outra pessoa.
Ao garantir que o conteúdo que você envia aos clientes seja relevante para os interesses e as preferências deles, você pode reduzir a probabilidade de que os clientes cancelem a inscrição e maximizar sua capacidade de alcançá-los com notificação push.
Monitorar e analisar o desempenho
É essencial monitorar continuamente o desempenho das suas notificações push com a Klaviyo para identificar rapidamente problemas de entrega e quedas nas principais métricas de push.
A melhor forma de fazer isso é monitorar os seguintes eventos de notificação push:
- Push recebida
- Push Aberta
- Push Devolvida
Você pode configurar um Relatório de várias métricas no Klaviyo para monitorar como seu desempenho com esses eventos muda ao longo do tempo.
Recursos adicionais
- Como entender o consentimento para notificação push
Saiba mais sobre o consentimento para notificações push e as melhores práticas de conformidade. Essas diretrizes podem ajudar você a estar em conformidade nas suas práticas de coleta de consentimento e manter um relacionamento positivo com seus clientes.
- Como enviar uma campanha de notificação push
Saiba como usar a Klaviyo para enviar campanhas de notificação push pelo seu app iOS ou Android.
- Como entender suas configurações de notificação push
Saiba mais sobre a página de configurações de notificações push, onde você pode configurar notificações push para seu aplicativo móvel e ajustar a janela do Smart Sending.