Analyse systèmeAnalyste Produit / Analyste de Données

Quelle méthode devrait-on utiliser pour évaluer l'effet causal de la suppression complète d'une fonctionnalité obsolète (legacy feature) sur la rétention et l'engagement des utilisateurs, lorsque la désactivation se fait étape par étape par cohortes, qu'il existe une hétérogénéité dans les modèles d'utilisation de la fonctionnalité entre les segments, et que la baisse d'activité observée peut être due à l'effet négatif de la suppression ou à l'attrition naturelle des utilisateurs inactifs ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse à la question

Historiquement, les équipes produits se sont concentrées exclusivement sur les métriques de croissance et l'implémentation de nouvelles fonctionnalités. Cependant, avec la saturation des produits numériques et l'accumulation de la dette technique, il est devenu crucial de justifier la suppression d'une fonctionnalité (feature deprecation). Le problème réside dans le fait que les utilisateurs ayant activement utilisé la fonctionnalité supprimée diffèrent systématiquement du reste de l'audience en termes d'engagement et de loyauté, ce qui crée un biais de sélection (selection bias), et que la désactivation par cohortes fausse les séries temporelles avec la saisonnalité et l'attrition naturelle.

Pour isoler l'effet causal réel, il est nécessaire d'appliquer Difference-in-Differences (DiD) avec une analyse de cohortes ou CausalImpact basé sur Bayesian Structural Time Series, en utilisant les cohortes non affectées comme contrôle synthétique. Un élément clé est la construction d'un modèle de matching par score de propension (PSM) au sein de chaque cohorte : pour les utilisateurs ayant perdu la fonctionnalité (traitement), on sélectionne des paires d'utilisateurs qui ne l'ont jamais utilisée (contrôle), mais qui ont un profil d'activité, de ancienneté et d'historique de conversions similaires. En cas de seuil clair d'intensité d'utilisation de la fonctionnalité (par exemple, >5 utilisations par mois), le Regression Discontinuity Design (RDD) est efficace, permettant de comparer les utilisateurs juste de chaque côté du seuil de désactivation.

Il est également important de contrôler le survivorship bias : si la fonctionnalité est supprimée en raison d'une faible utilisation, l'analyse ne doit inclure que les utilisateurs actifs au moment de la décision, excluant ceux qui s'étaient déjà désengagés avant le début de l'observation. Pour évaluer l'effet à long terme, un staggered DiD avec des effets dynamiques (event study) est appliqué, permettant de suivre comment la rétention à trois et sept jours évolue par rapport au moment de la désactivation, et de vérifier l'hypothèse de tendances parallèles via des tests placebo sur les périodes précédentes.

Situation de la vie réelle

Dans un grand produit edtech, une décision a été prise de supprimer le chat textuel obsolète avec un mentor au profit de consultations vidéo, car moins de 3% de l'audience utilisaient ce chat, mais son support prenait 20% des ressources de l'équipe. La publication était prévue par étapes : d'abord la désactivation pour les nouveaux utilisateurs, puis pour les cohortes à faible activité, et enfin pour les power users. L'entreprise craignait que cette suppression ne provoque une vague de mécontentement et une attrition des utilisateurs à forte valeur ajoutée, qui avaient historiquement beaucoup utilisé le chat pour clarifier les devoirs.

La première option envisagée était une simple analyse comparative de la rétention avant et après la désactivation pour chaque cohorte. Cette approche se distinguait par une mise en œuvre rapide et une clarté pour les parties prenantes, mais souffrait de l'impossibilité de séparer l'effet de la suppression de la dégradation naturelle de la cohorte (cohort aging) et des fluctuations saisonnières de l'activité des étudiants pendant l'été, période durant laquelle la dernière étape de désactivation était prévue. La deuxième option était un test A/B classique utilisant un feature flag masquant le chat pour 50% des utilisateurs, mais celle-ci a été abandonnée en raison de la complexité technique de maintenir deux versions de l'UI et de considérations éthiques : il n'était pas possible de promettre le soutien du chat à certains utilisateurs tout en en refusant à d'autres en cas de bugs.

