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.

Stichprobengröße

Für die Firebase A/B Testing-Inferenz muss vor Beginn eines Tests keine Mindeststichprobengröße festgelegt werden. Im Allgemeinen sollten Sie die höchste Testgruppe auswählen, die Ihnen angemessen erscheint. Bei größeren Stichproben ist die Wahrscheinlichkeit, ein statistisch signifikantes Ergebnis zu erzielen, höher, insbesondere wenn die Leistungsunterschiede zwischen den Varianten gering sind. Möglicherweise ist es auch hilfreich, einen Online-Rechner für die Stichprobengröße zu verwenden, um die empfohlene Stichprobengröße basierend auf den Merkmalen Ihres Tests zu ermitteln.

Tests bearbeiten

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

• Testname
• Beschreibung
• Ausrichtungsbedingungen
• Variantenwerte

So bearbeiten Sie einen Test:

1. Öffnen Sie die Ergebnisseite für den Test, den Sie ändern möchten.
2. Wählen Sie im Menü Mehr die Option Laufenden Test bearbeiten aus.
3. Nehmen Sie die gewünschten Änderungen vor und klicken Sie auf Veröffentlichen.

Wenn Sie das Verhalten der App während eines laufenden Tests ändern, kann das die Ergebnisse beeinträchtigen.

Logik für die Zuweisung von Remote Config-Varianten

Nutzer, die alle Targeting-Bedingungen des Tests erfüllen (einschließlich der Bedingung für den Prozentsatz der Impressionen), werden den Testvarianten entsprechend den Variantengewichten und einem Hash der Test-ID und der Firebase-Installations-ID des Nutzers zugewiesen.

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

• Wenn Sie eine neue Zielgruppe erstellen, kann es 24 bis 48 Stunden dauern, bis neue Nutzer aufgenommen werden.
• Neue Nutzer werden in der Regel 24 bis 48 Stunden nach Erfüllen der Voraussetzungen in entsprechende Zielgruppen aufgenommen.

Für zeitkritische Ausrichtung sollten Sie Google Analytics-Nutzerattribute oder integrierte Targeting-Optionen wie Land oder Region, Sprache und App-Version verwenden.

Sobald ein Nutzer an einem Test teilnimmt, wird er dauerhaft der entsprechenden Testvariante zugewiesen und erhält Parameterwerte aus dem Test, solange der Test aktiv ist. Das gilt auch, wenn sich seine Nutzereigenschaften ändern und er die Ausrichtungskriterien des Tests nicht mehr erfüllt.

Aktivierungsereignisse

Durch Testaktivierungsereignisse werden Testmessungen auf App-Nutzer beschränkt, die das Aktivierungsereignis auslösen. Das Aktivierungsereignis des Tests hat keine Auswirkungen auf die Testparameter, die von der App abgerufen werden. Alle Nutzer, die die Ausrichtungskriterien des Tests erfüllen, erhalten Testparameter. Daher ist es wichtig, ein Aktivierungsereignis auszuwählen, das nach dem Abrufen und Aktivieren der Testparameter, aber vor der Verwendung der Testparameter zur Änderung des App-Verhaltens erfolgt.

Gewichtung der Varianten

Beim Erstellen eines Tests können Sie die Standardgewichte der Varianten ändern, um einen größeren Prozentsatz der Testnutzer einer Variante zuzuweisen.

Testergebnisse interpretieren

Bei Firebase A/B Testing wird frequentistische Inferenz verwendet, um die Wahrscheinlichkeit zu ermitteln, dass Ihre Testergebnisse allein auf Zufall beruhen. Diese Wahrscheinlichkeit wird durch einen Wahrscheinlichkeitswert oder p-Wert dargestellt. Der p-Wert ist die Wahrscheinlichkeit, dass ein Leistungsunterschied dieser Größenordnung oder größer zwischen zwei Varianten aufgrund von Zufall auftreten könnte, wenn es tatsächlich keinen Effekt gibt. Er wird durch einen Wert zwischen 0 und 1 gemessen. Bei A/B Testing wird ein Signifikanzniveau von 0,05 verwendet.Das bedeutet:

• Ein p-Wert von weniger als 0,05 bedeutet, dass die Wahrscheinlichkeit, dass ein so extremer beobachteter Unterschied zufällig auftritt, bei weniger als 5% liegt, wenn die tatsächliche Differenz null wäre. Da 0,05 der Grenzwert ist, weist jeder p-Wert unter 0,05 auf einen statistisch signifikanten Unterschied zwischen den Varianten hin.
• Ein p-Wert über 0,05 bedeutet, dass der Unterschied zwischen den Varianten nicht statistisch signifikant ist.

