Comment distinguer les réponses lentes du désabonnement dans un produit de chat IA

Pourquoi le temps écoulé seul classe mal les utilisateurs

Un intervalle de temps est facile à mesurer, mais il n'explique pas ce qui s'est passé pendant cette période. Une personne a peut-être choisi de revenir plus tard ; une notification n'a peut-être pas atteint l'appareil ; l'application n'a peut-être pas enregistré une tâche terminée ; ou il se peut simplement qu'il n'y ait aucune nouvelle action à observer. Ces possibilités appellent des réponses produit différentes ; par conséquent, les regrouper sous une seule étiquette « inactif » rend les données sous-jacentes plus difficiles à interpréter.

Les systèmes de messagerie distinguent eux-mêmes les étapes de distribution. Firebase Cloud Messaging rend compte des envois, de la réception par l'application Android, des impressions de notification et des ouvertures sous forme de mesures distinctes ; un envoi peut signifier que le message a été mis en file d'attente ou transmis à un service tel qu'APNs, et non qu'une personne l'a vu. Firebase note également que certains rapports sont différés et que ses données globales de distribution ont des limites de couverture. Firebase: Understanding message delivery

Cette distinction suggère une règle d'analyse utile : ne déduisez jamais la cadence de réponse d'une personne à partir d'un événement en amont tel qu'une demande d'envoi, et ne considérez jamais une absence d'ouverture ou de réponse comme la preuve d'un échec de distribution. Enregistrez ce que le produit peut observer et laissez les résultats non observés comme indéterminés.

Laisser les personnes indiquer leur cadence de réponse préférée

Proposez une préférence simple et facultative qui répond à une question pratique : quand la personne aimerait-elle que le produit l'invite à répondre ou fasse un suivi ? Utilisez des choix compréhensibles tels que « quand je serai prêt », « plus tard aujourd'hui » ou « me le rappeler un jour spécifique », si ces options conviennent au produit. Les options exactes relèvent d'une décision de conception et non d'une affirmation sur ce que préfère un utilisateur en particulier.

Enregistrez la sélection en tant que préférence utilisateur avec son heure de mise à jour et, le cas échéant, une condition d'expiration ou de fin. Une préférence est un contexte durable sur l'utilisation que cette personne a choisi de faire du produit ; un intervalle de réponse est un fait concernant une conversation ou un message. Les plateformes d'analyse font une distinction similaire entre les propriétés utilisateur, qui décrivent un utilisateur, et les propriétés d'événement, qui décrivent une action spécifique. Amplitude: User properties and event properties

Faites en sorte que la préférence soit facile à modifier ou à effacer. Évitez de convertir les temps de réponse moyens observés en préférences présumées : un schéma historique peut aider à décrire un comportement passé, mais seul un choix explicite peut indiquer une préférence exprimée. S'il n'y a pas de préférence enregistrée, notez la valeur comme inconnue plutôt que d'attribuer une cadence par défaut à la place de la personne.

Suivre les tâches de conversation en tant qu'états observables

Définissez un ensemble restreint d'états de tâche autour d'actions que le système peut vérifier. Par exemple : waiting_for_user, waiting_for_service, ready_for_user, completed et cancelled. N'utilisez un état que lorsqu'un événement ou une réponse système le justifie. Un utilisateur qui envoie un message peut faire passer une tâche à waiting_for_service ; une réponse réussie peut la rendre ready_for_user ; une action explicite d'achèvement peut la marquer comme completed. Si une réponse ou une mise à jour d'état échoue, enregistrez l'échec et laissez la tâche en suspens jusqu'à ce qu'un événement ultérieur vienne la clarifier.

Associez un identifiant de conversation ou de tâche à ces événements afin qu'un analyste puisse reconstituer la séquence. Enregistrez l'heure de l'événement, le type d'événement, l'état actuel de la tâche et le résultat technique pertinent. Séparez la préférence au niveau de l'utilisateur des détails propres à la tâche : « préfère répondre quand il est prêt » peut s'appliquer à plusieurs conversations, tandis que « cette tâche attend une action de l'utilisateur » décrit une interaction actuelle unique. Dans l'analyse basée sur les événements, les propriétés d'événement capturent le contexte au moment d'une action, tandis que les propriétés utilisateur décrivent des attributs qui peuvent évoluer dans le temps. Amplitude: User properties and event properties

Cette séparation protège également l'interprétation historique. Lorsque quelqu'un modifie une préférence, conservez l'ancienne valeur sur les événements antérieurs et utilisez la nouvelle valeur pour les suivants ; ne réécrivez pas le passé comme si la préférence la plus récente avait toujours été d'application. La documentation d'Amplitude décrit ce comportement tenant compte de la chronologie pour les propriétés utilisateur. Amplitude: User properties and event properties

Séparer l'état de la distribution des actions de l'utilisateur

Pour chaque message de chat sortant ou notification, enregistrez les étapes que l'intégration expose réellement : tentative d'envoi, acceptation par le service de messagerie, distribution à l'application le cas échéant, affichage le cas échéant, ouverture le cas échéant, et toute erreur connue. N'inventez pas un accusé de réception que la plateforme ne fournit pas. Sur les plateformes Apple, APNs gère la distribution des notifications distantes vers les appareils de l'utilisateur ; ce rôle système est différent de l'enregistrement attestant que la personne a ouvert la notification. Apple: User Notifications

