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ü Mehr 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 Zielgruppe erstellen, kann es 24 bis 48 Stunden dauern, bis neue Nutzer in die Zielgruppe aufgenommen 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

Bei Testereignissen zur Aktivierung 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 Ausrichtung 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 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

Firebase A/B Testing verwendet die frequentistische Inferenz, um die Wahrscheinlichkeit zu ermitteln, dass Ihre Testergebnisse ausschließlich aufgrund von Zufall zustande gekommen sind. Diese Wahrscheinlichkeit wird durch einen Wahrscheinlichkeitswert oder einen p-Wert dargestellt. Der p-Wert ist die Wahrscheinlichkeit, dass ein so großer oder größerer Leistungsunterschied zwischen zwei Varianten aufgrund von Zufall aufgetreten ist, wenn es tatsächlich keinen Effekt gibt. Er wird mit einem Wert zwischen 0 und 1 gemessen. In A/B Testing wird ein Signifikanzniveau von 0,05 verwendet, sodass:

• Ein p-Wert unter 0,05 bedeutet, dass die Wahrscheinlichkeit, dass ein so extremer beobachteter Unterschied zufällig auftritt, bei einer tatsächlichen Differenz von null unter 5% liegt. 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 angezeigt. Wenn Sie beispielsweise den Werbeumsatz pro Nutzer als Messwert erfassen, wird der erfasste Umsatz pro Nutzer angezeigt. Wenn Sie die Anzahl der Nutzer ohne Abstürze erfassen, wird der Prozentsatz der Nutzer erfasst, bei denen es zu keinem Absturz gekommen ist. Diese Daten sind seit Beginn des Tests kumulative.

Die Ergebnisse werden in beobachtete Daten und Inferenzdaten unterteilt. Die beobachteten Daten werden direkt aus Google Analytics-Daten berechnet. Inferenzdaten enthalten 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 aktiven Nutzer, Anzahl der Nutzer, bei denen ein Absturz aufgetreten ist, Gesamtumsatz)
• Messwertspezifischer Wert (Bindungsrate, Conversion-Rate, Umsatz pro Nutzer)
• Prozentuale Differenz (Steigerung) zwischen der Variante und der ursprünglichen Variante

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 Konfidenzintervall von 95% für den geschätzten Gesamtumsatz von 5 bis 10 € führt, liegt die Wahrscheinlichkeit, dass die tatsächliche Differenz der Mittelwerte zwischen 5 und 10 € liegt, bei 95 %. Wenn der Konfidenzintervall den Wert 0 enthält, wurde kein statistisch signifikanter Unterschied zwischen der Variante und der Baseline festgestellt.

  Konfidenzintervallwerte werden im 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: Die Wahrscheinlichkeit, dass Daten so extrem sind wie die im Test erzielten Ergebnisse, vorausgesetzt, dass es keinen echten Unterschied zwischen der Variante und der Kontrollgruppe gibt. Je niedriger der p-Wert, desto höher ist die Wahrscheinlichkeit, dass die beobachtete Leistung auch bei Wiederholung des Tests 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 Baselinewert 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 erfassten Daten werden direkt anhand der Analytics-Daten berechnet und die modellierten 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)
• 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: Die Wahrscheinlichkeit, dass der Messwert für diese Variante im Vergleich zur Baseline 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 liegt

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 Messwert des Tests höher als der der 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 „eindeutig führend“, 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 Nutzerbindungsmesswerte für Variante A aber hinter der Nutzerbindung der Baseline zurückbleiben, 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 auszuführen, bis eine der folgenden Bedingungen erfüllt ist:

1. Im Test wurden genügend Daten erfasst, um ein aussagekräftiges Ergebnis zu erhalten. 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 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 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. 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 sich A/B Testing-Testdaten nicht nur in der Firebase-Konsole ansehen, sondern auch in BigQuery prüfen und analysieren. Für A/B Testing gibt es keine separate BigQuery-Tabelle. Test- und Variantenmitgliedschaften werden jedoch in jedem Google Analytics-Ereignis in den Analytics-Ereignistabellen gespeichert.

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

Mit diesen Nutzereigenschaften für Tests können Sie Testdaten extrahieren. So können Sie die Testergebnisse auf viele verschiedene Arten unterteilen und die Ergebnisse von A/B Testing unabhängig überprü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 finden Sie unter Preise und die BigQuery-Sandbox.

Prüfen Sie zuerst, ob Sie Ihre Analytics-Daten in 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 die 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 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 maximieren, um den Namen der Google Analytics-Ereignistabelle (project_name.analytics_000000000.events) zu sehen.
• Testdatum:Um eine schnellere und effizientere Abfrage zu erstellen, sollten Sie Ihre Abfragen auf die Google Analytics-Tagespartitionen der 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 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 Zielvorhaben, 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 grundlegende Abfrage wird 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 Kontrollgruppe) mit dem Namen „Test zur Winter-Willkommensseite“. Es werden der Name des aktiven Tests, der Name der Variante, das eindeutige Ereignis und die Ereignisanzahl für jedes Ereignis zurückgegeben. Im Query Builder wird der 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 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

Die folgende Beispielabfrage zeigt, wie Sie Daten für einen bestimmten Test in BigQuery abrufen. Diese Beispielabfrage gibt den Namen des Tests, die Namen der Varianten (einschließlich der Kontrollgruppe), Ereignisnamen und Ereigniszahlen 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 auch 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 Kontrollgruppe) und bis zu 25 Parameter für jede Variante umfassen. Ein Test kann eine Größe von bis zu 200 KiB haben. Dazu gehören Variantennamen, Variantenparameter und andere Konfigurationsmetadaten.