‘SQL’ 분석 트레이닝 - (3) A/B 테스트 (*협업 툴 Yammer)

강의 시나리오를 따라하고 실제로 sql 을 활용하여 문제를 해결하는 과정을 기록하기

프로젝트는 3 가지 이다.

프로젝트 1 - 유저 인게이지먼트 하락 원인 분석

프로젝트 2 - 검색 기능 분석

프로젝트 3 - A/B 테스트      <<<

(출처: [백문이불여일타] 데이터 분석을 위한 SQL 실전편)

• 프로젝트 진행 순서 (원문)
  • The problem
  • Getting oriented
  • The data
  • Making a recommendation
  • Answers

 

프로젝트 3 -  A / B 테스트

Validating A/B Test Results | SQL Analytics Training - Mode

Validating A/B Test Results | SQL Analytics Training - Mode

튜토리얼 페이지 : 프로젝트를 진행하기 위한 배경정보 페이지

 

 

 

A/B 테스트는 새로운 기능을 개발하기 이전에 기존의 기능을 향상시킬 수 있으며,

유저들의 행동패턴과 기능의 경험을 보다 잘 이해할 수 있게 한다.

A/B 테스트 대상인 &ldquo;publisher&rdquo; 기능

 

6월 한 달간 A/B 테스트를 진행하였다. ”control group”(대조군)은 기존의 버전을, ”treatment group”(실험군)은 새 버전을 사용하게 하였다.

 

 

문제 상황

새로운 기능을 사용하는 실험군에서 평균 50% 이상 더 많은 메세지가 포스팅 되었다. (유저수는 다르다.)

그러나 너무 많은 수치가 차이가 나기 때문에 어떤 실험상 오류가 있었는지 확인이 필요하다고 판단하였다.

 

&ldquo;publisher&rdquo; A/B 결과

• users
• total_treated_users : test group + control group
• treatment_percent : test group users / total treated users
• total : 실험기간 동안(한 달)
• average : total / users
• rate_difference : test_group 4.07 vs control_group 2.6 (인당, 실험기간동안, 테스트 그룹이 50% 더 높게 나타남)

(이하 통계 방법 생략)

• rate_lift
• stdev
• t_stat
• p_value

 

 

시작하기

데이터를 보기 전에 어떤 자료가 필요할지 생각 해보자. 표본 수는 충분한지 (p-value) << 가격 정책의 경우 표본 수 건드리기 힘들 수 있음 서비스 기능 <> 매출 ?!

 

 

데이터

일관성 있는 실험 설계이다.

6월 한달 기간 동안에 ’유저A가 control 그룹이면 test 그룹이 되지 않는다.'

 

Table 3 : Experiments

user_id

ocurred_at

experiment : 실험 설명 1. “publicher” 2. ㅇㅇㅇ 3. 등등

experiment_group : “test_group”, “control_group” 등 분류

location

device

 

 

결과 검증

가설의 결과를 검증할 수 있는 단계들

• “publisher” A/B 결과 << 쿼리 검증 해보기
• 메세지 포스팅 지표 << 이외에 다른 지표(로그인, 매출 등) 살펴보기
• 지표나 결과에 대한 데이터가 맞는지
• 결과적으로 이 기능을 공개할지? 테스트를 다시 할지?

 

 

준비하기

데이터를 보기 전에 가설을 세워보는 것이 중요하다.

• 의미있는 지표인가?
  • 포스팅 수치가 비지니스에 좋은지
  • 포스팅을 극단적으로 강조하면 어떻게 될지
• 제대로 측정 되었는가?
  • 방법론이 잘못 되었는지
  • 계산에서 실수가 있는지
• 실험 집단이 잘 처치 되었는가?
  • 유저들이 각 그룹에 랜덤하게 잘 분포 되었는지 (성별, 나이 등)
  • y(posting rates) = x(publisher) * (old or new)실험 외 변수나 상호작용 효과는 없는지?
  • x(독립변수) 이외에 기타 변인이 있는지

 

 

결과 검증

1. 로그인 지표 분석

앞서서 언급했듯이 포스팅 수치 뿐만아니라 다른 지표도 함께 살펴 보아야 한다. 포스팅 경험이 어떻게 나타나는지 또는 긍정적이었는지.

• yammer는 로그인 빈도를 핵심 지표로 보고 있다.

1-1. 실험 기간내 총 로그인 횟수

 

1-1. 해석

: 유저 당 평균 로그인 빈도는 상승했다.

하지만 로그인 빈도가 꾸준하게 증가한 것인지 특별한 이슈로 인한 일시적인 현상인지 알아야 한다.

1-2. 실험 기간내 로그인 빈도 (days)

1-2. 해석

: 실험 기간 동안 실험집단이 0.6일 더 자주 로그인하였다.

