Experimenten

Experimenten stellen je in staat om A/B-tests in het spel en matchmaking uit te voeren om de causale impact van wijzigingen in je spel te meten. Je kunt bijvoorbeeld verschillende onboarding-ervaringen aan verschillende spelers tonen en het verschil in speeltijd, retentie en andere belangrijke prestatie-indicatoren meten.

Experimenten zijn uitstekend voor het meten van het volgende:

• Betrokkenheid - Onboarding-stromen, voortgangssystemen, besturingsschema's, aangepaste matchmaking
• Monetisatie - Winkelzichtbaarheid en gebruikerservaring, soorten starterspakketten, prijsstelling

Experimenteer maken

Experimenten komen in twee types:

• In-game experimenten stellen je in staat om de impact van verschillende config-waarden te meten.
• Matchmaking-experimenten stellen je in staat om de impact van verschillende aangepaste matchmaking-configuraties te meten. In tegenstelling tot in-game experimenten kun je slechts één matchmaking-experiment tegelijk uitvoeren.

1. Als je nog geen config hebt, maak er dan een voor je spel.

2. Ga naar de Creator Hub Experiments-pagina voor je spel en klik op Experiment maken.

3. Voor Type, kies In-experience.

4. Geef een naam, doelmetric en geplande duur voor het experiment op. Experimenten duren tussen de 14-60 dagen.

   Ongeacht wat je kiest als je doelmetric, experimenten volgen alle metrics in de lijst.

5. Kies een percentage rollout. Dit getal is het percentage spelers dat je in het experiment wilt opnemen.

   Over het algemeen geldt: hoe meer mensen je in een experiment opneemt, hoe beter de gegevens, maar gebruik je oordeel over wat het beste is voor je spel.

   Let op de minimale detecteerbare effect, wat de kleinste wijziging in de geselecteerde metric is die het experiment betrouwbaar kan detecteren.

6. Geef varianten en percentages op.

   Varianten zijn alternatieve waarden voor je config. Voor een numerieke config-sleutel bossHealth met een controlewaarde van 500, kun je een variant van 300 opgeven. Je kunt tot twee varianten en één controle in een experiment hebben.

   Percentages bepalen hoe varianten binnen de experiment rollout worden toegewezen. Overweeg het volgende voorbeeld:

   • Je kiest een totale rollout van 40%.
   • Je specificeert twee varianten en een 50/50-splitsing tussen hen en de controle.

   In dit voorbeeld worden 60% van je gebruikers uitgesloten van het experiment; deze gebruikers ontvangen de controle en hebben geen impact op de experimentresultaten. Ongeveer 20% van je gebruikers ontvangt de controle als onderdeel van het experiment. Nog eens 20% ontvangt de variant. Afhankelijk van je spelersaantal is deze verdeling mogelijk niet groot genoeg om bruikbare resultaten op te leveren.

   Bij twijfel raden we eenvoudige 50/50-experimenten aan met één variant en één controle bij grote rollouts. De experimenten zijn gemakkelijker te configureren en de resultaten zijn gemakkelijker te interpreteren.

   

7. (Optioneel) Richt het experiment op een specifiek publiek zodat alleen bijpassende spelers in aanmerking komen voor inschrijving. Targeting gebruikt dezelfde spelerattributen als voorwaardelijke configs, en je kunt bestaande voorwaarden rechtstreeks van je configs kopiëren. Voor meer informatie, zie Experimenteer richten op specifieke doelgroepen.

   

8. De laatste stap is het plannen. Je kunt experimenten onmiddellijk starten of ze voor een latere datum en tijd plannen. Nadat je een experiment hebt gepland, kun je de configuratie (duur, rolloutpercentage, varianten, enz.) niet meer wijzigen, maar je kunt het opnieuw plannen.

Metrics

Experimenten volgen al de volgende metrics gedurende de experimentduur. Deze metrics worden elke 24 uur bijgewerkt terwijl het experiment draait. Tijdens de eerste 24 uur van je experiment worden echter speeltijd, conversieratio van betalende gebruikers en ARPU ook elke 5 minuten bijgewerkt, zodat je kritieke regressies (vroegtijdige schade) snel kunt opvangen.

Experimentstatus

De Experiments-pagina toont de volgende statussen voor experimenten.

