실험

실험은 게임 내 및 매치메이킹 A/B 테스트를 실행하여 게임 변경 사항의 인과적 영향을 측정할 수 있게 합니다. 예를 들어, 서로 다른 온보딩 경험을 다양한 플레이어에게 보여주고, 플레이 시간, 유지율 및 기타 주요 성과 지표의 차이를 측정할 수 있습니다.

실험은 다음을 측정하는 데 매우 유용합니다:

• 참여도 - 온보딩 흐름, 진행 시스템, 조작 방식, 맞춤형 매치메이킹
• 수익화 - 상점 가시성 및 사용자 경험, 시작 패키지 유형, 가격 책정

실험 생성

실험은 두 가지 유형으로 제공됩니다:

• 게임 내 실험은 다양한 구성 값의 영향을 측정할 수 있게 합니다.
• 매치메이킹 실험은 다양한 맞춤형 매치메이킹 구성의 영향을 측정할 수 있게 합니다. 게임 내 실험과는 달리, 한 번에 하나의 매치메이킹 실험만 실행할 수 있습니다.

1. 만약 구성이 없다면, 게임을 위한 구성을 하나 생성합니다.

2. Creator Hub 실험 페이지에서 실험 생성을 클릭합니다.

3. 유형에서 게임 내를 선택합니다.

4. 실험의 이름, 목표 지표 및 계획된 기간을 지정합니다. 실험은 14-60일 동안 실행됩니다.

   목표 지표로 무엇을 선택하든 간에, 실험은 목록에 있는 모든 지표를 추적합니다.

5. 퍼센트 롤아웃을 선택합니다. 이 숫자는 실험에 포함시키고 싶은 플레이어의 비율입니다.

   일반적으로 실험에 포함시키는 인원이 많을수록 데이터의 품질이 좋지만, 게임에 가장 적합한 것을 판단하여 결정하세요.

   실험이 안정적으로 감지할 수 있는 선택한 지표의 최소 감지 효과(minimum detectable effect)에 주의하세요.

6. 변형 및 퍼센트를 지정합니다.

   변형은 구성에 대한 대체 값입니다. 예를 들어, 제어 값이 500인 숫자 구성 키 bossHealth의 변형으로 300을 지정할 수 있습니다. 실험에는 최대 두 개의 변형과 하나의 제어가 있을 수 있습니다.

   퍼센트는 실험 롤아웃 내에서 변형을 할당하는 방법을 결정합니다. 다음 예를 고려해 보세요:

   • 전체 롤아웃을 40%로 선택합니다.
   • 두 개의 변형을 지정하고 제어와 50/50 비율로 나눕니다.

   이 예에서는 사용자의 60%가 실험에서 제외됩니다; 이 사용자들은 제어값을 받고 실험 결과에 영향을 미치지 않습니다. 약 20%의 사용자가 실험의 일환으로 제어값을 받고, 또 다른 20%가 변형을 받습니다. 플레이어 수에 따라 이러한 배분이 실행 가능한 결과를 도출하기에 충분하지 않을 수 있습니다.

   의심스러운 경우, 대규모 롤아웃에서 하나의 변형과 하나의 제어로 간단한 50/50 실험을 추천합니다. 실험이 구성하기 쉽고 결과를 해석하기 쉽습니다.

   

7. 마지막 단계는 일정을 잡는 것입니다. 실험을 즉시 시작하거나 나중의 날짜와 시간으로 일정을 잡을 수 있습니다. 실험 일정을 잡은 후에는 구성(기간, 롤아웃 비율, 변형 등)을 변경할 수 없지만, 다시 일정을 잡을 수는 있습니다.

지표

실험은 실험 기간 동안 다음 모든 지표를 추적합니다.

실험 상태

실험 페이지에는 실험에 대한 다음과 같은 상태가 표시됩니다.

코드에 실험 추가하기

게임 내 실험 적용은 구성 적용과 비슷합니다. 주요 차이는 ConfigService:GetConfigForPlayerAsync()를 사용한다는 점입니다. ConfigService:GetConfigAsync()는 실험을 적용하지 않습니다.

