Über Firebase A/B-Tests

Damit Sie die Relevanz und Nützlichkeit Ihrer Testergebnisse maximieren können, finden Sie auf dieser Seite detaillierte Informationen zur Funktionsweise von Firebase A/B Testing.

Probengröße

Für die Firebase A/B-Testing-Inferenz ist vor Beginn eines Experiments nicht die Festlegung einer Mindeststichprobengröße erforderlich. Im Allgemeinen sollten Sie die größte Experimentexpositionsstufe wählen, mit der Sie sich wohl fühlen. Größere Stichprobengrößen erhöhen die Chancen, ein statistisch signifikantes Ergebnis zu finden, insbesondere wenn die Leistungsunterschiede zwischen Varianten gering sind. Es kann auch hilfreich sein, einen Online-Stichprobengrößenrechner zu Rate zu ziehen, um die empfohlene Stichprobengröße basierend auf den Merkmalen Ihres Experiments zu ermitteln.

Experimente bearbeiten

Sie können ausgewählte Parameter laufender Experimente bearbeiten, darunter:

  • Experimentname
  • Beschreibung
  • Targeting-Bedingungen
  • Variantenwerte

So bearbeiten Sie ein Experiment:

  1. Öffnen Sie die Ergebnisseite für das Experiment, das Sie ändern möchten.
  2. Wählen Sie im Menü „Mehr die Option „Laufendes Experiment bearbeiten“ aus.
  3. Nehmen Sie Ihre Änderungen vor und klicken Sie dann auf „Veröffentlichen“ .

Beachten Sie, dass eine Änderung des Verhaltens der App während eines laufenden Experiments Auswirkungen auf die Ergebnisse haben kann.

Zuweisungslogik für Remote-Konfigurationsvarianten

Benutzer, die alle Experiment-Targeting-Bedingungen (einschließlich der Bedingung für die prozentuale Exposition) erfüllen, werden Experimentvarianten entsprechend der Variantengewichtung und einem Hash der Experiment-ID und der Firebase-Installations-ID des Benutzers zugewiesen.

Google Analytics-Zielgruppen unterliegen einer Latenz und sind nicht sofort verfügbar, wenn ein Nutzer zum ersten Mal die Zielgruppenkriterien erfüllt:

  • Wenn Sie eine neue Zielgruppe erstellen, kann es 24 bis 48 Stunden dauern, bis neue Benutzer gewonnen werden.
  • Neue Benutzer werden in der Regel 24 bis 48 Stunden nach ihrer Berechtigung in qualifizierte Zielgruppen aufgenommen.

Erwägen Sie für zeitkritisches Targeting die Verwendung von Google Analytics-Benutzereigenschaften oder integrierten Targeting-Optionen wie Land oder Region, Sprache und App-Version.

Sobald ein Benutzer einem Experiment beigetreten ist, wird er dauerhaft seiner Experimentvariante zugewiesen und erhält Parameterwerte aus dem Experiment, solange das Experiment aktiv bleibt, auch wenn sich seine Benutzereigenschaften ändern und er die Experiment-Targeting-Kriterien nicht mehr erfüllt.

Aktivierungsereignisse

Experimentaktivierungsereignisse beschränken die Experimentmessung auf App-Benutzer, die das Aktivierungsereignis auslösen. Das Aktivierungsereignis des Experiments hat keine Auswirkungen auf die Experimentparameter, die von der App abgerufen werden. Alle Benutzer, die die Experiment-Targeting-Kriterien erfüllen, erhalten Experimentparameter. Daher ist es wichtig, ein Aktivierungsereignis auszuwählen, das auftritt, nachdem die Experimentparameter abgerufen und aktiviert wurden, aber bevor die Experimentparameter zum Ändern des Verhaltens der App verwendet wurden.

Variantengewichte

Während der Experimenterstellung ist es möglich, die Standardvariantengewichtungen zu ändern, um einen größeren Prozentsatz der Experimentbenutzer einer Variante zuzuordnen.

Testergebnisse interpretieren

