Platform
Resources
샘플 비율 불일치(SRM)에 대한 빠른 가이드
참고: 이 글은 원래 영어로 작성된 블로그의 한국어 번역본입니다. 원문은 다음 링크에서 확인하실 수 있습니다: https://statsig.com/blog/sample-ratio-mismatch
"동전 던지기로 결정하자—먼저 50번 이기는 쪽이 승리"
공정한 동전을 여러 번 던져서 앞면이 8번, 뒷면이 2번 나왔다고 상상해보세요. (공정한 동전은 균형이 잡혀 있고, 마술사의 공연에 사용된 적이 없는 동전입니다.)
앞면과 뒷면이 반반씩 나올 것으로 예상했지만, 단순히 이상한 결과가 나왔을 수도 있습니다. 만약 동전을 100번 던져서 앞면이 80번, 뒷면이 20번 나온다면, 이 동전의 "공정성"에 대해 훨씬 더 의심하게 될 것입니다.
이 동전 던지기를 실험의 테스트 그룹이나 대조 그룹에 사용자를 무작위로 할당하는 데 사용한다면, 이러한 "공정성"의 부족을 표본 비율 불일치(Sample Ratio Mismatch, SRM)라고 합니다.
우리는 80/20의 결과와 공정한 동전에서 기대하는 50/50의 결과를 비교하는 카이제곱 검정으로 이 공정성 부족을 평가합니다. 이 카이제곱 검정의 p-값은 진정으로 공정한 동전으로 반복 시행했을 때 우리가 관찰한 것만큼 또는 그보다 더 극단적인 결과를 볼 것으로 예상되는 비율입니다.
직관이 SRM p-값으로 연결됩니다
동전 던지기 실험에서의 직관은 각 사례에 대한 카이제곱 검정의 p-값에 반영됩니다. 10번 던지기 실험에서 80%의 앞면을 보는 것은 p-값이 0.058이지만, 100번 던지기 실험에서 80%의 앞면을 얻는 것은 p-값이 사실상 0입니다.
SRM이 왜 나쁜가요?
표본 비율 불일치는 선택 편향의 증거입니다
무작위 실험의 기본 가정 중 하나는 개인을 대조 그룹이나 테스트 그룹에 무작위로 할당한다는 것입니다. 그렇지 않으면 할당과 독립적이지 않은 다른 변수가 있을 수 있으며, 이것이 우리가 관찰하는 처리와 대조 간의 차이의 진정한 원인일 수 있습니다.
구현 문제를 가리킵니다
SRM이 있다는 사실은 실험 구현에 어떤 문제가 있을 가능성이 높다는 것을 의미하지만, 사용자가 처리 그룹에 할당되는 방식이나 사후에 데이터가 측정되거나 처리되는 방식 중 하나에서 발생할 수 있습니다. Statsig을 사용하고 있다면, 우리가 아마도 배제할 수 있는 많은 잠재적 원인들이 있습니다!
조사해볼 몇 가지 원인들:
일부 사용자는 일부 변형에 적합하지 않습니다: 아마도 당신의 멋진 새 기능을 위한 코드가 의도치 않게 특정 사용자 세그먼트를 특정 처리 그룹으로 강제할 수도 있습니다.
Statsig을 사용한다면 이런 일은 일어나지 않습니다. 우리의 SDK는 적합하지 않은 사용자를 모든 실험 그룹에서 균등하게 필터링합니다.
등록이 노출과 분리되어 있습니다: 아마도 사용자는 특정 웹페이지에서 실험에 등록되지만 관련 경험에 도달할 때만 처리 그룹에 노출됩니다. 그러나 대조 그룹의 노출이 페이지 상단에서 발생하지만 테스트 그룹은 스크롤해야 한다면, 이것이 SRM을 일으킬 수 있는 메커니즘입니다.
Statsig SDK는 기본적으로 노출을 자동으로 기록하여 할당과 노출을 자동으로 연결하지만, 필요할 때는 분리할 수도 있습니다.
무작위화 절차가 실제로 무작위가 아닙니다: 사용자를 처리에 '무작위로' 할당하는 데 사용하는 함수가 실제로는 무작위가 아니며 잠재적으로 편향을 도입하고 있을 수 있습니다.
Statsig을 사용한다면 이런 일은 일어나지 않습니다 - 우리는 단위 ID와 실험 ID가 주어졌을 때 SHA256 해싱 알고리즘을 사용하여 결정적으로 처리 그룹을 할당합니다.
테스트 그룹과 대조 그룹 간의 충돌률 차이: 새 코드가 충돌을 도입하거나 해결한다면, 이것이 SRM을 초래할 수 있습니다. 테스트 그룹에 더 많은 충돌이 있다면, 테스트 그룹의 더 많은 사용자가 노출을 전송할 수 없게 되어 SRM을 일으킬 수 있습니다.
데이터 처리 문제: 이 데이터가 대조 또는 테스트 변형에 대해서만 삭제되거나 중복되는 어떤 프로세스가 있을 수 있습니다.
Statsig을 통해 모든 데이터를 전송한다면, 우리가 데이터 처리를 수행하므로 데이터 처리에서 오는 SRM은 없어야 합니다.
단지 매우 운이 나빴나요?
아마 아닐 것입니다.
이것이 p-값이 정량화하는 것입니다: 동일한 방식으로 수행된 반복 시행에서 우리가 관찰한 것만큼 극단적으로 그룹이 나뉘는 결과를 볼 것으로 예상되는 비율입니다. 이것은 정말 가능성이 낮지만 일어날 수 있는 일입니다.
Statsig 콘솔의 SRM
Statsig에서는 모든 실험에 대해 자동으로 SRM을 확인합니다. 진단의 실험 상태 확인에서 노출이 균형잡혀 있음이 녹색으로 표시되면, SRM이 감지되지 않았다는 의미입니다.
SRM p-값이 0.01 미만이면 노출이 불균형하다고 간주합니다.
Statsig을 사용하지 않고 실험에 SRM이 있는지 확인하려면, 아마도 카이제곱 검정을 손으로 하고 싶지 않을 것입니다. 저는 이전에 이 SRM 계산기를 사용했고 위의 (8, 2)와 (80, 20) 예제의 p-값을 계산하는 데 사용했습니다.
Statsig은 시간에 따른 SRM p-값을 자동으로 추적하므로 SRM의 증거를 언제 보는지 식별할 수 있습니다. 0.01 미만의 SRM p-값은 실험이 노출이 균형잡혀 있음 상태 확인에 실패한다는 것을 의미합니다.
이는 SRM을 일으킨 문제를 디버깅하기 위한 시작점도 있다는 것을 의미합니다.
SRM이 감지되고 근본 원인이 발견되면, 실험을 쉽게 포기하고 재할당할 수 있습니다. 동일한 설계의 새 실험은 사용자의 그룹을 무작위화하는 데 사용되는 다른 "솔트"를 가지므로, 사용자는 이 실험의 이전 반복에서의 그룹과 독립적으로 그룹에 무작위로 할당됩니다. 이것은 중요한데, 새로운 결과가 이전 실행에서의 부정적이거나 긍정적인 경험의 영향을 받지 않도록 보장하기 때문입니다.
SRM이 있다고 해서 결과를 버려야 하나요?
우리는 실험에서 SRM의 존재를 가볍게 여기고 싶지 않습니다. 이는 실험에 방법론적으로 잘못된 것이 있을 가능성이 매우 높다는 것을 나타냅니다. 그러나 우리가 방금 실행한 실험을 완전히 무시하고 싶지 않을 수도 있습니다.
중요한 것은, 이러한 판단을 내릴 때 SRM의 근본 원인을 알아야 한다는 것입니다. 이 중요한 지식 없이는 실험 편향의 잠재적 원인을 고려하고 어떤 방식으로 결과를 편안하게 사용할 수 있는지 판단하는 것이 불가능합니다.
SRM이 있는 실험을 볼 때 실험에서 방향성 있는 통찰력을 얻을 수 있는지 여부를 결정하기 위해 고려하는 몇 가지 요소가 있습니다:
SRM을 일으키는 사용자 그룹이 다른 사용자와 얼마나 다른가?
예: 우리 실험에서 신규 사용자는 모두 테스트 그룹에 있고, 신규 사용자는 기존 사용자와 매우 다르게 행동하므로, 실험 결과를 완전히 무시하고 실험을 다시 시작합니다.
SRM을 일으키는 사용자 간의 차이가 처리에도 영향을 미칠 수 있나?
예: 우리 실험에서 새 기능이 더 높은 지연 시간을 일으키는 모든 Internet Explorer 사용자에 대해 중복된 항목이 있습니다. 이것이 전반적으로 보이는 부정적인 결과를 주도하는 것 같고, 다른 브라우저를 사용하는 사용자는 새 기능에서 작은 긍정적인 영향을 받는 것 같습니다. 이로 인해 다른 실험을 실행하기 전에 모든 웹 브라우저에서 지연 시간을 줄이도록 제품을 반복할 수 있습니다.
결국, 이것은 판단의 문제입니다.
실험을 다시 시작하고 SRM이 있었던 이전 버전에서 아무런 학습도 하지 않는 것에는 단점이 있을 수 있지만(지연된 의사 결정, 사용자에게 열등한 경험 제공), 가장 과학적으로 엄격한 접근 방식은 SRM을 일으키는 문제가 발견되면 항상 이러한 실험을 설계된 대로 다시 실행하는 것입니다.
SRM의 존재에도 불구하고 실험 결과를 고려하려면, CUPED를 사용하여 실험 전 편향을 제어하는 것이 편향을 해결하는 데 도움이 될 수 있습니다.