À 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 des tests A/B Firebase.

Taille de l'échantillon

L'inférence des tests Firebase A/B ne nécessite pas l'identification d'une taille d'échantillon minimale avant de commencer une expérience. En général, vous devez choisir le niveau d'exposition d'expérience le plus élevé avec lequel vous vous sentez à l'aise. Des échantillons de plus grande taille augmentent les chances de trouver un résultat statistiquement significatif, en particulier lorsque les différences de performances entre les variantes sont faibles. Vous trouverez peut-être également utile de consulter un calculateur de taille d’échantillon en ligne pour trouver la taille d’échantillon recommandée en fonction des caractéristiques de votre expérience.

Modifier les tests

Vous pouvez modifier les paramètres sélectionnés des expériences en cours, notamment :

• Nom de l'expérience
• 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 vos modifications, puis cliquez sur Publier .

Notez que la modification du comportement de l'application au cours d'une expérience en cours peut avoir un impact sur les résultats.

Logique d'affectation des variantes de Remote Config

Les utilisateurs qui correspondent à toutes les conditions de ciblage des expériences (y compris la condition de pourcentage d'exposition) se voient attribuer des variantes d'expérience en fonction des pondérations des variantes et d'un hachage de l'ID d'expérience et de l'ID d'installation Firebase de l'utilisateur.

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

• Lorsque vous créez une nouvelle audience, cela peut prendre 24 à 48 heures pour accumuler de nouveaux utilisateurs.
• Les nouveaux utilisateurs sont généralement inscrits dans des audiences éligibles 24 à 48 heures après qu'ils soient devenus éligibles.

Pour un ciblage urgent, envisagez d'utiliser les propriétés utilisateur de Google Analytics ou les 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 des paramètres du test tant que le test reste actif, même si ses propriétés d'utilisateur changent et s'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 de l'expérience n'a aucun impact sur les paramètres d'expérience 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 que les paramètres d'expérience ont été récupérés et activés, mais avant que les paramètres d'expérience n'aient été utilisés pour modifier le comportement de l'application.

Variantes de poids

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

Interpréter les résultats des tests

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 se produire uniquement en raison du hasard. Cette probabilité est représentée par une valeur de probabilité , ou valeur p . La valeur p est la probabilité que la différence de performance entre deux variantes ait pu se produire en raison du hasard, mesurée par une valeur comprise entre 0 et 1. Les tests A/B utilisent un niveau de signification de 0,05 de sorte que :

• Une valeur p inférieure à 0,05 indique une différence statistiquement significative entre les variantes, ce qui signifie qu’il est peu probable qu’elle se soit produite par 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 et l'heure de la dernière mise à jour apparaît en haut de la page des résultats du test.

Le graphique des résultats de l'expérience 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, il affiche les revenus observés par utilisateur et si vous suivez les utilisateurs sans crash, il suit le pourcentage d'utilisateurs qui n'ont pas rencontré de crash. Ces données sont cumulées depuis le début de l'expérimentation.

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 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 retenus, nombre d'utilisateurs en panne, revenus totaux)
• Taux spécifique aux métriques (taux de rétention, taux de conversion, revenus par utilisateur)
• Pourcentage de différence (lift) entre la variante et la ligne de base

Données d'inférence

• L'IC à 95 % (différence de moyenne) affiche un intervalle qui contient la « vraie » valeur de la métrique suivie avec un niveau de confiance de 95 %. Par exemple, si votre test aboutit à un IC de 95 % pour un revenu total estimé compris 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 d’IC inclut 0, aucune différence statistiquement significative entre la variante et la ligne de base n’a été détectée.

  Les valeurs de l'intervalle de confiance apparaissent dans le format qui correspond à 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 ligne de base ; en d’autres termes, toute différence observée est probablement due au hasard. Plus la valeur p est faible, plus la confiance dans le maintien des performances observées dans le futur 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 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 crash, les utilisateurs qui déclenchent un événement Google Analytics).

Les résultats de l’expérience fournissent des informations importantes pour chaque variante de l’expérience, notamment :

• Dans quelle mesure chaque mesure de l'expérience est-elle supérieure ou inférieure à la référence, telle que mesurée directement (c'est-à-dire les données réelles observées)
• La probabilité que la différence observée entre la variante et la ligne de base ait pu se produire en raison du hasard (valeur p)
• Une plage susceptible de contenir la « vraie » différence de performances entre la variante et la référence pour chaque métrique d'expérience ---un moyen de comprendre les scénarios de performances du "meilleur des cas" et du "pire des cas".

