[데이터 애널리스트 공부] 데이터를 잘 활용하는 일본기업_메루카리_[시리즈] A/B 테스트 개선 -SRM 확인 및 원인 규명 우선순위 부여-

[데이터 애널리스트 공부] 데이터를 잘 활용하는 일본기업_메루카리_[시리즈] A/B 테스트 개선 -SRM 확인 및 원인 규명 우선순위 부여-

---

https://note.com/mercari_data/n/n2fe407bcc505?magazine_key=mf16f8a98b30a

[シリーズ]A/Bテスト改善 -SRMの確認と原因究明の優先順位づけ-｜Mercari Analytics Blog

 

안녕하세요 멜카리 Analytics팀의 @nakanipi입니다.저는 메루카리에서 홈 화면 주위나 메타데이터 기능의 분석·개선, 또 A/B 테스트의 개선을 담당하고 있습니다.

이번에는 '메루카리에서의 A/B 테스트 개선' 시리즈의 제2탄을 들려드리도록 하겠습니다.제1탄에서는 메르카리에 있어서의 A/B 테스트의 현존 과제를 전달했습니다.타자인 '테스트 설계·분석 방법의 확립과 보급'의 주제에 대해 본 기사에서는 SRM (Sample Ratio Mismatch : 사용자 수의 군간 편향) 에 대해 소개하겠습니다.

제1탄에서도 조금 언급했듯이 메루카리사 내에서는

-SRM을 확인하지 않고 결론 내린 A/B 테스트가 존재한다
-SRM이 발생했을 때의 대처 방법이 정리되어 있지 않아 주지되고 있지 않다

이런 문제가 있어 SRM에 대한 문서를 작성하고, 방법론이나 SRM 발생 시의 대처법을 정리해 주지시키고 있습니다.
이번 블로그에서는, SRM에 관한 개관과 메르카리에서의 대처에 대해 소개합니다.

또한 A/B 테스트 전체의 디자인에 관해서는 과거에 소개한 '메리카리에서의 A/B 테스트 표준화에 대한 대처'가 참고가 될 것으로 생각됩니다.

 

목차
1.SRM이란
2.SRM의 검지
  2-1.카이제곱검정 실시
3.SRM이 일어났을 경우의 원인 분류
4.SRM 5개의 대분류(FIVE COMMON TYPES OF SRMs)
5.사내 SRM 사례
A. 할당의 실수
B. 로그의 송신 에러
C. 쿼리 미스
D.인위적 개입
6.애널리스트 팀에 의한 SRM조사 우선순위
7.향후 전망
8.마지막으로

 

SRM이란

Sample Ratio Mismatch (SRM)는 A/B 테스트의 Control / Treatment 할당에 있어서 샘플 사이즈가 기대한 비율로 모이지 않았을 때 잘못된 분석 결과를 이끌어 버릴 가능성이 있는 현상을 말합니다. 예를 들어 실험 디자인에서는 사용자 할당 비율이 50:50이라고 가정했지만, 실제 할당에서는 60:40이 되어버려 우연이라고는 할 수 없는 차이로 판정할 수 있는 경우입니다.

SRM이 일어나고 있을 때 대부분의 경우 Control/Treatment 사이에 속성 및 경향 측면에서의 차이가 발생하고 있어 분석 결과에 바이어스가 발생할 가능성이 높아집니다.

 

https://x.com/ronnyk/status/932798952679776256?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E932798952679776256%7Ctwgr%5E0bbbf69d8dddf6b865ee6561f01f0106e6bc12a6%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fnote.com%2Fmercari_data%2Fn%2Fn3792921cc37d

X의 Ronny Kohavi님(@ronnyk)

SRM의 검지

그럼 어떻게 SRM을 감지하면 좋은 것일까요.

Control / Treatment의 실험 디자인 할당 비율을 귀무가설로 생각했을 경우, 실제 할당 비율이 귀무가설 하에서 얻을 가능성이 낮은 경우에 SRM이 발생하고 있다고 근거를 제시할 수 있습니다.즉, 적합도의 카이제곱 검정을 실시함으로써 기대만큼의 비율로 샘플 사이즈가 할당되어 있는지를 검지할 수 있습니다.

 

카이제곱검정 실시

엑셀 … bit.ly/srmCheck  from Kohavi 

python

import scipy as sp
import pandas as pd

## SRM detaction
assignment_ratio = 1 / 2

control_uu = 50
treatment_uu = 26

total_uu = control_uu  + treatment_uu
observed_values = [control_uu, treatment_uu]
expected_values = [total_uu * (1.0 - assignment_ratio), total_uu * assignment_ratio]
result = sp.stats.chisquare(observed_values, f_exp=expected_values)

print(f"control UU: {control_uu}")
print(f"treatment UU: {treatment_uu}")
print(f"P-Value in SRM: {result.pvalue}\n")

# in case significance level is 0.01
if result.pvalue > 0.01:
    print("Non SRM")
else:
    raise ValueError("SRM occurred")

 

SRM이 일어났을 경우의 원인 분류

