[A/B test] 뱅크샐러드 A/B test 사례

뱅크샐러드 실험 관련 조직

• 신뢰성 : 실험플랫폼을 통해 신뢰할 수 없는 데이터를 제공받은 사용자는 잘못된 의사결정을 하게 됩니다. 만약 이러한 경우가 반복된다면, 사용자는 실험플랫폼의 분석 결과를 믿지 않고 데이터 기반 의사결정을 거부하게 될 것입니다.

• 유연성 : 다양한 영역에서 실험을 가능하게 만들어야 하고, 이를 정량적으로 측정하기 위한 여러 종류의 실험 지표를 지원해야 합니다. 이뿐만 아니라 더 효율적인 실험을 제공하고 연구하기 위해서는 Data Scientist & Analyst들이 쉽게 새로운 통계 방법론을 추가해 볼 수 있는 환경이 필요합니다.

뱅크샐러드의 실험 히스토리는?

뱅크샐러드가 생각하는, 실험을 해야하는 이유

뱅크샐러드가 실험 조직 문화를 만들기 위한 노력

• 뱅크샐러드 구성원이라면 누구나 데이터를 조회하고 분석할 수 있는 역량을 가질 수 있도록 1분기 내내 각종 가이드를 만들고 데이터 관련 교육을 진행

• 1분기 동안 총 12개의 가이드를 만들고, 5번의 교육을 제공

• 데이터 조회를 어려워하거나 고도화된 분석이 필요한 분들을 위해 “데이터 자문 서비스”를 만들어 어려움을 겪는 분들을 도움

• 기초적인 내용을 모아서, 신규 입사자들을 대상으로 뱅크샐러드 데이터 활용하는 온보딩 강의를 진행

뱅크샐러드의 발전된 실험 조직 문화

• 초기 : 실험 플랫폼 팀이 개발자들을 위한 실험 생성 가이드, 배포 가이드 등을 제공
→ 각 스쿼드에서는 개발자분들의 도움을 받아 실험을 생성하고 진행

• 후기 : 전사 구성원들이 점차 실험 문화에 적응해나가기 시작할 무렵, 실험 플랫폼 웹이 배포

뱅크샐러드가 인하우스 실험 인프라로 처음 실행한 실험은?

실험에 대해 오해하여 발생한 커뮤니케이션은?

실험 문화 적응을 위한 노력

• 실험 설계에 작성하는 내용을 최대한 간소하게 변경하여, 누구나 실험 설계 문서를 작성하고 피드백을 통해 고도화할 수 있게 함

• 제품 배포 막바지에 실험 설계하는 경우에는 최대한 빨리 실험 설계 리뷰를 마쳐, 제품 배포 일정 연기를 방지

• 실험 생성/수정을 할 때 실험 코드 작성에 익숙하지 않은 개발자들을 대상으로 실험 설계가 완료된 경우 실험 플랫폼 팀에서 실험 생성 및 수정하는 코드 작업을 지원

• 실험이 진행되면 매주 실험 지표 결과를 분석하여, 실험 진행/종료 의사결정을 함께하며 실험 분석 과정 및 결과에 적응하도록 도움

• 조직 구성원들이 자주 묻는 내용(FAQ)을 정리하고, 실험 배포 가이드, 모니터링 가이드, 실험 기술 용어들을 정리하여 누구나 실험에 대해 궁금할 때마다 꺼내 볼 수 있게 문서화 함

실험 조직 문화가 되고 나서의 뱅크샐러드의 모습은?

• 실험이 많아지기 전 : 실험 플랫폼에서 실험 분석 결과(지표)를 제공할 순 없는 상태라 매 실험 설계마다 설정한 지표들을 BI 툴을 통해 확인

• 실험이 많아지고 나서 :
• 더 정확하고 신뢰도 있는 실험 문화를 구축하고자 주간 실험 리뷰 회의를 구성
• 데이터 사이언티스트들이 매주 진행 중인 실험들의 지표를 추출하고, 통계적 검정력, 통계적 유의성과 함께 실험 결과를 분석
• 주간 실험 리뷰 회의에서는 실험과 관련된 이해관계자가 참석하여 의사결정이 필요한 실험 및 진행 중인 실험들의 지표 현황을 공유하고 next action을 결정
• 성공적인 실험의 인사이트를 모두가 나누고, 실험 노하우를 학습하며 그다음 실험을 어떻게 진행할지 조언을 구하기도 함

뱅크샐러드의 Alignment Day란?

💡