Interpréter les résultats des expériences optimisées par Google Optimize

Les résultats des tests A/B Firebase pour les expériences commencées avant le 23 octobre 2023 ont été optimisés par Google Optimize. Google Optimize a utilisé l'inférence bayésienne pour générer des statistiques pertinentes à partir de vos données de 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 analytiques et les données modélisées ont été dérivées de l'application de 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 des métriques pour tous les utilisateurs de la variante)
• Valeur moyenne (valeur moyenne de la métrique pour les utilisateurs de la variante)
• % de différence par rapport à la ligne de base

Données modélisées

• Probabilité de dépasser la référence : quelle est la probabilité que la métrique soit plus élevée pour cette variante par rapport à la référence
• Pourcentage de différence par rapport à la référence : basé sur les estimations médianes du modèle de la métrique pour la variante et la référence
• Plages de métriques : les plages dans lesquelles la valeur de la métrique est la plus susceptible d'être trouvée, avec une certitude de 50 % et 95 %

Dans l’ensemble, les résultats de l’expérience nous donnent trois informations importantes pour chaque variante de l’expérience :

1. Dans quelle mesure chaque mesure expérimentale est-elle supérieure ou inférieure à la référence, telle que mesurée directement (c'est-à-dire les données réellement observées)
2. Quelle est la probabilité que chaque mesure d'expérience soit supérieure à la référence/meilleure globale, sur la base de l'inférence bayésienne (probabilité d'être meilleure/meilleure respectivement)
3. Les plages plausibles pour chaque métrique d'expérience basée sur l'inférence bayésienne – scénarios du « meilleur des cas » et du « pire des cas » (intervalles crédibles)

Détermination du leader

Pour les expériences utilisant l'inférence Frequentist , 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 de l'objectif. Si plusieurs variantes répondent à ce critère, la variante avec la valeur p la plus basse est choisie.

Pour les expériences utilisant Google Optimize , Firebase a déclaré qu'une variante est un « leader incontesté » si elle a plus de 95 % de chances d'être meilleure que la variante de base sur la métrique principale. Si plusieurs variantes répondaient aux critères de « leader incontesté », seule la variante la plus performante dans l’ensemble était qualifiée de « leader incontesté ».

Étant donné que la détermination du leader est basée uniquement sur l'objectif principal, vous devez prendre en compte tous les facteurs pertinents et examiner les résultats des mesures secondaires avant de décider de déployer ou non une variante leader. Vous souhaiterez peut-être prendre en compte les avantages attendus du changement, le risque de baisse (tel que l'extrémité inférieure de l'intervalle de confiance pour l'amélioration) et l'impact sur les mesures autres que l'objectif principal.

Par exemple, si votre métrique principale est celle des utilisateurs sans crash et que la variante A est clairement leader par rapport à la référence, mais que les métriques de fidélisation des utilisateurs de la variante A sont à la traîne en matière de rétention des utilisateurs de référence, vous souhaiterez peut-être approfondir vos recherches avant de déployer la variante A plus largement.

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

Durée du test

Firebase recommande de poursuivre l'exécution d'un test jusqu'à ce que les conditions suivantes soient remplies :

1. L'expérience a accumulé suffisamment de données pour fournir un résultat utile. Les expériences et les données de résultats sont mises à jour une fois par jour. Vous souhaiterez peut-être consulter un calculateur de taille d’échantillon en ligne pour évaluer la taille d’échantillon recommandée pour votre expérience.
2. L'expérience a duré suffisamment longtemps pour garantir un échantillon représentatif de vos utilisateurs et mesurer les performances à long terme. Deux semaines est la durée d'exécution minimale recommandée pour une expérience Remote Config typique.

Les données de l'expérience sont traitées pendant 90 jours maximum après le début de l'expérience. Après 90 jours, l'expérience est automatiquement arrêtée. Les résultats du test ne sont plus mis à jour dans la console Firebase et le test cesse d'envoyer les valeurs des 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 modèle Remote Config. 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 tests A/B dans la console Firebase, vous pouvez inspecter et analyser les données des tests dans BigQuery. Bien que les tests A/B ne disposent pas d'une table BigQuery distincte, les adhésions aux expériences et aux variantes sont stockées sur chaque événement Google Analytics dans les tables d'événements Analytics.

Les propriétés utilisateur qui contiennent des informations sur l'expérience sont de la forme userProperty.key like "firebase_exp_%" ou userProperty.key = "firebase_exp_01" où 01 est l'ID de l'expérience et userProperty.value.string_value contient l'index (de base zéro) de l'expérience. variante d'expérimentation.

Vous pouvez utiliser ces propriétés utilisateur d'expérience pour extraire des données d'expérience. Cela vous donne le pouvoir de découper les résultats de vos tests de différentes manières et de vérifier indépendamment les résultats des tests A/B.

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 de tests A/B à 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 d'un forfait Spark, vous pouvez utiliser le bac à sable BigQuery pour accéder à BigQuery sans frais, sous réserve des limites du bac à sable . Consultez Tarifs et sandbox BigQuery pour plus d'informations.

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 utilisant > 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 Lien .
3. Consultez À propos de la liaison de Firebase à BigQuery , puis cliquez sur Suivant .
4. Dans la section Configurer l'intégration , activez le bouton Google Analytics .

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

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

6. Cliquez sur Lien vers BigQuery .

Selon la manière dont vous avez choisi d'exporter les données, cela peut prendre jusqu'à un jour pour que les tableaux soient disponibles. Pour plus d'informations sur l'exportation de données de projet vers BigQuery, consultez Exporter des données de projet vers BigQuery .

Accéder aux données de tests A/B dans BigQuery

Avant de rechercher des données pour une expérience spécifique, vous souhaiterez obtenir tout ou partie des éléments suivants à utiliser dans votre requête :

• ID de l'expérience : vous pouvez l'obtenir à partir de l'URL de la page de présentation de l'expérience . 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 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 rédiger une requête plus rapide et plus efficace, il est recommandé de limiter vos requêtes aux partitions de la table des événements quotidiens de Google Analytics qui contiennent vos données de test (tables identifiées par le suffixe YYYYMMDD ). Ainsi, 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'une expérience spécifique .
• Noms d'événements : ils correspondent généralement aux métriques d'objectif que vous avez configurées dans l'expérience. Par exemple, les événements in_app_purchase , ad_impression ou user_retention .

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

Après avoir rassemblé les informations dont vous avez besoin pour générer votre requête :

1. Ouvrez BigQuery dans la console Google Cloud.
2. Sélectionnez votre projet, puis sélectionnez 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 du test à l'aide de la requête générée automatiquement par la console Firebase

Si vous utilisez le plan Blaze, la page de présentation de l'expérience fournit un exemple de requête qui renvoie le nom de l'expérience, les variantes, les noms d'événements et le nombre d'événements pour l'expérience que vous consultez.

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

1. Depuis la console Firebase, ouvrez A/B Testing et sélectionnez l'expérience de test A/B que vous souhaitez interroger pour ouvrir l' aperçu de l'expérience .
2. Dans le menu Options, sous Intégration BigQuery , sélectionnez Interroger les données du test . Cela ouvre votre projet dans BigQuery dans la console Google Cloud Console 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 ligne de base) nommée « Expérience de bienvenue en hiver ». Il renvoie le nom de l'expérience active, 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 des exemples de requêtes supplémentaires, passez à 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 des expériences de test A/B des tables d'événements Google Analytics.

