Contexte historique
Entre 2010 et 2015, l'approche de la compatibilité totale dominait, où les entreprises maintenaient des applications native pour iOS et Android, couvrant 95% du marché selon les versions d'OS. Cependant, avec la complexité croissante des fonctionnalités et le passage à des API modernes (telles que Biometric API, Camera2, Jetpack Compose), le coût de maintien du code legacy a dépassé la rentabilité des utilisateurs retenus. Dans les années 2020, la politique "n-2" est devenue la norme, exigeant le développement de méthodologies pour évaluer le véritable effet de la désactivation, et pas seulement l'analyse corrélationnelle des métriques.
Problématique
L'arrêt forcé crée une endogénéité d'auto-sélection : les utilisateurs avec des appareils obsolètes ne peuvent physiquement pas passer à la version requise de iOS ou Android, tandis que l'audience active avec des smartphones modernes se met à jour rapidement. La baisse observée du MAU peut être le résultat d'un vrai départ (churn) ou d'une migration vers une PWA (Progressive Web App) ou le web mobile. Le A/B-testing classique est impossible, car la désactivation est technique et s'applique à tous les utilisateurs d'une version d'OS spécifique simultanément, et le suivi de l'identité entre l'application native et la version web est compliqué à cause des restrictions de Safari et Chrome sur les cookies.
Solution détaillée
La méthodologie optimale est basée sur une combinaison de régression disjointe (RDD) et de contrôle synthétique (Synthetic Control Method). Premièrement, RDD est utilisé avec un seuil basé sur la version d'OS (par exemple, la coupure entre Android 8.0 et Android 9.0), où les utilisateurs avec des versions légèrement inférieures au seuil servent de groupe témoin pour les utilisateurs juste au-dessus du seuil, avec ajustement pour des caractéristiques continues (modèle d'appareil, historique de fréquence d'utilisation).
Deuxièmement, pour évaluer la migration vers le canal web, un contrôle synthétique est construit sur la base des données historiques de DAU par cohortes d'utilisateurs similaires par leurs comportements avant la désactivation. Une combinaison pondérée de cohortes non exposées (par exemple, utilisateurs d'autres régions avec une structure d'appareil similaire) est créée pour modéliser la trajectoire contrefactuelle des métriques.
Troisièmement, le difference-in-differences avec Propensity Score Matching est appliqué pour faire correspondre les utilisateurs qui auraient pu se mettre à jour mais ne l'ont pas fait, avec ceux qui se sont mis à jour, tout en ajustant pour les caractéristiques techniques des appareils. Il est important de suivre la migration cross-device via une Customer Data Platform (CDP), en liant le device_id de l'application mobile au cookie_id de la version web via un user_id unique lors de l'authentification. Une survival analysis (modèles de Cox) est également utilisée pour estimer le temps jusqu'au départ en fonction de la version d'OS et de la disponibilité d'alternatives web.
Contexte : Un grand marketplace a décidé d'arrêter le support de Android 7.0 et inférieur (environ 8% de la base) pour intégrer le Biometric API pour des paiements sécurisés. Le budget du projet prévoyait une perte de pas plus de 3% de l'audience active, compensée par une augmentation des conversions dans les nouvelles versions.
Option 1 : Comparaison simple du MAU avant et après la désactivation par dates avec un calcul du pourcentage de perte. Avantages : simplicité de calcul, rapidité des résultats, ne nécessite pas d'infrastructure complexe. Inconvénients : ignore complètement la saisonnalité, la migration vers le web et l'auto-sélection par appareil ; risque élevé de faux positifs quant au départ, lorsque des utilisateurs sont simplement passés à m.site.
Option 2 : Construction d'une analyse de cohortes avec correspondance par appareils avec Android 8.0 (ceux qui auraient pu rester mais se sont mis à jour) contre Android 7.0 (ceux qui ne pouvaient pas se mettre à jour). Avantages : prend en compte les limites techniques, permet d'isoler l'effet de l'incapacité à se mettre à jour de l'indisposition à le faire. Inconvénients : complexité à obtenir des données pures en raison de la fragmentation des OEM (comme Samsung, Xiaomi), des différences de comportement des utilisateurs selon les marques et de l'hétérogénéité géographique.
Option 3 : Approche complète avec Synthetic Control au niveau des régions géographiques avec une forte proportion d'anciens appareils (comparaison de la région A, où 30% sont sur Android 7, avec la région B, où cela représente 5%, avant et après la désactivation) avec ajustement sur les tendances globales du marché. Avantages : prend en compte les facteurs macroéconomiques et la saisonnalité, permet d'évaluer l'effet global sur l'entreprise. Inconvénients : nécessite des échantillons plus importants et suppose l'absence d'autres interventions simultanées dans les régions.
Solution choisie : L'Option 3 a été mise en œuvre en combinaison avec une analyse de cohortes d'utilisateurs autorisés (pour suivre la migration vers le web via des connexions SSO). Le choix a été motivé par la nécessité de séparer le véritable départ de la cannibalisation du trafic web, ce qui est crucial pour évaluer le unit-economics (les utilisateurs web ont un AOV de 15% inférieur).
Conclusion : L'analyse a montré que seulement 40% des **MAU" "perdus" avaient réellement quitté, 35% avaient migré vers PWA, et 25% avaient mis à jour leurs appareils dans le trimestre. L'effet négatif réel s'est avéré 2,5 fois inférieur à celui prévu, ce qui a permis de continuer la stratégie de mise à jour des API pour les 92% restants de l'audience, avec une augmentation de GMV de 8% grâce aux nouvelles fonctionnalités de paiement.
Comment distinguer l'impossibilité technique de mise à jour de la refus comportemental de se mettre à jour, si les deux groupes restent sur d'anciennes versions de l'application ?
La réponse doit être fondée sur l'analyse des device_change events dans la CDP. Les utilisateurs avec un refus comportemental (lazy updaters) ont souvent un modèle de "mises à jour différées" dans leur historique (par exemple, en sautant plusieurs versions mineures, mais en installant des correctifs de sécurité critiques), tandis que les utilisateurs techniquement limités ne changent jamais la version d'OS pendant tout le cycle de vie de l'appareil. De plus, l'analyse du hardware fingerprint via WebGL ou Canvas dans la version web est utilisée : si l'utilisateur apparaît dans la PWA avec le même appareil (selon User-Agent et résolution d'écran) que dans l'application native avant la désactivation, cela confirme une migration et non un départ. Il est également important de segmenter par l'historique de app_version : si l'utilisateur s'est régulièrement mis à jour dans Android 7 (entre les patchs 7.0->7.1), mais ne pas être passé à 8.0, cela indique une limite technique et non un manque de volonté.
Pourquoi le Propensity Score Matching standard peut donner des estimations biaisées lors de l'évaluation de l'effet de la mise à jour forcée dans des conditions de forte corrélation entre les revenus des utilisateurs et le modèle d'appareil ?
Le PSM standard est basé sur l'indépendance conditionnelle, supposant que les covariables observées expliquent complètement l'auto-sélection. Cependant, dans le cas de la politique de sunset, une variable cachée existe — le revenu disponible, qui est corrélée simultanément avec le modèle de smartphone (flagship contre budget) et avec le LTV de l'utilisateur. Les appareils économiques ne reçoivent souvent pas de mises à jour d'OS et leurs propriétaires ont une capacité de paiement plus faible. Le PSM standard sous-estimera l'effet négatif, car il "pondérera" les utilisateurs riches avec de nouveaux appareils comme des équivalents des pauvres avec d'anciens, bien que leurs comportements diffèrent fondamentalement. La solution consiste à utiliser le Coarsened Exact Matching (CEM) avec stratification précise par segments de prix des appareils (low-end, mid-range, flagship) avant d'appliquer le PSM, ou des variables instrumentales (IV) en utilisant la politique de mises à jour des OEM comme choc exogène.
Comment prendre en compte correctement les effets de réseau entre les utilisateurs de différentes versions d'application lors de l'évaluation des départs, si la fonctionnalité "partager le produit" fonctionne différemment dans l'ancienne et la nouvelle version ?
Les effets de réseau créent un spillover entre les groupes de traitement et de contrôle : si un utilisateur actif de la nouvelle version (traitement) ne peut pas partager du contenu avec un ami sur l'ancienne version (qui ne prend pas en charge le nouveau format deep link), cela dégrade l'expérience des deux et peut accélérer le départ du groupe de contrôle non pas à cause de la politique de sunset, mais en raison de la dégradation de l'UX. Pour corriger cela, il est nécessaire d'appliquer un network-based DID (Différences en Différences avec des poids de réseau). Un graphique des relations sociales est construit (via l'analyse des referral codes, des commandes conjointes ou des messages dans le chat de l'application). La "contagion" des métriques est évaluée : si un utilisateur du groupe de contrôle (ancienne version) a de nombreuses connexions avec le groupe de traitement (nouvelle version), son comportement sera biaisé. Un terme d'interaction Traitement x Network_Exposure est ajouté au modèle, où Network_Exposure est la proportion de connexions dans le réseau utilisant la nouvelle version. À un niveau élevé d'effets de réseaux, l'effet véritable de la politique de sunset sera sous-estimé, car une partie des utilisateurs "contrôlés" aura en fait subi un impact indirect, et un ajustement sur intention de traiter (ITT) est nécessaire, tenant compte de cette contamination.