실험 요약

이 가이드에서는 실험 사례를 소개합니다. 이 문서에서는 조기에 모범 사례 권장 사항을 실험해야 하는 이유를 자세히 설명하고 프로세스에 익숙해지는 데 도움이 되는 정보를 제공합니다.

실험이 중요한 이유

실험은 게임 환경 변화의 효과를 확인하기 위한 일반적인 표준입니다. 게임 환경 변화의 효과를 이해하고, 이를 뒷받침하는 데이터가 있다면, 보다 효과적인 게임 디자인, 경험 및 마케팅 전략을 수립할 수 있는 결정을 내리는 것이 더욱더 쉬워집니다. 지속적인 실험을 통해 변화의 효과가 시간이 지남에 따라 감소하는지 확인할 수 있습니다.

어떤 단계의 게임 개발 여정(생성 또는 운영)이든 관계없이, PlayFab 실험을 통해 개인, 팀 및 스튜디오가 게임 환경을 신중하게 변경할 수 있으며, 경험적 데이터를 수집하여 게임에 가장 적합한 요소를 정확히 파악하는 데 도움이 됩니다.

실험은 제어되고 제한된 대상 그룹(플레이어 트래픽)에서 게이머의 동작에 대한 인사이트를 제공하는 효과적인 사례입니다. 따라서 불만족스러운 게임 환경으로부터 플레이어 기반을 보호합니다. 또한 리소스를 더 잘 활용하고 라이브 게임에서 게임 기능을 쉽게 사용하거나 사용하지 않도록 설정할 수 있습니다. 실험은 "우리는 생각한다"에서 "우리는 안다"라는 의사 결정 능력으로 전환하는 데 도움이 됩니다. 이는 제어되고 제한된 대상 그룹(플레이어 트래픽)을 통해 게이머의 행동에 대한 인사이트를 제공하는 효과적인 사례입니다. 따라서 게임 환경이 저하되지 않도록 플레이어 기반을 보호합니다. 또한 리소스를 더 잘 활용하고 라이브 게임에서 게임 기능을 쉽게 사용하거나 사용하지 않도록 설정할 수 있습니다.

실험 시 게임 스튜디오에 대한 몇 가지 일반적인 목표는 다음과 같습니다.

• 활성 플레이어 기반 증가
• 높은 전환률
• 낮은 이탈률

실험의 신뢰도가 중요합니다.

실행 중인 실험의 결과에 따라 결정을 내릴 때 관계/인과 관계가 있는지 확인해야 합니다. 실험의 신뢰도는 실험 결과의 통계적 유의성으로 계산됩니다.

신뢰도는 PlayFab의 실험 결과의 중심입니다. 모든 메트릭에서 통계적 유의성이 확인됩니다.

예를 들어 보존에서 2% 리프트를 측정하는 실험을 실행하고 p-값이 0.04인 통계적으로 유의미한 것으로 표시되었다면 A와 B 간에 차이가 없다고 가정할 경우 2% 이상의 결과가 관찰될 확률이 4%입니다(즉, null 가설이 참이라고 가정). 실제 차이는 직접 측정할 수 없으며 통계는 합리적인 추정치를 얻는 데 사용됩니다. 노이즈(임의성)로 인해 결과가 오인될 가능성이 있습니다.

통계적 중요도는 위험 허용 범위 및 신뢰 수준을 반영하기 때문에 중요합니다. 메트릭은 매일 변동할 수 있으며 통계 분석은 노이즈 환경에서 비즈니스 의사 결정을 내리는 데 적합한 수학 기반을 제공합니다.

PlayFab 실험은 95% 신뢰도 또는 p-값 0.05에서 통계적으로 유의미한 메트릭 이동에 플래그를 지정합니다.

샘플 비율 불일치(SRM)

샘플 비율 불일치(SRM)는 실험 변형 간의 예상 사용자 비율(예: 실험이 시작되기 전에 구성됨)과 실험 종료 시 관찰된 사용자의 실제 비율 간에 유의미한 차이를 나타내는 데이터 품질 검사입니다.

SRM은 일부 누락된 데이터 또는 균일하지 않은 방식으로 제어 및 처리 변형에 영향을 주는 중복 문제가 있음을 나타냅니다. 제어된 실험의 기본 원칙은 처리 및 제어 변형이 통계적으로 동등해야 함을 요구합니다. 이 원칙을 위반하면 실험 결과가 선택 편향의 영향을 받을 수 있습니다.

SRM이 있는 분석은 신뢰할 수 없는 것으로 간주되므로 의사 결정을 내리는 데 사용하면 안 됩니다. 실제로 한 실험에 SRM이 있는 경우 분석에서 어떠한 결론도 도출하지 마세요(SRM을 해결할 때까지는 안 됨).

SRM을 검색하는 방법

각 제어 및 처리 변형에서 10%의 트래픽으로 실험을 실행하도록 구성된 예제를 살펴보겠습니다.