Firebase A/B Testing verwendet häufige Schlussfolgerungen , um Ihnen dabei zu helfen, die Wahrscheinlichkeit zu verstehen, dass Ihre Experimentergebnisse ausschließlich auf zufällige Zufälle zurückzuführen sind. Diese Wahrscheinlichkeit wird durch einen Wahrscheinlichkeitswert oder p-Wert dargestellt. Der p-Wert ist die Wahrscheinlichkeit, dass der Leistungsunterschied zwischen zwei Varianten zufällig aufgetreten sein könnte, gemessen durch einen Wert zwischen 0 und 1. A/B-Tests verwenden ein Signifikanzniveau von 0,05, sodass:

  • Ein p-Wert von weniger als 0,05 weist auf einen statistisch signifikanten Unterschied zwischen den Varianten hin, was bedeutet, dass er wahrscheinlich nicht durch Zufall entstanden ist.
  • Ein p-Wert größer als 0,05 zeigt an, dass der Unterschied zwischen den Varianten statistisch nicht signifikant ist.

Experimentdaten werden einmal täglich aktualisiert und die letzte Aktualisierungszeit wird oben auf der Seite mit den Experimentergebnissen angezeigt.

Das Experimentergebnisdiagramm zeigt die kumulierten Durchschnittswerte der ausgewählten Metrik an. Wenn Sie beispielsweise den Werbeumsatz pro Benutzer als Metrik verfolgen, wird der beobachtete Umsatz pro Benutzer angezeigt. Wenn Sie Benutzer ohne Abstürze verfolgen, wird der Prozentsatz der Benutzer erfasst, bei denen kein Absturz aufgetreten ist. Diese Daten sind ab Beginn des Experiments kumulativ.

Die Ergebnisse werden in beobachtete Daten und Inferenzdaten unterteilt. Beobachtete Daten werden direkt aus Google Analytics-Daten berechnet und Inferenzdaten stellen p-Werte und Konfidenzintervalle bereit, die Ihnen bei der Bewertung der statistischen Signifikanz der beobachteten Daten helfen.

Für jede Metrik werden die folgenden Statistiken angezeigt:

Beobachtete Daten

  • Gesamtwert für die verfolgte Metrik (Anzahl der behaltenen Benutzer, Anzahl der abgestürzten Benutzer, Gesamtumsatz)
  • Metrikspezifische Rate (Retentionsrate, Conversion-Rate, Umsatz pro Benutzer)
  • Prozentualer Unterschied (Anstieg) zwischen der Variante und der Basislinie

Inferenzdaten

  • 95 % CI (Mittelwertdifferenz) zeigt ein Intervall an, das den „wahren“ Wert der verfolgten Metrik mit einer Konfidenz von 95 % enthält. Wenn Ihr Experiment beispielsweise ein 95 %-KI für den geschätzten Gesamtumsatz zwischen 5 und 10 US-Dollar ergibt, besteht eine 95-prozentige Chance, dass der tatsächliche Mittelwertunterschied zwischen 5 und 10 US-Dollar liegt. Wenn der KI-Bereich 0 umfasst, wurde kein statistisch signifikanter Unterschied zwischen der Variante und dem Ausgangswert festgestellt.

    Konfidenzintervallwerte werden in dem Format angezeigt, das der verfolgten Metrik entspricht. Beispiel: Zeit (in HH:MM:SS ) für die Benutzerbindung, USD für Werbeeinnahmen pro Benutzer und Prozentsatz für die Conversion-Rate.

  • P-Wert , der die Wahrscheinlichkeit darstellt, dass zwischen der Variante und der Basislinie kein echter Unterschied besteht; Mit anderen Worten: Jeder beobachtete Unterschied ist wahrscheinlich auf einen Zufall zurückzuführen. Je niedriger der p-Wert, desto größer ist die Sicherheit, dass die beobachtete Leistung auch in Zukunft wahr bleibt. Ein Wert von 0,05 oder weniger weist auf einen signifikanten Unterschied und eine geringe Wahrscheinlichkeit hin, dass die Ergebnisse auf Zufall zurückzuführen sind. P-Werte basieren auf einem einseitigen Test , bei dem der Variantenwert größer als der Basiswert ist. Firebase verwendet einen T-Test auf ungleiche Varianz für kontinuierliche Variablen (numerische Werte, wie Umsatz) und einen Z-Proportionstest für Conversion-Daten (binäre Werte, wie Benutzerbindung, absturzfreie Benutzer, Benutzer, die ein Google Analytics-Ereignis auslösen).

