Experimente

Experimente ermöglichen es Ihnen, A/B-Tests im Spiel und beim Matchmaking durchzuführen, um die ursächlichen Auswirkungen von Änderungen an Ihrem Spiel zu messen. Zum Beispiel können Sie unterschiedlichen Spielergruppen verschiedene Onboarding-Erfahrungen zeigen und den Unterschied in der Spielzeit, der Bindung und anderen wichtigen Leistungskennzahlen messen.

Experimente sind hervorragend geeignet, um Folgendes zu messen:

• Engagement – Onboarding-Flüsse, Fortschrittssysteme, Steuerungsmechanismen, individuelles Matchmaking
• Monetarisierung – Sichtbarkeit des Shops und Benutzererfahrung, Starterpakettypen, Preisgestaltung

Experimente erstellen

Experimente gibt es in zwei Typen:

• In-Spiel-Experimente ermöglichen es Ihnen, die Auswirkungen unterschiedlicher Konfigurationswerte zu messen.
• Matchmaking-Experimente ermöglichen es Ihnen, die Auswirkungen unterschiedlicher konfektionierter Matchmaking-Konfigurationen zu messen. Im Gegensatz zu In-Spiel-Experimenten können Sie nur ein Matchmaking-Experiment gleichzeitig durchführen.

1. Wenn Sie noch keine Konfiguration haben, erstellen Sie eine für Ihr Spiel.

2. Gehen Sie auf die Creator Hub Experimente-Seite für Ihr Spiel und klicken Sie auf Experiment erstellen.

3. Wählen Sie für Typ die Option In-Erfahrung.

4. Geben Sie einen Namen, eine Ziel-Metrik und die geplante Dauer des Experiments an. Experimente dauern zwischen 14 und 60 Tagen.

   Unabhängig davon, was Sie als Ihre Ziel-Metrik wählen, verfolgen Experimente alle Metriken in der Liste.

5. Wählen Sie eine Prozentverteilung. Diese Zahl ist der Prozentsatz der Spieler, die Sie in das Experiment einbeziehen möchten.

   Im Allgemeinen gilt: Je mehr Personen Sie in ein Experiment einbeziehen, desto besser die Daten, aber verwenden Sie Ihr Urteilsvermögen, um zu entscheiden, was für Ihr Spiel am besten ist.

   Achten Sie auf den minimalen nachweisbaren Effekt, der die kleinste Änderung in der ausgewählten Metrik ist, die das Experiment zuverlässig erkennen kann.

6. Geben Sie Varianten und Prozentsätze an.

   Varianten sind alternative Werte für Ihre Konfiguration. Für einen numerischen Konfigurationsschlüssel bossHealth mit einem Kontrollwert von 500 könnten Sie eine Variante von 300 angeben. Sie können bis zu zwei Varianten und eine Kontrolle in einem Experiment haben.

   Prozentsätze bestimmen, wie Varianten innerhalb der Experimentverteilung zugewiesen werden. Betrachten Sie folgendes Beispiel:

   • Sie wählen eine Gesamtverteilung von 40 %.
   • Sie geben zwei Varianten und eine 50/50-Aufteilung zwischen ihnen und der Kontrolle an.

   In diesem Beispiel sind 60 % Ihrer Benutzer vom Experiment ausgeschlossen; diese Benutzer erhalten die Kontrolle und haben keinerlei Einfluss auf die Ergebnisse des Experiments. Etwa 20 % Ihrer Benutzer erhalten die Kontrolle als Teil des Experiments. Weitere 20 % erhalten die Variante. Je nach Spielerzahl könnte diese Verteilung nicht groß genug sein, um umsetzbare Ergebnisse zu liefern.

   Im Zweifelsfall empfehlen wir einfache 50/50-Experimente mit einer Variante und einer Kontrolle bei großen Verteilungen. Die Experimente sind einfacher zu konfigurieren, und die Ergebnisse sind leichter zu interpretieren.

   

7. Der letzte Schritt ist die Planung. Sie können Experimente sofort starten oder für ein späteres Datum und eine spätere Uhrzeit planen. Nachdem Sie ein Experiment geplant haben, können Sie seine Konfiguration (Dauer, Verteilungsprozent, Varianten usw.) nicht mehr ändern, aber Sie können es neu planen.

Metriken

Experimente verfolgen die folgenden Metriken über die Dauer des Experiments.

Experimentstatus

Die Experimente-Seite zeigt die folgenden Status für Experimente an.

Fügen Sie Experimente zu Ihrem Code hinzu

Die Anwendung von In-Spiel-Experimenten ist ähnlich wie das Anwenden von Konfigurationen. Der Hauptunterschied besteht in der Verwendung von ConfigService:GetConfigForPlayerAsync() anstelle von ConfigService:GetConfigAsync().