Experimenteer richten op specifieke doelgroepen

Standaard kan een in-game experiment elke speler inschrijven in je rolloutpercentage. Targeting stelt je in staat om het experiment op een specifiek publiek uit te voeren, zoals spelers in bepaalde landen, specifieke dienstjaren of actieve uitgaven niveaus. Targeting gebruikt dezelfde attributen als config-targeting.

Gerichte experimenten instellen

Je configureert targetingcriteria wanneer je het experiment maakt. Nadat het experiment is gestart, kun je de targetingregels, de controlewaarde, de varianten of enige voorwaardelijke regels die de config-sleutel gebruikt niet meer wijzigen.

Je kunt bestaande voorwaardelijke regels uit je configs hergebruiken om je targeting te definiëren, maar het experiment slaat een onafhankelijke kopie van elke regel op. Het bewerken of verwijderen van de oorspronkelijke config-voorwaarde later heeft geen effect op de targeting van het experiment.

Omdat het verkleinen van je publiek je steekproefgrootte vermindert, werkt Roblox de minimale detecteerbare effect (MDE) bij met een schatting van het publiek dat aan je targetingcriteria voldoet. Zorg ervoor dat je gerichte publiek groot genoeg is om statistisch significante resultaten te produceren.

Hoe Roblox gerichte waarden oplost

Roblox evalueert experimenten eerst, voordat enige regels van standaard voorwaardelijke configs worden toegepast. Wanneer een config-sleutel een actief experiment heeft, lost Roblox de waarde in deze volgorde op:

1. De actieve experimentwaarde, als de speler is gericht en ingeschreven.
2. De eerste overeenkomende config-voorwaarde.
3. Alle daaropvolgende overeenkomende config-voorwaarden.
4. De standaardwaarde.

Spelers in de controlegroep ontvangen de waarde die je bestaande config-regels produceren. Je kunt niet meer dan één actief experiment op dezelfde config-sleutel tegelijk uitvoeren.

Per-sessie evaluatie

Roblox evalueert targetingattributen per sessie, zodat de geschiktheid van een individuele speler in de loop van de tijd kan veranderen:

• Als een speler aan je targetingcriteria voldoet tijdens een sessie, kunnen ze worden ingeschreven en ontvangen ze een experimentvariant.
• Als ze later niet meer aan de criteria voldoen, stoppen ze met het ontvangen van de experimentwaarde en vallen ze onmiddellijk terug op je standaard config-regels. Als je experiment continuïteit nodig heeft die verder gaat dan geschiktheid—bijvoorbeeld een multi-sessie onboarding-stroom gericht op nieuwe spelers—moet je de waarde zelf behouden, bijvoorbeeld in een data store.

De gegevens van een speler blijven toegeschreven aan de variant (of controle) waarin ze zijn ingeschreven, zelfs als ze later niet meer aan de criteria voldoen. Bijvoorbeeld, D7-retentie telt nog steeds een speler die zich op dag 0 heeft ingeschreven en of ze op dag 7 zijn teruggekeerd, zelfs als ze op dag 4 niet meer kwalificeren.

Config-wijzigingen terwijl een experiment draait

Om configuratiedrift en beschadigde experimentgegevens te voorkomen, vergrendelt Roblox de config-sleutel op het moment dat een experiment begint te draaien:

• Je kunt de lopende config-sleutel niet bewerken of verwijderen, noch kun je de standaard voorwaardelijke waarden wijzigen.
• Alle globale voorwaarden waar de actieve config naar verwijst zijn ook vergrendeld. Je kunt ze niet bewerken, verwijderen of opnieuw ordenen ten opzichte van elkaar.

De vergrendeling wordt opgeheven wanneer het experiment is voltooid.

Voeg experimenten toe aan je code

Het toepassen van in-game experimenten is vergelijkbaar met configs toepassen. Het belangrijkste verschil is het gebruik van ConfigService:GetConfigForPlayerAsync() in plaats van ConfigService:GetConfigAsync().

GetConfigForPlayerAsync() haalt een speler-specifieke snapshot op. Wanneer je GetValue() aanroept, controleert de snapshot op een actief experiment en schrijft de gebruiker in (of niet) op basis van het rolloutpercentage.

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)

