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

Firebase A/B Testing-Inferenz erfordert nicht, dass vor Beginn eines Tests eine Mindeststichprobengröße festgelegt wird. Im Allgemeinen sollten Sie die größte Testauswirkung auswählen, die Sie für angemessen halten. Mit größeren Stichproben steigt die Wahrscheinlichkeit, ein statistisch signifikantes Ergebnis zu erhalten, insbesondere wenn die Leistungsunterschiede zwischen den Varianten gering sind. Es kann auch hilfreich sein, einen Online-Rechner für die Stichprobengröße zu verwenden, um die empfohlene Stichprobengröße anhand der Merkmale 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 des Tests, den Sie ändern möchten.
2. Wählen Sie im Dreipunkt-Menü die Option Laufenden Test bearbeiten aus.
3. Nehmen Sie die gewünschten Änderungen vor und klicken Sie auf Veröffentlichen.

Hinweis: Wenn Sie das Verhalten der App während eines laufenden Tests ändern, kann sich das auf die Ergebnisse auswirken.

Logik für die Remote Config-Variantenzuweisung

Nutzer, die allen Bedingungen für das Test-Targeting entsprechen (einschließlich der Bedingung für den Prozentsatz der Auslieferung), werden den Testvarianten gemäß den Variantengewichten und einem Hashwert der Test-ID und der Firebase-Installations-ID des Nutzers zugewiesen.

Google AnalyticsZielgruppen sind von Latenz betroffen und 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 erfasst werden.
• Neue Nutzer werden in der Regel 24 bis 48 Stunden, nachdem sie die Voraussetzungen erfüllen, in geeignete Zielgruppen aufgenommen.

Für ein zeitkritisches Targeting können Sie Google Analytics-Nutzereigenschaften oder integrierte Targeting-Optionen wie Land oder Region, Sprache und App-Version verwenden.

Sobald ein Nutzer an einem Test teilgenommen hat, wird er dauerhaft seiner 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

Mit Aktivierungsereignissen für Tests wird die Testmessung 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 Kriterien für die Testausrichtung 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 zum Ändern des App-Verhaltens auftritt.

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 auswerten

Für Firebase A/B Testing wird frequentistische Inferenz verwendet, um die Wahrscheinlichkeit zu verstehen, dass die Testergebnisse allein aufgrund einer Zufallswahrscheinlichkeit aufgetreten sind. Diese Wahrscheinlichkeit wird durch einen Wahrscheinlichkeitswert bzw. p-Wert dargestellt. Der p-Wert ist die Wahrscheinlichkeit, dass der Leistungsunterschied zwischen zwei Varianten aufgrund von Zufall eingetreten sein könnte. Er wird anhand eines Werts zwischen 0 und 1 gemessen. In A/B Testing wird ein Signifikanzniveau von 0,05 verwendet, sodass:

• Ein p-Wert unter 0,05 weist auf einen statistisch signifikanten Unterschied zwischen den Varianten hin. Das bedeutet, dass er wahrscheinlich nicht zufällig aufgetreten ist.
• 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 angezeigt. Wenn Sie beispielsweise den Werbeumsatz 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 seit Beginn des Tests kumulative.

Die Ergebnisse werden in beobachtete Daten und Inferenzdaten unterteilt. Beobachtete Daten werden direkt aus Google Analytics-Daten berechnet. Inferenzdaten liefern p-Werte und Konfidenzintervalle, damit Sie die statistische Signifikanz der beobachteten Daten besser beurteilen können.

Für jeden Messwert werden die folgenden Statistiken angezeigt:

Erfasste Daten

• Gesamtwert für den erfassten Messwert (Anzahl der aktiven Nutzer, Anzahl der Nutzer, bei denen ein Absturz aufgetreten ist, Gesamtumsatz)
• Messwertspezifischer Wert (Bindungsrate, Conversion-Rate, Umsatz pro Nutzer)
• Prozentualer Unterschied (Steigerung) zwischen Variante und Baseline

Inferenzdaten

• 95 %-Konfidenzintervall (Differenz der Mittelwerte): Hier sehen Sie ein Intervall, das den „wahren“ Wert des erfassten Messwerts mit einer Wahrscheinlichkeit von 95 % enthält. Wenn Ihr Test beispielsweise zu einem CI-Wert von 95% für einen geschätzten Gesamtumsatz zwischen 5 $und 10 $führt, besteht eine Wahrscheinlichkeit von 95 %, dass die tatsächliche Differenz der Mittelwerte zwischen 5 $und 10 $liegt. Wenn der Konfidenzintervall den Wert 0 enthält, wurde kein statistisch signifikanter Unterschied zwischen der Variante und der Baseline festgestellt.

  Die Werte für das Konfidenzintervall werden in dem Format angezeigt, das dem erfassten Messwert entspricht. Beispiel: „Zeit“ (in HH:MM:SS) für die Nutzerbindung, „€“ für den Werbeumsatz pro Nutzer und „Prozentsatz“ für die Conversion-Rate.

