샘플 비율 불일치(SRM)

표본 비율 불일치(SRM)는 실험 변형 간 트래픽의 실제 분배가 의도된 분배와 무작위 변동으로 설명할 수 있는 범위를 넘어설 때 발생합니다. 예를 들어, 50/50으로 균등하게 분배되도록 설정된 테스트에서 대조군에 51,200명, 변형군에 48,800명의 방문자가 유입된 경우, 이는 단순히 운이 나빴던 것이 아닙니다. 해당 규모의 트래픽에서 정확한 무작위 배정을 가정했을 때 이 정도의 차이는 통계적으로 발생할 가능성이 매우 낮습니다. SRM은 예상 할당량에 대한 카이제곱 검정을 통해 감지되며, SRM이 발생한 것으로 나타난 테스트는 원인을 찾을 때까지 유효하지 않은 것으로 간주해야 합니다.

SRM이 중요한 이유는 두 그룹이 더 이상 비교 가능하지 않다는 것을 나타내기 때문입니다. 통제된 실험의 전체 논리는 무작위 배정을 통해 적용된 처리 방식만 다른 두 그룹을 생성하는 데 기반합니다. 만약 어떤 체계적인 과정이 특정 방문자를 한 그룹으로 유도하거나, 다른 그룹의 방문자를 집계 전에 제외한다면, 관찰된 전환율의 차이는 테스트 중인 변화가 아닌 그러한 과정을 반영하는 것일 수 있습니다. 보고된 결과는 단순히 부정확한 것이 아니라, 연구팀이 측정하고자 하는 것과는 다른 것을 측정하고 있는 것입니다.

원인은 거의 항상 통계적인 문제라기보다는 기술적인 문제입니다. 로딩 속도가 느린 변형 코드는 방문자가 집계되기 전에 이탈하게 만들어, 인내심이 부족한 사용자들을 특정 그룹에서 체계적으로 제외시킵니다. 리디렉션 기반 테스트는 리디렉션 중에 트래픽 손실을 초래하며, 이러한 손실은 기기나 연결 속도에 따라 고르게 분산되지 않습니다. 변형별로 봇 필터링이 일관성 없이 적용되거나, 캐싱 레이어가 특정 버전에만 불균형적으로 서비스를 제공하거나, 한 변형에서는 렌더링 완료 전에 추적 호출이 발생하지만 다른 변형에서는 후에 발생하거나, 동시에 실행되는 실험 간의 상호 작용 등 모두 SRM을 유발합니다. 이러한 각각의 결함은 비율을 확인했는지 여부와 관계없이 결과에 영향을 미칠 수 있습니다.

적절한 대응은 테스트를 중단하고 원인을 진단하여 수정하고 처음부터 다시 시작하는 것입니다. SRM(스위칭 랜덤화) 오류로 인해 영향을 받은 테스트를 그룹 가중치를 재조정하거나 하위 집합을 분석하여 복구하려는 시도는 거의 정당화될 수 없습니다. 누락되거나 잘못 할당된 트래픽이 무작위로 누락된 것이 아니기 때문입니다. 이미 3주 동안 트래픽을 소모한 테스트를 살리고 싶은 강한 욕구가 있으며, 특히 테스트 결과가 긍정적인 것처럼 보일 때는 더욱 그렇습니다. 그러나 잘못된 무작위화로 인한 결과는 증거로서의 가치가 없으며, 그러한 결과에 기반하여 제품을 출시하는 것은 테스트를 전혀 하지 않는 것보다 더 나쁩니다.

SRM은 누군가가 찾아보지 않는 한 눈에 띄지 않기 때문에 검사 ​​과정이 자동화되어야 합니다. 성숙한 프로그램은 표준 분석 파이프라인의 일부로 모든 실험에 대해 SRM 테스트를 실행하고, 엄격한 임계값을 초과하는 편차를 표시하며, 해당 플래그가 해제될 때까지 결과를 발표하지 않습니다. 과거 실험에 대한 사후 감사를 통해 상당수의 과거 테스트가 영향을 받았다는 사실을 발견하는 경우가 많은데, 이는 테스트 프로그램에서 발견할 수 있는 불편한 사실 중 하나이지만, 동시에 가장 가치 있는 발견이기도 합니다. 왜냐하면 과거의 성공 사례가 왜 실제 비즈니스 결과로 이어지지 않았는지 설명해 주기 때문입니다.

불일치 문제를 조사하는 것은 단순한 탐색이 아니라 체계적인 과정입니다. 첫 번째 단계는 불균형이 테스트 도구 자체의 할당 기록에 존재하는지 아니면 분석 플랫폼의 기록에만 존재하는지 확인하는 것입니다. 이를 통해 무작위 배정 문제와 추적 문제를 구분할 수 있습니다. 두 번째 단계는 기기, 브라우저, 지역, 트래픽 소스별로 비율을 분류하는 것입니다. 원인이 특정 그룹에 불균형적으로 영향을 미치는 경우가 많으며, 가장 큰 편차를 보이는 그룹이 문제의 원인을 직접적으로 가리키는 경우가 많기 때문입니다. 세 번째 단계는 시간적 맥락을 확인하는 것입니다. 초기에는 정확했지만 나중에 변동이 생긴 비율은 배포, 캐싱 변경 또는 테스트 도중에 도입된 타사 스크립트와 같은 변화를 나타낼 수 있습니다. 각 조사 내용을 문서화하면 반복되는 원인 목록을 구축할 수 있으며, 대부분의 조직은 대부분의 문제에 대해 동일한 두세 가지 원인을 발견합니다.

자동 SRM 점검 도입은 일반적으로 가장 초기에 제시되는 기술적 권장 사항 중 하나입니다. CRO 서비스 참여도가 높은 이유는 구현 비용이 매우 저렴하고 프로그램이 생성하는 모든 결과물의 신뢰성을 즉시 향상시키기 때문입니다. SRM이 변형 렌더링 지연이나 리디렉션 지연으로 인해 발생하는 경우, 해결책은 다음과 같습니다. 웹 성능 테스트 도구 자체보다는 작업 방식에 문제가 있을 수 있으며, 근본적인 속도 문제를 해결하면 실험의 타당성과 측정되는 전환율 모두 향상되는 경향이 있습니다.