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 dem Start eines Tests keine Mindeststichprobengröße festgelegt werden. Im Allgemeinen sollten Sie die größte Testbeteiligung auswählen, die Ihnen geeignet erscheint. Größere Stichproben erhöhen die Wahrscheinlichkeit, ein statistisch signifikantes Ergebnis zu erzielen, insbesondere wenn die Leistungsunterschiede zwischen den Varianten gering sind. Möglicherweise ist es auch hilfreich, einen Online-Stichprobenrechner zu verwenden, um die empfohlene Stichprobengröße basierend auf den Merkmalen Ihres Experiments zu ermitteln.

Tests bearbeiten

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

• Testname
• Beschreibung
• Ausrichtungsbedingungen
• Variantenwerte

So bearbeiten Sie einen Test:

1. Rufen Sie in der Firebase-Konsole DevOps & Engagement > A/B Testing auf.
2. Öffnen Sie die Ergebnisseite für den Test, den Sie ändern möchten.
3. Wählen Sie im Menü Mehr die Option Laufenden Test bearbeiten aus.
4. Nehmen Sie die gewünschten Änderungen vor und klicken Sie auf Veröffentlichen.

Beachten Sie, dass sich eine Änderung des App-Verhaltens während eines laufenden Tests auf die Ergebnisse auswirken kann.

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 Nutzer, die die Variante sehen), werden den Testvarianten entsprechend der Variantengewichtung 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 in die Zielgruppe aufgenommen werden.
• Neue Nutzer werden in der Regel 24 bis 48 Stunden, nachdem sie die Voraussetzungen erfüllen, in die entsprechenden Zielgruppen aufgenommen.

Für zeitkritische Ausrichtung solltest du die Verwendung von Google Analytics-Nutzereigenschaften oder integrierten Ausrichtungsoptionen wie Land oder Region, Sprache und App-Version in Betracht ziehen.

Sobald ein Nutzer einem Test zugewiesen wurde, wird er dauerhaft seiner Testvariante zugeordnet und erhält Parameterwerte aus dem Test, solange der Test aktiv ist. Das gilt auch dann, wenn sich seine Nutzereigenschaften ändern und er die Targeting-Kriterien 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 Targeting-Kriterien 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 des Tests können Sie die Standardgewichtung der Varianten ändern, um einen größeren Prozentsatz der Testnutzer einer Variante zuzuordnen.

Testergebnisse interpretieren

Firebase A/B Testing verwendet die frequentistische Inferenz, um Ihnen zu helfen, die Wahrscheinlichkeit zu verstehen, dass Ihre Testergebnisse ausschließlich auf Zufall zurückzuführen sind. Diese Wahrscheinlichkeit wird durch einen Wahrscheinlichkeitswert oder p-Wert dargestellt. Der p-Wert ist die Wahrscheinlichkeit, dass ein Leistungsunterschied dieser oder größerer Größenordnung zwischen zwei Varianten zufällig aufgetreten sein könnte, wenn tatsächlich kein Effekt vorliegt. Er wird durch einen Wert zwischen 0 und 1 gemessen. A/B Testing verwendet ein Signifikanzniveau von 0,05, sodass:

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

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

In der Grafik mit den Testergebnissen werden die kumulativen Durchschnittswerte des ausgewählten Messwerts angezeigt. Wenn Sie beispielsweise „Werbeeinnahmen pro Nutzer“ als Messwert erfassen, werden die beobachteten Einnahmen pro Nutzer angezeigt. Wenn Sie „Absturzfreie Nutzer“ erfassen, wird der Prozentsatz der Nutzer erfasst, bei denen kein Absturz aufgetreten ist. Diese Daten sind kumulativ ab Beginn des Tests.

Die Ergebnisse sind in Beobachtete Daten und Inferenzdaten unterteilt. Erfasste Daten werden direkt anhand der Google Analytics-Daten berechnet. Die Inferenzdaten enthalten p-Werte und Konfidenzintervalle, mit denen Sie die statistische Signifikanz der erfassten Daten bewerten können.

Für jeden Messwert werden die folgenden Statistiken angezeigt:

Erfasste Daten

• Gesamtwert für den erfassten Messwert (Anzahl der gehaltenen Nutzer, Anzahl der Nutzer mit Abstürzen, Gesamteinnahmen)
• Messwertspezifische Rate (Bindungsrate, Conversion-Rate, Umsatz pro Nutzer)
• Prozentualer Unterschied (Anstieg) zwischen der Variante und der Baseline

Inferenzdaten

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

  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, USD für den Werbeumsatz pro Nutzer und Prozentsatz für die Conversion-Rate.

• p-Wert: Dieser Wert gibt die Wahrscheinlichkeit an, dass Daten beobachtet werden, die so extrem sind wie die im Test erzielten Ergebnisse, wenn es keinen tatsächlichen Unterschied zwischen der Variante und der Baseline gibt. Je niedriger der p-Wert, desto höher ist 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 zufällig waren. Die p-Werte basieren auf einem einseitigen Test, bei dem der Wert der Variante größer als der Wert der Baseline ist. Firebase verwendet einen t-Test mit ungleicher Varianz für kontinuierliche Variablen (numerische Werte wie Umsatz) und einen z-Test für Proportionen für Conversion-Daten (binäre Werte wie Nutzerbindung, absturzfreie Nutzer, Nutzer, die ein Google Analytics-Ereignis auslösen).

Die Testergebnisse liefern wichtige Informationen zu jeder Testvariante, darunter:

• Wie viel höher oder niedriger jeder Testmesswert im Vergleich zur Baseline ist, wie 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 „tatsächlichen“ Leistungsunterschied zwischen der Variante und der Baseline für jeden Testmesswert enthält. So können Sie die Szenarien für die „beste“ und die „schlechteste“ Leistung nachvollziehen.

