Ceci est le troisième article de notre série sur la façon dont vous, un développeur, pouvez créer ou améliorer le meilleur système de notification pour votre entreprise. Il suit le premier article sur l’identification des besoins des utilisateurs et la conception en gardant à l’esprit l’évolutivité et la fiabilité. Dans cet article, nous allons apprendre à configurer le routage et les préférences.
Les notifications servent à diverses fins, de la diffusion d’informations à la fourniture d’alertes de sécurité cruciales qui nécessitent une attention immédiate. Un système de notification fiable permet à la fois des interactions précieuses entre une organisation et ses clients et prospects et stimule également l’engagement des utilisateurs. Ces systèmes combinent l’ingénierie logicielle et l’art du marketing auprès des bonnes personnes au bon moment.
La création d’un service capable d’acheminer dynamiquement les notifications et de gérer les préférences est vitale pour tout système de notification. Mais si vous n’avez jamais construit un système comme celui-ci, il peut être difficile de déterminer quelles sont les exigences et où se trouvent les cas extrêmes.
Dans cet article, vous apprendrez des points inestimables à prendre en compte lors de la création de votre propre service de routage. Vous comprendrez les exigences du support multicanal et du choix des bons fournisseurs d’API. Vous apprendrez également à concevoir les préférences de l’utilisateur afin de tirer le meilleur parti de chaque message.
Support multicanal : une nécessité
Disons que vous venez de créer une application Web. Le premier canal que vous utiliserez pour vous connecter avec vos utilisateurs est probablement l’e-mail en raison de son omniprésence. Cependant, avec la diversification des canaux et selon votre cas d’utilisation, l’e-mail peut ne pas être le canal de notification le plus efficace pour vous. Par rapport à d’autres canaux, les e-mails ont généralement un faible taux de livraison, un faible taux d’ouverture et un temps d’ouverture élevé. Il n’est pas rare que les gens prennent une journée entière pour remarquer votre e-mail. Si votre e-mail parvient à l’utilisateur, cela peut prendre un certain temps avant qu’il ne l’ouvre, voire pas du tout.
Pour interagir plus efficacement avec vos utilisateurs, vous souhaiterez prendre en charge les canaux sur un large éventail de systèmes, sans se limiter à une seule application ou à un seul appareil. Il est essentiel de comprendre non seulement quels canaux sont les plus pertinents pour vous, mais aussi pour vos utilisateurs. Si vous choisissez d’utiliser Telegram et que vos utilisateurs ne l’ont pas, ce ne sera pas un canal très utile pour interagir avec eux. La prise en charge multicanal est également vitale, car même si vous pouvez choisir les canaux appropriés aujourd’hui, vous ne saurez pas quels canaux vous devrez prendre en charge à l’avenir. En règle générale, plus vous prenez en charge les canaux appropriés, plus grandes sont les chances d’intersection avec les applications que vos utilisateurs utilisent réellement maintenant et à l’avenir.
Choix des canaux et des fournisseurs de notification
Vous devrez sélectionner les chaînes pertinentes et les fournisseurs appropriés pour chaque chaîne. Par exemple, les deux principaux fournisseurs de notifications push mobiles sont Apple Push Notification Service (APN) et les APN Firebase Cloud Messaging (FCM) ne prennent en charge que les appareils Apple, tandis que Firebase prend en charge à la fois Android et iOS ainsi que les applications Web Chrome.
Dans le monde des fournisseurs de messagerie, SendGrid, Mailgun et Postmark sont tous populaires, mais il y en a des centaines d’autres. Toutes les API de messagerie diffèrent par ce qu’elles offrent, à la fois en termes de fonctionnalités prises en charge et de flexibilité des API. Certains fournisseurs, comme Mailgun, ne prennent en charge que les e-mails transactionnels déclenchés par l’activité de l’utilisateur. D’autres fournisseurs, comme SendGrid et Sendinblue, proposent à la fois des e-mails transactionnels et marketing. Si votre entreprise opte pour un fournisseur capable de gérer les deux, vous souhaiterez toujours séparer les sources de trafic, en utilisant différentes adresses e-mail ou domaines, pour faciliter la délivrabilité des e-mails.
Si vous n’avez qu’un seul domaine pour envoyer les deux types d’e-mails et que le domaine est signalé comme spam, vos e-mails transactionnels critiques seront également affectés. Quel que soit le fournisseur que vous choisissez, vous voudrez toujours vérifier méticuleusement vos vérifications DKIM, SPF et DMARC, ainsi que la liste noire des domaines et des adresses IP à l’aide de vos propres outils ou d’un site comme Mail-Tester.
Faire des demandes et recevoir des réponses diffère également avec chaque fournisseur d’API de messagerie. Certains fournisseurs, comme Amazon SES, exigent que le développeur gère l’envoi des pièces jointes, tandis que d’autres, comme Mailgun, fournissent des champs dans le schéma de l’API pour inclure directement les fichiers de pièces jointes.
Il existe des écarts minimes dans le formatage des requêtes HTTPS. Les tailles de charge utile maximales vont de 10 Mo avec l’API Amazon SES et jusqu’à 50 Mo avec Postmark. Il existe également des différences entre les limites de taux pour les demandes.
En termes de réponses API, Amazon SES fournit un identifiant de message lorsqu’un e-mail est envoyé avec succès via l’API, mais, par exemple, SendGrid renvoie une réponse vide dans cette situation. Les codes de réponse HTTP diffèrent également légèrement selon le fournisseur. Par exemple, AWS SES utilise le code de réponse 200 pour les opérations d’envoi d’e-mails réussies, tandis que Sendinblue utilise , et SendGrid utilise 202. Quel que soit le fournisseur que vous choisissez, ne créez pas votre application uniquement pour s’adapter à *leur* logique et spécifications. Si vous le faites, il sera beaucoup plus difficile de changer de fournisseur à l’avenir car vous devrez remanier votre backend. Il est crucial d’investir dans une couche d’abstraction basée sur votre propre paradigme.
Acheminement dynamique des notifications entre les canaux
Comment déterminez-vous les canaux à utiliser et à quel moment ? Ce n’est pas parce que vous pouvez utiliser le courrier électronique, les SMS et le push mobile que vous devez tous les utiliser simultanément, car cela comporte un risque élevé d’ennuyer vos utilisateurs. C’est là que vous commencez à formuler un algorithme pour acheminer les messages entre les différents canaux et les différents fournisseurs au sein de chaque canal. L’algorithme doit être robuste pour gérer les échecs de livraison et autres erreurs. Par exemple, si l’utilisateur ne s’est pas engagé avec une notification push après une journée, la renvoyez-vous ou utilisez-vous un e-mail à la place ?
Vous pouvez commencer à construire l’algorithme en utilisant des critères de base. Par exemple, s’il n’y a pas de numéro de téléphone, éliminez les SMS comme option pour cet utilisateur. Si le courrier électronique est le canal principal, choisir d’envoyer à 10 h ou à 13 h, heure locale, améliore généralement les taux de lecture. Si l’utilisateur est présent ou actif dans l’application, envisagez d’envoyer une notification push dans l’application au lieu d’un e-mail. Enfin, et c’est particulièrement important, obtenez les préférences de votre utilisateur pour savoir comment et quand il souhaite être contacté et intégrez ces préférences dans votre service de routage.
Ajout de préférences utilisateur à votre système
Une fois que vous avez défini vos canaux, vos fournisseurs et votre algorithme de routage, vous devez penser à fournir aux utilisateurs un contrôle granulaire sur les préférences de notification au lieu d’un simple commutateur binaire opt-in/opt-out.
Considérez ceci : si vous autorisez uniquement l’activation ou la désactivation de toutes les notifications à la fois, vos utilisateurs pourraient se désabonner de toutes vos communications car ils trouvent une notification spécifique ennuyeuse. En conséquence, vous perdrez un engagement précieux des utilisateurs.
Avec un contrôle granulaire des préférences, un utilisateur identifie exactement comment et quand il a de vos nouvelles. Si un utilisateur n’aime pas les e-mails mais souhaite recevoir des SMS (ce qui n’est pas courant, mais possible !), il peut ajuster ses préférences et garder la ligne de communication SMS ouverte. Chaque canal de notification activé est une autre opportunité d’engager l’utilisateur d’une manière productive pour lui. Du point de vue de l’utilisateur final, il permet de contrôler comment et quand il est contacté.
Notez que pour certains canaux, les préférences de l’utilisateur doivent être ignorées. Par exemple, l’authentification à deux facteurs doit aller au SMS ou au push mobile, quelle que soit la préférence de l’utilisateur pour le courrier électronique. La possibilité de remplacer la logique par défaut doit être intégrée à votre algorithme lors de la conception de votre moteur de routage.
Si vous souhaitez pousser plus loin l’engagement des utilisateurs, autorisez les utilisateurs à activer/désactiver des canaux, une fréquence, un calendrier et des sujets spécifiques. Vous pouvez leur permettre de définir leurs préférences en fonction de l’heure de la journée, de la fréquence par période ou de spécifier plusieurs adresses e-mail. Vous pouvez leur donner la possibilité de recevoir des e-mails transactionnels, résumés, des newsletters quotidiennes ou uniquement les plus critiques. Vous pouvez également leur permettre de rediriger leurs notifications vers une autre adresse, par exemple, si l’utilisateur est absent du bureau.
Les préférences granulaires s’étendent également au-delà de la domination des développeurs et de l’expérience de l’utilisateur. La granularité du consentement fait désormais partie des lois sur le respect de la vie privée en Europe et dans l’État de Californie et pourrait suivre ailleurs à l’avenir. Séparément, les préférences granulaires sont un outil d’analyse extrêmement avantageux pour l’équipe marketing afin d’améliorer la stratégie de marque et les efforts de personnalisation. Y a-t-il une chaîne ou un sujet en particulier qui semble être plus populaire ? Ces informations peuvent être très utiles pour s’aligner sur vos utilisateurs et développer votre entreprise.
Conseils pour une maintenance à l’épreuve du temps
Lorsque vous commencez avec des notifications pour un nouveau produit, il n’y a rien de mal à s’en tenir à un seul canal et à un seul fournisseur. Le principe le plus important à garder à l’esprit est de concevoir votre système de notification de manière à pouvoir l’étendre à l’avenir. Vous devriez laisser la porte ouverte pour inclure plus de fournisseurs lorsque vous en avez besoin.
Ne supposez pas que Paradigmes d’API sont les mêmes pour chaque fournisseur ou type de notification. Par exemple, vous souhaitez envoyer un e-mail et, si la livraison échoue, envoyer une notification push à la place. Mais vous n’obtiendrez pas de réponse HTTP 400 du fournisseur de messagerie en cas d’échec. Le fournisseur réessayera votre e-mail dans quelques jours. Au lieu de cela, vous voudrez inclure des webhooks ou des files d’attente pour vous informer de l’échec, et vous devrez suivre l’état du message ici. Si vous faites des hypothèses générales sur le fonctionnement des appels d’API ou sur la manière dont les erreurs sont renvoyées, vous aurez du mal à vous adapter à un paradigme différent à l’avenir. Au lieu de cela, vous pouvez ajouter une couche d’abstraction au-dessus de l’API.
Il est également inestimable de centraliser la façon dont vous appelez les API du fournisseur. Si vous répartissez les appels vers une API dans votre base de code, il sera plus difficile d’intégrer d’autres canaux ou fournisseurs d’API à l’avenir. Supposons que vous commenciez avec la messagerie et AWS SES en tant que fournisseur. Dans deux ans, vous pourriez également décider d’intégrer les notifications push mobiles. À quoi cela peut-il ressembler? La dette technique encourue inclura le récurage de la base de code pour toutes les instances d’appels à l’API AWS SES avant de pouvoir intégrer le push mobile en tant que canal supplémentaire. Mais avec les appels centralisés, vous disposerez d’un code plus cohérent, plus propre et réutilisable au fur et à mesure de votre croissance.
Combien de canaux de notification devriez-vous avoir ?
En règle générale, avoir trois ou quatre canaux pertinents pour votre produit est un scénario idéal pour un produit mature. Lorsque vous croisez des canaux avec les préférences et la disponibilité des utilisateurs, vous créez des niveaux de complexité plus élevés pour votre algorithme. Offrir de nombreux canaux pour les notifications peut devenir trop complexe à maintenir. Mais offrir trop peu de canaux peut nuire à vos chances d’interagir avec les utilisateurs, car certains canaux peuvent ne pas être viables pour tous les utilisateurs. Par exemple, vous pouvez décider de proposer des notifications par e-mail et push. Mais si un utilisateur n’a pas téléchargé votre produit, votre interaction avec lui se limite uniquement aux e-mails.
Meilleures technologies pour les moteurs de routage et de préférences
En fin de compte, il est avantageux de choisir des technologies qui conviendront à vos besoins de routage et de préférences. Il y aura beaucoup de programmation asynchrone, car le service de routage attendra souvent de recevoir des réponses pour chaque fonction. Vous aurez envie de choisir un langage ou un framework qui vous permet…