Die Experimentergebnisse liefern wichtige Erkenntnisse für jede Experimentvariante, darunter:

  • Wie viel höher oder niedriger jede Experimentmetrik im Vergleich zur direkt gemessenen Basislinie (d. h. den tatsächlich beobachteten Daten) ist
  • Die Wahrscheinlichkeit, dass der beobachtete Unterschied zwischen der Variante und der Basislinie durch Zufall entstanden sein könnte (p-Wert)
  • Ein Bereich, der wahrscheinlich den „wahren“ Leistungsunterschied zwischen der Variante und der Basislinie für jede Experimentmetrik enthält – eine Möglichkeit, die Leistungsszenarien „Best Case“ und „Worst Case“ zu verstehen

Interpretieren Sie die Ergebnisse von Experimenten mit Google Optimize

Die Ergebnisse des Firebase A/B-Tests für Experimente, die vor dem 23. Oktober 2023 gestartet wurden, wurden von Google Optimize bereitgestellt. Google Optimize nutzte Bayes'sche Inferenz, um aus Ihren Experimentdaten aufschlussreiche Statistiken zu generieren.

Die Ergebnisse werden in „beobachtete Daten“ und „modellierte Daten“ unterteilt. Beobachtete Daten wurden direkt aus Analysedaten berechnet und modellierte Daten wurden aus der Anwendung unseres Bayes'schen Modells auf die beobachteten Daten abgeleitet.

Für jede Metrik werden die folgenden Statistiken angezeigt:

Beobachtete Daten

  • Gesamtwert (Summe der Metrik für alle Benutzer in der Variante)
  • Durchschnittswert (Durchschnittswert der Metrik für Benutzer in der Variante)
  • % Unterschied zum Ausgangswert

Modellierte Daten

  • Wahrscheinlichkeit, die Basislinie zu übertreffen: Wie wahrscheinlich ist, dass die Metrik für diese Variante im Vergleich zur Basislinie höher ist?
  • Prozentualer Unterschied zum Ausgangswert: basierend auf den mittleren Modellschätzungen der Metrik für die Variante und den Ausgangswert
  • Metrikbereiche: die Bereiche, in denen der Wert der Metrik am wahrscheinlichsten zu finden ist, mit 50 % und 95 % Sicherheit

Insgesamt liefern uns die Experimentergebnisse drei wichtige Erkenntnisse für jede Variante im Experiment:

  1. Wie viel höher oder niedriger jede Experimentmetrik im Vergleich zur direkt gemessenen Basislinie (d. h. den tatsächlich beobachteten Daten) ist
  2. Wie wahrscheinlich ist es, dass jede Experimentmetrik höher als die Basislinie/am besten insgesamt ist, basierend auf der Bayes'schen Schlussfolgerung (Wahrscheinlichkeit, besser bzw. am besten zu sein)?
  3. Die plausiblen Bereiche für jede Experimentmetrik basierend auf Bayes'scher Schlussfolgerung – „Best-Case“- und „Worst-Case“-Szenarien (glaubwürdige Intervalle)

Führungsentschlossenheit

Bei Experimenten mit Frequentist-Inferenz erklärt Firebase eine Variante als führend, wenn bei der Zielmetrik ein statistisch signifikanter Leistungsunterschied zwischen der Variante und der Basislinie besteht. Wenn mehrere Varianten dieses Kriterium erfüllen, wird die Variante mit dem niedrigsten p-Wert ausgewählt.