그럼 SRM이 일어났을 경우 어떻게 원인을 규명하면 좋은 것일까요.
Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioners에서는 복수 기업에 있어서의 SRM 사례나 과거의 A/B 테스트의 재분석·분석자에 대한 인터뷰에 의한 SRM 원인의 분류를 소개하고 있습니다.저희도 참고하고 있기 때문에 소개하도록 하겠습니다.

 

SRM 5개의 대분류(FIVE COMMON TYPES OF SRMs)

논문에서는 SRM의 5가지 예와 함께 분류 결과를 소개하고 있습니다.

1. Experiment Assignment (실험의 할당)

테스트 개요: MSN.com 에서의 A/A 테스트(control vs control 테스트)
SRM 원인: 실험 할당 시스템의 버그로, 49.9:50의 비율이 되어 버렸다.

 

2. Experiment Execution (실험 실시)

테스트 개요: Skype 통화의 오디오 품질을 개선하기 위한 A/B 테스트
SRM 원인: 세션 중간에 실험 설정이 비동기로 새로고침되어 약 30%의 Treatment User 로그가 기록되지 않았다.

3. Experiment Log Processing (실험로그 처리)

테스트 개요: Microsoft의 Carlusel UI 개선을 위해 표시하는 카드를 12장에서 16장으로 늘린 A/B 테스트
SRM 원인: 인게이지먼트가 높은(카드에 많이 접촉한) Treatment군의 유저가 bot로 분류되어 제외되어 있었다.

3. Experiment Log Processing: The MSN Carousel Experimen

4. Experiment Analysis (실험 분석)

테스트 개요 : Microsoft FRE 페이지 (First-Run Experience : 사용자가 제품을 처음 열었을 때 나타나는 페이지) 건너뛰기가 사용자의 활동에 영향을 미치는지 여부에 대한 A/B 테스트
SRM 원인: 트리거 조건 (할당할 때의 조건) 가 분석 대상의 전 유저를 커버할 수 없었다.

5. Experiment Interference (실험의 방해)

테스트 개요: Microsoft Homepage 재설계 A/B 테스트
SRM 원인: 검색 엔진 캠페인으로 인해 일부 사용자가 강제로 Treatment 군에 할당되어 버렸다.

 

사내 SRM사례

여기에서는, 실제로 메루카리 사내에서 일어난 SRM에 대해 「SRM의 5개의 대분류」에 대조해 소개하고자 합니다.

A. 할당의 실수

이것은 실험 할당 설정을 잘못하여 SRM이 발생한 사례입니다.이 실험은 3군의 할당(Control / Treatment 1 / Treatment 2)의 한 실험으로 Control군의 할당 수가 유의하게 많아지고 있었습니다.원인 규명을 위해 먼저 실험 설정을 확인했습니다.메루카리에서는 내부 실험 시스템(이른바 Feature Flag)을 가지고 있습니다.실험 전에 Feature Flag 설정 화면에서 각 군에 대해 몇 %를 할당할지 웨이트 설정을 합니다.이 설정을 확인한 결과, 이 웨이트의 설정이 34:33:33으로 되어 있었던 것을 알 수 있었습니다.정확하게는 SRM이 아니라 설정대로인 것을 알았기 때문에 문제가 없다고 판단하고 그대로 실험·분석을 실시하고 있습니다.

 

B. 로그의 송신 에러

이것은 로그의 송신 에러에 의해서 SRM이 일어나 버린 사례입니다.API 불러오기에서 오류가 발생했을 때 집계 대상 테이블로 로그 전송이 Treatment군만 건너뛸 수 있도록 구현되어 있었습니다.SRM이 일어나는 것을 확인한 후 시스템 조사를 진행하여 버그가 발견되었습니다.실험 설정도 쿼리도 틀리지 않은 경우 시스템을 의심하는 흐름으로 진행하고 있습니다.

C. 쿼리 미스

이는 실험 분석 중 쿼리 오류로 인해 SRM이 발생한 사례입니다.Treatment군에 대한 할당 수가 유의하게 많아지고 있었습니다.실험의 분석을 실시하는 쿼리로 할당 유저와 관측하고 싶은 지표를 연결하는 처리에 있어서, INNER JOIN이 원인으로 특정한 행동을 하고 있던 유저가 최종적으로 UU수로 출력되고 있었습니다.그 때문에 당초의 할당 비율에 대해 Control/Treatment 군 모두 유저수가 함께 왜곡되어 버렸던 것을 알 수 있었습니다.이 사례에서 수동으로 쿼리를 다시 사용하는 등에는 특히 조심해야 한다는 교훈을 얻을 수 있었습니다.

 

D.인위적 개입

