Dépannage et questions fréquentes sur les tests A/B

Combien de tests puis-je créer et exécuter ?

Vous pouvez créer jusqu'à 300 tests par projet (y compris les déploiements progressifs), dont 24 peuvent être exécutés simultanément. Les autres tests sont considérés comme terminés. Si vous atteignez cette limite, vous devez supprimer les tests en brouillon ou terminés avant d'en créer d'autres.

Pourquoi ne puis-je pas voir mes tests après avoir dissocié mon projet de Google Analytics, puis l'avoir associé à nouveau ?

Si vous associez votre projet à une autre propriété Google Analytics, vous perdrez l'accès aux tests créés précédemment. Pour retrouver l'accès à un test précédent, associez à nouveau votre projet à la propriété Google Analytics qui était associée au moment de la création du test.

Pourquoi le message "Projet non associé à Google Analytics" s'affiche-t-il lorsque je crée un Remote Config test ?

Si vous avez déjà activé Google Analytics dans votre projet et associé vos applications, mais que le message indiquant que Google Analytics n'est pas associé s'affiche toujours, assurez-vous qu'un flux Analytics existe pour toutes les applications de votre projet. Actuellement, pour utiliser A/B Testing, toutes les applications d'un projet doivent être associées à Analytics.

Voici comment vérifier la liste de tous les flux actifs pour votre Google Analytics intégration :

1. Dans la console Firebase, accédez à la page settings Settings > Integrations.
2. Sur la fiche Google Analytics, cliquez sur Manage (Gérer).

La création d'un flux Google Analytics pour toute application qui n'en possède pas devrait résoudre le problème. Vous pouvez créer des flux pour les applications manquantes de plusieurs manières :

• Si une ou deux applications seulement ne possèdent pas de flux associé Google Analytics, vous pouvez choisir l'une des méthodes suivantes pour ajouter un flux Google Analytics :
  • Dans la console Firebase, supprimez et ajoutez à nouveau toute application sans flux actif.
  • Dans la console Google Analytics, sélectionnez Admin, cliquez sur Data Streams, puis cliquez sur Add stream. Ajoutez les détails de l'application manquante, puis cliquez sur Register app.