Für Experimente, bei denen Google Optimize verwendet wurde, erklärte Firebase, dass eine Variante ein „klarer Spitzenreiter“ ist, wenn die Wahrscheinlichkeit, dass sie bei der primären Metrik besser als die Basisvariante ist, bei über 95 % liegt. Wenn mehrere Varianten die Kriterien des „eindeutigen Spitzenreiters“ erfüllten, wurde nur die insgesamt leistungsstärkste Variante als „eindeutiger Spitzenreiter“ gekennzeichnet.

Da die Bestimmung des Leaders nur auf dem primären Ziel basiert, sollten Sie alle relevanten Faktoren berücksichtigen und die Ergebnisse sekundärer Metriken überprüfen, bevor Sie entscheiden, ob Sie eine führende Variante einführen oder nicht. Möglicherweise möchten Sie den erwarteten Vorteil der Änderung, das Abwärtsrisiko (z. B. das untere Ende des Konfidenzintervalls für Verbesserungen) und die Auswirkungen auf andere Kennzahlen als das primäre Ziel berücksichtigen.

Wenn Ihre primäre Metrik beispielsweise „Absturzfreie Benutzer“ ist und Variante A gegenüber der Basislinie klar an der Spitze liegt, die Benutzerbindungsmetriken von Variante A jedoch hinter der Basisbenutzerbindung zurückbleiben, sollten Sie dies möglicherweise weiter untersuchen, bevor Sie Variante A breiter einführen.

Sie können jede Variante einführen, nicht nur eine führende Variante, basierend auf Ihrer Gesamtbewertung der Leistung sowohl der primären als auch der sekundären Metriken.

Versuchsdauer

Firebase empfiehlt, dass ein Experiment so lange ausgeführt wird, bis die folgenden Bedingungen erfüllt sind:

  1. Das Experiment hat genügend Daten gesammelt, um ein nützliches Ergebnis zu liefern. Experimente und Ergebnisdaten werden einmal täglich aktualisiert. Möglicherweise möchten Sie einen Online-Stichprobengrößenrechner zu Rate ziehen, um die empfohlene Stichprobengröße Ihres Experiments zu ermitteln.
  2. Das Experiment läuft lange genug, um eine repräsentative Stichprobe Ihrer Benutzer sicherzustellen und die längerfristige Leistung zu messen. Die empfohlene Mindestlaufzeit für ein typisches Remote-Config-Experiment beträgt zwei Wochen.

Experimentdaten werden maximal 90 Tage nach Experimentstart verarbeitet. Nach 90 Tagen wird das Experiment automatisch beendet. Experimentergebnisse werden in der Firebase-Konsole nicht mehr aktualisiert und das Experiment sendet keine experimentspezifischen Parameterwerte mehr. An diesem Punkt beginnen Clients mit dem Abrufen von Parameterwerten basierend auf den in der Remote Config-Vorlage festgelegten Bedingungen. Historische Experimentdaten bleiben erhalten, bis Sie das Experiment löschen.

BigQuery-Schema

Zusätzlich zur Anzeige von A/B-Test-Experimentdaten in der Firebase-Konsole können Sie Experimentdaten in BigQuery untersuchen und analysieren. Während A/B-Tests keine separate BigQuery-Tabelle haben, werden Experiment- und Variantenmitgliedschaften für jedes Google Analytics-Ereignis in den Analytics-Ereignistabellen gespeichert.

Die Benutzereigenschaften, die Experimentinformationen enthalten, haben die Form userProperty.key like "firebase_exp_%" oder userProperty.key = "firebase_exp_01" , wobei 01 die Experiment-ID ist und userProperty.value.string_value den (nullbasierten) Index des enthält Versuchsvariante.

Sie können diese Experimentbenutzereigenschaften verwenden, um Experimentdaten zu extrahieren. Dies gibt Ihnen die Möglichkeit, Ihre Experimentergebnisse auf viele verschiedene Arten aufzuteilen und die Ergebnisse von A/B-Tests unabhängig zu überprüfen.