GetConfigForPlayerAsync() ruft einen spielerspezifischen Snapshot ab. Wenn Sie GetValue() aufrufen, überprüft der Snapshot auf ein aktives Experiment und meldet (oder meldet nicht) den Benutzer basierend auf dem Verteilungsprozentsatz an.

local ConfigService = game:GetService("ConfigService")
local Players = game:GetService("Players")

local function onPlayerAdded(player)
    local playerConfig = ConfigService:GetConfigForPlayerAsync(player)
    local leaderboardColor = playerConfig:GetValue("leaderboardColor")
end

Players.PlayerAdded:Connect(onPlayerAdded)

• Sie müssen GetConfigForPlayerAsync() separat für jeden Spieler aufrufen; GetConfigAsync() gilt nicht für Experimente.

• Nachdem Sie GetValue() auf einem spielerspezifischen Snapshot aufgerufen haben, ist der Spieler, der mit dem Snapshot verbunden ist, für dieses Schlüssel und nur dieses Schlüssel in das Experiment eingeschrieben. Alle weiteren Aufrufe der Methode geben während der Dauer des Experiments die gleiche Kontrolle oder Variante zurück. Nur der erste Aufruf ist zufällig.

  Warten Sie mit dem Aufruf von GetValue(), bis Sie es benötigen. Ein zu früher Aufruf von GetValue() kann dazu führen, dass Sie Spieler einschreiben, die nie mit dem Teil des Spiels interagieren, an dem Sie experimentieren.

• Die Einschreibung in Experimente ist nicht auf neue Benutzer beschränkt. Selbst wenn ein Benutzer zuvor einen Wert von GetConfigAsync() erhalten hat, können Sie ihn weiterhin mit einem spielerspezifischen Snapshot von GetConfigForPlayerAsync() in ein Experiment einschreiben.

• Wenn ein Schlüssel in einem spielerspezifischen Snapshot kein aktives Experiment hat, gibt GetValue() den Standardkonfigurationswert (oder nil, wenn kein Wert vorhanden ist) zurück.

Zielgerichtete Einschreibung

Wenn Sie einen Teil Ihrer Spieler, der bestimmten Kriterien entspricht, anvisieren möchten, müssen Sie zusätzlichen Code schreiben, um diese Kriterien zu überprüfen und erst dann GetValue() aufrufen, um sie in das Experiment einzuschreiben. Betrachten Sie folgendes Beispiel:

• Sie möchten ein neues Steuerungsschema in Ihrem Spiel testen.
• Sie möchten bestehende Spieler (die vermutlich an das bestehende Schema gewöhnt sind) nicht einbeziehen, sondern nur neue Spieler.

Ihr Code könnte so aussehen:

local function getControlScheme(player, racesCompleted)
    if racesCompleted > 0 then
        return "standardScheme"
    else
        -- Spieler ist neu, in Experiment einschreiben
        local playerConfigSnapshot = ConfigService:GetConfigForPlayerAsync(player)
        if playerConfigSnapshot:GetValue("useNewControlScheme") then
            return "newScheme"
        else
            return "standardScheme"
        end
    end
end

Wenn Sie möchten, dass das Steuerungsschema in den folgenden Sitzungen bestehen bleibt, müssen Sie wahrscheinlich einen Wert im Datenspeicher für den Eintrag des Spielers hinzufügen.

Ergebnisse anzeigen und interpretieren

Nachdem ein Experiment mindestens 24 Stunden gelaufen ist, klicken Sie auf Anzeigen, um Details und Ergebnisse zu sehen.

Sie können die Gesamtanzahl der eingeschriebenen Spieler sowie die Anzahl der Spieler sehen, die den Kontrollwert und jede Variante erhalten haben. Diese Seite früh im Experiment zu betrachten, ist nützlich, um sicherzustellen, dass das Experiment ordnungsgemäß läuft, nicht um Maßnahmen zu ergreifen. Bevor Sie Maßnahmen ergreifen, siehe Best Practices.

Nachdem das Experiment abgeschlossen ist, überprüfen Sie die Ergebnisse-Registerkarte. Achten Sie auf statistisch signifikante Änderungen in den Zielmetriken, die im Dashboard grün oder rot hervorgehoben sind. Diese Änderungen zeigen wahrscheinlicher den Einfluss Ihrer Variante und sind weniger wahrscheinlich falsch positiv oder negativ.

Fahren Sie mit der Maus über eine Metrik, um die Schaltfläche Vertrauen anzeigen anzuzeigen, die das Vertrauensintervall anzeigt.

Eine Metrik ist statistisch signifikant, wenn das Vertrauensintervall für ihre prozentuale Änderung nicht mit 0 % überlappt. Im folgenden Beispiel beträgt die D1-Retention 17,4 %, mit unteren und oberen Grenzen von 8,02 % und 22,03 %, was die Änderung statistisch signifikant macht.

