안녕하세요!
데이터 맛집의 스터디주제로 새로운 알고리즘이 기업이나 고객에게 얼마나 많은 영향을 미치는가를 파악하는 테스트 기법을 소개 해 드리겠습니다.
소프트웨어 혁신은 세상을 바꾸고, 개인에게 권한을 부여하며, 경제를 성장시키는 등 예상을 뛰어넘는 수준으로 발전을 가속화하고 있습니다.
하지만 이러한 디지털 변환의 진정한 잠재력은 이러한 혁신이 제공하는 데이터의 잠재력을 이해할 때에만 파악할 수 있습니다. 사실 우리는 데이터 혁신과 함께 살아왔습니다. 방대한 양의 데이터뿐만 아니라 정보를 수집하고, 저장하고, 분석하고, 변환하는 방식을 바꾸는 이러한 데이터 혁신을 주도하여 더 나은 로직(솔루션)을 통해 기회를 모색합니다.
이후, 기존 대비 로직(솔루션)을 통해 얼마나 많은 발전이나 비즈니스의 성장이 있었는지 파악하여 또다시 하여금 재 성장할 발판을 만들게 됩니다. 좋은 알고리즘이나 모델을 개발하는 것도 중요하지만, 실질적으로 도움을 주는 Volume의 크기를 측정하는 방법 중 하나인 A/B Test를 소개 해 드리고자 합니다.
요약 하자면,
- 집단 특성간 차이를 고려할 것
- OMTM이나, 핵심 지표기준 달성 목표로 생각할 것
- 실제로 일어난 사실을 근거로 테스트 할 것
A/B 테스트(A/B Test)란?
- 마케팅과 웹 분석에서, A/B 테스트(버킷 테스트 또는 분할-실행 테스트)는 두 개의 변형 A와 B를 사용하는 종합 대조 실험(controlled experiment)입니다.통계 영역에서 사용되는 것과 같은 통계적 가설 검정은 "2-표본 가설 검정"의 한 형태다.
(위키백과 참조)
단순히 새로운 알고리즘이나 로직이 기존 알고리즘 대비 얼마나 성능을 개선시켰는가를 넘어, 기업과 비즈니스에 각각의 테스트가 어떤 도움을 줄 것인지에 대하여 설명 하고자 합니다.
특성집단을 반영한 세그먼트간 A/B Test
A/B Test는 대부분 일반적으로 모든 사용자에게 동일한 확률로 같은 변형(예를 들어, 사용자 인터페이스 요소)을 적용합니다.
하지만, 같은 상황에서, 변형에 대한 응답은 이질적일 수 있으며, A Test set가 전반적으로는 더 높은 응답률을 가질 수 있지만,
B Test set가 고객 기반의 특정 세그먼트(개인화)에서는 훨씬 더 높은 응답률을 보일 수도 있습니다.
예를 들어 보겠습니다.
| 성별 | 전체 | 남성 | 여성 |
| 노출 | 1000 | 500 | 500 |
| 전환 | 130 | 60 | 70 |
| A | 65/1000(6.5%) | 10/500(2%) | 60/500(12%) |
| B | 65/1000(6.5%) | 50/500(10%) | 10/500(2%) |
우선 1000건의 노출로, 130의 전환이 일어났다면, ROI는 13% 발생 하였으며, A와 B는 각각 6.5%의 ROI를 획득 할 수 있었다.
그렇다면 정말 A와 B의 Test간 효과는 동일 했을까요?
이 경우, 결과적으로 A/B 테스트의 결과로 세분화 전략을 취해, 앞으로 남성에게는 B를 보내고 여성에게는A를 보낼 수 있습니다. 예시를 통해, 개인화된 A/B 테스트를 통해 남성 응답률이 증가(500% 증가)할 것을 예상할 수 있었습니다.
OMTM, KPI, NSM 등 핵심 지표 달성 A/B Test
OMTM(One Metric That Matters)은 "지금 가장 중요한 하나의 지표"를 의미합니다.
현 시점에 발생한 상황을 대응하기 위한 목표라고 생각할 수 있으며, 팀 단위 또는 프로젝트 별 목표라고 생각합니다.
엔지니어 팀의 경우 사이트의 버그 개선수가 OMTM이 될 수 있으며, 마케팅 팀의 경우라면 다양하겠지만 프로모션 기간 내 이벤트 참여 수 등이 될 수 있습니다.
이처럼 OMTM은 현 상황을 빠르게 대응하기 때문에 단기적으로 달성 가능한 OMTM을 설정하여 관리하게 됩니다.
'우리의 알고리즘이나 로직이 기존에 상황(문제)를 해결하고자 하는 목적은 무엇인가'를 찾는것은 모든 팀 단위가 풀어나가야 할 목적지 입니다.
위의 그림처럼 A카테고리의 매출 증가라는 OMTM의 달성을 위해 해당 원인 분석 한다.
만약 카테고리의 매출이 적었다면 원인 분석을 통해 특정 버그나 상품 없음의 문제로 원인을 파악 하고 좀더 깊게 확인해 보면 특정 버그나, 노출의 문제로가 매출이 저조 하였다는 것을 알 수 있습니다.
원인A, 원인B 중 OMTM을 달성시킬 원인은 무엇일까요?
단순히 위의 모델처럼 비즈니스에서 원인을 파악하기는 어렵겠지만, 원인을 해결하기 위해 풀어나가기 위해 우리는 원인A, B로 원인을 정리하여, 어떤 원인이 문제를 해결해 갈지 Test 할 수 있습니다.
다수의 원인이 분석 되었다면, 실행 가능한 모든 원인을 해결 하는 것보다, 해당 원인 중 일부를 구동하여, 실질적으로
카테고리 내 버그를 20%해결하고, 주요상품노출을 20%증가시켜, 무엇이 이용자(User)에게 긍정적인 영향을 주는지 파악하며, 해당원인을 먼저 개선하는것이 의사결정과, 비용절감, 한정된 자원을 활용하는 것에 도움을 줄 수 있습니다.
알고리즘 간 A/B Test
Recommendation System의 기본적 개념은 특정 고객이 선호하는 List를 set-up 시키는 것이다.
예를 들어 설명하자면, 남북 정상회담이 개최되는 시기에 특정유저들이 선호하는 뉴스를 기반으로 추천시스템을
개발한다고 가정했을 때, 축적된 DB기반으로 어떠한 규칙과 페턴을 정형화 시켜 유저가 선호할 만한 뉴스를 추천해 준다.
하지만 대부분의 추천 서비스에나 나타나는 문제인 information utilization problem를 체감하게 되는 이유는
추천 시스템 구축에 활용하기 위한 데이터, 정보들을 올바르게 활용하기 위한 고민에서 나온다고 할 수 있다.
e-commerce를 예를 들어, 고객들은 상품을 구매하기 위하여 다음과 같은 프로세스로 제품을 선택한다.
ㅇ서비스가 활성화 됨에 따라 고객의 수, 제품의 품목 수는 증가한다.(차원의 저주)
ㅇ각 프로세스 별 로그데이터가 의미하는 바는 다르다.
대부분의 고객들은 상품을 눌러보고, 다른 상품도 살펴보고, 본인 기준에 마음에 든다면 장바구니에 넣어뒀다가 이를 구매하기도 한다. 이런 정보들을 Implicit Score(암묵 점수)라고 한다.
또한 '왓챠'나 '넷플릭스' 같은 영화 추천 서비스에서처럼, 사용자들은 아이템에 대한 명확한 평가를 내리지 않는다.
단지 상품을 눌러보고, 관심 표시를 하거나 구매 하는 정도이다. 상품에 대한 리뷰를 작성하거나 별점을 주는 고객은
극소수에 가깝다. 이러한 로그 데이터 속에 숨어있는 정보를 이용하는 고민이 필요하다. 하지만 이것이 쉽지 않기 때문에 Information Utilization Problem(정보활용의 문제) 이라고 부르는 것이다. 만약 고객의 구매 목록 데이터가 있을 때,
구매가 완료되었다고 과연 이 데이터가 상품에 대한 호감을 나타내는 데이터라고 할 수 있을까?
환불이나 교환이 일어났다면? 이 모든 것을 고려하여 데이터를 활용하기 용이한 Explicit Score(명시 점수 :
영화 평점에 대한 rating 같은 점수)처럼 데이터를 Utilization 하는 과정이 필요할 것이다.
Explicit Score와 Implicit Score를 파악 한 후에는?
Implicit Score와 Explicit Score가 항상 좋은 데이터인 것은 아니다. 대부분의 잘 정리된 명시 점수의 외에도 Sparsity Problem을 심각하게 겪을 것이다.
이러한 문제를 정확히 예측한다는 것은 사실상 불가능하다.
그렇지만 우리가 만들어 가야 할 서비스의 가장 큰 목적은 " how to make user to feel satisfy " 이다.
각 요소 별 Score의 가중치와 외부요소들의 만들어진 추천 알고리즘 간 A/B Test을 통해 알고리즘간 성능 테스트 역시
진행 되어야 할 요소이다.
이상으로 활용사례를 통해 A/B를 알아보았습니다.
“Test Everything (모든것을 테스트하는)” 문화는 많은 장점이 있지만, AB 테스트 건수를 KPI 로 설정하는 건 말그대로 주객이 전도된 것입니다.
이 경우 많은 리소스를 허비하는것 뿐만 아니라, 결국 테스트를 통해 달성하려는 비즈니스 목표도 잊혀지게 됩니다.
굳이 테스팅이 필요없는 경우에도 시간과 리소스를 투입하고있는건 아닌지 항상 주의가 필요합니다.
테스트를 위한 테스트는 피하자
“올해 저희팀 KPI 는 AB테스트 20회 입니다.”
기억하세요:
목적 없는 테스팅을 경험한 이는 아래와 같이 말합니다.
예전에 다녔던 회사에는 모든 변경이 AB 테스트를 거쳐야 한다는 규칙이 있었다.. (중략)..
그런 와중에 AB 테스트 건수로 팀을 평가하겠다는 공지가 내려왔다. 각 개발팀은 좋은 평가를 받기 위해 온갖 잡다한 아이디어를 짜내 AB 테스트를 수행하기 시작했다. 어떤 가설을 세웠고 어떤 사실을 배웠는지는 중요하지 않았다. AB 테스트 건수를 늘리는 게 중요했다.
무작위로 AB 테스트를 진행하면서 소가 뒷걸음치다 쥐를 잡는 격으로 운 좋게 대박이 걸리는 경우도 있었지만, 그 성공은 다른 성공으로 이어질 수 없었다.
'추천 시스템 > Testing' 카테고리의 다른 글
| [A/B Test] A/B테스트 개인화 이론 (0) | 2020.03.26 |
|---|---|
| [A/B Test] Page Lanking, Retention 관련 Testing (0) | 2020.03.19 |
