À propos des tests A/B Firebase

Pour vous aider à maximiser la pertinence et l'utilité de vos résultats de test, cette page fournit des informations détaillées sur le fonctionnement de Firebase A/B Testing.

Taille de l'échantillon

L'inférence Firebase A/B Testing ne nécessite pas l'identification d'une taille d'échantillon minimale avant de commencer un test. En général, vous devez choisir le niveau d'exposition aux tests le plus élevé qui vous convient. Plus la taille de l'échantillon est importante, plus vous avez de chances d'obtenir un résultat statistiquement pertinent, surtout lorsque les différences de performances entre les variantes sont faibles. Vous pouvez également consulter un calculateur de taille d'échantillon en ligne pour trouver la taille d'échantillon recommandée en fonction des caractéristiques de votre test.

Modifier des tests

Vous pouvez modifier certains paramètres des tests en cours, y compris :

• Nom du test
• Description
• Conditions de ciblage
• Valeurs des variantes

Pour modifier un test :

1. Ouvrez la page de résultats du test que vous souhaitez modifier.
2. Dans le menu Plus , sélectionnez Modifier l'expérience en cours.
3. Apportez les modifications souhaitées, puis cliquez sur Publier.

Notez que la modification du comportement de l'application pendant un test en cours peut avoir un impact sur les résultats.

Logique d'attribution des variantes Remote Config

Les utilisateurs qui remplissent toutes les conditions de ciblage du test (y compris la condition de pourcentage d'exposition) sont attribués aux variantes du test en fonction des pondérations des variantes et d'un hachage de l'ID du test et de l'ID d'installation Firebase de l'utilisateur.

Google Analytics Les audiences sont soumises à une latence et ne sont pas disponibles immédiatement lorsqu'un utilisateur répond aux critères d'audience pour la première fois :

• Lorsque vous créez une audience, un délai de 24 à 48 heures peut être nécessaire pour qu'elle accumule de nouveaux utilisateurs.
• Les nouveaux utilisateurs sont généralement ajoutés aux audiences éligibles 24 à 48 heures après leur éligibilité.

Pour le ciblage sensible au facteur temps, envisagez d'utiliser des propriétés utilisateur Google Analytics ou des options de ciblage intégrées telles que le pays ou la région, la langue et la version de l'application.

Une fois qu'un utilisateur a rejoint un test, il est attribué de manière persistante à sa variante de test et reçoit les valeurs de paramètre du test tant que celui-ci reste actif, même si ses propriétés utilisateur changent et qu'il ne répond plus aux critères de ciblage du test.

Événements d'activation

Les événements d'activation des tests limitent la mesure des tests aux utilisateurs de l'application qui déclenchent l'événement d'activation. L'événement d'activation du test n'a aucun impact sur les paramètres du test récupérés par l'application. Tous les utilisateurs qui répondent aux critères de ciblage du test recevront les paramètres du test. Il est donc important de choisir un événement d'activation qui se produit après la récupération et l'activation des paramètres du test, mais avant que ces paramètres ne soient utilisés pour modifier le comportement de l'application.

Pondération des variantes

Lors de la création d'un test, il est possible de modifier les pondérations par défaut des variantes pour placer un pourcentage plus élevé d'utilisateurs de test dans une variante.

Interpréter les résultats du test

Firebase A/B Testing utilise l'inférence fréquentiste pour vous aider à comprendre la probabilité que les résultats de votre test soient dus uniquement au hasard. Cette probabilité est représentée par une valeur de probabilité ou une valeur p. La valeur p correspond à la probabilité qu'une différence de performances de cette ampleur (ou plus grande) entre deux variantes puisse être due au hasard s'il n'y a en réalité aucun effet. Elle est mesurée par une valeur comprise entre 0 et 1. A/B Testing utilise un niveau de signification de 0,05, ce qui signifie que :

• Une valeur p inférieure à 0,05 indique que si la véritable différence était nulle, il y aurait moins de 5 % de chances qu'une différence observée aussi extrême se produise de manière aléatoire. Comme 0,05 est le seuil, toute valeur p inférieure à 0,05 indique une différence statistiquement significative entre les variantes.
• Une valeur p supérieure à 0,05 indique que la différence entre les variantes n'est pas statistiquement significative.

Les données de test sont actualisées une fois par jour. L'heure de la dernière actualisation s'affiche en haut de la page des résultats du test.

Le graphique des résultats du test affiche les valeurs moyennes cumulées de la métrique sélectionnée. Par exemple, si vous suivez le revenu publicitaire par utilisateur en tant que métrique, le revenu observé par utilisateur s'affiche. Si vous suivez les utilisateurs sans plantage, le pourcentage d'utilisateurs n'ayant pas rencontré de plantage est indiqué. Ces données sont cumulatives depuis le début du test.

Les résultats sont divisés en données observées et données d'inférence. Les données observées sont calculées directement à partir des données Google Analytics. Les données d'inférence fournissent des valeurs p et des intervalles de confiance pour vous aider à évaluer la signification statistique des données observées.

Pour chaque métrique, les statistiques suivantes sont affichées :

Données observées

• Valeur totale de la métrique suivie (nombre d'utilisateurs fidélisés, nombre d'utilisateurs ayant rencontré un plantage, revenus totaux)
• Taux spécifique à la métrique (taux de fidélisation, taux de conversion, revenu par utilisateur)
• Différence en pourcentage (impact) entre la variante et la référence

Données d'inférence

• IC à 95 % (différence de moyennes) affiche un intervalle qui contient la valeur "réelle" de la métrique suivie avec un niveau de confiance de 95 %. Par exemple, si les résultats de votre test indiquent un intervalle de confiance à 95 % pour le revenu total estimé entre 5 $et 10 $, il y a 95 % de chances que la véritable différence de moyenne se situe entre 5 $et 10 $. Si la plage de l'intervalle de confiance inclut 0, cela signifie qu'aucune différence statistiquement significative n'a été détectée entre la variante et la référence.

  Les valeurs de l'intervalle de confiance s'affichent dans le format correspondant à la métrique suivie. Par exemple, "Temps (en HH:MM:SS)" pour la fidélisation des utilisateurs, "USD" pour les revenus publicitaires par utilisateur et "pourcentage" pour le taux de conversion.

• Valeur p, qui représente la probabilité d'observer des données aussi extrêmes que les résultats obtenus lors du test, étant donné qu'il n'y a pas de véritable différence entre la variante et la référence. Plus la valeur p est faible, plus la confiance est élevée que les performances observées resteront vraies si nous répétons le test. Une valeur de 0,05 ou moins indique une différence significative et une faible probabilité que les résultats soient dus au hasard. Les valeurs p sont basées sur un test unilatéral, où la valeur de la variante est supérieure à celle de la référence. Firebase utilise un test t à variance inégale pour les variables continues (valeurs numériques, comme les revenus) et un test z des proportions pour les données de conversion (valeurs binaires, comme la fidélisation des utilisateurs, les utilisateurs n'ayant pas subi de plantage, les utilisateurs qui déclenchent un événement Google Analytics).