Utilisez les résultats d'infrastructure comme des signaux d'infrastructure. Par exemple, une requête ayant échoué, un rejet par le fournisseur, un délai d'attente dépassé ou une file d'attente retardée doivent inciter à vérifier l'état de la distribution ou du service. Une requête d'envoi réussie n'est que la preuve de cette étape précise. Firebase explique que sa statistique d'envoi peut représenter un message mis en file d'attente pour distribution ou transmis à un autre service, et que ses données globales de transport Android décrivent des tendances générales plutôt que chaque message individuel. Firebase: Understanding message delivery

Pour le traitement interne des messages, les accusés de réception nécessitent également une lecture attentive. Google Cloud Pub/Sub décrit les messages comme étant en attente jusqu'à ce qu'ils soient acquittés et note que les messages non acquittés peuvent être redistribués après un délai limite ; les messages peuvent également être distribués plus d'une fois. C'est un rappel utile pour rendre le traitement des événements tolérant aux doublons et pour distinguer une absence d'accusé de réception de traitement d'une absence de réponse de l'utilisateur. Google Cloud: Subscription overview

Appliquer une règle de classification prudente

Un outil pratique d'aide à la décision peut permettre de garder des étiquettes ciblées et fondées sur des preuves :

Preuve observée : La personne a sélectionné une préférence de délai de réponse, et aucune action plus récente n'est observée ; Étiquette d'analyse appropriée : Préférence enregistrée ; réponse non encore observée ; Ce qu'elle n'établit pas : Que la personne est partie, ou qu'une distribution a échoué

Preuve observée : Une requête de service ou une étape de distribution de message a échoué ou a expiré ; Étiquette d'analyse appropriée : Problème technique à l'étape enregistrée ; Ce qu'elle n'établit pas : La raison pour laquelle la personne n'a pas répondu

Preuve observée : Le produit a une étape suivante confirmée en attente d'une action de l'utilisateur ; Étiquette d'analyse appropriée : Tâche en attente d'une action de l'utilisateur ; Ce qu'elle n'établit pas : Que la tâche a été abandonnée

Preuve observée : Une réalisation, une annulation ou une autre action finale est enregistrée ; Étiquette d'analyse appropriée : Terminée ou annulée, selon ce qui est observé ; Ce qu'elle n'établit pas : Un jugement plus large sur l'utilisation future

Preuve observée : Les preuves sont manquantes, retardées ou contradictoires ; Étiquette d'analyse appropriée : Inconnu ou nécessite une réconciliation ; Ce qu'elle n'établit pas : Toute explication comportementale certaine

L'étiquette « churn » (désabonnement) devrait nécessiter une règle définie au niveau du produit et suffisamment de preuves pour appuyer cette règle ; elle ne doit pas être un synonyme d'un long intervalle entre les messages. Si un tableau de bord a besoin d'un statut avant que les preuves ne soient complètes, « aucune réponse récente observée » est plus précis qu'une affirmation sur la raison de l'absence de la personne. Considérez ce statut comme provisoire et révisez-le lorsque des événements différés arrivent.

Bâtir l'analyse autour de la préférence et de l'état de la tâche

Une analyse de cohorte utile consiste à se demander si les personnes qui choisissent explicitement une cadence plus lente accomplissent leurs tâches déclarées dans un délai cohérent avec cette préférence. Comparez ce qui est comparable : regroupez par préférence choisie et par type de tâche, et examinez séparément les échecs de distribution, les requêtes de service non résolues et les événements d'achèvement. Ne transformez pas l'intervalle de silence d'une personne en un signal d'échec à l'échelle du produit ; recherchez des schémas récurrents à travers des tâches et des conditions de distribution comparables.

Par exemple, si une personne sélectionne « quand je serai prêt », qu'une conversation reste ouverte et que le produit n'enregistre aucune erreur de distribution ni nouvelle action de l'utilisateur, le statut défendable est « aucune réponse observée ; préférence enregistrée ; tâche toujours ouverte ». Si la réponse sortante présente une erreur de service enregistrée, le statut doit refléter cette erreur, même si la préférence de la personne est également connue. Il s'agit d'une classification illustrative basée sur le modèle d'événement ci-dessus, et non d'un résultat mesuré du produit.

Avant d'utiliser une métrique pour prendre des décisions, vérifiez si les événements arrivent en retard, sont dupliqués ou sont manquants sur certaines plateformes. Firebase indique que certains rapports de distribution sont retardés et que les métriques agrégées peuvent omettre ou arrondir les résultats ; Pub/Sub documente une distribution au moins une fois et une redistribution possible. Rapprochez les événements à l'aide d'identifiants de message ou de tâche stables, et évitez de compter une nouvelle tentative comme une seconde action de l'utilisateur. Firebase: Understanding message delivery, Google Cloud: Subscription overview

Concevoir le suivi en fonction du choix de la personne

Si le suivi fait partie du produit, faites en sorte qu'il reflète la préférence choisie par la personne. Une heure de rappel définie peut déterminer l'envoi d'un rappel ; « quand je serai prêt » peut signifier l'absence de relance programmée dans le temps. Donnez à la personne un moyen clair de modifier ce choix, et rendez l'état actuel visible dans la conversation afin qu'elle puisse savoir si le produit l'attend, attend un service ou s'il a terminé.

Utilisez l'analytique pour repérer les anomalies techniques et comprendre l'achèvement des tâches, non pour fabriquer des certitudes à partir du silence. Les préférences explicites fournissent du contexte, les états des tâches montrent le travail restant et les événements de distribution révèlent les étapes techniques connues. Lorsqu'un de ces éléments manque, conservez l'incertitude dans l'étiquette. Cela permet d'obtenir un compte rendu plus utile des réponses lentes tout en laissant l'utilisateur maître du moment où il revient.

Continuer sur ce thème