O que você vai aprender
Saiba mais sobre a entrega de notificações push, inclusive como elas são entregues e por que podem falhar.
Entrega de notificações pushEntrega de notificações push
A entrega de notificação por push refere-se a quando uma notificação por push é entregue com êxito ao dispositivo do destinatário.
Um perfil pode ter mais de um token push se tiver seu aplicativo móvel instalado em vários dispositivos. As notificações push serão tentadas para todos os dispositivos com um token armazenado no perfil.
O conceito de capacidade de entrega não se aplica às notificações por push como acontece com o e-mail, pois não há classificação realizada quando o dispositivo do destinatário recebe a notificação com êxito.
Quando o senhor envia uma notificação por push por meio de uma campanha ou fluxo, o Klaviyo verifica o push e o envia para o Apple Push Notification Service (APNs) para iOS ou para o serviço de notificação por push do Android, o Firebase Cloud Messaging (FCM), para entrega no dispositivo do destinatário. O senhor poderá ver algumas notificações push ignoradas se houver um problema com a entrega.
Os APNs e o FCM aceitarão a notificação e tentarão entregá-la ao dispositivo do destinatário ou rejeitarão a notificação com uma série de possíveis erros.
A Klaviyo só tem conhecimento se esses serviços aceitam ou rejeitam a notificação. A Klaviyo não pode confirmar se a notificação falha depois que os APNs ou o FCM aceitam o push.
Deseja solicitar um recurso para as notificações push do Klaviyo? Preencha este formulário do Google para nos contar sobre isso!
Motivos da rejeição
Se o Klaviyo receber uma resposta de erro dos APNs ou FCM após o envio de uma notificação, um evento chamado Bounced push será criado para cada token afetado pela falha na entrega. Isso aparecerá no feed de atividades do perfil receptor junto com a atividade do destinatário para o respectivo fluxo ou campanha da qual a notificação foi enviada.
O evento push Bounced inclui metadados que mostram a mensagem de código de erro (por exemplo, ExpiredToken) retornada por APNs ou Firebase. Se o senhor estiver vendo problemas de entrega, trabalhe com o desenvolvedor do aplicativo para resolver o erro com base na descrição do evento.
Para visualizar os metadados de um evento, clique em Detalhes da atividade para o evento no registro de atividades do perfil.
iOS
Para notificações push do iOS enviadas por meio de APNs, as rejeições podem ocorrer por pelo menos um dos motivos listados na referência da Apple para lidar com respostas de notificação de APNs.
| Código de status |
Cadeia de erro de APNs |
Descrição dos APNs |
|
400 |
BadDeviceToken |
O token de dispositivo especificado era ruim. Verifique se a solicitação contém um token válido e se o token corresponde ao ambiente. |
|
400 |
BadTopic |
O valor 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 |
IdleTimeout |
Tempo ocioso esgotado. |
|
400 |
InvalidPushType |
O valor apns-push-type é inválido. |
|
400 |
PayloadEmpty |
A carga útil da mensagem estava vazia. |
|
403 |
BadCertificate |
O certificado era ruim. |
|
403 |
BadCertificateEnvironment |
O certificado do cliente era para o ambiente errado. |
|
403 |
InvalidProviderToken |
O token do provedor não é válido ou a assinatura do token não pôde ser verificada. |
|
404 |
BadPath |
A solicitação continha um valor :path incorreto. |
|
405 |
MethodNotAllowed |
O método :especificado não era POST. |
|
410 |
ExpiredToken |
O token do dispositivo expirou. |
|
410 |
Não registrado |
O token do dispositivo está inativo para o tópico especificado. |
|
429 |
TooManyProviderTokenUpdates |
O token do provedor está sendo atualizado com muita frequência. |
|
500 |
InternalServerError |
Ocorreu um erro interno no servidor. |
|
503 |
ServiceUnavailable |
O serviço não está disponível. |
Android
Para notificações push do Android enviadas por meio do 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 de status |
Cadeia de erro FCM |
Descrição do FCM |
|
400 |
INVALID_ARGUMENT |
Verifique o formato do token de registro que o senhor passa para o servidor. Verifique se ele corresponde ao token de registro que o aplicativo cliente recebe ao se registrar no Firebase Notifications. Não trunque nem adicione caracteres adicionais. |
|
400 |
INVALID_ARGUMENT |
Certifique-se de que a mensagem foi endereçada a um token de registro cujo nome de pacote corresponda ao valor passado na solicitação. |
|
400 |
INVALID_ARGUMENT |
Verifique se o tamanho total dos dados de carga útil 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 da carga útil não contêm uma chave (como from, ou gcm, ou qualquer valor prefixado por google) que seja usada internamente pelo FCM. Observe que algumas palavras (como collapse_key) também são usadas pelo FCM, mas são permitidas na carga útil; nesse caso, o valor da carga útil 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 |
UNREGISTRADO |
A instância do aplicativo não foi registrada no FCM. Isso geralmente significa que o token usado não é mais válido e um novo deve 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 |
INTERNO |
Ocorreu um erro interno desconhecido. |
|
503 |
NÃO DISPONÍVEL |
O servidor está sobrecarregado. |
O senhor também verá um evento de push Bounced se o destinatário estiver ausente ou tiver um token de push inválido.
Práticas recomendadas
Coletar o consentimento do usuárioColetar o consentimento do usuário
Para enviar uma notificação por push a um perfil, o senhor deve primeiro obter o consentimento explícito dele.
Para coletar o consentimento da notificação por push, o senhor deve fornecer aos clientes um prompt na tela de permissão durante a primeira interação com o seu aplicativo móvel.
É uma prática recomendada que o prompt da tela de permissão inclua uma linguagem de consentimento que forneça as seguintes informações e permita que o usuário opte por participar ou não:
-
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 de conta, alterações de conta, lembretes e descontos especiais). -
Por que os usuários devem optar
Inclua informações sobre por que um cliente deve fornecer permissões (por exemplo, para receber atualizações importantes ou acesso antecipado a vendas).
Saiba mais sobre a coleta de consentimento para notificações push.
Enviar notificações relevantes
Ao enviar campanhas de notificação por push, é importante aproveitar a segmentação da Klaviyo para enviar conteúdo personalizado e relevante para seus assinantes.
Por exemplo, se o senhor sabe que tem um segmento de clientes recorrentes dedicados, pode usar as notificações push para alertá-los sobre novas ofertas ou promoções antes de qualquer outra pessoa.
Ao garantir que o conteúdo que envia aos clientes seja relevante para seus interesses e preferências, o senhor pode reduzir a probabilidade de os clientes optarem por não participar e maximizar sua capacidade de alcançar seus clientes com notificações push.
Monitorar e analisar o desempenhoMonitorar e analisar o desempenho
É essencial monitorar continuamente o desempenho de suas notificações push com o Klaviyo para identificar rapidamente problemas de entrega e quedas nas principais métricas de push.
A melhor maneira de fazer isso é monitorar os seguintes eventos de notificação por push:
- Empurrão recebido
- Empurrão aberto
- Empurrão devolvido
O senhor pode configurar um relatório multimétrico na Klaviyo para monitorar como seu desempenho com esses eventos muda ao longo do tempo.
Recursos adicionaisRecursos adicionais
Compreender o consentimento para notificações push