이것은 실험에 대한 인위적 개입으로 인해 SRM이 발생한 사례입니다.Treatment군에 대한 할당 수가 유의하게 많아 집계 쿼리는 문제가 없음을 확인할 수 있었습니다.실험 중 계속 SRM이 일어나고 있는지, 어느 기간에만 SRM이 일어나고 있는지 확인하기 위해 일일로 실험 대상 사용자의 수를 확인했습니다.그러다 어느 기간에만 SRM이 발생했고, 이 상황을 프로덕트 매니저에게 전달했더니 그 기간에 Treatment군 사용자에게만 알림을 보낸 것이 발각됐습니다.이 실험에서는, 어떤 화면을 보는 것이 할당의 트리거였지만, Treatment군에 대해, 그 화면에 액세스를 재촉하는 것 같은 통지를 보내고 있었던 것 같습니다.이로 인해 알림을 보낸 타이밍에 Treatment 군에서 사용자 수가 일시적으로 많아져 SRM이 일어나고 있었습니다.이 사례에서 트리거 발화 전에 알림을 보내는 것은 피하는 것이 좋다는 교훈을 얻을 수 있었습니다.

 

E. 랜덤

SRM의 대분류로서 생각할 수 있는 원인을 모두 검증한 후, 그래도 결과를 알 수 없는 경우도 있습니다.이 경우 SRM의 판정은 랜덤이 원인(우연히 판정이 유의하게 되었다)으로 결론짓고 재테스트를 실시하고 있습니다.

 

Analytics 팀의 SRM 조사 우선 순위 부여

현재, 메루카리에도 A/B 테스트 집계 자동화 툴은 존재하지만, 모든 팀에서 사용할 수는 없기 때문에 수동 집계와 같은 휴먼에러에 의해 가까운 지점부터 조사하도록 하고 있습니다.

전제적으로 이 원인규명 프로세스는 A/A 테스트가 끝나고 복수의 A/B 테스트가 행해진 적이 있는 영역에서 SRM이 발생한 경우를 상정하고 있습니다.만약 첫 화면이나 디바이스에서 A/B 테스트를 하는 경우는, 우선 A/A 테스트를 실시해, Feature Flag의 설정이나 시스템에 문제가 없는지를 확인합시다.

우선 의심해야 할 것은 집계의 실수입니다.집계 기간이 올바른지, 트리거나 제한 조건을 틀리지 않았는지 등을 확인합니다.또, 쿼리를 스프레드시트 등에 붙여 한층 더 통계량을 계산하거나 할 때에는 함수나 셀 참조의 오류가 없는지등도 확인해 갑니다.

만약 여기서 집계가 맞을 것 같으면 실험 설정을 보러 가겠습니다.원래 할당 설정이 언밸런스라면 물론 결과도 언밸런스가 됩니다.그 외에도 사용하고 있는 툴에 따라 다르지만 Treatment의 수를 늘리거나 줄이거나 실험의 개방율을 올릴 때 역치가 아닌 군간의 웨이트를 바꾸어 버렸을 경우에는 SRM이 일어날 가능성이 높아집니다.또한 통지를 보내지 않았는지 등 실험에 대한 인위적 개입에 대해서는 프로덕트 매니저에게 확인합니다.

집계와 실험 설정이 올바른 것 같으면 마지막으로 구현이 올바른지 확인합니다.Control/Treatment에서 다른 거동을 하는 곳은 없는지, 로그의 송신이나 퍼포먼스는 올바른지, 파이프라인의 조사 등을 엔지니어분들께도 협력하면서 확인해 나가겠습니다.

이렇게까지 조사해도 원인을 알 수 없는 경우에는 위에서 설명한 바와 같이 랜덤일 가능성도 있습니다.일정한 확률로 일어날 수 있기 때문에, 그 경우는 실험을 다시 합니다.

논문의 10가지 SRM 조사 지침(Rules of Thumb for SRM Investigations)에서는 SRM의 진단과 분류를 신속하게 수행하기 위한 10가지 관점에 대해 소개하고 있으므로 이에 대해서도 많은 참고가 될 것입니다.

향후 전망

우선 순위를 정하고 있어도 SRM 조사에는 막대한 시간을 필요로 하기 일쑤입니다.
SRM의 근본 원인을 없애기 위해 향후 전망으로 휴먼 에러를 없애기 위해서라도 A/B 테스트 자동화 툴의 적용 범위를 확대하는 것을 목표로 하고 있습니다.

마지막으로

앞으로도 Mercari Analytics Blog에서는 AB테스트 개선을 위한 3가지 대처에 따라 기사를 소개하고자 합니다.다음 번에는 '테스트 설계·분석 방법의 확립과 그 보급'에 관련된 A/B 테스트 결과의 분석·해석 방법에 대한 기사가 나올 예정입니다.앞으로도 꼭 @mercari_data 를 팔로우해서 새로운 기사를 체크해주세요.기대해 주세요.

메르카리사내에서는, AB테스트 개선을 위한 3개의 대처에서 말한 대로 A/B테스트 주위에서는 아직 해야 할 일이 많은 상황입니다.이 개선을 통해서 사내 전체의 데이터 활용의 레벨을 끌어올림으로써, 제대로 된 의사결정에의 공헌을 실시할 수 있게 된다고 생각하고 있습니다.

---

[데이터 애널리스트 공부] 데이터를 잘 활용하는 일본기업_메루카리_[시리즈] A/B 테스트 개선 -SRM 확인 및 원인 규명 우선순위 부여-