• p-Wert: Gibt die Wahrscheinlichkeit an, dass es keinen tatsächlichen Unterschied zwischen der Variante und der Baseline gibt. Mit anderen Worten: Jeder beobachtete Unterschied ist wahrscheinlich auf Zufall zurückzuführen. Je niedriger der p-Wert ist, desto höher ist die Wahrscheinlichkeit, dass die beobachtete Leistung auch in Zukunft erreicht wird. Ein Wert von 0,05 oder niedriger 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 Wert der Variante größer als der Kontrollwert ist. In Firebase wird für kontinuierliche Variablen (numerische Werte wie Umsatz) ein T-Test mit ungleicher Varianz 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 Proportionen verwendet.

Die Testergebnisse liefern wichtige Informationen zu den einzelnen Testvarianten, darunter:

• Wie viel höher oder niedriger die einzelnen Testmesswerte im Vergleich zum Kontrollwert sind, direkt gemessen (d. h. die tatsächlich beobachteten Daten)
• Die Wahrscheinlichkeit, dass der beobachtete Unterschied zwischen Variante und Baseline aufgrund von Zufall entstanden ist (p-Wert)
• Ein Bereich, der wahrscheinlich den „wahren“ Leistungsunterschied zwischen der Variante und der Baseline für jeden Testmesswert enthält. So können Sie die Leistungsszenarien „Best Case“ und „Worst Case“ nachvollziehen.

Ergebnisse von Google Optimize-Tests auswerten

Firebase A/B Testing Die Ergebnisse von Tests, die vor dem 23. Oktober 2023 gestartet wurden, wurden mit Google Optimize berechnet. In Google Optimize wurden anhand der bayesschen Inferenz aus Ihren Testdaten aussagekräftige Statistiken erstellt.

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

Für jeden Messwert werden die folgenden Statistiken angezeigt:

Erfasste Daten

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

Modellierte Daten

• Wahrscheinlichkeit, die ursprüngliche Variante zu übertreffen: gibt an, wie wahrscheinlich es ist, dass der Messwert für diese Variante im Vergleich zur ursprünglichen Variante höher ist
• Abweichung von ursprünglicher Variante in %: Berechnet auf Grundlage der Medianmodellschätzungen des Messwerts für die Variante und die ursprüngliche Variante.
• Messwertbereiche: Bereiche, in denen der Messwert mit einer Wahrscheinlichkeit von 50 % und 95 % am wahrscheinlichsten zu finden ist

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

1. Wie viel höher oder niedriger der jeweilige Testmesswert im Vergleich zum Kontrollwert ist, direkt gemessen (d. h. die tatsächlich beobachteten Daten)
2. Die Wahrscheinlichkeit, dass jeder Testmesswert höher als die Kontrollgruppe bzw. der beste Wert insgesamt ist, basierend auf der bayesschen Inferenz (Wahrscheinlichkeit, besser bzw. am besten zu sein)
3. Plausible Bereiche für jeden Testmesswert basierend auf bayesscher Inferenz – Best-Case- und Worst-Case-Szenarien (glaubwürdige Intervalle)

Bestimmung des Leaders

Bei Tests, bei denen die frequentistische Inferenz verwendet wird, erklärt Firebase eine Variante als führend, 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, für die Google Optimize verwendet wurde, erklärte Firebase eine Variante als „eindeutigen Gewinner“, wenn die Wahrscheinlichkeit, dass sie beim primären Messwert besser als die Baseline-Variante abschneidet, über 95 % lag. Wenn mehrere Varianten die Kriterien für einen klaren Gewinner erfüllten, wurde nur die insgesamt leistungsstärkste Variante als „Klarer 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 Vorteil der Änderung, das Risiko einer Verschlechterung (z. B. der untere Grenzwert des Konfidenzintervalls für die Verbesserung) und die Auswirkungen auf andere Messwerte als das primäre Ziel.

Wenn Ihr primärer Messwert beispielsweise „Nutzer ohne Abstürze“ ist und Variante A deutlich besser abschneidet als die Baseline, die Messwerte zur Nutzerbindung für Variante A aber hinter der Baseline liegen, sollten Sie weitere Untersuchungen durchführen, bevor Sie Variante A weiter einführen.

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

Höchstdauer für Tests

Firebase empfiehlt, einen Test so lange laufen zu lassen, bis die folgenden Bedingungen erfüllt sind:

1. Für den Test wurden genügend Daten erfasst, 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 Ihres Tests zu bewerten.
2. Der Test hat lange genug gedauert, um eine repräsentative Stichprobe Ihrer Nutzer zu erhalten und die langfristige Leistung zu messen. Zwei Wochen ist die empfohlene Mindestlaufzeit für einen typischen Remote Config-Test.