ConfigService:GetConfigForPlayerAsync()는 플레이어별 스냅샷을 검색합니다. ConfigSnapshot:GetValue()를 호출할 때, 스냅샷은 활성 실험을 확인하고 롤아웃 비율에 따라 사용자를 등록(또는 등록하지 않음)합니다.

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)

• 각 플레이어에 대해 ConfigService:GetConfigForPlayerAsync()를 별도로 호출해야 합니다; ConfigService:GetConfigAsync()는 실험을 적용하지 않습니다.

• 플레이어별 스냅샷에서 ConfigSnapshot:GetValue()를 호출한 후, 해당 스냅샷과 연결된 플레이어는 해당 키에 대해 실험에 등록됩니다. 이후의 모든 메서드 호출은 실험 기간 동안 동일한 제어값 또는 변형을 반환합니다. 첫 번째 호출만 무작위로 결정됩니다.

  필요할 때까지 ConfigSnapshot:GetValue()를 호출하지 마세요. 너무 일찍 호출하면, 실험 중인 게임 부분과 상호작용하지 않는 플레이어를 등록할 수 있습니다.

• 실험에의 등록은 신규 사용자에 한정되지 않습니다. 사용자가 이전에 ConfigService:GetConfigAsync()로 값을 받았다 하더라도, ConfigService:GetConfigForPlayerAsync()에서 플레이어별 스냅샷을 사용하여 실험에 등록할 수 있습니다.

• 플레이어별 스냅샷의 키에 활성 실험이 없는 경우, ConfigSnapshot:GetValue()는 표준 구성 값(값이 없으면 nil)을 반환합니다.

타겟 등록

특정 기준을 충족하는 플레이어의 일부를 타겟으로 설정하고 싶다면, 해당 기준을 확인하고 그 후에만 ConfigSnapshot:GetValue()를 호출하여 실험에 등록하도록 추가 코드를 작성해야 합니다. 다음 예를 고려해 보세요:

• 게임에서 새로운 조작 방식을 테스트하려고 합니다.
• 기존 플레이어(기존 스킴에 익숙할 것으로 예측됨)는 포함하고 싶지 않고, 신규 플레이어만 포함하고 싶습니다.

코드는 다음과 유사할 수 있습니다:

local function getControlScheme(player, racesCompleted)
    if racesCompleted > 0 then
        return "standardScheme"
    else
        -- 플레이어가 신규이며, 실험에 등록합니다.
        local playerConfigSnapshot = ConfigService:GetConfigForPlayerAsync(player)
        if playerConfigSnapshot:GetValue("useNewControlScheme") then
            return "newScheme"
        else
            return "standardScheme"
        end
    end
end

조작 방식이 이후 세션에서도 지속되도록 하려면, 데이터 저장소에 플레이어의 항목에 값을 추가해야 할 수도 있습니다.

결과 보기 및 해석

실험이 최소 24시간 동안 실행된 후, 보기를 클릭하여 세부정보 및 결과를 확인합니다.

등록된 총 플레이어 수와 제어값 및 각 변형을 받은 플레이어 수를 볼 수 있습니다. 실험 초기에 이 페이지를 보는 것은 실험이 제대로 실행되고 있는지를 확인하는 데 유용하며, 행동을 취하기 위한 것이 아닙니다. 행동을 취하기 전에 모범 사례를 참조하세요.

실험이 완료된 후에는 결과 탭을 확인합니다. 대시보드에서 강조 표시된 목표 지표의 통계적으로 유의미한 변화를 찾습니다. 이러한 변화는 변형의 영향을 보여줄 가능성이 더 높고, 거짓 긍정 또는 부정의 가능성은 낮습니다.

어떤 지표에 마우스를 올리면 신뢰도 보기 버튼이 나타나며, 신뢰 구간을 보여줍니다.

지표가 통계적으로 유의미할 때, 그 비율 변화의 신뢰 구간이 0%와 겹치지 않아야 합니다. 다음 예에서 D1 유지율이 17.4% 증가했으며, 하한과 상한이 각각 8.02% 및 22.03%로, 이 변화는 통계적으로 유의미합니다.