Führen Sie zunächst die folgenden Schritte aus, wie in dieser Anleitung beschrieben:

  1. Aktivieren Sie den BigQuery-Export für Google Analytics in der Firebase-Konsole
  2. Greifen Sie mit BigQuery auf A/B-Testdaten zu
  3. Entdecken Sie Beispielabfragen

Aktivieren Sie den BigQuery-Export für Google Analytics in der Firebase-Konsole

Wenn Sie den Spark-Plan nutzen, können Sie die BigQuery-Sandbox verwenden, um kostenlos auf BigQuery zuzugreifen, vorbehaltlich der Sandbox-Beschränkungen . Weitere Informationen finden Sie unter Preise und die BigQuery-Sandbox .

Stellen Sie zunächst sicher, dass Sie Ihre Analytics-Daten nach BigQuery exportieren:

  1. Öffnen Sie die Registerkarte „Integrationen“ , auf die Sie über “ > „Projekteinstellungen“ in der Firebase-Konsole zugreifen können.
  2. Wenn Sie BigQuery bereits mit anderen Firebase-Diensten verwenden, klicken Sie auf Verwalten . Andernfalls klicken Sie auf „Verknüpfen“ .
  3. Lesen Sie die Informationen zum Verknüpfen von Firebase mit BigQuery und klicken Sie dann auf Weiter .
  4. Aktivieren Sie im Abschnitt „Integration konfigurieren“ den Schalter „Google Analytics“ .

  5. Wählen Sie eine Region aus und wählen Sie Exporteinstellungen.

  6. Klicken Sie auf „Mit BigQuery verknüpfen“ .

Je nachdem, wie Sie die Daten exportieren, kann es bis zu einem Tag dauern, bis die Tabellen verfügbar sind. Weitere Informationen zum Exportieren von Projektdaten nach BigQuery finden Sie unter Projektdaten nach BigQuery exportieren .

Greifen Sie in BigQuery auf A/B-Testdaten zu

Bevor Sie Daten für ein bestimmtes Experiment abfragen, möchten Sie einige oder alle der folgenden Informationen erhalten, die Sie in Ihrer Abfrage verwenden können:

  • Experiment-ID: Diese erhalten Sie über die URL der Experiment-Übersichtsseite . Wenn Ihre URL beispielsweise wie folgt aussieht: https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25 , lautet die Experiment-ID 25 .
  • Google Analytics-Property-ID : Dies ist Ihre 9-stellige Google Analytics-Property-ID. Sie finden dies in Google Analytics; Es erscheint auch in BigQuery, wenn Sie Ihren Projektnamen erweitern, um den Namen Ihrer Google Analytics-Ereignistabelle ( project_name.analytics_000000000.events ) anzuzeigen.
  • Experimentdatum: Um eine schnellere und effizientere Abfrage zu erstellen, empfiehlt es sich, Ihre Abfragen auf die Google Analytics-Tagesereignistabellenpartitionen zu beschränken, die Ihre Experimentdaten enthalten – Tabellen, die mit dem Suffix YYYYMMDD gekennzeichnet sind. Wenn Ihr Experiment also vom 2. Februar 2024 bis zum 2. Mai 2024 lief, würden Sie ein _TABLE_SUFFIX between '20240202' AND '20240502' angeben. Ein Beispiel finden Sie unter „Auswählen der Werte eines bestimmten Experiments“ .
  • Ereignisnamen: Normalerweise entsprechen diese Ihren Zielmetriken , die Sie im Experiment konfiguriert haben. Zum Beispiel in_app_purchase Ereignisse, ad_impression oder user_retention Ereignisse.

Nachdem Sie die Informationen gesammelt haben, die Sie zum Generieren Ihrer Abfrage benötigen:

  1. Öffnen Sie BigQuery in der Google Cloud Console.
  2. Wählen Sie Ihr Projekt und dann SQL-Abfrage erstellen aus .
  3. Fügen Sie Ihre Anfrage hinzu. Beispielabfragen zum Ausführen finden Sie unter Beispielabfragen erkunden .
  4. Klicken Sie auf Ausführen .

Fragen Sie Experimentdaten mit der automatisch generierten Abfrage der Firebase-Konsole ab