• Je moet GetConfigForPlayerAsync() afzonderlijk voor elke speler aanroepen; GetConfigAsync() past geen experimenten toe.

• Nadat je GetValue() op een speler-specifieke snapshot hebt aangeroepen, is de speler die aan de snapshot is gekoppeld ingeschreven in het experiment voor die sleutel en die sleutel alleen. Alle volgende aanroepen naar de methode retourneren dezelfde controle of variant voor de duur van het experiment. Alleen de eerste aanroep is willekeurig.

  Wacht met het aanroepen van GetValue() totdat je het nodig hebt. Te vroeg aanroepen van GetValue() kan ervoor zorgen dat je spelers inschrijft die nooit interactie hebben met het deel van het spel waar je op experimenteert.

• Inschrijving voor experimenten is niet beperkt tot nieuwe gebruikers. Zelfs als een gebruiker eerder een waarde heeft ontvangen van GetConfigAsync(), kun je ze nog steeds inschrijven in een experiment met een speler-specifieke snapshot van GetConfigForPlayerAsync().

• Als een sleutel in een speler-specifieke snapshot geen actief experiment heeft, retourneert GetValue() de standaard config-waarde (of nil als het geen waarde heeft).

Aangepaste inschrijving

Als je alleen spelers wilt inschrijven die voldoen aan criteria op basis van in-game status, moet je extra code schrijven om die criteria te controleren en pas daarna GetValue() aanroepen om ze in het experiment in te schrijven. Overweeg het volgende voorbeeld:

• Je wilt een nieuw besturingsschema testen in je racegame.
• Het schema is voor gevorderde spelers, dus je wilt spelers targeten die een groot aantal races hebben gewonnen.

Je code zou er ongeveer zo uit kunnen zien:

local function getControlScheme(player, racesWon)
    if racesWon < 20 then
        return "standardScheme"
    else
        -- Speler heeft veel overwinningen, schrijf in voor experiment
        local playerConfigSnapshot = ConfigService:GetConfigForPlayerAsync(player)
        if playerConfigSnapshot:GetValue("useNewControlScheme") then
            return "newScheme"
        else
            return "standardScheme"
        end
    end
end

Als je wilt dat het besturingsschema aanhoudt in volgende sessies, moet je waarschijnlijk een waarde toevoegen aan de invoer van de speler in een data store.

Resultaten bekijken en interpreteren

Klik op Bekijk om details en resultaten te zien. In het tabblad Details en voortgang kun je het totale aantal ingeschreven spelers zien, evenals het aantal spelers dat de controlewaarde en elke variant heeft ontvangen. Deze pagina vroeg in het experiment bekijken is nuttig om ervoor te zorgen dat het experiment goed draait, niet om actie te ondernemen. Voordat je actie onderneemt, zie Best practices.

Vroegtijdige schade metrics

Voor de eerste 24 uur, of totdat de eerste dagelijkse resultaten binnenkomen, worden vroegtijdige schade metrics elke 5 minuten bijgewerkt, zodat je onbedoelde kritieke schade vroeg kunt opvangen. Klik op Metrics om deze resultaten te zien. Let op kritieke schade metrics die in het rood zijn gemarkeerd.

Beweeg over een metric en klik op Bekijk vertrouwen om het betrouwbaarheidsinterval te zien.

Tijdens dit venster testen de resultaten alleen op schade, dus het betrouwbaarheidsinterval heeft geen ondergrens, alleen een bovengrens. Een metric wordt als kritisch schadelijk gemarkeerd als het hele betrouwbaarheidsinterval onder de kritieke schadegrens valt. In het volgende voorbeeld is de speeltijd -12,67% met een bovengrens van -2,73%. Hoewel de schatting lager is dan de kritieke schadegrens van -10% en het hele betrouwbaarheidsinterval onder 0% ligt, wordt de metric niet geclassificeerd als kritisch schadelijk omdat het interval niet volledig onder de schadegrens ligt.

Gebruik deze resultaten alleen om vroege stopbeslissingen in de eerste 24 uur te begeleiden. Gebruik ze niet voor lanceerbeslissingen, vertrouw in plaats daarvan op dagelijkse resultaten.

Vroegtijdige schadegrenzen