편리하게도, 결과 페이지에서는 기본 구성 값을 실험의 변형 중 하나로 교체할 수 있습니다. 결정하기를 클릭하여 변형을 선택하거나 승자 변경을 클릭하여 마음을 바꿀 수 있습니다. 그 후 구성 페이지로 돌아가면 새로운 값을 확인할 수 있어야 합니다.

실험을 위한 모범 사례

• **최소 감지 효과(MDE)**를 사용하여 실험을 실행할 가치가 있는지 결정하세요.

  Roblox는 목표 지표 및 변형당 플레이어 수를 기반으로 일일 활성 사용자, 롤아웃 비율, 실험 기간 및 변형 분할을 사용하여 MDE를 계산합니다. 목표 지표에 대한 MDE가 너무 높다면(예: 100% 이상), 통계적 유의미성을 달성하기 어려울 것입니다. 일일 활성 사용자가 1,000명 이하인 게임은 실험에서 유용한 데이터를 얻기 어려울 수 있습니다.

  

• 가설로 시작하세요. 단순히 변수 하나를 변경하고 결과를 확인하기보다는, 무엇을 변경했는지, 어떤 일이 일어날 것으로 예상되는지, 그 이유에 대한 인과관계 문장을 작성하세요. 실험을 거듭할수록, 결과에 수반되는 서면 가설 세트가 사고를 정리하고 새로운 실험 아이디어를 제기하는 데 도움이 될 수 있습니다.

• 실험을 전체 기간 동안 실행하게 하세요. 참신함의 효과(변화가 더 좋기 때문이 아닌 단순히 새로운 것에 대한 임시의 관심)는 초기 결과에 심각한 편향을 초래할 수 있으며, 때때로 통계적 유의미성을 swing하게 만들 수 있습니다. 실험을 조기에 종료하면, 더 많은 데이터가 평탄하게 만들거나 반박했을 이상 징후에 대한 조치를 조기 취할 가능성이 높아집니다.

• 통계적 유의미성이 없이는 행동을 취하지 마세요. 플레이어 행동의 변화가 작게 보이더라도, 일반적으로 작은 표본 크기 때문인 경우가 많습니다. 변화가 통계적으로 유의미하지 않다면 무시합니다.

• 실험 중에 변경을 피하세요. 주요 버그는 물론 수정이 필요하지만, 경험 콘텐츠의 변화는 플레이어 행동에 영향을 미치고 결과를 무효화할 수 있으며, 변경 사항이 실험과 관련이 없어 보인다 하더라도 마찬가지입니다. 유사하게, 실험들이 서로 영향을 미칠 가능성이 신뢰할 수 있다고 판단되지 않으면 동시에 실행하세요.

• 신뢰 구간을 사용해 지표를 깊이 들여다보고 통계적 유의미성의 경계 사례를 확인하세요. 신뢰 구간이 너무 넓으면, 지표가 통계적 유의미성에 도달하지 못할 수 있습니다.

• 한 지표가 유의미하게 상승하고 다른 지표가 유의미하게 하락한다면, 거래가치가 가치 있는지를 결정해야 합니다. 통계적으로 유의미한 변화와 함께 생각해보아야 합니다.

• 실험은 강력한 시그널을 제공하지만, 통계적 유의미성은 확실성이 아닌 확률을 다룹니다—그러므로 신뢰 구간이 있습니다. 데이터 변동성, 샘플 크기 및 변화의 크기는 변형이 플레이어 행동에 영향을 미쳤는지를 감지할 확률에 영향을 미칩니다. 실험 결과에 기반해 취하는 모든 조치는 플레이어 피드백 및 게임에 대한 전체 비전과 같은 정성적 데이터와 균형을 이루어야 합니다.

• 발견 및 결정을 문서화하세요. 추가 실험을 실행하지 않더라도, 지식 체계와 증거를 보유하는 것은 게임 디자인에 얼마나 도움이 될 수 있습니다.