Wenn Sie den Blaze-Plan verwenden, bietet die Übersichtsseite des Experiments eine Beispielabfrage, die den Experimentnamen, Varianten, Ereignisnamen und die Anzahl der Ereignisse für das angezeigte Experiment zurückgibt.

So rufen Sie die automatisch generierte Abfrage ab und führen sie aus:

  1. Öffnen Sie in der Firebase-Konsole A/B-Tests und wählen Sie das A/B-Test-Experiment aus, das Sie abfragen möchten, um die Experimentübersicht zu öffnen.
  2. Wählen Sie im Menü „Optionen“ unter „BigQuery-Integration“ die Option „Experimentdaten abfragen“ aus. Dadurch wird Ihr Projekt in BigQuery in der Google Cloud Console-Konsole geöffnet und eine einfache Abfrage bereitgestellt, mit der Sie Ihre Experimentdaten abfragen können.

Das folgende Beispiel zeigt eine generierte Abfrage für ein Experiment mit drei Varianten (einschließlich der Basislinie) mit dem Namen „Winter-Welcome-Experiment“. Für jedes Ereignis werden der Name des aktiven Experiments, der Variantenname, das eindeutige Ereignis und die Ereignisanzahl zurückgegeben. Beachten Sie, dass der Abfrage-Generator Ihren Projektnamen nicht im Tabellennamen angibt, da dieser direkt in Ihrem Projekt geöffnet wird.

  /*
    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

Weitere Abfragebeispiele finden Sie unter Beispielabfragen erkunden .

Entdecken Sie Beispielabfragen

In den folgenden Abschnitten finden Sie Beispiele für Abfragen, mit denen Sie A/B-Test-Experimentdaten aus Google Analytics-Ereignistabellen extrahieren können.

Extrahieren Sie Kauf- und Experimentstandardabweichungswerte aus allen Experimenten

Sie können Testergebnisdaten verwenden, um die Ergebnisse von Firebase A/B-Tests unabhängig zu überprüfen. Die folgende BigQuery-SQL-Anweisung extrahiert Experimentvarianten, die Anzahl der einzelnen Benutzer in jeder Variante und summiert den Gesamtumsatz aus in_app_purchase und ecommerce_purchase Ereignissen sowie Standardabweichungen für alle Experimente innerhalb des als _TABLE_SUFFIX angegebenen Anfangs- und Enddatums. Sie können die Daten, die Sie aus dieser Abfrage erhalten, mit einem statistischen Signifikanzgenerator für einseitige T-Tests verwenden, um zu überprüfen, ob die von Firebase bereitgestellten Ergebnisse mit Ihrer eigenen Analyse übereinstimmen.

Weitere Informationen darüber, wie A/B-Tests Inferenzen berechnen, finden Sie unter Testergebnisse interpretieren .

  /*
    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;

Wählen Sie die Werte eines bestimmten Experiments aus

Die folgende Beispielabfrage veranschaulicht, wie Daten für ein bestimmtes Experiment in BigQuery abgerufen werden. Diese Beispielabfrage gibt den Experimentnamen, Variantennamen (einschließlich Baseline), Ereignisnamen und Ereignisanzahlen zurück.

  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

Grenzen

A/B-Tests sind auf insgesamt 300 Experimente, 24 laufende Experimente und 24 Entwurfsexperimente beschränkt.

  • Wenn Sie das Limit von insgesamt 300 Experimenten oder das Limit von 24 Experimententwürfen erreichen, müssen Sie ein vorhandenes Experiment löschen, bevor Sie ein neues erstellen können.

  • Wenn Sie das Limit von 24 laufenden Experimenten erreichen, müssen Sie ein laufendes Experiment stoppen, bevor Sie ein neues starten.

Ein Experiment kann maximal 8 Varianten (einschließlich der Basislinie) und bis zu 25 Parameter für jede Variante haben. Ein Experiment kann eine Größe von bis zu etwa 200 KiB haben. Dazu gehören Variantennamen, Variantenparameter und andere Konfigurationsmetadaten.