La troisième option choisie fut l'analyse via la méthode Difference-in-Differences avec contrôle synthétique. Pour chaque cohorte perdant l'accès au chat, les analystes, via Propensity Score Matching, trouvaient une paire d'utilisateurs de la cohorte précédente qui n'avaient jamais ouvert le chat, mais avaient un modèle de visionnage des leçons, un historique de soumission de devoirs et une géographie identiques. Cela a permis de comparer les trajectoires de rétention du groupe traitement (ceux qui ont perdu le chat) et du groupe contrôle (ceux qui ne l'ont jamais utilisé), isolant l'effet pur de la perte de la fonctionnalité des tendances générales.

Le résultat final a montré que pour les power users (top 10% par fréquence d'utilisation du chat), la suppression a bien réduit la rétention à 30 jours de 8%, mais cela a été compensé par une augmentation de 15% de la conversion vers les consultations vidéo et une amélioration des métriques de performance de l'application (une réduction du taux de crash de 12% due à la suppression du code legacy). Pour le segment moyen, l'effet était statistiquement insignifiant, ce qui a permis à l'entreprise de justifier la suppression complète de la fonctionnalité en se concentrant sur la migration des power users vers le nouveau canal de communication via des offres personnalisées.

Ce que les candidats oublient souvent

Comment distinguer l'effet de la suppression d'une fonctionnalité de l'effet de "simplification" de l'interface (simplification effect), lorsque la réduction de la charge cognitive peut masquer le négatif associé à la perte de la fonctionnalité ?

La réponse réside dans la décomposition des métriques : il est nécessaire de suivre non seulement la rétention, mais aussi le temps d'achèvement des tâches, le taux d'erreur et le taux de découverte de fonctionnalités pour les fonctionnalités restantes. Si après la suppression du chat, la métrique de temps pour la soumission des devoirs diminue (les utilisateurs soumettent plus rapidement) avec une rétention stable, cela témoigne d'un effet de simplification positif, compensant la perte du canal de communication. Pour l'évaluation quantitative, une analyse de médiation est construite : une connexion causale directe est évaluée entre "suppression → rétention" et indirectement via "suppression → simplification de l'UI → rétention", permettant de séparer le négatif pur de l'amélioration structurelle de l'UX.

Comment calculer correctement la puissance statistique pour un test de "non-infériorité" lors de la suppression d'une fonctionnalité, lorsque l'objectif est de prouver que le dommage ne dépasse pas un seuil acceptable ?

Les candidats appliquent souvent le calcul classique de puissance pour le test de supériorité, ce qui conduit à des conclusions injustifiées sur la "sécurité" de la suppression. Dans le cadre du test de non-infériorité, l'hypothèse nulle est formulée comme "l'effet est inférieur au seuil", et la puissance dépend de la marge d'indifférence (δ), qui doit être définie à l'avance par l'entreprise (par exemple, -2% de rétention). La formule de puissance nécessite l'indication de l'effet véritable attendu (généralement 0 ou légèrement positif) et de la variance, où l'approche vers δ nécessite des échantillons exponentiellement plus grands. Il est essentiel d'utiliser des calculateurs de puissance spécialisés pour des proportions appariées avec correction pour la clusterisation par cohortes, car les utilisateurs au sein d'une même cohorte corrèlent par rapport au temps de désactivation.

Comment prendre en compte les effets de réseau (spillover effects), lorsque la suppression d'une fonctionnalité pour un utilisateur affecte le comportement des autres à travers la rupture des liens de communication ?

Dans les produits sociaux ou les logiciels SaaS B2B, la suppression d'une fonctionnalité pour un acteur (par exemple, la désactivation d'une ancienne API pour un administrateur) affecte l'expérience des utilisateurs finaux (les employés), créant une interférence entre le traitement et le contrôle. Pour isoler cet effet, la randomisation basée sur des clusters ou une analyse via exposure mapping est utilisée : au lieu d'un statut de traitement individuel, on utilise la proportion d'utilisateurs dans le graphique social (équipe, famille) ayant perdu la fonctionnalité. Si la corrélation entre l'événement de désactivation individuelle et la proportion d'utilisateurs désactivés dans le cluster est élevée (>0,8), les estimations fournies par l'OLS classique sont biaisées. La solution consiste à utiliser la régression IV (variables instrumentales), où l'instrument est le fait d'appartenir à la cohorte de désactivation, tandis que la perte effective de la fonctionnalité est une variable endogène, ou d'appliquer des méthodes d'inférence causale pour l'interférence, comme le test de randomisation de Fisher avec correction pour la taille du cluster.