Elke metric heeft zijn eigen vroegtijdige schadegrens. Als de lift van een variant onder deze grens valt, wordt deze geclassificeerd als kritisch schadelijk voor die metric. Voor vergelijkingen van metric-varianten met minder dan 10.000 ingeschreven spelers over de variant en de controle worden variant-lifts weergegeven, maar beslissingen over schade worden pas genomen wanneer de steekproefgrootte voldoende gegevens biedt om schade betrouwbaar te detecteren.

Vroegtijdige schade meldingen

Als kritieke schade wordt gedetecteerd in je experiment tijdens de vroegtijdige schade-analyseperiode, wordt er een melding verzonden naar de spel eigenaar en experiment eigenaar voor vroege actie. Meldingen worden verzonden via e-mail, Creator Hub-meldingsvak en via een optionele webhook. Na ontvangst van een vroegtijdige schade melding, moet je de experimentmetrics bekijken en beslissen of het experiment vroegtijdig moet worden gestopt.

Dagelijkse resultaten

Nadat een experiment minstens 24 uur heeft gedraaid, klik je op Resultaten om de laatste resultaten te zien, die elke 24 uur worden bijgewerkt. Let op statistisch significante veranderingen in doelmetrics, die het dashboard in het groen of rood markeert. Deze veranderingen zijn waarschijnlijker om de impact van je variant te tonen en minder waarschijnlijk om valse positieven of negatieven te zijn.

Een metric is statistisch significant wanneer het betrouwbaarheidsinterval voor de procentuele verandering niet overlapt met 0%. In het volgende voorbeeld is ARPU met 2,37% gestegen, met lagere en hogere grenzen van 0,55% en 4,19%, wat de verandering statistisch significant maakt.

Voor de gemak laat de resultatenpagina je de standaard config-waarde vervangen door een van de varianten uit het experiment.

Steekproefverhouding mismatch

Als je experiment er niet in slaagt om gebruikers in de varianten in de verwachte verhoudingen in te schrijven, verschijnt er een waarschuwingsbanner voor Steekproefverhouding Mismatch (SRM) in het tabblad experimentresultaten. Als SRM wordt gedetecteerd, wordt aanbevolen om je experiment te stoppen en opnieuw te starten.

SRM wordt elke 5 minuten gecontroleerd gedurende de eerste 24 uur van je experiment, en daarna dagelijks. SRM kan experimentresultaten ongeldig maken; neem geen lanceerbeslissingen op basis van gecompromitteerde en onbetrouwbare resultaten.

Neem een beslissing

Wanneer je experiment eindigt, klik je op Neem beslissing om een begeleide rollout te starten. Roblox toont eventuele waarschuwingen over statistische significantie en experimentduur, en vraagt je vervolgens om een winnende variant te selecteren of de controle te behouden. Op basis van je keuze voert Roblox de juiste wijziging door in je permanente configs; terugkeren naar de Configs-pagina toont de nieuwe waarde. Klik op Verander winnaar als je van gedachten verandert.

Als je onopgeloste gestage wijzigingen op de config hebt wanneer je het experiment voltooit, slaat Roblox ze tijdelijk op en herstelt ze op basis van de beste inspanning na de rollout.

Je beslissing bepaalt de config-wijzigingen die Roblox voorstelt:

• Controle: Roblox maakt geen wijzigingen in je bestaande configs.

• Ongespecificeerde variant: De variantwaarde wordt de nieuwe standaardwaarde van de config. Roblox verwijdert alle andere voorwaarden op die config-sleutel, hoewel ze in je globale voorwaardenlijst blijven.

• Gerichte variant: Roblox integreert de winnende regel terug in je permanente config met behulp van de eerste toepasselijke optie in deze prioriteitsvolgorde:

  1. Overschrijven: Als een identieke voorwaarde al bovenaan de config staat, overschrijft Roblox de waarde met de waarde van de winnende variant.
  2. Bestaande toevoegen: Als er een overeenkomende globale voorwaarde bestaat die van nature bovenaan zou staan, voegt Roblox deze toe aan de config met de waarde van de variant.
  3. Promoten: Als een overeenkomende globale voorwaarde veilig kan worden gepromoot naar de laagste rang die nodig is om het de bovenste regel in deze config te maken (zonder andere configs te wijzigen), voegt Roblox deze toe aan de config en herschikt deze globaal.
  4. Nieuwe maken: Anders maakt Roblox een nieuwe globale voorwaarde die één niveau boven de hoogste voorwaarde die momenteel in de config wordt gebruikt, is gerangschikt. Als dit een duplicaatregel binnen de config creëert, verwijdert Roblox de overbodige voorwaardelijke waarde terwijl de globale regel behouden blijft.

