Qué aprenderás
Aprenda sobre la entrega de notificaciones push, incluyendo cómo se entregan y por qué pueden fallar.
Envío de notificaciones pushEnvío de notificaciones push
La entrega de notificaciones push se refiere al momento en que una notificación push se entrega con éxito en el dispositivo de un destinatario.
Un perfil puede tener más de un token push si tiene instalada su aplicación móvil en varios dispositivos. Se intentarán enviar notificaciones push a todos los dispositivos con un token almacenado en el perfil.
El concepto de entregabilidad no se aplica a las notificaciones push como en el caso del correo electrónico, ya que no se realiza ninguna clasificación una vez que el dispositivo del destinatario recibe correctamente la notificación.
Cuando envía una notificación push a través de una campaña o flujo, Klaviyo la comprueba y la envía al servicio de notificaciones push de Apple (APN) para iOS, o al servicio de notificaciones push de Android, Firebase Cloud Messaging (FCM) para su entrega al dispositivo del destinatario. Es posible que se omitan algunas notificaciones push si hay algún problema con la entrega.
Los APN y FCM aceptarán la notificación e intentarán entregarla al dispositivo del destinatario, o bien la rechazarán con una serie de posibles errores.
Klaviyo sólo tiene conocimiento de si estos servicios aceptan la notificación o la rechazan. Klaviyo no puede confirmar si la notificación falla después de que APN o FCM acepten el push.
¿Quiere solicitar una función para las notificaciones push de Klaviyo? ¡Rellene este formulario de Google para contárnoslo!
Motivos de rechazo
Si Klaviyo recibe una respuesta de error de APN o FCM después de enviar una notificación, se crea un evento llamado Push rebotado para cada token afectado por la entrega fallida. Esto aparecerá en el feed de actividad del perfil receptor junto con la actividad del destinatario para el flujo o la campaña respectiva desde la que se envió la notificación.
El evento push Rebotado incluye metadatos que muestran el mensaje de código de error (por ejemplo, ExpiredToken) devuelto por APN o Firebase. Si observa problemas de entrega, colabore con el desarrollador de su aplicación para resolver el error basándose en la descripción del evento.
Para ver los metadatos de un evento, haga clic en Detalles de la actividad del evento en el registro de actividades del perfil.
iOS
En el caso de las notificaciones push de iOS enviadas a través de APN, pueden producirse rechazos por al menos una de las razones enumeradas en la referencia de Apple para la gestión de las respuestas a las notificaciones procedentes de APN.
| Código de estado |
Cadena de error APNs |
Descripción de los APN |
|
400 |
BadDeviceToken |
El token de dispositivo especificado era incorrecto. Verifique que la solicitud contiene un token válido y que éste coincide con el entorno. |
|
400 |
BadTopic |
El valor apns-topic no es válido. |
|
400 |
DeviceTokenNotForTopic |
El token del dispositivo no coincide con el tema especificado. |
|
400 |
DuplicateHeaders |
Se han repetido una o varias cabeceras. |
|
400 |
IdleTimeout |
Tiempo muerto. |
|
400 |
InvalidPushType |
El valor apns-push-type no es válido. |
|
400 |
PayloadEmpty |
La carga útil del mensaje estaba vacía. |
|
403 |
BadCertificate |
El certificado era malo. |
|
403 |
BadCertificateEnvironment |
El certificado del cliente era para el entorno equivocado. |
|
403 |
InvalidProviderToken |
El token del proveedor no es válido o no se ha podido verificar la firma del token. |
|
404 |
BadPath |
La solicitud contenía un valor :path incorrecto. |
|
405 |
MethodNotAllowed |
El método :especificado no era POST. |
|
410 |
ExpiredToken |
El token del dispositivo ha caducado. |
|
410 |
No registrado |
El testigo de dispositivo está inactivo para el tema especificado. |
|
429 |
TooManyProviderTokenUpdates |
El token de proveedor se actualiza con demasiada frecuencia. |
|
500 |
InternalServerError |
Se ha producido un error interno del servidor. |
|
503 |
ServiceUnavailable |
El servicio no está disponible. |
Android
En el caso de las notificaciones push de Android enviadas a través de FCM, pueden producirse rechazos por al menos una de las razones enumeradas en la referencia de Google para los códigos de error de FCM.
|
Código de estado |
Cadena de error FCM |
Descripción del FCM |
|
400 |
ARGUMENTO_NO_VALIDO |
Compruebe el formato del testigo de registro que pasa al servidor. Asegúrese de que coincide con el token de registro que la aplicación cliente recibe al registrarse con Firebase Notifications. No trunque ni añada caracteres adicionales. |
|
400 |
ARGUMENTO_NO_VALIDO |
Asegúrese de que el mensaje iba dirigido a un token de registro cuyo nombre de paquete coincide con el valor pasado en la solicitud. |
|
400 |
ARGUMENTO_NO_VALIDO |
Compruebe que el tamaño total de los datos de carga útil incluidos en un mensaje no supera los límites del FCM: 4096 bytes para la mayoría de los mensajes, o 2048 bytes en el caso de mensajes a temas. Esto incluye tanto las claves como los valores. |
|
400 |
ARGUMENTO_NO_VALIDO |
Compruebe que los datos de la carga útil no contienen una clave (como from, o gcm, o cualquier valor prefijado por google) que sea utilizada internamente por FCM. Tenga en cuenta que algunas palabras (como collapse_key) también son utilizadas por FCM pero están permitidas en la carga útil, en cuyo caso el valor de la carga útil será anulado por el valor de FCM. |
|
400 |
ARGUMENTO_NO_VALIDO |
Compruebe que el valor utilizado en ttl es un número entero que representa una duración en segundos comprendida entre 0 y 2.419.200 (4 semanas). |
|
400 |
ARGUMENTO_NO_VALIDO |
Compruebe que los parámetros proporcionados tienen el nombre y el tipo correctos. |
|
403 |
SENDER_ID_MISMATCH |
El ID del remitente autenticado es diferente del ID del remitente de la ficha de registro. |
|
404 |
UNREGISTERED |
La instancia de la aplicación se ha dado de baja de FCM. Esto suele significar que el token utilizado ya no es válido y debe utilizarse uno nuevo. |
|
429 |
CUOTA_EXCEDIDA |
Límite de envío superado para el destino del mensaje. Se devuelve una extensión de tipo google.rpc.QuotaFailure para especificar qué cuota se ha superado. |
|
500 |
INTERIOR |
Se ha producido un error interno desconocido. |
|
503 |
NO DISPONIBLE |
El servidor está sobrecargado. |
También verá un evento push Rebotado si falta el destinatario o tiene un token push no válido.
Buenas prácticas
Recoger el consentimiento del usuarioRecoger el consentimiento del usuario
Para enviar una notificación push a un perfil, primero debe recabar su consentimiento explícito .
Para recabar el consentimiento de las notificaciones push, debe proporcionar a los clientes un aviso en la pantalla de permiso durante su primera interacción con su aplicación móvil.
Es una buena práctica que su solicitud de pantalla de permiso incluya un lenguaje de consentimiento que proporcione la siguiente información y les permita optar por aceptar o rechazar:
-
Qué tipos de notificaciones envía su marca
Incluya detalles sobre las diferentes notificaciones push que su marca planea enviar (por ejemplo, cambios en la cuenta, cambios de cuenta, recordatorios y descuentos especiales). -
Por qué los usuarios deben optar por
Incluya información sobre por qué un cliente debe dar permisos (por ejemplo, para recibir actualizaciones importantes o acceso anticipado a las ventas).
Más información sobre la recogida del consentimiento para notificaciones push.
Enviar notificaciones relevantes
Al enviar campañas de notificaciones push, es importante aprovechar la segmentación de Klaviyo para enviar contenido personalizado y relevante para sus suscriptores.
Por ejemplo, si sabe que tiene un segmento de clientes habituales dedicados, podría utilizar las notificaciones push para alertarles de nuevas ofertas o promociones antes que nadie.
Al asegurarse de que el contenido que envía a los clientes es relevante para sus intereses y preferencias, puede reducir la probabilidad de que los clientes se den de baja y maximizar su capacidad de llegar a sus clientes con las notificaciones push.
Supervisar y analizar el rendimientoSupervisar y analizar el rendimiento
Es esencial supervisar continuamente el rendimiento de sus notificaciones push con Klaviyo para identificar rápidamente los problemas de entrega y las caídas en las métricas push clave.
La mejor manera de hacerlo es supervisar los siguientes eventos de notificaciones push:
- Empuje recibido
- Empuje abierto
- Empujón rebotado
Puede configurar un informe multimétrico en Klaviyo para controlar cómo cambia su rendimiento con estos eventos a lo largo del tiempo.
Recursos adicionalesRecursos adicionales
Comprender el consentimiento de las notificaciones push