Testdaten werden einmal täglich aktualisiert. Der Zeitpunkt der letzten Aktualisierung wird oben auf der Seite mit den Testergebnissen angezeigt.

Im Diagramm mit den Testergebnissen werden die kumulativen Durchschnittswerte des ausgewählten Messwerts dargestellt. Wenn Sie beispielsweise den Anzeigenumsatz pro Nutzer als Messwert erfassen, wird der beobachtete Umsatz pro Nutzer angezeigt. Wenn Sie Nutzer ohne Abstürze erfassen, wird der Prozentsatz der Nutzer erfasst, bei denen kein Absturz aufgetreten ist. Diese Daten sind kumulativ seit Beginn des Tests.

Die Ergebnisse werden in Beobachtete Daten und Inferenzdaten unterteilt. Beobachtete Daten werden direkt aus Google Analytics-Daten berechnet. Mit den Inferenzdaten erhalten Sie p-Werte und Konfidenzintervalle, mit denen Sie die statistische Signifikanz der beobachteten Daten bewerten können.

Für jeden Messwert werden die folgenden Statistiken angezeigt:

Erfasste Daten

• Gesamtwert für den erfassten Messwert (Anzahl der gebundenen Nutzer, Anzahl der Nutzer, bei denen die App abgestürzt ist, Gesamtumsatz)
• Messwertspezifische Rate (Bindungsrate, Conversion-Rate, Umsatz pro Nutzer)
• Prozentualer Unterschied (Steigerung) zwischen der Variante und der ursprünglichen Variante

Inferenzdaten

• 95% CI (Differenz der Mittelwerte) zeigt ein Intervall an, das den „wahren“ Wert des erfassten Messwerts mit einer Wahrscheinlichkeit von 95% enthält. Wenn Ihr Test beispielsweise ein 95‑%‑Konfidenzintervall für den geschätzten Gesamtumsatz zwischen 5 und 10 $ ergibt, liegt die Wahrscheinlichkeit, dass die tatsächliche Differenz der Mittelwerte zwischen 5 und 10 $ liegt, bei 95 %. Wenn der CI-Bereich 0 enthält, wurde kein statistisch signifikanter Unterschied zwischen der Variante und der Baseline festgestellt.

  Die Werte für das Konfidenzintervall werden im Format des erfassten Messwerts angezeigt. Beispiele: „Zeit“ (in HH:MM:SS) für die Nutzerbindung, „USD“ für den Anzeigenumsatz pro Nutzer und „Prozentsatz“ für die Conversion-Rate.

• p-Wert: Er gibt die Wahrscheinlichkeit an, dass Daten beobachtet werden, die so extrem sind wie die im Test erzielten Ergebnisse, wenn es keinen echten Unterschied zwischen der Variante und der Baseline gibt. Je niedriger der p-Wert, desto höher die Wahrscheinlichkeit, dass die beobachtete Leistung auch bei einer Wiederholung des Tests gleich bleibt. Ein Wert von 0,05 oder niedriger weist auf einen signifikanten Unterschied und eine geringe Wahrscheinlichkeit hin, dass die Ergebnisse auf Zufall beruhen. P-Werte basieren auf einem einseitigen Test, bei dem der Wert der Variante größer als der Wert der Baseline ist. In Firebase wird für kontinuierliche Variablen (numerische Werte wie Umsatz) ein T‑Test mit ungleichen Varianzen und für Conversion-Daten (binäre Werte wie Nutzerbindung, Nutzer ohne Abstürze, Nutzer, die ein Google Analytics-Ereignis auslösen) ein Z‑Test für Anteile verwendet.

Die Testergebnisse liefern wichtige Informationen zu jeder Testvariante, darunter:

• Wie viel höher oder niedriger jeder Testmesswert im Vergleich zur Baseline ist, direkt gemessen (d. h. die tatsächlich beobachteten Daten)
• Die Wahrscheinlichkeit, dass der beobachtete Unterschied zwischen der Variante und der Baseline zufällig aufgetreten ist (p-Wert)
• Ein Bereich, der wahrscheinlich den „wahren“ Leistungsunterschied zwischen der Variante und der Baseline für jeden Testmesswert enthält. So lassen sich die Leistungszenarien für den „Best Case“ und den „Worst Case“ nachvollziehen.