Les résultats du test fournissent des insights importants pour chaque variante, y compris :

• Différence (en pourcentage) entre chaque métrique du test et la métrique de référence, telle qu'elle a été mesurée directement (c'est-à-dire les données observées réelles)
• Probabilité que la différence observée entre la variante et la référence soit due au hasard (valeur p)
• Plage susceptible de contenir la "véritable" différence de performances entre la variante et la référence pour chaque métrique de test. Elle permet de comprendre les scénarios de performances "optimistes" et "pessimistes".

Interpréter les résultats des tests optimisés par Google Optimize

Les résultats Firebase A/B Testing des tests démarrés avant le 23 octobre 2023 étaient fournis par Google Optimize. Google Optimize utilisait l'inférence bayésienne pour générer des statistiques pertinentes à partir des données de vos tests.

Les résultats sont divisés en "données observées" et "données modélisées". Les données observées ont été calculées directement à partir des données d'analyse, et les données modélisées ont été obtenues en appliquant notre modèle bayésien aux données observées.

Pour chaque métrique, les statistiques suivantes sont affichées :

Données observées

• Valeur totale (somme de la métrique pour tous les utilisateurs de la variante)
• Valeur moyenne (valeur moyenne de la métrique pour les utilisateurs de la variante)
• Différence par rapport à la valeur de référence (%)

Données modélisées

• Probabilité de surpasser la référence : probabilité que la métrique soit plus élevée pour cette variante que pour la référence
• Différence en pourcentage par rapport à la référence : basée sur les estimations médianes du modèle pour la métrique de la variante et de la référence
• Plages de métriques : plages dans lesquelles la valeur de la métrique est la plus susceptible de se trouver, avec une certitude de 50 % et de 95 %

Dans l'ensemble, les résultats des tests nous fournissent trois insights importants pour chaque variante :

