Réponse à la question.

La personnalisation des notifications push nécessite une approche quasi-expérimentale stricte en raison de l'auto-sélection des utilisateurs selon leur temps d'activité. La contamination croisée (cross-contamination) possible à travers les réseaux sociaux ou les comptes familiaux complique encore l'isolement de l'effet.

La méthode clé est le Difference-in-Differences (DiD) avec contrôle synthétique. Le groupe de contrôle est formé sur la base du matching par score de propension selon le temps d'ouverture de l'application et les tendances historiques des commandes.

Pour corriger les effets de l'heure de la journée, une stratification par fuseaux horaires est appliquée. La contamination croisée est détectée par l'analyse de device ID et des adresses IP à la recherche de comptes partagés.

La métrique de rétention est calculée comme le rapport de risque avec l'utilisation du modèle des risques proportionnels de Cox. Cela permet de prendre en compte les données censurées et l'hétérogénéité des risques de perte.

Situation de la vie réelle

Dans l'application Delivery Club, un modèle ML en Python utilisant CatBoost pour personnaliser le timing des notifications push était prévu. Le problème était que les utilisateurs actifs ouvraient principalement l'application pendant les heures de déjeuner, créant un biais de sélection.

Le rollout partiel dans 20% de l'audience a provoqué un effet de "bouche à oreille". Les utilisateurs du groupe de contrôle prenaient connaissance des promotions par leurs collègues, ce qui entraînait une contamination croisée.

La première solution envisagée était un test A/B classique avec segmentation géographique. La ville A était le groupe test, la ville B — le groupe de contrôle.

Les avantages de cette approche comprenaient une isolation claire des groupes et la simplicité d'interprétation des résultats pour l'entreprise. Les inconvénients étaient les différences de préférences culinaires et de revenus entre les villes, créant un biais de 12 à 15% dans la rétention de base.

La deuxième option était d'analyser uniquement les utilisateurs ayant activé les notifications (analyse per-protocol). Cela permettait de se concentrer sur le public cible réagissant aux communications.

Les avantages — une grande pertinence pour l'équipe produit. Les inconvénients — ignorer l'effet du biais de désinscription : les utilisateurs ayant désactivé les notifications avaient un taux d'abandon de base 3 fois plus élevé, ce qui déformait l'effet global de l'intervention.

La troisième solution était le Causal Impact de Google avec construction d'un contrôle synthétique. Des Bayesian Structural Time Series ont été utilisées pour modéliser le contrefactuel.

Les avantages incluaient la prise en compte des tendances temporelles et de la saisonnalité sans besoin de contrôle explicite. Les inconvénients — une sensibilité élevée au choix des covariables et la fragilité de l'hypothèse des tendances parallèles avant l'intervention.

L'approche choisie était une méthode combinée : Inverse Probability Weighting (IPW) pour corriger l'auto-sélection selon le temps d'activité, plus Diff-in-Diff avec la clustering des erreurs standards au niveau des clusters géographiques.

Cette solution conservait la variabilité individuelle des temps d'envoi, cruciale pour la personnalisation. En même temps, un contrôle était exercé sur les spillovers inter-groupes grâce à la robustesse de cluster.

Le résultat a été la détection d'un effet incrémental réel de +8,3% sur la rétention à 7 jours. Une comparaison naïve montrait +15%. L'effet s'est avéré statistiquement significatif uniquement pour le segment "utilisateurs avec 3+ commandes dans l'historique".

Cela a permis d'optimiser le budget d'envoi, en excluant les utilisateurs froids du public cible des campagnes personnalisées.

Ce que les candidats oublient souvent

Comment prendre correctement en compte la saisonnalité lors du calcul de la prévision LTV pour un produit d'abonnement avec des plans annuels et mensuels en tenant compte de l'hétérogénéité des cohortes ?

Les débutants utilisent souvent une simple moyenne des courbes de rétention historiques sans tenir compte du fait que les utilisateurs arrivant pendant la période Black Friday ont un profil de rétention qualitativement différent. Leur churn est de 2 à 3 fois plus élevé que celui des utilisateurs organiques.

L'approche correcte consiste à construire des modèles distincts BG/NBD ou Gamma-Gamma pour chaque cohorte, en tenant compte des variables dummy saisonnières. Une alternative est l'utilisation de Cohort-Based LTV avec ajustement à l'aide du Bayesian Hierarchical Modeling pour emprunter de la puissance entre les cohortes (partial pooling).

Quelle est la différence entre l'analyse intent-to-treat (ITT) et l'analyse treatment-on-the-treated (TOT) lors de l'évaluation de l'effet d'une visite d'onboarding, et quand appliquer quelle approche ?

L'ITT analyse l'effet de l'offre (offer) de passer par l'onboarding à tous les utilisateurs du groupe test, y compris ceux qui refusent. Le TOT mesure l'effet de la participation effective à la visite (complier average causal effect).

L'ITT est conservateur et convient aux décisions commerciales concernant l'évolutivité de la fonction. Il reflète le comportement réel du public en tenant compte des frictions. Le TOT nécessite des variables instrumentales et répond à la question de la faisabilité d'un onboarding forcé.

Une erreur dans le choix de la méthode entraîne une surestimation de l'effet de 40 à 60%. Pour le TOT, des bogues aléatoires dans l'affichage de la visite peuvent être utilisés comme instrument.

Comment diagnostiquer le problème du "peeking" lors de la réalisation de tests A/B séquentiels et quelles corrections statistiques appliquer ?

Le peeking se produit lors de l'arrêt prématuré d'un test à l'atteinte de la signification. Le diagnostic — analyse du p-value au fil du temps : lors de peeking, la courbe montre un "flou" avec des croisements fréquents du seuil de 0.05.

Les solutions incluent le Group Sequential Testing avec des fonctions d'alphaspending (O'Brien-Fleming). Une alternative est le Bayesian A/B Testing avec approche ROPE (Region of Practical Equivalence).

La fixation de la taille de l'échantillon à travers des Data Quality Gates dans Apache Airflow est également efficace. Une erreur critique est l'utilisation de naïve confidence intervals sans correction de Bonferroni, ce qui gonfle le taux de faux positifs à 25-30% lors de 5 vérifications intermédiaires.