[67일차]지난 강의 리뷰

김준석·2024년 2월 28일

Today I Learned - 데브코스 데이터분석

데브코스_데이터분석-A/B Test[14주차]

목록 보기

10/25

A/B Test 버킷팅 코드

이전에 사용자 트래픽별 A/B Test 버킷팅 코드를 리뷰해 보았을 때

전체 사용자에 대해서 그룹을 지어버리게 되니 실용적이지 못한다고 했다.

또한 하나의 사용자가 여러 AB테스트에 들어갈 문제점도 발생할 수 있기에 버킷팅 코드를 좀 더 개선시켜 보자.

개선된 코드

점진적인 커버리지 증대 지원 : size_of_test 파라미터 추가(1, 5, 10, 50, 100)
- AB 테스트에 포함되지 않는 경우 -1을 리턴
md5 으로 새로운 숫자를 만들어낼 때 abtest_id도 추가
- user_id와 abtest_id를 합해서 새로운 id를 생성.
  이렇게 되면 하나의 유저가 여러 abtest에 들어가도 파악이 수월해진다.

def split_userid(abtest_id, user_id, size_of_test, num_of_variants=2):
	id = user_id + abtest_id
	h = hashlib.md5(str(id).encode())
	if (int(h.hexdigest(), 16) % 100) < size_of_test:
		return int(h.hexdigest(), 16) % num_of_variants
	else
		-1

이렇게 하면 Interaction을 줄일 수 있다.
Interaction : 상호작용 이슈.

A/B 테스트 QA의 중요성

많은 A/B 테스트는 개발자 혹은 디자이너의 손을 타고 구현이 된다.
즉, 그 과정에서 A/B 테스트 제안자의 생각이 제대로 반영되지 않을 수 있다.
- 코딩의 경우 항상 버그의 존재 가능성
- 이를 제대로 QA하는 것은 A/B 테스트 제안자의 책임이기도 하다.
특히 A/B 테스트 시스템 자체가 새로 만들어졌거나 변경이 생긴 경우 QA는 더 중요해진다.
주기적으로 A/A 테스트를 수행해보는 것이 중요하다.

새로운 기능의 점진적 커버리지 확대

만일 A/B 테스트 결과가 전체적으로는 안좋지만 특정 사용자층에 대해서만 좋다면,
그런 사용자들에게만 배포를 하면서 점차적으로 다른 사용자층에게 좋은 모델을 생성하는 식으로 진행하는 것이 좋다.

A/B 테스트 결과를 다양한 세그먼트의 사용자별로 보는 것이 중요.

즉 A/B 테스트로 모든 사용자들에게 특화된 기능을 만들려고 하기 보다는
각 사용자들에게 효과를 보는 모델을 만드는 식으로 하는 것이 더 좋은 경우도 있다!

A/B 테스트 성공의 경우 지표는 항상 좋아야 하나?

테스트에 따라서는 지표가 개선되지 않아도 성공적으로 간주할 수 있다.
- 예를 들어 운영비용이 적은 방식 또는 자동화로 리소스를 줄이는 경우 성공으로 간주 가능하다.
하지만 이런 부분은 기존 가설에 내용이 분명하게 명시되어 있어야 된다.
- 얻어 걸리는 식으로 하는 경우 KPI에 사용 불가할 수 있다.

모바일 앱 기반 A/B 테스트의 난점

어플의 경우 업데이트를 하는 사용자도 있고 안하는 사용자도 있을 수 있다.
모바일 휴대폰의 경우 시간정보를 사용자가 변경 가능하기 때문에 데이터 품질이 안좋을 수 있다.

안 좋은 AB 테스트 가설 예

잘못된 가설을 바탕으로 하는 경우
- 예)CS팀 문의자들의 Churn rate을 낮추겠다
굉장히 임팩트가 작은 기능 구현에 사용하는 경우
- 즉 가설이 중요한 문제를 다루지 않는 경우
B2C 환경에서 다른 가격대를 테스트하는 경우
- 하나의 강의를 고객들에게 다른 가격으로 판매하는 경우
- 컨트롤하기가 쉽지 않음 (실제 유데미 사례)
검색엔진 UI와 검색엔진 알고리즘을 동시에 테스트하는 경우
- 두 모델이 서로 상관관계가 있을 수 있기 때문에
  한번에 하나만 테스트 해야된다.(야후 차이나)