Zur Vereinfachung ermöglicht die Ergebnisseite, den Standardkonfigurationswert durch eine der Varianten aus dem Experiment zu ersetzen. Klicken Sie auf Entscheidung treffen, um eine Variante auszuwählen, oder auf Gewinner ändern, wenn Sie Ihre Meinung ändern. Wenn Sie dann zur Konfigurationen-Seite zurückkehren, sollten Sie den neuen Wert sehen.

Best Practices für Experimente

• Verwenden Sie den minimalen nachweisbaren Effekt (MDE), um zu entscheiden, ob Ihr Experiment es wert ist, durchgeführt zu werden.

  Roblox berechnet den MDE anhand Ihrer Zielmetriken und der Anzahl der Spieler pro Variante, die auf täglichen aktiven Benutzern, dem Verteilungsprozentsatz, der Dauer des Experiments und den Variantenaufteilungen basieren. Wenn der MDE für Ihre Zielmetrik zu hoch ist (zum Beispiel mehr als 100 %), ist es unwahrscheinlich, dass Sie statistische Signifikanz erreichen können. Spiele mit weniger als 1.000 täglichen aktiven Benutzern könnten Schwierigkeiten haben, nützliche Daten aus Experimenten zu erhalten.

  

• Beginnen Sie mit einer Hypothese. Anstatt nur eine Variable zu ändern und die Ergebnisse zu überprüfen, schreiben Sie eine Ursache-Wirkung-Aussage darüber, was Sie geändert haben, was Sie erwarten, dass passiert und warum. Je mehr Sie experimentieren, desto nützlicher ist es, ein Set schriftlicher Hypothesen zu haben, um Ihre Ergebnisse zu begleiten, um Ihr Denken zu klären und neue Ideen für Experimente zu entwickeln.

• Lassen Sie Experimente ihre volle Dauer laufen. Der Neuheitseffekt (vorübergehendes Interesse an einer Veränderung, nicht weil sie besser ist, sondern weil sie neu ist) kann frühe Ergebnisse stark verzerren und manchmal dazu führen, dass sie in und aus der statistischen Signifikanz schwanken. Ein vorzeitiges Beenden von Experimenten erhöht die Wahrscheinlichkeit, dass Sie voreilige Maßnahmen aufgrund anomaler Spitzen ergreifen, die mehr Daten geglättet oder sogar widerlegt hätten.

• Handeln Sie nicht ohne statistische Signifikanz. Selbst scheinbar große Änderungen im Spielerverhalten könnten nicht statistisch signifikant sein, was im Allgemeinen auf die geringe Stichprobengröße zurückzuführen ist. Wenn eine Änderung nicht statistisch signifikant ist, ignorieren Sie sie.

• Vermeiden Sie Änderungen während Experimente. Große Fehler erfordern natürlich Behebungen, aber Änderungen am Spielinhalt können das Spielerverhalten beeinflussen und Ihre Ergebnisse ungültig machen, auch wenn die Änderungen scheinbar nichts mit Ihrem Experiment zu tun haben. Führen Sie ähnliche Experimente nur gleichzeitig durch, wenn Sie sicher sind, dass sie sich nicht gegenseitig beeinflussen.

• Verwenden Sie Vertrauensintervalle für tiefere Analysen von Metriken und überprüfen Sie auf Grenzfälle statistischer Signifikanz. Wenn das Vertrauensintervall zu weit ist, könnte die Metrik niemals statistische Signifikanz erreichen.

• Wenn eine Metrik signifikant steigt und eine andere signifikant sinkt, müssen Sie entscheiden, ob der Kompromiss es wert ist, möglicherweise in Verbindung mit anderen statistisch signifikanten Bewegungen.

• Experimente bieten ein starkes Signal, aber statistische Signifikanz handelt mit Wahrscheinlichkeiten, nicht mit Gewissheiten—daher das Vertrauensintervall. Datenvariabilität, Stichprobengröße und Änderungsausmaß beeinflussen alle die Wahrscheinlichkeit, zu erkennen, ob eine Variante das Verhalten der Spieler beeinflusst hat. Jede Maßnahme, die Sie basierend auf den Ergebnissen eines Experiments ergreifen, sollte gegen qualitative Daten wie Feedback von Spielern und Ihre allgemeine Vision für das Spiel abgewogen werden.

• Dokumentieren Sie Ihre Ergebnisse und Entscheidungen. Selbst wenn Sie sie nicht nutzen, um zusätzliche Experimente durchzuführen, kann ein Wissens- und Nachweisbestand darüber, wie Sie Ihre Spiele gestalten, von Nutzen sein.