뱅크샐러드의 전 구성원이 모여 지난 분기 성과와 다음 분기 계획을 공유

• 각 조직이 지난 분기 동안 어떤 실험을 진행했고,

• 성공한 실험에 대해선 성과를 발표하고,

• 실패한 실험은 lesson learned를 공유

분석 인프라 V2 : 자동으로 실험 분석하기

• 실험 분석 파이프라인 : 자동으로 실험의 결과와 관련된 데이터를 수집하여 실험 분석 결과를 계산하고 적재하는 환경

• 파이프라인 구조 :
• Metric Configuration : 실험 지표 관리
Metric Configuration이란 실험 지표들을 관리하기 위한 설정들을 의미
→ 실험 지표란 실험 결과를 대변할 수 있는 정량적 수치로, 계산하는데 필요한 정보와 방법은 지표별로 달라짐
• 사용자 당 가계부 방문 수
• 계산에 필요한 정보: 사용자가 가계부에 방문한 기록
• 계산하는 방법: 사용자별로 가계부에 방문한 횟수를 더하여 계산
• 사용자의 가계부 방문 전환율
• 계산에 필요한 정보: 사용자가 가계부에 방문한 기록
• 계산하는 방법: 사용자별로 1번 이상 방문한 경우에는 1, 아닌 경우에는 0으로 계산
• Data Preparation : 실험 분석 결과 계산에 필요한 데이터 가공
Data Preparation이란 용어 그대로 분석에 필요한 데이터를 준비하는 과정
→ 실험 분석을 위해서는 어떤 실험인지, 어떤 사용자가 실험에 노출되었는지, 실험 지표는 무엇인지에 대한 정보가 필요하고, 이 정보들은 아래와 같이 각 Context(실험, 사용자, 지표) 별로 구조화
• Experiment Information : 실험을 정의하는데 필요한 정보들을 의미
실험이 생성/수정/삭제/완료된 history를 활용하여 분석해야 하는 실험들의 정보를 조회하게 된다. 실험 정보는 실험이 사용자에게 노출되는 비율, 노출되는 조건(Platform, App Version, …), 실험 상태, 실험 기간 등으로 정의된다.



• Trigger Event : Trigger란 Subject(사용자)가 실험에 노출된 이벤트를 의미
여기서 Subject란 실험의 분석 단위를 의미하며 User, Device, Session 등으로 정의된다. Trigger Event는 Subject의 종류가 무엇이며, Subject가 어떤 실험의 어떤 그룹에 언제 노출되었는지의 데이터로 정의된다.



• Subject Event : 실험의 지표를 계산하기에 필요한 Subject의 이벤트 정보들을 의미
Subject가 언제 어떤 이벤트를 어떻게 일으켰는지의 데이터가 포함되며, Metric Configuration의 Event Query를 사용해 계산되게 된다.



• Metric Calculation : 실험 분석 결과 계산
실험 분석 결과는 실험을 통한 의사결정에 필요한 정보들을 의미하고, 반드시 아래의 정보들을 포함해야 한다.

지표 수치

지표 차이

지표 차이의 통계적 유의성

• Metric calculation의 다양한 과정
• Experiment Event : Subject Event를 Subject가 실험에 노출된 시점(Trigger Time) 이후의 데이터만 조회한 결과물
분석을 진행할 때 필요한 데이터는 Subject가 실험에 노출된 이후 시점의 데이터이다. 그전의 데이터는 실험의 영향을 받기 전(받지 않은) 데이터이기 때문에 제외해야 한다.



• Subject-level Aggregated : 지표 계산을 위해서 Experiment Event를 Subject 단위로 Aggregation 하여 Subject별로 지표를 계산한 결과
Metric Configuration의 Aggregation Query를 사용해서 계산한다.
• 사용자 A의 앱 방문 수: 실험 노출 이후 2번 가계부를 방문함
• 사용자 B의 앱 방문 수: 실험 노출 이후 1번 가계부를 방문함
• Metric-level Aggregated : 지표 값의 평균, Standard Error 등 통계적 유의성을 검증하는데 필요한 정보들을 지표 단위로 계산한 결과
• 사용자의 앱 방문 수의 평균: (2+1) / 2 = 1.5
• Experiment Analysis Result : 실험 분석 결과
지표의 수치, 지표의 차이, 지표의 통계적 유의성(p-value) 등이 포함되며 의사결정에 필요한 정보들(신뢰구간, 표준편차, Minimum Detectable Effect)을 함께 제공한다.