Ergebnisse von Tests interpretieren, die mit Google Optimize durchgeführt wurden

Firebase A/B Testing-Ergebnisse für Tests, die vor dem 23. Oktober 2023 gestartet wurden, basierten auf Google Optimize. In Google Optimize wurde die bayessche Inferenz verwendet, um aussagekräftige Statistiken aus Ihren Testdaten zu generieren.

Die Ergebnisse werden in „Beobachtete Daten“ und „Modellierte Daten“ unterteilt. Die erfassten Daten wurden direkt anhand der Analytics-Daten berechnet und die geschätzten Daten beruhen auf dem bayesschen Modell, das auf die erfassten Daten angewendet wird.

Für jeden Messwert werden die folgenden Statistiken angezeigt:

Erfasste Daten

• Gesamtwert (Summe des Messwerts für alle Nutzer in der Variante)
• Durchschnittswert (durchschnittlicher Wert des Messwerts für Nutzer in der Variante)
• Abweichung von ursprünglicher Variante in %

Geschätzte Daten

• Wahrscheinlichkeit, die ursprüngliche Variante zu übertreffen: Die Wahrscheinlichkeit, dass der Messwert für diese Variante höher ist als für die Baseline.
• Prozentualer Unterschied zur ursprünglichen Variante: basiert auf den Medianmodellschätzungen des Messwerts für die Variante und die ursprüngliche Variante
• Messwertbereiche: Die Bereiche, in denen der Wert des Messwerts mit 50-prozentiger und 95-prozentiger Wahrscheinlichkeit zu finden ist

Insgesamt liefern die Testergebnisse drei wichtige Erkenntnisse für jede Variante im Test:

1. Wie viel höher oder niedriger jeder Testmesswert im Vergleich zur Baseline ist, direkt gemessen (d.h. die tatsächlich beobachteten Daten)
2. Wie wahrscheinlich es ist, dass jeder Testmesswert höher als der Baseline-Wert bzw. der beste Gesamtwert ist, basierend auf der bayesschen Inferenz (Wahrscheinlichkeit, besser bzw. am besten zu sein)
3. Die plausiblen Bereiche für die einzelnen Testmesswerte basierend auf der bayesschen Inferenz – „Best-Case“- und „Worst-Case“-Szenarien (glaubwürdige Intervalle)

Leader-Bestimmung

Bei Tests mit frequentistischer Inferenz wird eine Variante in Firebase als führend deklariert, wenn beim Zielmesswert ein statistisch signifikanter Leistungsunterschied zwischen der Variante und der Baseline besteht. Wenn mehrere Varianten dieses Kriterium erfüllen, wird diejenige mit dem niedrigsten p-Wert ausgewählt.

Bei Tests, in denen Google Optimize verwendet wurde, wurde eine Variante in Firebase als „klar führend“ deklariert, wenn die Wahrscheinlichkeit, dass sie beim primären Messwert besser als die Baseline-Variante ist, über 95 % lag. Wenn mehrere Varianten die Kriterien für einen eindeutigen Gewinner erfüllten, wurde nur die insgesamt leistungsstärkste Variante als „eindeutiger Gewinner“ gekennzeichnet.

Da die führende Variante nur auf dem primären Zielmesswert basiert, sollten Sie alle relevanten Faktoren in Betracht ziehen und auch die Ergebnisse bei den sekundären Messwerten überprüfen, bevor Sie entscheiden, ob diese Variante auf alle Nutzer angewendet werden soll oder nicht. Berücksichtigen Sie dabei den erwarteten Nutzen der Änderung, das Risiko (z. B. das untere Ende des Konfidenzintervalls für die Verbesserung) und die Auswirkungen auf andere Messwerte als das primäre Zielvorhaben.

Wenn Ihr primärer Messwert beispielsweise „Nutzer ohne Abstürze“ ist und Variante A deutlich besser als die Baseline ist, die Messwerte zur Nutzerbindung von Variante A aber hinter der Baseline zurückbleiben, sollten Sie die Situation genauer untersuchen, bevor Sie Variante A weiter einführen.

Sie können jede Variante einführen, nicht nur die führende, basierend auf Ihrer Gesamtbewertung der Leistung bei primären und sekundären Messwerten.

Höchstdauer für Tests

Firebase empfiehlt, einen Test so lange auszuführen, bis die folgenden Bedingungen erfüllt sind:

1. Für den Test wurden genügend Daten erhoben, um ein aussagekräftiges Ergebnis zu liefern. Test- und Ergebnisdaten werden einmal täglich aktualisiert. Sie können einen Online-Stichprobenrechner verwenden, um die empfohlene Stichprobengröße für Ihren Test zu ermitteln.
2. Der Test wurde lange genug ausgeführt, um eine repräsentative Stichprobe Ihrer Nutzer zu erhalten und die langfristige Leistung zu messen. Zwei Wochen sind die empfohlene Mindestlaufzeit für einen typischen Remote Config-Test.

Testdaten werden maximal 90 Tage nach Testbeginn verarbeitet. Nach 90 Tagen wird der Test automatisch beendet. Die Testergebnisse werden nicht mehr in der Firebase-Konsole aktualisiert und es werden keine testspezifischen Parameterwerte mehr gesendet. An diesem Punkt beginnen Clients, Parameterwerte basierend auf den in der Remote Config-Vorlage festgelegten Bedingungen abzurufen. Verlaufsdaten aus Tests werden so lange aufbewahrt, bis Sie den Test löschen.

BigQuery-Schema

Neben der Anzeige von A/B Testing-Testdaten in der Firebase-Konsole können Sie Testdaten auch in BigQuery untersuchen und analysieren. Für A/B Testing gibt es keine separate BigQuery-Tabelle. Die Zugehörigkeit zu Tests und Varianten wird jedoch für jedes Google Analytics-Ereignis in den Analytics-Ereignistabellen gespeichert.

Die Nutzerattribute, die Testinformationen enthalten, haben das Format userProperty.key like "firebase_exp_%" oder userProperty.key = "firebase_exp_01", wobei 01 die Test-ID und userProperty.value.string_value den (nullbasierten) Index der Testvariante enthält.

Mit diesen Nutzereigenschaften für Tests lassen sich Testdaten extrahieren. So können Sie die Testergebnisse auf viele verschiedene Arten aufschlüsseln und die Ergebnisse von A/B Testing unabhängig überprüfen.

Führen Sie zuerst die folgenden Schritte aus, wie in diesem Leitfaden beschrieben:

1. BigQuery-Export für Google Analytics in der Firebase Console aktivieren
2. Mit BigQuery auf A/B Testing-Daten zugreifen
3. Beispielabfragen ansehen

BigQuery-Export für Google Analytics in der Firebase Console aktivieren

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

Prüfen Sie zuerst, ob Sie Ihre Analytics-Daten nach BigQuery exportieren:

1. Öffnen Sie den Tab Integrationen, den Sie in der Firebase-Konsole über  > Projekteinstellungen aufrufen können.
2. Wenn Sie BigQuery bereits mit anderen Firebase-Diensten verwenden, klicken Sie auf Verwalten. Klicken Sie andernfalls auf Verknüpfen.
3. Lesen Sie den Abschnitt Firebase mit BigQuery verknüpfen und klicken Sie dann auf Weiter.
4. Aktivieren Sie im Abschnitt Integration konfigurieren den Schalter Google Analytics.

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

   Hinweis :Weitere Informationen zu Google Analytics für Firebase-Einstellungen finden Sie unter Datenerhebung.

6. Klicken Sie auf Mit BigQuery verknüpfen.

Je nachdem, wie Sie Daten exportiert haben, 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.

Auf A/B Testing-Daten in BigQuery zugreifen

Bevor Sie Daten für ein bestimmtes Experiment abfragen, sollten Sie einige oder alle der folgenden Informationen für Ihre Abfrage abrufen:

• Test-ID:Sie finden sie in der URL der Seite Testübersicht. Wenn Ihre URL beispielsweise so aussieht: https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25, ist die Test-ID 25.
• Property-ID Google Analytics: Das ist Ihre 9-stellige Property-ID Google Analytics. Sie finden sie unter Google Analytics. Sie wird auch in BigQuery angezeigt, wenn Sie den Projektnamen maximieren, um den Namen der Google Analytics-Ereignistabelle (project_name.analytics_000000000.events) aufzurufen.
• Testdatum:Um eine schnellere und effizientere Abfrage zu erstellen, sollten Sie Ihre Abfragen auf die Google Analytics-Partitionen der täglichen Ereignistabelle beschränken, die Ihre Testdaten enthalten. Diese Tabellen sind mit dem Suffix YYYYMMDD gekennzeichnet. Wenn Ihr Test also vom 2. Februar 2024 bis zum 2. Mai 2024 ausgeführt wurde, geben Sie _TABLE_SUFFIX between '20240202' AND '20240502' an. Ein Beispiel finden Sie unter Werte für ein bestimmtes Experiment auswählen.
• Ereignisnamen:In der Regel entsprechen diese den Zielvorhabenmesswerten, die Sie im Test konfiguriert haben. Beispiele: in_app_purchase-Ereignisse, ad_impression-Ereignisse oder user_retention-Ereignisse.

