Vérification de l'accessibilité et repli entre canaux

Faites arriver le message quand même

Quelqu’un désactive le push, ou se désabonne d’une liste e-mail, et le message que vous avez conçu pour lui n’arrive tout simplement pas. Rien dans le rapport d’envoi ne le signale : la campagne s’est exécutée, le compteur a augmenté, et une personne ne l’a jamais vu. Une alerte de fraude bancaire qui ne tente que le push n’a pas rempli son rôle si le push est désactivé. Une notification de commande qui ne tente que le push rate un client en pleine période de Soldes, notifications coupées. Vérification de l’accessibilité intercepte cela avant l’envoi, et redirige la personne vers un autre canal au lieu de vous laisser coder la logique de repli à la main.

Ce que vous apporte Vérification de l’accessibilité

Ce qui compte comme accessible

2 des 5 canaux ont une réponse publiée pour ce que signifie «non-accessible». Le reste de la logique de balise n’est pas encore public.

C’est une balise d’abonnement, pas une tentative de livraison en temps réel. Un utilisateur marqué accessible peut quand même manquer le message plus loin dans la chaîne si son appareil est hors ligne ou si l’application a été désinstallée entretemps. Ce que cet élément vous apporte, et qu’une répartition conditionnelle générique ne fait pas, c’est la branche elle-même : un embranchement accessible/non-accessible conçu pour cet usage, que vous déposez sur le canevas et enchaînez, au lieu de câbler à la main une condition générique ou une étape d’attente sur des données d’abonnement.

Enchaînez les vérifications en cascade

Redirigez la branche non-accessible d’une vérification push vers une vérification e-mail, et la branche non-accessible de cette dernière vers une vérification SMS ou WhatsApp. Chaque étape réduit l’audience aux personnes que le canal précédent n’a pas pu atteindre, jusqu’à ce que le message arrive ou qu’il n’y ait plus de canal à tenter.

Clôturez la cascade avec l'in-app

L’in-app ne fait pas partie des 5 canaux vérifiés par cet élément, mais c’est l’étape finale la plus courante. Un message in-app atteint quiconque ouvre l’application, quel que soit son statut d’abonnement sur tous les autres canaux.

Ce qui rend un parcours omnicanal

L’omnicanal, ce n’est pas seulement lister 5 canaux dans les paramètres. C’est la capacité du parcours à détecter, personne par personne, quand un canal est fermé, et à réagir avant que l’envoi échoue silencieusement. Vérification de l’accessibilité est ce qui donne cette capacité au Constructeur de parcours client : une façon de contourner un canal fermé au lieu de simplement lister les canaux dont vous disposez.

Là où cet élément prend tout son sens

Une vérification parmi les canaux qu’elle protège

Conçu pour les canaux entre lesquels elle bascule

Une cascade vaut ce que valent les canaux derrière elle : Notifications push mobiles en premier essai, E-mail en repli, SMS ou WhatsApp pour clôturer.

Répartition conditionnelle semble similaire : un élément, deux branches ou plus, évalué une fois. La différence tient à ce qu’il lit : un segment, une balise ou une valeur d’événement déjà sur le profil, plutôt que la disponibilité d’un canal. Les deux vivent dans le Constructeur de parcours client, sur le même canevas que tout autre élément de contrôle de flux.

Les données derrière elle restent sur une infrastructure que vous pouvez nommer

Les balises d’abonnement qu’une Vérification de l’accessibilité lit passent par la même infrastructure que le reste de la plateforme : le matériel propre de Pushwoosh aux États-Unis et en Allemagne, sous RGPD et BDSG (la loi allemande sur la protection des données), certifié ISO 27001:2022 et SOC 2 Type I. Le détail complet figure sur la page «sécurité des données».

Comment ça marche

Ce qu’il faut garder en tête

FAQ

Atteignez-les sur le canal qui reste ouvert

Enchaînez une Vérification de l’accessibilité pour chaque canal qu’un message pourrait utiliser, et arrêtez de traiter un canal fermé comme une impasse.

Explorer les produits connexes