• Si plusieurs flux d'application sont manquants, la dissociation et la réassociation de votre propriété Google Analytics constituent le moyen le plus rapide et le plus efficace de créer les flux d'application manquants :
  1. Dans la console Firebase, accédez à la page des settings Settings > Integrations (Paramètres > Intégrations).
  2. Sur la fiche Google Analytics, cliquez sur Manage (Gérer).
  3. Notez l'Google Analytics ID de propriété et le compte Google Analytics associé.
  4. Cliquez sur more_vert More et sélectionnez Unlink Analytics from this project.
  5. Lisez l'avertissement qui s'affiche (ne vous inquiétez pas, vous associerez à nouveau la même propriété à l'étape suivante), puis cliquez sur Unlink Google Analytics.
     
     Une fois la dissociation terminée, vous serez redirigé vers la page Integrations (Intégrations).
  6. Sur la fiche Google Analytics, cliquez sur Enable (Activer) pour lancer le processus de réassociation.
  7. Sélectionnez votre compte Analytics dans la liste Select account.
  8. À côté de Automatically create a new property in this account (Créer automatiquement une propriété dans ce compte), cliquez sur edit Edit (Modifier), puis sélectionnez votre ID de propriété dans la liste Analytics property (Propriété Analytics) qui s'affiche.
     
     La liste de toutes les applications de votre projet s'affiche. Les mappages de flux existants pour chaque application sont listés, et un flux est créé pour les applications qui n'en possèdent pas.
  9. Cliquez sur Enable Google Analytics (Activer Google Analytics) pour réassocier la propriété.
  10. Cliquez sur Finish (Terminer).

Si vous recevez toujours un message d'erreur lorsque vous créez des tests A/B avec Remote Config après avoir suivi ces étapes, contactez l'assistance Firebase.

Quelles sont les principales fonctionnalités du nouveau A/B Testing workflow ?

• Création dans Remote Config : vous créez désormais des tests directement à partir de la Remote Config section de la console Firebase. Par exemple, sur la page Parameters (Paramètres), cliquez sur Create Experiment (Créer un test), ce qui ouvre un flux de création basé sur une barre latérale.
• Ciblage plus riche et réutilisation des conditions : les tests utilisent le générateur de conditions natif de Remote Config, ce qui vous permet de réutiliser les conditions existantes et de cibler les utilisateurs avec des critères riches (tels que les audiences Analytics, les propriétés utilisateur, les versions d'application, la langue de l'appareil et le pays/la région) évalués dans un ordre séquentiel prévisible.
• Architecture unifiée : les tests font partie du modèle Remote Config. Cela signifie que les modifications apportées aux tests (ciblage, variantes, arrêt) sont regroupées avec d'autres Remote Config modifications et prennent effet lorsque le modèle est publié.
• Mises à jour en temps réel : grâce au mécanisme de récupération Remote Config, les mises à jour des valeurs de test peuvent être propagées à vos utilisateurs mobiles en temps réel.
• Onglet "Staging" : les tests en cours de création ou de mise à jour sont conservés dans un sous-onglet "Staging" au sein de Remote Config. Ils sont locaux à la session de console active.
• Suppression des anciens brouillons : l'ancien onglet Drafts (Brouillons) autonome de A/B Testing est obsolète. Les brouillons existants dans cet onglet sont en lecture seule (ils peuvent être dupliqués ou supprimés) et ne peuvent pas être démarrés ou modifiés. Cet onglet sera définitivement supprimé le 31 octobre 2026.
• Suppression des appareils de test : la fonctionnalité "Gérer les appareils de test" n'est plus disponible dans le nouveau workflow. Pour cibler des appareils de test internes spécifiques, vous pouvez ajouter un ou plusieurs ID d'installation Firebase (FIDs) aux conditions du test lors de sa création.

Combien de tests puis-je créer et exécuter ?

Vous pouvez créer jusqu'à 300 tests par projet (y compris les déploiements progressifs), dont 24 peuvent être exécutés simultanément. Les autres tests sont considérés comme terminés. Si vous atteignez cette limite, vous devez supprimer les tests en brouillon ou terminés avant d'en créer d'autres.

Comment créer un test ?

Vous pouvez créer des tests directement à partir de la section Remote Config. Par exemple, pour créer un test à partir de la page "Parameters" (Paramètres), accédez à Remote Config > Parameters (Remote Config > Paramètres), puis cliquez sur Create Experiment (Créer un test). Un flux de création basé sur une barre latérale s'ouvre semblable à celui utilisé pour créer des déploiements progressifs Remote Config.

Comment tester ou examiner un test en interne avant de le présenter à tous les utilisateurs ?

Dans la plupart des cas où vous souhaitez valider et tester un test avant de le déployer, vous êtes probablement plus intéressé par le test des valeurs du test et du comportement de l'application que par le test de la distribution du test lui-même. Dans ce cas, nous vous recommandons de créer un test que vous pouvez cibler sur un groupe de test limité. Après avoir créé le test et vérifié que les variantes fonctionnent comme prévu, vous pouvez dupliquer le test et modifier les conditions pour cibler vos utilisateurs externes, et appliquer d'autres conditions en fonction des utilisateurs que vous souhaitez cibler.

Vous pouvez également cibler des appareils de test internes spécifiques pour valider le comportement du test avant de le présenter à des utilisateurs finaux. Pour ce faire, ajoutez un ou plusieurs ID d'installation Firebase (FIDs) aux conditions du test lors de sa création.

Où puis-je trouver mes brouillons de test temporaires et qu'est-ce que l'onglet "Staging" ?

Avec ce workflow, les brouillons de test temporaires (y compris les tests en cours de création ou de mise à jour) sont disponibles dans un sous-onglet appelé Staging au sein de Remote Config. Les brouillons de ce sous-onglet ne sont pas conservés au-delà de la session en cours.

Comment arrêter un test en cours d'exécution ?

Pour arrêter un test, vous devez désormais publier le modèle Remote Config. Lorsque vous cliquez sur Stop Experiment (Arrêter le test), une fenêtre pop-up de confirmation de publication s'affiche. Cette fenêtre pop-up liste toutes les modifications qui prendront effet, y compris l'arrêt du test. La publication du modèle est nécessaire pour finaliser l'arrêt.

Pourquoi mon test A/B en cours d'exécution s'est-il arrêté de manière inattendue ?

Les tests peuvent s'arrêter automatiquement en raison de modifications apportées au modèle Remote Config :

• Restauration du modèle : si vous restaurez votre modèle Remote Config à une version où le test n'existait pas, le test s'arrête. Si vous restaurez une version où un test était déjà arrêté, il ne redémarrera pas. Vous pouvez dupliquer le test arrêté et le republier si vous souhaitez le recréer et l'exécuter.
• Dissociation des paramètres : si un test n'est associé qu'à un seul paramètre, la dissociation de la condition associée à ce paramètre entraînera l'arrêt du test.

La restauration d'une ancienne version du modèle Remote Config réactivera-t-elle un test qui a été arrêté ou supprimé précédemment ?

Non. La restauration d'un modèle Remote Config ne redémarrera aucun test qui a déjà été arrêté, expiré ou supprimé, même si ce test était actif dans la version restaurée. Vous pouvez dupliquer le test et le republier si vous souhaitez le recréer et l'exécuter.

Que se passe-t-il lorsqu'un test expire et quelles mesures dois-je prendre ?

Les expériences A/B Testing expirent automatiquement après 90 jours d'exécution. Lorsqu'un test arrive à expiration :

• L'outil cesse de collecter des données : le test cesse de collecter de nouvelles données et de calculer des métriques. Les résultats historiques et les métriques collectés au cours de la période de 90 jours restent disponibles dans la console Firebase pour examen.
• Le test n'est plus actif : le test cesse de s'exécuter et sa logique de condition ne filtre plus activement les utilisateurs pour les variantes de test.
• Le test expiré doit être supprimé : vous devez supprimer le test expiré du paramètre Remote Config. Si le test expiré n'est pas supprimé, vous ne pourrez pas créer de test à l'aide du même paramètre tant qu'il n'aura pas été nettoyé.

Actions recommandées :

• Examinez les résultats du test dans la console Firebase pour examiner les métriques finales et déterminer s'il existe une variante gagnante.
• Appliquez les modifications et nettoyez le test expiré :
  • S'il existe une variante gagnante, déployez-la pour appliquer la valeur à vos utilisateurs. Notez que le déploiement d'une variante ne supprime pas automatiquement le test expiré.
  • Si vous ne souhaitez pas déployer de variante, supprimez le test du paramètre pour revenir à la valeur de paramètre par défaut.
  Dans les deux cas, supprimez explicitement le test expiré du paramètre et publiez le Remote Config modèle pour finaliser le nettoyage.
• Dupliquez le test ou créez-en un à partir du paramètre si vous devez continuer à tester ou collecter plus de données.

Points clés à retenir :

• Les déploiements progressifs ne suppriment pas automatiquement les tests expirés : le déploiement d'une variante gagnante ne nettoie pas automatiquement le test expiré. Vous devez toujours supprimer explicitement le test expiré du paramètre Remote Config et publier le modèle.
• Les tests expirés ne peuvent pas être réactivés : une fois qu'un test expire, il ne peut pas être redémarré ni réactivé, même si vous effectuez un rollback de votre Remote Config modèle à une version où le test était actif.
• Le minuteur de 90 jours démarre lors de la publication : le compte à rebours de l'expiration commence dès que le test est publié dans le modèle, même si l'exposition de l'utilisateur est initialement définie sur 0%.

L'assistance en temps réel est-elle disponible pour les tests A/B Testing ?

Oui, les mises à jour en temps réel sont désormais compatibles avec les expériences A/B Testing. Assurez-vous que votre application utilise les dernières versions requises du SDK (SDK Firebase pour Android version 34.13.0, SDK Firebase pour iOS version 12.13.0 et SDK JavaScript Firebase version 12.15.0 ) pour profiter de cette fonctionnalité.

Si je modifie les conditions de ciblage d'un test en cours d'exécution pour exclure certains utilisateurs, pourquoi ces utilisateurs sont-ils toujours inclus dans les données de mesure du test ?

A/B Testing utilise des buckets persistants pour la mesure.

Une fois qu'un utilisateur est attribué à un test et que sa mesure commence, il continue d'être inclus dans les métriques du test, même si les modifications ultérieures apportées aux conditions de ciblage l'excluent normalement. Toutefois, ces utilisateurs cesseront de recevoir les valeurs de variante du test s'ils ne répondent plus aux conditions mises à jour. Pour en savoir plus, consultez la logique d'attribution des variantes Remote Config.

Le message d'erreur Associez une application à cette condition ou sélectionnez-en une autre s'affiche lorsque je configure le ciblage d'un test.

Cette erreur signifie que la condition de ciblage sélectionnée nécessite qu'une application Firebase explicite soit ciblée, mais que la configuration actuelle n'en inclut pas. Assurez-vous que la condition contient une règle qui cible au moins l'une de vos applications Firebase.

Pourquoi mes conditions ne ciblent-elles aucun utilisateur ?

Les conditions du modèle Remote Config sont évaluées de manière séquentielle de haut en bas à l'aide de la logique de "première correspondance". Si une condition générale est placée au-dessus d'une condition de test plus spécifique , la condition plus large capture l'utilisateur en premier, et le test est ignoré. Pour résoudre ce problème, envisagez l'une des solutions suivantes dans l'onglet Conditions :

• Réorganiser les conditions : assurez-vous que les conditions de test plus spécifiques (les moins inclusives) sont placées plus haut dans la liste d'évaluation afin qu'elles soient vérifiées avant les conditions plus larges et plus générales conditions.
• Utiliser des paramètres dédiés : si vous avez des besoins de ciblage complexes, envisagez de créer un paramètre Remote Config unique spécifiquement pour votre test afin d'éviter les conflits de conditions.

Je ne parviens pas à supprimer une condition de l'onglet Conditions.

Les conditions ne peuvent pas être supprimées si elles sont associées à des tests actifs/en cours d'exécution. Vous devez d'abord arrêter le test et supprimer la condition.

Je ne parviens pas à supprimer une règle d'une condition si cette règle est associée à une application spécifique.

Si une condition contient une règle qui cible explicitement une application Firebase, cette règle d'association d'application spécifique ne peut pas être supprimée lors de la modification de la condition.

Je vois un avertissement concernant l'utilisation de plusieurs conditions de pourcentage dans le ciblage de mon test. Dois-je m'inquiéter ?

Il s'agit d'un avertissement non bloquant. Il s'affiche pour vous informer lorsque le ciblage d'un test combine plusieurs conditions basées sur un pourcentage, car leur effet combiné, associé au pourcentage d'exposition du test, peut parfois entraîner une distribution inattendue des utilisateurs. Vous pouvez continuer, mais soyez attentif à la façon dont ces conditions interagissent.

Où puis-je trouver et gérer les tests brouillons ou les appareils de test ?

Avec le nouveau A/B Testing workflow, voici quelques-unes des modifications liées aux anciens brouillons et appareils de test :

• Suppression de l'onglet "Brouillons" : l'onglet Drafts (Brouillons) et les tests brouillons existants ne sont plus modifiables. Vous ne pouvez qu'afficher, dupliquer ou supprimer les tests brouillons existants. L'onglet Drafts (Brouillons) sera définitivement supprimé de la console le 31 octobre 2026.
• Suppression des appareils de test : la fonctionnalité Manage test devices (Gérer les appareils de test) n'est plus disponible dans le nouveau workflow. Pour cibler des appareils de test internes spécifiques, vous pouvez ajouter un ou plusieurs ID d'installation Firebase (FIDs) aux conditions du test lors de sa création. Pour tester une fonctionnalité expérimentale pour les applications d'assurance qualité, attribuez le test à un ID d'application spécifique et définissez l'exposition sur 100%. Pour examiner le test avant de le déployer, définissez l'exposition sur 0%. Notez que la période d'expiration du test de 90 jours commence lors de la publication, même avec une exposition de 0 %. Après avoir examiné le test, vous pouvez augmenter le pourcentage d'exposition pour commencer le déploiement complet complet.

Puis-je créer des paramètres lors de la création d'un test ?

Non, vous ne pouvez pas créer de paramètre Remote Config directement dans la barre latérale de création de test. Vous devez créer le paramètre dans Remote Config avant de configurer un test qui l'utilise.

Comment puis-je atténuer les problèmes de récupération (survenus en mai 2026) avec le nouveau workflow ?

Un problème a empêché les tests Firebase A/B Testing créées entre le 13 mai 2026 et le 22 mai 2026 d'atteindre les SDK client. Cela signifie que vos utilisateurs finaux n'ont pas reçu de variantes de test et qu'il n'y a pas de métriques disponibles pour ces tests. Notez que la diffusion des tests à vos utilisateurs finaux est désormais automatiquement restaurée, et la collecte de métriques commencera à partir de la prochaine récupération. Si vous devez étendre la période de mesure de votre test en raison de cette interruption ou si vous avez d'autres questions sur le nouveau workflow, veuillez contacter l'assistance Firebase.