Tipp :Wenn Sie den Blaze-Tarif nutzen, kann Firebase eine Beispielabfrage generieren, um den Testnamen, die Variante, den Ereignisnamen und die Anzahl der Ereignisse für den ausgewählten Test zu extrahieren. Weitere Informationen

Firebase

Nachdem Sie die Informationen zusammengetragen haben, die Sie zum Generieren der Anfrage benötigen:

1. Öffnen Sie BigQuery in der Google Cloud-Konsole.
2. Wählen Sie Ihr Projekt und dann SQL-Abfrage erstellen aus.
3. Geben Sie Ihre Frage ein. Beispielabfragen, die Sie ausführen können, finden Sie unter Beispielabfragen ansehen.
4. Klicken Sie auf Ausführen.

Tipp :In dieser Anleitung wird die Verwendung der Google Cloud-Konsole beschrieben. Sie können aber auch die Befehlszeile oder Clientbibliotheken verwenden, um BigQuery abzufragen. Weitere Informationen finden Sie in der Dokumentation zu BigQuery.

Testdaten mit der automatisch generierten Abfrage der Firebase Console abfragen

Wenn Sie den Blaze-Tarif verwenden, finden Sie auf der Seite Testübersicht eine Beispielabfrage, die den Testnamen, die Varianten, die Ereignisnamen und die Anzahl der Ereignisse für den Test zurückgibt, den Sie sich ansehen.

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

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

Im folgenden Beispiel sehen Sie eine generierte Abfrage für einen Test mit drei Varianten (einschließlich der Baseline) mit dem Namen „Winter-Willkommen-Test“. Es werden der Name des aktiven Tests, der Name der Variante, das eindeutige Ereignis und die Anzahl der Ereignisse für jedes Ereignis zurückgegeben. Im Query Builder wird Ihr Projektname nicht im Tabellennamen angegeben, da er 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.

Beispielabfragen ansehen

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

Standardabweichungswerte für Käufe und Tests aus allen Tests extrahieren

Sie können die Daten aus Testergebnissen verwenden, um die Firebase A/B Testing-Ergebnisse unabhängig zu überprüfen. Mit der folgenden BigQuery-SQL-Anweisung werden die Varianten von A/B-Tests, die Anzahl der einzelnen Nutzer in jeder Variante sowie der Gesamtumsatz aus in_app_purchase- und ecommerce_purchase-Ereignissen und die Standardabweichungen für alle A/B-Tests im Zeitraum, der als _TABLE_SUFFIX-Start- und ‑Enddatum angegeben ist, extrahiert. Sie können die Daten aus dieser Abfrage mit einem Generator für statistische Signifikanz für einseitige t-Tests verwenden, um zu überprüfen, ob die von Firebase bereitgestellten Ergebnisse mit Ihrer eigenen Analyse übereinstimmen.

Weitere Informationen zur Berechnung von Inferenz in A/B Testing 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;

Werte für einen bestimmten Test auswählen

Die folgende Beispielabfrage zeigt, wie Sie Daten für einen bestimmten Test in BigQuery abrufen. Mit dieser Beispielabfrage werden der Testname, die Variantennamen (einschließlich „Baseline“), die Ereignisnamen und die Ereignisanzahl zurückgegeben.

  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

Limits

A/B Testing ist auf insgesamt 300 Tests, 24 laufende Tests und 24 Testentwürfe begrenzt. Diese Limits werden für Remote Config-Rollouts freigegeben. Wenn Sie beispielsweise zwei laufende Roll-outs und drei laufende Tests haben, können Sie bis zu 19 weitere Roll-outs oder Tests durchführen.

• Wenn Sie das Limit von 300 Tests insgesamt oder das Limit von 24 Testentwürfen erreichen, müssen Sie einen vorhandenen Test löschen, bevor Sie einen neuen erstellen können.

• Wenn Sie das Limit von 24 laufenden Tests und Roll-outs erreichen, müssen Sie einen laufenden Test oder Roll-out beenden, bevor Sie einen neuen starten können.

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