À propos des tests A/B Firebase

Pour vous aider à optimiser 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

Firebase A/B Testing inférence ne nécessite pas l'identification d'une taille d'échantillon minimale avant de démarrer un test. En général, vous devez choisir le niveau d'exposition au test 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, 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 tests

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

  • 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 le test 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 correspondent à toutes les conditions de ciblage du test (y compris la condition d'exposition en pourcentage ) sont attribués aux variantes du test en fonction de la pondération des variantes et d'un hachage de l'ID du test et de l'ID d'installation de l'utilisateur Firebase.

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

  • 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 inscrits dans les audiences éligibles 24 à 48 heures après qu'ils sont devenus éligibles.

Pour le ciblage urgent, 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 permanente à sa variante de test et reçoit les valeurs des paramètres 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 du test limitent la mesure du test 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. Par conséquent, il est 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 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 d'un test, il est possible de modifier la pondération 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 se soient produits uniquement par hasard. Cette probabilité est représentée par une valeur de probabilité ou valeur p. La valeur p est la probabilité qu'une différence de performances aussi importante, voire plus importante, entre deux variantes se soit produite par hasard s'il n'y a en fait aucun effet, mesuré par une valeur comprise entre 0 et 1. A/B Testing utilise un niveau de signification de 0,05, de sorte que :

  • Une valeur p inférieure à 0,05 indique que si la différence réelle était nulle, il y a moins de 5 % de chances qu'une différence observée aussi extrême se produise de manière aléatoire. Étant donné que 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 du test sont actualisées une fois par jour, et la dernière heure de 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 comme métrique, il affiche les revenus observés par utilisateur. Si vous suivez les utilisateurs sans plantage, il suit le pourcentage d'utilisateurs qui n'ont pas rencontré de plantage. 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, 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 s'affichent :

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, revenus par utilisateur)
  • Différence en pourcentage (rehaussement) 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 IC à 95 % pour les revenus totaux estimés entre 5 et 10 $, il y a 95 % de chances que la différence réelle de moyennes se situe entre 5 et 10 $. Si la plage de l'IC inclut 0, aucune différence statistiquement significative entre la variante et la référence n'a été détectée.

    Les valeurs de l'intervalle de confiance s'affichent dans le format qui correspond à la métrique suivie. Par exemple, "Temps" (au format 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 dans le test, étant donné qu'il n'existe aucune différence réelle entre la variante et la référence. Plus la valeur p est faible, plus la confiance que les performances observées restent vraies si nous répétons le test est élevée. 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 à la valeur de référence. Firebase utilise un test t de variance inégale pour les variables continues (valeurs numériques, comme les revenus) et un test z de proportions pour les données de conversion (valeurs binaires, comme la fidélisation des utilisateurs, les utilisateurs sans plantage, les utilisateurs qui déclenchent un Google Analytics événement).

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

  • La différence (positive ou négative) entre chaque métrique du test et la référence, telle qu'elle est mesurée directement (c'est-à-dire les données observées réelles)
  • La probabilité que la différence observée entre la variante et la référence soit due au hasard (valeur p)
  • Une 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, ce qui permet de comprendre les scénarios de performances "optimaux" et "pessimistes"

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

Firebase A/B Testing résultats des tests A/B Firebase pour les tests démarrés avant le 23 octobre 2023 étaient optimisés par Google Optimize. Google Optimize utilisait l'inférence bayésienne pour générer des statistiques utiles à 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. 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 s'affichent :

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 par rapport à la valeur de référence (%) : basée sur les estimations médianes du modèle de la métrique pour la variante et la référence
  • Plages de métriques : plages où la valeur de la métrique est la plus susceptible d'être trouvée, avec une certitude de 50 % et de 95 %

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

  1. La différence (positive ou négative) entre chaque métrique du test et la référence, telle qu'elle est mesurée directement (c'est-à-dire les données observées réelles)
  2. La probabilité que chaque métrique du test soit supérieure à la référence / meilleure dans l'ensemble, en fonction de l'inférence bayésienne (probabilité d'être meilleure / meilleure respectivement)
  3. Les plages plausibles pour chaque métrique du test en fonction de l'inférence bayésienne : scénarios "optimaux" et "pessimistes" (intervalles crédibles)

Détermination de la variante optimale

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 optimale" 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 "clairement optimale", seule la variante la plus performante dans l'ensemble était étiquetée comme "clairement 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 de l'avantage attendu de la modification, du risque de baisse (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 sans plantage" et que la variante A est clairement optimale 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 supplémentaires 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 tests et les données de 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 à plus long terme. La durée d'exécution minimale recommandée pour un test Remote Config type est de deux semaines.

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

Schéma BigQuery

En plus d'afficher les données des expériences A/B Testing dans la console Firebase, vous pouvez inspecter et analyser les données des expériences 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 au sein des 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'index (basé sur zéro) de la variante du test.

Vous pouvez utiliser ces propriétés utilisateur du test pour extraire les données du test. Vous pouvez ainsi segmenter les résultats de votre test de nombreuses manières différentes 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. Activer 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'BigQuery exportation pour Google Analytics dans la console Firebase

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

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

  1. Ouvrez l'onglet Intégrations, auquel vous pouvez accéder en sélectionnant > 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 Google Analytics bouton.

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

  6. Cliquez sur Associer à BigQuery.

Selon la façon dont vous avez choisi d'exporter les données, les tables peuvent mettre jusqu'à un jour à être disponibles. Pour en savoir plus sur l'exportation des données de projet vers BigQuery, consultez Exporter des 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 Aperçu du test. Par exemple, si votre URL ressemble à https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25, l'ID du test est 25.
  • Google Analytics ID de propriété : il s'agit de votre ID de propriété à neuf chiffres Google Analytics. 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 Google Analytics table d'événements (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énementsGoogle Analyticsquotidiens qui contiennent les données de votre test (tables identifiées par un suffixe YYYYMMDD). Ainsi, si votre test s'est déroulé du 2 février 2024 au 2 mai 2024, vous spécifiez un _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.

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

  1. Ouvrez BigQuery dans la Google Cloud console.
  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.

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

Si vous disposez du forfait Blaze, la page Aperçu du test 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 Firebase console, ouvrez A/B Testing et sélectionnez le test A/B que vous souhaitez interroger pour ouvrir la page Aperçu du test.A/B Testing
  2. Dans le menu "Options", sous BigQuery intégration, sélectionnez Interroger les données du test. Votre projet s'ouvre alors dans BigQuery dans la console Google Cloud 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 de bienvenue en hiver". Il 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 A/B Testing les données des expériences des tables d'événements Google Analytics.

Extraire les valeurs d'achat et d'écart type du test de tous les tests

Vous pouvez utiliser les données des résultats du test pour vérifier indépendamment Firebase A/B Testing les résultats. L'instruction SQL BigQuery suivante extrait les variantes du test, le nombre d'utilisateurs uniques dans chaque variante, et additionne les revenus totaux des événements in_app_purchase et ecommerce_purchase, ainsi que les écarts types pour tous les tests dans la plage de dates 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 pertinence 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 du test.

  /*
    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 illustre 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 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 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 de tests, vous devez supprimer un test existant avant d'en créer un.

  • 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 démarrer un autre.

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 des variantes, les paramètres des variantes et d'autres métadonnées de configuration.