1. Différence (en pourcentage) entre chaque métrique du test et la métrique de référence, telle qu'elle est mesurée directement (c'est-à-dire les données observées réelles)
2. Probabilité que chaque métrique de test soit supérieure à la référence / la meilleure métrique globale, en fonction de l'inférence bayésienne (probabilité d'être meilleure / la meilleure, respectivement)
3. Plages plausibles pour chaque métrique de test basées sur l'inférence bayésienne : scénarios "meilleur cas" et "pire cas" (intervalles crédibles)

Détermination des régions principales

Pour les tests utilisant l'inférence fréquentiste, Firebase indique qu'une variante est optimale s'il existe une différence pertinente d'un point de vue statistique entre ses performances et celles de la référence pour la métrique d'objectif. Si plusieurs variantes répondent à ce critère, celle ayant la valeur P la plus faible sera choisie.

Pour les tests qui utilisaient Google Optimize, Firebase indiquait qu'une variante était "clairement gagnante" si elle avait plus de 95 % de chances d'être meilleure que la variante de référence pour la métrique principale. Si plusieurs variantes répondaient aux critères de "variante optimale", seule la variante la plus performante dans l'ensemble était désignée comme "variante optimale".

Étant donné que seul l'objectif principal est utilisé pour déterminer la variante optimale, vous devez tenir compte de tous les facteurs applicables et examiner les résultats des métriques secondaires avant de décider de déployer ou non une variante optimale. Vous pouvez tenir compte du potentiel de hausse attendu en cas de modification, du risque de baisse (comme la limite inférieure de l'intervalle de confiance pour l'amélioration) et de l'impact sur les métriques autres que l'objectif principal.

Par exemple, si votre métrique principale est "Utilisateurs n'ayant pas subi de plantage" et que la variante A est clairement en tête par rapport à la référence, mais que les métriques de fidélisation des utilisateurs de la variante A sont inférieures à celles de la référence, vous pouvez effectuer des recherches plus approfondies avant de déployer la variante A plus largement.

Vous pouvez déployer n'importe quelle variante, et pas seulement une variante optimale, en fonction de votre évaluation globale des performances pour les métriques principales et secondaires.

Durée des tests

Firebase recommande de continuer à exécuter un test jusqu'à ce que les conditions suivantes soient remplies :

1. Le test a accumulé suffisamment de données pour fournir un résultat utile. Les données de test et les résultats sont mis à jour une fois par jour. Vous pouvez consulter un calculateur de taille d'échantillon en ligne pour évaluer la taille d'échantillon recommandée pour votre test.
2. Le test a duré suffisamment longtemps pour garantir un échantillon représentatif de vos utilisateurs et mesurer les performances à long terme. La durée d'exécution minimale recommandée pour un test Remote Config standard est de deux semaines.

Les données de test sont traitées pendant 90 jours maximum après le début du test. Au bout de 90 jours, le test est automatiquement arrêté. Les résultats des tests ne sont plus mis à jour dans la console Firebase et le test cesse d'envoyer des valeurs de paramètres spécifiques. À ce stade, les clients commencent à récupérer les valeurs des paramètres en fonction des conditions définies dans le modèle Remote Config. Les données historiques des tests sont conservées jusqu'à ce que vous supprimiez le test.

Schéma BigQuery

En plus d'afficher les données des tests A/B Testing dans la console Firebase, vous pouvez les inspecter et les analyser dans BigQuery. Bien que A/B Testing ne dispose pas d'une table BigQuery distincte, les appartenances aux tests et aux variantes sont stockées dans chaque événement Google Analytics des tables d'événements Analytics.

Les propriétés utilisateur qui contiennent des informations sur les tests sont au format userProperty.key like "firebase_exp_%" ou userProperty.key = "firebase_exp_01", où 01 correspond à l'ID du test et userProperty.value.string_value contient l'index (basé sur zéro) de la variante du test.

Vous pouvez utiliser ces propriétés utilisateur d'expérimentation pour extraire les données d'expérimentation. Vous pouvez ainsi segmenter les résultats de vos tests de différentes manières et vérifier indépendamment les résultats de A/B Testing.

Pour commencer, effectuez les opérations suivantes décrites dans ce guide :

1. Activez l'exportation BigQuery pour Google Analytics dans la console Firebase.
2. Accéder aux données A/B Testing à l'aide de BigQuery
3. Explorer des exemples de requêtes

Activer l'exportation BigQuery pour Google Analytics dans la console Firebase