Type	1일	2일	3일	5일	7일	14일	21일
처리 변형 수	105	1,050	10,500	105,000	1,050,000	10,500,000	100,500,000
제어 변형 수	100	1,000	10,000	100,000	1,000,000	10,000,000	100,000,000
샘플 비율	1.05	1.05	1.05	1.05	1.05	1.05	1.05
SRM p-값	0.7269	0.2695	0.0005	~=0	~=0	~=0	~=0

이 시나리오에서는 두 플라이트 간의 실제 비율이 각 시나리오에서 동일하더라도 처리 및 제어에서 더 큰 사용자 수에 대한 p-값이 점점 더 작아집니다. 이는 관찰된 결과가 예상과 다르다는 것을 나타냅니다.

SRM을 조사하는 방법

SRM 조사와 해결은 복잡하고 불확실한 과정입니다. 따라서, SRM을 해결하려면 파노라마적 시각을 갖는 구조적 접근과 근본 원인 및 해결 전략의 가능성에 대한 인식을 필요로 합니다. 이를 위해

• "왜 이런 일이 일어났는가?"라는 질문으로 시작합니다.
• 해당 SRM의 원인에 대한 가설을 작성합니다.
• 그 가설이 사실이라면 관찰된 증거가 무엇인지 예측합니다.
• 해당 증빙 정보를 찾습니다.
• 원인을 분석하여 해결 방법을 파악합니다.

추가 질문을 하면 조사를 통해 해결에 필요한 단계를 고안하는 데 도움이 될 수 있습니다. 예를 들면 :

• 하나의 분석/실험에서만 발생했습니까? 또는 여러 분석/실험에서 발생했습니까?
• 처리가 어떤 역할을 합니까? 실험의 특성은 무엇입니까?
• 지금(SRM)과 이전(SRM이 없는 이전 실험) 사이에 변경된 사항이 있습니까?
• 관점, 파이프라인, 필터가 변경되었습니까?

SRM의 일반적인 근본 원인

• 게임 내 처리 환경이 제어 환경보다 더 많이 충돌함
• 의도하지 않게 다양한 양의 데이터를 전송하는 처리 환경입니다. 예를 들어 텔레메트리 버퍼를 늘리는 클라이언트에 대한 실험은 다시 돌아오는 데이터의 양을 확실히 증가시켜 SRM이 발생하게 됩니다.

사례로서의 실험

• 가설에서 시작

  실험에 대한 명확한 목표와 시나리오가 있는지 확인하기 위해 가설을 세웁니다. 또한 테스트 중인 변경 내용이 중요할 만큼 유의미한지 확인합니다.

  가설을 만들려면 다음 템플릿을 사용합니다.

  관찰 [A] 및 피드백 [B]로 인해 [D] 플레이어에 대해 [C]를 변경하면 [E]가 발생하게 될 것이라고 생각합니다. [F]가 표시되고 [G]를 가져오면 유효성이 검사됩니다.

• 실험을 올바르게 예약합니다.

  신뢰할 수 있는 결과를 얻으려면 비슷한 기간 동안 A/B 실험을 실행합니다. 계절별 최고치 및 최저치를 고려합니다.

• 실험 기간

  실험에 충분한 시간을 할당합니다. 실험에 할당된 시간이 부족하면 결과가 왜곡될 수 있습니다. 런타임이 너무 짧은 경우 통계적으로 정확한 결론을 내리기에 충분한 데이터 요소를 수집하지 못할 수 있습니다. 런타임이 너무 길면 성공적인 변형을 잠재 대상으로 롤아웃하지 않아 변환이 누락될 위험이 있습니다. 의심스러운 경우 다시 테스트하는 것이 합리적입니다.

• 플라이트 % 비율에 주의합니다.

  플라이트 % 비율에 따라 샘플 크기가 결정됩니다. 적절한 샘플 크기로 대상을 지정합니다. 그렇지 않으면 신뢰할 수 있는 결과를 얻지 못하며 해당 데이터를 기반으로 한 결정에 결함이 있을 수 있습니다.

• 유형 1 및 유형 2 오류 방지 실험에서의 통계는 확실성이 아닌 확률을 제공합니다. 따라서 실험의 한 변형이 가장 적합한지 여부를 100% 확신할 수 없습니다. 따라서 유형 1 및 형식 2 오류를 방지합니다.

  유형 1 오류를 피하려면 결정에 도달하기 전에 필요한 유의 수준을 올리고(기본적으로 95%로 설정하여) 더 많은 데이터를 수집하기 위해 실험을 더 오래 진행합니다. 또한 유형 2 오류의 가능성을 줄이려면 실험의 플라이팅 모집단(샘플 크기)을 늘립니다.

• 실험 중간에 변경하지 마세요.

  이상적인 기간이 끝나기 전에 테스트를 중단하거나 원래 가설의 일부가 아닌 새 변수를 도입하는 경우 결과는 신뢰할 수 없습니다. 즉, 변경 중 하나가 변환의 리프트를 발생시킨 것인지 아니면 임의의 확률로 발생했는지 확인하기가 어렵습니다.

  변형이 많을수록 신뢰할 수 있는 결과를 얻기 위해 테스트를 더 오래 실행해야 합니다. 세분화된 접근 방식을 사용합니다. 모든 변형 그룹에서 동시에 2~4개의 변수를 실험하는 것이 좋습니다. 이렇게 하면 테스트 기간 및 효율성의 균형을 가장 잘 맞출 수 있습니다.