Testdaten werden nach Testbeginn maximal 90 Tage lang 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. Ab diesem Zeitpunkt rufen Clients Parameterwerte basierend auf den in der Remote Config-Vorlage festgelegten Bedingungen ab. Verlaufsdaten aus Tests werden so lange aufbewahrt, bis Sie den Test löschen.

BigQuery-Schema

Sie können Testdaten von A/B Testing nicht nur in der Firebase-Konsole aufrufen, sondern auch in BigQuery Testdaten prüfen 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 Nutzereigenschaften, die Testinformationen enthalten, haben das Format userProperty.key like "firebase_exp_%" oder userProperty.key = "firebase_exp_01", wobei 01 die Test-ID ist und userProperty.value.string_value den (nullbasierten) Index der Testvariante enthält.

Sie können diese Testnutzereigenschaften verwenden, um Testdaten zu extrahieren. Dadurch haben Sie die Möglichkeit, die Testergebnisse auf viele verschiedene Arten aufzuschlüsseln und die Ergebnisse von A/B Testing unabhängig zu prüfen.

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

1. BigQuery-Export für Google Analytics in der Firebase Console aktivieren
2. Über 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 haben, können Sie die BigQuery-Sandbox verwenden, um kostenlos auf BigQuery zuzugreifen. Dabei gelten die Sandbox-Beschränkungen. Weitere Informationen findest du unter Preise und die BigQuery-Sandbox.

Achten Sie zuerst darauf, dass Sie Ihre Analytics-Daten nach BigQuery exportieren:

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

5. Wählen Sie eine Region und die 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 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.

Auf A/B Testing-Daten in BigQuery zugreifen

Bevor Sie Daten für einen bestimmten Test abfragen, sollten Sie einige oder alle der folgenden Informationen für Ihre Abfrage bereitstellen:

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

Tipp: Wenn Sie den Blaze-Tarif nutzen, kann Firebase eine Beispielabfrage generieren, um den Namen des Tests, die Variante, den Ereignisnamen und die Anzahl der Ereignisse für den ausgewählten Test zu extrahieren. Weitere Informationen finden Sie unter Testdaten mit der automatisch generierten Abfrage der Firebase-Konsole abfragen

.

Nachdem Sie die Informationen für die Abfrage zusammengestellt haben, gehen Sie so vor:

1. Öffnen Sie BigQuery in der Google Cloud-Konsole.
2. Wählen Sie Ihr Projekt und dann SQL-Abfrage erstellen aus.
3. Fügen Sie Ihre Suchanfrage hinzu. Beispiele für ausführbare Abfragen finden Sie unter Beispielabfragen ansehen.
4. Klicken Sie auf Ausführen.

Tipp: In diesen Schritten wird die Verwendung der Google Cloud-Konsole beschrieben. Sie können BigQuery aber auch mit der Befehlszeile oder den Clientbibliotheken abfragen. Weitere Informationen finden Sie in der BigQuery-Dokumentation.

Testdaten mit der automatisch generierten Abfrage in der Firebase Console abfragen

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

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 Optionsmenü 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 angezeigt, mit der Sie Ihre Testdaten abfragen können.

Das folgende Beispiel zeigt eine generierte Abfrage für einen Test mit drei Varianten (einschließlich der Baseline) namens „Winterwelcome Experiment“. Für jedes Ereignis werden der Name des aktiven Tests, der Variantenname, das eindeutige Ereignis und die Ereignisanzahl zurückgegeben. Beachten Sie, dass Query Builder den Projektnamen im Tabellennamen nicht angibt, 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 ansehen.

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.

Werte für die Standardabweichung von Käufen und Tests aus allen Tests extrahieren

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

Weitere Informationen dazu, wie A/B Testing die Inferenz berechnet, 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

In der folgenden Beispielabfrage wird gezeigt, wie Sie Daten für einen bestimmten Test in BigQuery abrufen. Diese Beispielabfrage gibt den Testnamen, die Variantennamen (einschließlich Baseline), die Ereignisnamen und die Ereignisanzahl 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

Limits

A/B Testing ist auf insgesamt 300 Tests, 24 laufende Tests und 24 Testentwürfe beschränkt. Diese Limits gelten für Remote Config Roll-outs. Wenn Sie beispielsweise zwei laufende Einführungen und drei laufende Tests haben, können Sie bis zu 19 zusätzliche Einführungen oder Tests haben.

• Wenn Sie das Limit von 300 Tests insgesamt oder 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 Einführungen erreichen, müssen Sie einen laufenden Test oder eine laufende Einführung beenden, bevor Sie einen neuen starten können.

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