1-1과 1-2를 연결하여 보았을 때,

대략적으로 하루에 실험집단이 1.13 (=4.1 / 3.6) , 대조집단이 1.1 (=3.3 / 3.0) 만큼 더 자주 로그인 하는 것으로 나타났다.

 

 

 

2. 샘플링의 공정성

통계학의 방법론의 오류는 스킵…

(1-tailed vs. 2-tailed tests, required sample sizes, assumptions about sample distributions, etc.)

실험 기간 동안에 기존 유저와 신규 유저가 모두 포함되었는데, 기간 후반에 유입된 신규 유저는 포스팅 할 시간이 부족할 수 있다.

새로운 기능이나 업데이트로 인한 유저들은 일시적인 관심일 수 있다.

하지만 신규 유저에게는 이 효과가 적용되지 않는다.

따라서 신규유저와 기존유저를 구분해서 확인해 볼 필요가 있다.

 

 

3. 유저 분포

신규유저와 기존유저의 cohort 결과를 보면,

그룹당 유저 분포

모든 신규유저가 control_group 속해 있었다.

잠정 결론이었던 신규 포스팅 기능의 사용량이 많았던건, control_group에 신규유저가 몰려 있었기 때문일 수 있다.

(신규 유저는 포스팅 할 시간이 없었을 수도..)

 

따라서 이러한 유저들의 특질적인 차이를 제외시킨 상태

즉, 기존유저들만으로 다시 A/B 테스트 or 재집계 해볼 수 있다.

 

(좌) (1) “publisher” A/B 결과 (기존+신규 유저)  /  (2) “publisher” A/B 결과 (기존 유저)

기존 유저 데이터만 측정해본 결과

(1) : test_group = 4.07 , control_group = 2.66

(2) : test_group = 4.07 , control_group = 2.91

두 그룹간의 갭이 줄어들었지만, 테스트 그룹에서 “publisher” 전송횟수가 더 많다는것은 확인되었다.

(추가적으로 로그인 지표도 함께 비교해볼 수 있겠다.)

 

 

4. 추가적인 문제탐색

새로운 유저 vs. 기존유저 뿐만 아니라

디바이스별

유저타입별로(i.e., contents producers vs. reders) 등

 

결론적으로

몇 가지 컨트롤 가능한 변수를 제외했음에도 불구하고 명확하게 차이나는 결과를 보인다.

그러나 그룹간 cohort를 확인해볼 필요가 있으며,

실험 설계에서 새로운 유저가 모두 컨트롤 그룹에 속하게 되는 버그는 수정되어야 한다.

 

 

주요 SQL 해설

그룹별 평균 메세지 발신

SELECT user_id,
       experiment,
       experiment_group,
       occurred_at
  FROM tutorial.yammer_experiments
 WHERE experiment = 'publisher_update';

실험 기본 정보 출력

 

occurred_at은 실험에 참가한 날짜이다.

따라서 user_id 별로 occurred_at 부터 6월30일 까지의 이벤트 로그를 봐야한다.

SELECT user_id,
       experiment,
       experiment_group,
       occurred_at
  FROM tutorial.yammer_experiments ex
       INNER JOIN tutorial.yammer_users u ON ex.user_id = u.user_id 
        LEFT JOIN tutorial.yammer_events e ON ex.user_id = e.user_id 
              AND e.occurred_at BETWEEN ex.occurred_at AND '2014-06-30 23:59:59'
              AND e.event_name = 'send_message'
 WHERE experiment = 'publisher_update';

INNER JOIN 과 LEFT JOIN을 사용해 실험에 참여된 사용자를 구분해 낸다.

해당기간동안에 'send_message' 이벤트를 걸러낸다.

SELECT experiment_group
     , COUNT(user_id) AS user
     , AVG(cnt_send_message) AS average
     , SUM(cnt_send_message) AS total
  FROM (
        SELECT u.user_id,
               ex.experiment_group,
               COUNT(e.user_id) AS cnt_send_message
          FROM tutorial.yammer_experiments ex
          INNER JOIN tutorial.yammer_users u ON ex.user_id = u.user_id 
           LEFT JOIN tutorial.yammer_events e ON ex.user_id = e.user_id 
                 AND e.occurred_at BETWEEN ex.occurred_at AND '2014-06-30 23:59:59'
                 AND e.event_name = 'send_message'
        WHERE experiment = 'publisher_update'
        GROUP BY u.user_id, ex.experiment_group
      ) smbu -- send message by user
GROUP BY experiment_group;

COUNT(user_id) 유저별 'send_message' 횟수 그리고

AVG(cnt_send_message), SUM(cnt_send_message) 그룹별 평균 횟수와 합계를 출력한다.

카운팅 집계된 테이블을 ‘smbu’로 서브쿼리화 시킨다.