• p-값에 반영된 통계적 유의성에 주의합니다.

  데이터가 신뢰할 수 있는지 확인합니다. 데이터 안정성 측정값은 결과가 임의 확률로 인한 것이 아니라는 것을 결정하는 통계적 유의성입니다.

  p-값은 AB 실험의 기반이 되는 null 가설에서 통계적 유의성을 결정하는 데 사용됩니다. 이는 수집된 데이터와 null 가설 간의 호환성을 측정합니다. 값이 낮을수록 null 가설을 거부할 수 있습니다.

• 열린 마음을 유지합니다.

  때때로 종래의 지식이나 심지어 이전의 경험을 활용하여 통계 정보를 무시하고 결정을 내리려는 유혹을 받기도 합니다. 아무리 놀라워도 말입니다. 테스트 결과에 대해 확신이 없는 경우 다시 실행하고 데이터를 비교합니다.

실험 문화 및 프로세스를 채택합니다.

실험 문화는 중요합니다. 모든 사용자가 조직 전체에서 혜택을 받을 수 있도록 다른 프로세스의 일부로 이를 제공해야 합니다. 일관된 A/B 실험은 플레이어를 위한 긍정적인 제품 가치를 추가할 수 있는 방법을 찾을 확률이 높아지므로 전환율을 실질적으로 향상시킬 수 있습니다.

의사 결정 패러다임을 HiPPO(최고 급여자의 의견)에 의존하는 것에서 데이터 중심의 선택으로 전환할 수 있습니다. 더 많은 직원의 아이디어가 테스트의 형태로 인정받을 수 있습니다. 중요한 것은 아이디어를 시도하기 쉬울 때, 결과와 다음 단계에 대해 이야기하는 것입니다. 무엇보다 직원들에게 업무에 대한 동기 부여가 가능합니다.

실험 문화를 구축하려면 게임 반복을 위해 안정적이고 반복 가능한 프로세스를 도입합니다. 다음과 같은 기초 단계를 사용하여 일정한 실험을 문화로 만들 수 있습니다.

• 목표를 설정합니다.

  실행 가능한 실험 목표(예: 참여)를 통해 팀은 '성장'과 같은 추상적인 목표에 갇히지 않고 실험을 진행할 수 있습니다.

• 팀의 지원으로 더 많은 것을 테스트하고 우선순위를 지정합니다.

  비즈니스 영향에 따라 가설/아이디어를 브레인스토밍하고 우선 순위를 지정할 수 있도록 정성적 및 정량적 데이터를 수집하고 분석합니다. 신뢰할 수 있고 반복 가능한 프레임워크를 사용하여 실험 여정 내내 팀을 안내합니다. 그렇지 않고 갑자기 더 많은 실험을 요청하고 여러 번 변경을 요청하면 팀이 어려움을 느끼게 됩니다.

• 결과를 팀에 다시 전달합니다.

  테스트 결과를 팀으로 전달하여 실험에 대한 추진력을 구축합니다. 공유를 통해 팀은 향후 테스트를 반복하고 개선하는 방법에 대한 인사이트를 얻을 수 있습니다. 이렇게 하면 사람들이 추가 실험에 대해 기대하게 됩니다.

• 실패를 수용합니다.

  실패는 테스트의 일부입니다. 실패를 정규화합니다. 실패가 실험을 중단하지 못하도록 하고, 반성하고, 학습하고, 실험을 계속 진행하도록 합니다.

• 좋은 실험 위생 문화를 도입합니다.

  팀이 실행하는 모든 실험에 대한 표준 프로토콜을 만듭니다. 누가 실험을 통제하든 실험 결과를 정확하고 의미있게 유지하는 데 도움이 됩니다.

실험을 실행하기 위한 권장 계획 프로세스

단계	Description
기회 분석
조사	실험 소유자는 실험 기회를 조사하고 분석합니다. 실험의 우선 순위를 지정합니다.
실험 디자인
범위 지정	실험 디자인을 시작합니다. 가설을 작성하기 위한 목표 메트릭을 파악합니다.
기능 디자인 검토	기능/환경 변경에 대한 디자인을 완료합니다. 실험의 일부로 변수를 통해 처리 변형 그룹에 도입됩니다.
코딩	기능 변경을 구현합니다.
Prod 배포	실험 디자인을 검토합니다. 연관 코드를 배포합니다.
실험 만들기
실험 구성	PlayFab에서 실험을 만듭니다.
실험 실행
A/B 실험을 실행합니다.	실험은 실험 구성에 따라 시작됩니다. 환경은 대상 그룹에 오케스트레이션됩니다. 텔레메트리가 수집되고 통계 계산이 수행됩니다.
실험 분석
결과 평가	성과 기록표를 통해 결과를 평가합니다.
출시 결정	이해 관계자들은 출시 결정을 평가합니다.
롤아웃 또는 롤백
실험 마무리	선정된 변형은 대상 그룹의 100%까지 롤업됩니다.