Best practices voor experimenten

• Gebruik de minimale detecteerbare effect (MDE) om te beslissen of je experiment de moeite waard is om uit te voeren.

  Roblox berekent MDE met behulp van je doelmetric en het aantal spelers per variant, dat is gebaseerd op dagelijks actieve gebruikers, rolloutpercentage, experimentduur en variant-splitsingen. Als de MDE te hoog is voor je doelmetric (bijvoorbeeld meer dan 100%), is het onwaarschijnlijk dat je statistische significantie kunt bereiken. Spellen met minder dan 1.000 dagelijks actieve gebruikers kunnen moeite hebben om bruikbare gegevens uit experimenten te halen.

  

• Begin met een hypothese. In plaats van gewoon een variabele te wijzigen en de resultaten te controleren, schrijf een oorzaak-en-gevolgverklaring over wat je hebt veranderd, wat je verwacht dat er gebeurt en waarom. Naarmate je meer experimenteert, kan het hebben van een set geschreven hypothesen om je resultaten te vergezellen helpen om je denken te verduidelijken en nieuwe ideeën voor experimenten te stimuleren.

• Laat experimenten hun volledige duur draaien. Het nieuwigheidseffect (tijdelijke interesse in een wijziging niet omdat het beter is, maar omdat het nieuw is) kan vroege resultaten sterk vertekenen, waardoor ze soms in en uit statistische significantie kunnen schommelen. Experimenten vroegtijdig beëindigen vergroot de kans dat je voortijdige actie onderneemt op basis van anomalieën die meer gegevens zouden hebben afgevlakt of zelfs tegengesproken.

  • De uitzondering is vroegtijdige schade in de eerste 24 uur: als metrics worden gemarkeerd als kritisch schadelijk of je ziet steekproefverhouding mismatch, bekijk en overweeg te stoppen. Gebruik geen vroegtijdige schade resultaten voor lanceerbeslissingen.

• Handel niet zonder statistische significantie. Zelfs schijnbaar grote veranderingen in het gedrag van spelers zijn mogelijk niet statistisch significant, meestal vanwege een kleine steekproefgrootte. Als een verandering niet statistisch significant is, negeer deze dan.

• Vermijd wijzigingen tijdens experimenten. Grote bugs moeten natuurlijk worden opgelost, maar wijzigingen in spelinhoud kunnen het gedrag van spelers beïnvloeden en je resultaten ongeldig maken, zelfs als de wijzigingen schijnbaar niet gerelateerd zijn aan je experiment. Evenzo, voer alleen experimenten gelijktijdig uit als je zeker weet dat ze elkaar niet zullen beïnvloeden.

• Gebruik betrouwbaarheidsintervallen voor diepgaande analyses van metrics en om te controleren op grensgevallen van statistische significantie. Als het betrouwbaarheidsinterval te breed is, kan de metric nooit statistische significantie bereiken.

• Als één metric significant omhoog gaat en een andere significant omlaag, moet je beslissen of de afweging het waard is, mogelijk in combinatie met andere statistisch significante bewegingen.

• Experimenten bieden een sterk signaal, maar statistische significantie handelt in waarschijnlijkheden, niet in zekerheden—vandaar het betrouwbaarheidsinterval. Gegevensvariabiliteit, steekproefgrootte en de omvang van de verandering beïnvloeden allemaal de waarschijnlijkheid om te detecteren of een variant het gedrag van spelers heeft beïnvloed. Elke actie die je onderneemt op basis van de resultaten van een experiment moet worden afgewogen tegen kwalitatieve gegevens zoals feedback van spelers en je algehele visie voor het spel.

• Documenteer je bevindingen en beslissingen. Zelfs als je ze niet gebruikt om aanvullende experimenten uit te voeren, kan het hebben van een kennisbasis en bewijs helpen bij het ontwerpen van je spellen.