À propos des tests A/B Firebase

Pour vous aider à maximiser la pertinence et l'utilité des résultats de vos tests, 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 d'identifier une taille d'échantillon minimale avant de commencer un test. En règle générale, vous devez choisir le niveau d'exposition au test le plus élevé qui vous convient. Des échantillons de plus grande taille augmentent les chances d'obtenir un résultat statistiquement pertinent, en particulier 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 expériences

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 des 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 modifier le comportement de l'application pendant l'exécution d'un test peut avoir un impact sur les résultats.

Logique d'attribution des variantes Remote Config

Les utilisateurs qui correspondent à toutes les conditions de ciblage du test (y compris la condition de pourcentage d'exposition) sont affectés aux variantes de 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.

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

  • Lorsque vous créez une audience, un délai de 24 à 48 heures peut être nécessaire pour accumuler de nouveaux utilisateurs.
  • Les nouveaux utilisateurs sont généralement inscrits aux audiences éligibles 24 à 48 heures après avoir rempli les critères d'éligibilité.

Pour le ciblage basé sur le 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 participé à un test, il est attribué de manière persistante à sa variante de test et reçoit les valeurs de paramètre du test tant qu'il reste actif, même si ses propriétés utilisateur changent et qu'il ne remplit plus les critères de ciblage du test.

Événements d'activation

Les événements d'activation du test limitent les mesures du test aux utilisateurs de l'application qui les déclenchent. 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. Par conséquent, il est important de choisir un événement d'activation qui se produit après l'extraction et l'activation des paramètres du test, mais avant que les paramètres du test ne soient utilisés pour modifier le comportement de l'application.

Pondération des variantes

Lors de la création du test, vous pouvez modifier les pondérations par défaut des variantes pour placer un pourcentage plus élevé d'utilisateurs du 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 aient pu être uniquement dus au hasard. Cette probabilité est représentée par une valeur de probabilité ou valeur p. La valeur p correspond à la probabilité que la différence de performances entre deux variantes puisse être due au hasard, mesurée par une valeur comprise entre 0 et 1. A/B Testing utilise un niveau de signification de 0,05 afin que :

  • Une valeur p inférieure à 0,05 indique une différence statistiquement pertinente entre les variantes, ce qui signifie qu'il est peu probable qu'elles soient le résultat du hasard.
  • Une valeur p supérieure à 0,05 indique que la différence entre les variantes n'est pas statistiquement significative.

Les données du test sont actualisées une fois par jour. L'heure de la dernière mise à jour 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 les revenus publicitaires par utilisateur en tant que métrique, elle affiche les revenus observés par utilisateur. Si vous suivez les utilisateurs sans plantage, elle suit le pourcentage d'utilisateurs qui n'ont pas rencontré de plantage. Ces données sont cumulées 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, et les données d'inférence fournissent des valeurs p et des intervalles de confiance pour vous aider à évaluer la pertinence 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 conservés, nombre d'utilisateurs ayant généré une erreur, revenus totaux)
  • Taux spécifique à une métrique (taux de fidélisation, taux de conversion, revenus par utilisateur)
  • Différence en pourcentage (impact) entre la variante et la référence

Données d'inférence

  • Intervalle de confiance à 95 % (différence de moyennes) affiche un intervalle contenant la valeur "vraie" de la métrique suivie avec une confiance de 95 %. Par exemple, si votre test génère un intervalle de confiance à 95 % pour les revenus totaux estimés 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'intégration continue inclut 0, aucune différence statistiquement pertinente entre la variante et la référence n'a été détectée.

    Les valeurs de l'intervalle de confiance s'affichent au 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é qu'il n'y ait pas de véritable différence entre la variante et la référence. En d'autres termes, toute différence observée est probablement due au hasard. Plus la valeur p est faible, plus la confiance est élevée quant à la validité des performances observées à l'avenir. Une valeur égale ou inférieure à 0,05 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 à extrémité unique, où la valeur de la variante est supérieure à la valeur de 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 rétention des utilisateurs, les utilisateurs n'ayant pas subi de plantage et les utilisateurs qui déclenchent un événement Google Analytics).

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

  • Écart entre chaque métrique du test et la référence, mesuré 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 ait été due au hasard (valeur p)
  • Plage susceptible de contenir la différence de performances "réelle" entre la variante et la référence pour chaque métrique du test. Il s'agit d'un moyen de comprendre les scénarios de performances "meilleur cas" et "pire cas".

Interpréter les résultats des tests 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 a utilisé l'inférence bayésienne pour générer des statistiques intéressantes à partir des données de votre test.

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 supérieure pour cette variante par rapport à la référence
  • Différence par rapport à la valeur de référence (en pourcentage) : basée sur les estimations du modèle médian de la métrique pour la variante et la valeur de référence
  • Plage de métrique : plage dans laquelle la valeur de la métrique est la plus susceptible d'être trouvée, avec une probabilité de 50 % et 95 %

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

  1. Écart entre chaque métrique du test et la référence, mesuré directement (c'est-à-dire les données observées réelles)
  2. Probabilité que chaque métrique du test soit supérieure à la référence/meilleure valeur globale, d'après l'inférence bayésienne (probabilité d'être meilleure/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 leaders

Pour les tests utilisant l'inférence fréquentiste, Firebase déclare qu'une variante est en tête s'il existe une différence de performances statistiquement significative entre la variante et la référence sur la métrique d'objectif. Si plusieurs variantes répondent à ce critère, celle ayant la valeur p la plus faible est choisie.

Pour les tests qui ont utilisé Google Optimize, Firebase a déclaré qu'une variante était "leader incontesté" 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 "leader clair", seule la variante la plus performante dans l'ensemble était désignée comme "leader clair".

É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 de l'avantage attendu de la modification, du risque insatisfaisant (tel que 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 supérieure à la référence, mais que les métriques de fidélisation des utilisateurs de la variante A sont inférieures à la référence, vous pouvez approfondir votre analyse 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 collecté suffisamment de données pour fournir un résultat utile. Les données des tests et des résultats sont mises à 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 été exécuté suffisamment longtemps pour garantir un échantillon représentatif de vos utilisateurs et mesurer les performances à plus long terme. Deux semaines est la durée d'exécution minimale recommandée pour un test Remote Config standard.

Les données du 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 du test ne sont plus mis à jour dans la console Firebase, et le test cesse d'envoyer des valeurs de paramètres spécifiques au test. À ce stade, les clients commencent à extraire les valeurs des paramètres en fonction des conditions définies dans le modèle Remote Config. L'historique des données du test est conservé jusqu'à ce que vous le supprimiez.

Schéma BigQuery

En plus d'afficher les données des tests A/B Testing dans la console Firebase, vous pouvez inspecter et analyser les données des tests 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 dans les tables d'événements Analytics.

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

Vous pouvez utiliser ces propriétés utilisateur de test pour extraire les données du test. Vous pouvez ainsi diviser les résultats de votre test de différentes manières et vérifier indépendamment les résultats de A/B Testing.

Pour commencer, procédez comme suit, comme décrit 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 la section Tarifs et bac à sable BigQuery.

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

  1. Ouvrez l'onglet Integrations (Intégrations) auquel vous pouvez accéder en cliquant sur > Project settings (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 l'option Google Analytics.

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

  6. Cliquez sur Associer à BigQuery.

Selon la méthode choisie pour exporter les données, l'accès aux tableaux peut prendre jusqu'à une journée. 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 des données pour 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 test est 25.
  • ID de propriété Google Analytics : il s'agit de votre ID de propriété Google Analytics à 9 chiffres. Vous pouvez le trouver dans Google Analytics. Il 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 du test : 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 contenant vos données de test (tables identifiées par un suffixe YYYYMMDD). Par conséquent, si votre test s'est déroulé du 2 février 2024 au 2 mai 2024, vous devez spécifier un _TABLE_SUFFIX between '20240202' AND '20240502'. Pour obtenir un exemple, consultez Sélectionner les valeurs d'un test spécifique.
  • Noms des événements : ils correspondent généralement aux métriques d'objectif que vous avez configurées dans le test. Par exemple, des événements in_app_purchase, ad_impression ou user_retention.
.

Une fois que vous avez rassemblé 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 cliquez sur Créer une requête SQL.
  3. Ajoutez votre requête. Pour obtenir des exemples de requêtes à exécuter, consultez la section Explorer des exemples de requêtes.
  4. Cliquez sur Exécuter.

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

Si vous utilisez le forfait Blaze, la page Présentation du test fournit un exemple de requête qui renvoie le nom du test, les variantes, les noms des é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, puis sélectionnez le test A/B Testing que vous souhaitez interroger pour ouvrir la présentation du test.
  2. Dans le menu "Options", sous Intégration BigQuery, sélectionnez Interroger les données du 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 vos données de test.

L'exemple suivant montre une requête générée pour un test avec 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 la section 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 du test pour vérifier de manière indépendante les résultats Firebase A/B Testing. L'instruction SQL BigQuery suivante extrait les variantes d'expérience, le nombre d'utilisateurs uniques dans chaque variante, et somme les revenus totaux des événements in_app_purchase et ecommerce_purchase, ainsi que les écarts-types pour toutes les expériences au cours de la période spécifiée comme dates de début et de fin de l'_TABLE_SUFFIX. Vous pouvez utiliser les données que vous obtenez de cette requête avec un générateur de signification statistique pour les tests t à extrémité unique afin de vérifier que les résultats fournis par Firebase correspondent à votre propre analyse.

Pour en savoir plus sur le calcul de l'inférence par A/B Testing, consultez la section 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 du test, les noms des variantes (y compris la référence), les noms des événements et leur nombre.

  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 tests brouillons. Ces limites sont partagées avec les déploiements Remote Config. Par exemple, si vous avez deux déploiements en cours et trois tests en cours, vous pouvez avoir jusqu'à 19 déploiements ou tests supplémentaires.

  • Si vous atteignez la limite de 300 tests au total ou la limite de 24 brouillons, 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 autre.

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