Si vous disposez du forfait Spark, vous pouvez utiliser le bac à sable BigQuery pour accéder à BigQuery sans frais, sous réserve des limites du bac à sable. Pour en savoir plus, consultez Tarifs et bac à sable BigQuery.

Tout d'abord, assurez-vous d'exporter vos données Analytics vers BigQuery :

1. Ouvrez l'onglet Intégrations, accessible via > Paramètres du projet dans la console Firebase.
2. Si vous utilisez déjà BigQuery avec d'autres services Firebase, cliquez sur Gérer. Sinon, cliquez sur Associer.
3. Consultez À propos de l'association de Firebase à BigQuery, puis cliquez sur Suivant.
4. Dans la section Configurer l'intégration, activez le bouton à bascule Google Analytics.

5. Sélectionnez une région et choisissez les paramètres d'exportation.

   Remarque : Pour en savoir plus sur Google Analytics pour les paramètres Firebase, consultez Collecte de données.

6. Cliquez sur Associer à BigQuery.

Selon la façon dont vous avez choisi d'exporter les données, il peut s'écouler jusqu'à un jour avant que les tables ne soient disponibles. Pour en savoir plus sur l'exportation des données de projet vers BigQuery, consultez Exporter les données de projet vers BigQuery.

Accéder aux données A/B Testing dans BigQuery

Avant d'interroger les données d'un test spécifique, vous devez obtenir tout ou partie des éléments suivants à utiliser dans votre requête :

• ID du test : vous pouvez l'obtenir à partir de l'URL de la page Présentation du test. Par exemple, si votre URL ressemble à https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25, l'ID de l'expérience est 25.
• ID de propriété Google Analytics : il s'agit de l'ID de propriété Google Analytics à neuf chiffres. Vous trouverez cette information dans Google Analytics. Elle apparaît également dans BigQuery lorsque vous développez le nom de votre projet pour afficher le nom de votre table d'événements Google Analytics (project_name.analytics_000000000.events).
• Date de l'expérience : pour composer une requête plus rapide et plus efficace, il est recommandé de limiter vos requêtes aux partitions de table d'événements quotidiens Google Analytics qui contiennent vos données d'expérience (tables identifiées avec le suffixe YYYYMMDD). Par exemple, si votre test s'est déroulé du 2 février 2024 au 2 mai 2024, vous devez spécifier _TABLE_SUFFIX between '20240202' AND '20240502'. Pour obtenir un exemple, consultez Sélectionner les valeurs d'un test spécifique.
• Noms d'événements : ils correspondent généralement aux métriques d'objectif que vous avez configurées dans le test. Par exemple, les événements in_app_purchase, ad_impression ou user_retention.

Conseil : Si vous disposez du forfait Blaze, Firebase peut générer un exemple de requête pour extraire le nom du test, la variante, le nom de l'événement et le nombre d'événements pour le test que vous sélectionnez. Pour en savoir plus, consultez Interroger les données de test à l'aide de la requête générée automatiquement par la console Firebase

.

Une fois que vous avez collecté les informations nécessaires pour générer votre requête :

1. Ouvrez BigQuery dans la console Google Cloud.
2. Sélectionnez votre projet, puis Créer une requête SQL.
3. Ajoutez votre requête. Pour obtenir des exemples de requêtes à exécuter, consultez Explorer des exemples de requêtes.
4. Cliquez sur Exécuter.

Conseil : Bien que ces étapes décrivent l'utilisation de la console Google Cloud, vous pouvez également utiliser la CLI ou les bibliothèques clientes pour interroger BigQuery. Pour en savoir plus, consultez la documentation BigQuery.

Interroger les données de test à l'aide de la requête générée automatiquement dans la console Firebase

Si vous utilisez le forfait Blaze, la page Présentation des tests fournit un exemple de requête qui renvoie le nom du test, les variantes, les noms d'événements et le nombre d'événements pour le test que vous consultez.

Pour obtenir et exécuter la requête générée automatiquement :

1. Dans la console Firebase, ouvrez A/B Testing et sélectionnez le test A/B Testing pour lequel vous souhaitez exécuter une requête afin d'ouvrir la page Vue d'ensemble du test.
2. Dans le menu "Options", sous Intégration BigQuery, sélectionnez Interroger les données de test. Votre projet s'ouvre dans BigQuery au sein de la console Google Cloud et fournit une requête de base que vous pouvez utiliser pour interroger les données de votre test.