Leader-Bestimmung

Bei Tests mit frequentistischer Inferenz 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.

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. Sie sollten die erwarteten Vorteile der Änderung, das Abwärtsrisiko (z. B. das untere Ende des Konfidenzintervalls für die Verbesserung) und die Auswirkungen auf andere Messwerte als das primäre Ziel berücksichtigen.

Wenn Ihr primärer Messwert beispielsweise „Absturzfreie Nutzer“ ist und Variante A deutlich besser als die Baseline abschneidet, die Messwerte für die Nutzerbindung von Variante A jedoch hinter der Baseline zurückbleiben, sollten Sie weitere Untersuchungen durchführen, bevor Sie Variante A auf breiterer Basis einführen.

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

Höchstdauer für Tests

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

1. Im Rahmen des Tests wurden genügend Daten erfasst, um ein aussagekräftiges Ergebnis zu liefern. Tests 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 ist lange genug gelaufen, 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 in der Firebase-Konsole nicht mehr aktualisiert und es werden keine testspezifischen Parameterwerte mehr gesendet. An diesem Punkt beginnen Clients, Parameterwerte basierend auf den in der Vorlage Remote Config festgelegten Bedingungen abzurufen. Verlaufsdaten von Tests werden so lange aufbewahrt, bis Sie den Test löschen.

BigQuery-Schema

Sie können A/B Testing-Testdaten nicht nur in der Firebase Console ansehen, sondern auch in BigQuery prüfen und analysieren. A/B Testing hat zwar keine separate BigQuery-Tabelle, aber die Zugehörigkeit zu Tests und Varianten wird 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.

Mit diesen Nutzereigenschaften können Sie 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 dieser Anleitung 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. Dabei gelten die Sandbox-Limits. Weitere Informationen finden Sie unter Preise und die BigQuery-Sandbox.

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

1. Rufen Sie in der Firebase-Konsole den Tab Einstellungen > Integrationen auf.

2. Klicken Sie auf der Karte BigQuery auf Verwalten und prüfen Sie, ob Ihr Projekt Analytics-Daten nach BigQuery exportiert.

   Wenn auf der Karte Verknüpfen steht, müssen Sie den Export einrichten (fahren Sie mit dem nächsten Schritt fort).

3. Wenn Sie den Export einrichten müssen:

   1. Lesen Sie den Artikel Firebase mit BigQuery verknüpfen und klicken Sie dann auf Weiter.

   2. Aktivieren Sie im Abschnitt Integration konfigurieren die Option Google Analytics.

   3. Wählen Sie eine Region und die Exporteinstellungen aus.

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

   4. 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.

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 einholen:

• 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.
• Google Analytics-Property-ID: Ihre 9-stellige Google Analytics-Property-ID. Sie finden sie in 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) einzublenden.
• Testdatum: Um eine schnellere und effizientere Abfrage zu erstellen, empfiehlt es sich, die Abfragen auf die Partitionen der täglichen Ereignistabelle Google Analytics zu beschränken, die Ihre Testdaten enthalten. Diese Tabellen sind mit dem Suffix YYYYMMDD gekennzeichnet. Wenn Ihr Test also vom 2. Februar 2026 bis zum 2. Mai 2026 lief, geben Sie _TABLE_SUFFIX between '20260202' AND '20260502' an. Ein Beispiel finden Sie unter Werte eines bestimmten Tests auswählen.
• Ereignisnamen: Diese entsprechen in der Regel den Zielmesswerten, die Sie im Test konfiguriert haben. Beispiel: in_app_purchase-Ereignisse, ad_impression 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 finden Sie unter Testdaten mit der automatisch generierten Abfrage der Firebase-Konsole abfragen

.

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

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

Tipp: In diesen Schritten wird die Verwendung der Google Cloud Console 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 angezeigten Test zurückgibt.

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

1. Rufen Sie in der Firebase-Konsole DevOps & Engagement > A/B Testing auf.
2. Wählen Sie den A/B Testing-Test aus, den Sie abfragen möchten, um die Testübersicht zu öffnen.
3. 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 bereitgestellt, 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) mit dem Namen „Winter welcome experiment“. Es werden der Name des aktiven Tests, der Name der Variante, das eindeutige Ereignis und die Ereignisanzahl für jedes Ereignis zurückgegeben. Beachten Sie, dass der Query Builder den Projektnamen nicht im Tabellennamen 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 '20260202' AND '20260502')
    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.

Kauf- und Teststandardabweichungswerte aus allen Tests extrahieren

Sie können die Testergebnisdaten verwenden, um die Ergebnisse vonFirebase A/B Testingunabhängig zu überprüfen. Mit der folgenden BigQuery-SQL-Anweisung werden Testvarianten, die Anzahl der einzelnen Nutzer in jeder Variante, die Summe der Gesamteinnahmen aus in_app_purchase- und ecommerce_purchase-Ereignissen sowie die Standardabweichungen für alle Tests innerhalb des Zeitraums extrahiert, der durch die _TABLE_SUFFIX-Start- und ‑Enddaten angegeben ist. 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 eines bestimmten Tests auswählen

Die folgende Beispielabfrage zeigt, 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 beschränkt, davon 24 laufende Tests. Diese Limits werden mit Remote Config-Roll-outs geteilt. Wenn Sie beispielsweise zwei laufende Roll-outs und drei laufende Tests haben, können Sie bis zu 19 zusätzliche Roll-outs oder Tests haben.

• Wenn Sie das Limit von 300 Tests erreicht haben, 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 pro Variante haben. Ein Test kann eine Größe von bis zu etwa 200 KiB haben. Dazu gehören Variantennamen, Variantenparameter und andere Konfigurationsmetadaten.