Extraire les valeurs d'écart type d'achat et d'expérimentation de toutes les expériences

Vous pouvez utiliser les données des résultats des tests pour vérifier indépendamment les résultats des tests A/B Firebase. L'instruction BigQuery SQL suivante extrait les variantes de test, le nombre d'utilisateurs uniques dans chaque variante, additionne 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 plage de temps spécifiée comme dates de début et de fin _TABLE_SUFFIX . Vous pouvez utiliser les données que vous obtenez à 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 plus d'informations sur la manière 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électionnez les valeurs d'un test spécifique

L'exemple de requête suivant illustre comment obtenir des données pour une expérience spécifique dans BigQuery. Cet exemple de requête renvoie le nom de l'expérience, les noms des variantes (y compris la ligne de base), 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

Les tests A/B sont limités à 300 expériences au total, 24 expériences en cours et 24 projets d'expériences.

• Si vous atteignez la limite de 300 expériences au total ou la limite de 24 projets d'expériences, vous devez supprimer une expérience existante avant d'en créer une nouvelle.

• Si vous atteignez la limite de 24 expériences en cours, vous devez arrêter une expérience en cours avant d'en démarrer une nouvelle.

Une expérience peut comporter un maximum de 8 variantes (y compris la référence) et jusqu'à 25 paramètres pour chaque variante. Une expérience peut avoir une taille allant jusqu'à environ 200 Ko. Cela inclut les noms de variantes, les paramètres de variantes et d'autres métadonnées de configuration.