L'exemple suivant montre une requête générée pour un test comportant trois variantes (y compris la référence) nommé "Test d'accueil hivernal". Elle renvoie le nom du test actif, le nom de la variante, l'événement unique et le nombre d'événements pour chaque événement. Notez que le générateur de requêtes ne spécifie pas le nom de votre projet dans le nom de la table, car il s'ouvre directement dans votre projet.

  /*
    This query is auto-generated by Firebase A/B Testing for your
    experiment "Winter welcome experiment".
    It demonstrates how you can get event counts for all Analytics
    events logged by each variant of this experiment's population.
  */
  SELECT
    'Winter welcome experiment' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'Welcome message (1)'
      WHEN '2' THEN 'Welcome message (2)'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_000000000.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN '20240202' AND '20240502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

Pour obtenir d'autres exemples de requêtes, consultez Explorer des exemples de requêtes.

Explorer des exemples de requêtes

Les sections suivantes fournissent des exemples de requêtes que vous pouvez utiliser pour extraire les données de test A/B Testing à partir des tables d'événements Google Analytics.

Extraire les valeurs d'écart type des achats et des tests de tous les tests

Vous pouvez utiliser les données des résultats de test pour vérifier indépendamment les résultats de Firebase A/B Testing. L'instruction SQL BigQuery suivante extrait les variantes de test, le nombre d'utilisateurs uniques dans chaque variante et la somme des revenus totaux des événements in_app_purchase et ecommerce_purchase, ainsi que les écarts types pour tous les tests au cours de la période spécifiée comme dates de début et de fin _TABLE_SUFFIX. Vous pouvez utiliser les données obtenues à partir de cette requête avec un générateur de signification statistique pour les tests t unilatéraux afin de vérifier que les résultats fournis par Firebase correspondent à votre propre analyse.

Pour en savoir plus sur la façon dont A/B Testing calcule l'inférence, consultez Interpréter les résultats des tests.

  /*
    This query returns all experiment variants, number of unique users,
    the average USD spent per user, and the standard deviation for all
    experiments within the date range specified for _TABLE_SUFFIX.
  */
  SELECT
    experimentNumber,
    experimentVariant,
    COUNT(*) AS unique_users,
    AVG(usd_value) AS usd_value_per_user,
    STDDEV(usd_value) AS std_dev
  FROM
    (
      SELECT
        userProperty.key AS experimentNumber,
        userProperty.value.string_value AS experimentVariant,
        user_pseudo_id,
        SUM(
          CASE
            WHEN event_name IN ('in_app_purchase', 'ecommerce_purchase')
              THEN event_value_in_usd
            ELSE 0
            END) AS usd_value
      FROM `PROJECT_NAME.analytics_ANALYTICS_ID.events_*`
      CROSS JOIN UNNEST(user_properties) AS userProperty
      WHERE
        userProperty.key LIKE 'firebase_exp_%'
        AND event_name IN ('in_app_purchase', 'ecommerce_purchase')
        AND (_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYMMDD')
      GROUP BY 1, 2, 3
    )
  GROUP BY 1, 2
  ORDER BY 1, 2;

Sélectionner les valeurs d'un test spécifique

L'exemple de requête suivant montre comment obtenir des données pour un test spécifique dans BigQuery. Cet exemple de requête renvoie le nom de l'expérience, les noms des variantes (y compris la variante de référence), les noms des événements et le nombre d'événements.

  SELECT
    'EXPERIMENT_NAME' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'VARIANT_1_NAME'
      WHEN '2' THEN 'VARIANT_2_NAME'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_ANALYTICS_PROPERTY.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN 'YYYMMDD' AND 'YYYMMDD')
    AND userProperty.key = 'firebase_exp_EXPERIMENT_NUMBER'
  GROUP BY
    experimentVariant, eventName

Limites

A/B Testing est limité à 300 tests au total, 24 tests en cours et 24 brouillons de tests. Ces limites sont partagées avec les déploiements Remote Config. Par exemple, si vous avez deux déploiements et trois tests en cours d'exécution, vous pouvez ajouter jusqu'à 19 déploiements ou tests.

• Si vous atteignez la limite de 300 tests au total ou de 24 brouillons de tests, vous devez supprimer un test existant avant d'en créer un autre.

• Si vous atteignez la limite de 24 tests et déploiements en cours, vous devez arrêter un test ou un déploiement en cours avant d'en lancer un nouveau.

Un test peut comporter jusqu'à huit variantes (y compris la référence) et jusqu'à 25 paramètres pour chaque variante. Un test peut avoir une taille maximale d'environ 200 Kio. Cela inclut les noms et les paramètres des variantes, ainsi que d'autres métadonnées de configuration.