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

A/B Test란,실제 사용자를 대상으로 새로만든 모델을 노출함으로써기존 모델과 비교 평가하는 방법 좀 더 구체화 해서 설명해보자.객관적으로 새로운 기능이나 변경을 측정/비교하는 방식큰 위험없이 새로운 기능을 테스트하고 빠르게 배우는 방법이다.보통 서비스내의 다른 영역

비지니스 관련 지표를 개선되는지 객관적으로 측정하기 위함가설 기반의 실제 사용자 대상 비교위험을 최소화하기 위함아무리 사용자 설문등이 좋아도 실제 사용자들이 어떻게 반응할지는 알 수가 없다.처음에는 작은 퍼센트의 사용자들에게만 새 기능을 노출 시키고 문제가 없으면 퍼센

가설 설립아래 내용을 미리 측정해본다.왜 필요한지어떤 효과가 있을지성공 확신도어떤 이슈가 발생할 지누가 이 서비스를 원할지해당 내용을 기준으로 PPT를 진행하고 승인이 되면 QA가 진행 됨.사용자의 기준을 설립하고 Test 부분을 조금씩 노출 시킴.보통 트래픽을 기준으

사용자별 A/B 버킷 정보누가 A에 들어갔고 B에 들어갔는지사용자별 행동 정보(퍼널데이터)사용자가 어떤 아이템들을 보았고,어떤 아이템들을 클릭했고어떤 아이템들을 구매했는지데이터 분석가는 1과 2의 정보를 JOIN!A와 B로 그룹핑 하여(지역, 성별, 나이 등)그룹간 통

A/B 테스트에서 생길 수 있는 문제들을 살펴보자테스트 하기가 굉장히 어려운 특정 결정은 데이터로 판단할 수 없음가설없이 혹은 대충 쓴 가설로 A/B Test를 하는 경우분석에 필요한 데이터 품질이 낮은 경우이러한 경우는 Test보다는 직관적으로 판단해야 됨.결과 분석

A/B 시스템은 결국런타임과 분석 시스템의 결합이다.데이터를 수집하고 적재하는 런타임의 경우 엔지니어의 역할.분석의 경우 데이터 분석가의 역할 업로드중..Saas를 사용해서 구현하는 경우가 대다수Saas : 클라우드 형태의 인터넷 서비스Saas를 사용하다가 회사가 커지

사용자가 유입되었을 때 버킷에 그 데이터를 담은 뒤A와 B로 분류진행.Userid VS deviceid 둘 중 무엇을 기준으로 사용자를 나눌 것인가.A/B 테스트의 성격에 따라 userid를 사용할지 deviceid를 사용할지 결정로그인한 사용자에게만 하는 테스트인가

가설을 잘 세워야 배우는 것이 있다.한기용 강사님 야후 때의 일화 : 검색 결과 요약을 바꾸는 A/B 테스트를 수행검색결과 요약을 잘 만들면 클릭이 더 많이 생길까?AB 테스트 실험을 제안한 사람이 분석하는 것은 좋지 않다.자신이 제안한 것이기 때문에 주관적일 수 있다

이번 시간에는 한기용 강사님께서 유데미에서 AB테스트 시스템을 구축하고 추천엔진 검증에 사용했던 경험을 강의해주셨다.먼저 AB 테스트 시스템을 구축 했다.기존 Optimizely(ab테스트 도구)를 걷어내고 자체 구축 진행런타임 시스템 구축 : 다른 엔지니어링 팀과 협

이전에 사용자 트래픽별 A/B Test 버킷팅 코드를 리뷰해 보았을 때전체 사용자에 대해서 그룹을 지어버리게 되니 실용적이지 못한다고 했다.또한 하나의 사용자가 여러 AB테스트에 들어갈 문제점도 발생할 수 있기에 버킷팅 코드를 좀 더 개선시켜 보자.점진적인 커버리지 증

A/B 테스트 분석에 사용되는 기본 통계를 학습해보자귀무가설, 정규분포, 중심극한정리, Z-test, T-test 등등.A/B 테스트는 기본적으로 귀무 가설을 사용한다.예) A와 B의 구매율은 동일하다.A/B 사용자 분류 후 z-test 또는 t-test를 진행하게 되

A와 B의 트래픽 크기를 통계적으로 비교해보자AB 테스트 성공실패 지표를 비교하기 전에 제일 먼저 해야하는 일은 트래픽이 양쪽에우리가 원하는 형태로 나눠졌는지부터 점검 하는 것이다.AB 테스트 사용자 크기를 통계적으로 비교 해보자50:50으로 나눈 테스트라면 이는 P(

개발환경 : colabaa_example 테이블의 user_id를 가지고 다음을 수행앞서 설명한 파이썬 함수로 A/B로 나눴을 때 A에 속한 사용자의 수와 B에 속한 사용자의 수앞서 설명한 SQL 함수로 A/B로 나눴을 때 A에 속한 사용자의 수와 B에 속한 사용자의

A/B 테스트 시스템은 런타임 시스템과 분석 시스템 두 개로구성되는데 이에 대해 살펴보자Production DB에 저장되는 정보들을 Data Warehouse로 적재했다고 가정raw_data.user_event사용자/날짜/아이템별로 impression이 있는 경우 그

이전 글에서 추출했었던 Impression, Click, Purchase, Amount 의 평균 값을 토대로 A그룹과 B그룹을 비교한다.이때 차이가 유의미한 경우 Color 표시를 진행차이가 유의미한 경우란?z-score가 1.96보다 크면 초록색z-score가 -1.

A/B Test 분석이 어떤식으로 구현되는지 정리해보자AB Test별로 다음 분석이 가능해야 한다.AB 테스트 전체 기간에 걸쳐 주요 지표가 비교 가능해야 한다일별로 주요 지표의 비교가 가능해야 한다 (trend)주요 지표의 경우 통계적으로 유의미한지 무의미한지 표시가

dbt는 ELT를 쉽게 해주는 툴이다.ETL을 하는 이유는 결국 ELT를 하기 위함이다.이때 데이터 품질 검증이 중요해진다.데이터 품질유지는 결국비용/노력 감소와 생산성 증대의 지름길이 된다.아래의 노력들을 통해 데이터 품질을 유지할 수 있다.입출력 체크더 다양한 품질

Data Build Tool이 무엇인지 알아보자Data Build Tool (https://www.getdbt.com/)ELT용 오픈소스: In-warehouse data transformation(이미 웨어하우스에 들어온 데이터를 변화한다!)Analytics

dbt 설치dbt Cloud vs. dbt Coregit을 보통 사용함dbt 환경설정Connector 설정Connector가 바로 바탕이 되는 데이터 시스템 (Redshift, Spark, …)데이터 모델링 (tier)Raw Data -> Staging -> Core테

dbt Model을 사용해 입력 데이터들을 transform해보자ELT 테이블을 만듦에 있어 기본이 되는 빌딩 블록테이블이나 뷰(View)나 CTE의 형태로 존재입력, 중간, 최종 테이블을 정의하는 곳티어 (raw, staging, core 등)raw→ staging(

최종 출력 데이터를 만드는 과정을 살펴보자최종 출력 데이터 과정에서는 Materialization이라는 것을 이해해야 된다.입력 데이터(테이블)들을 연결해서 새로운 데이터(테이블) 생성하는 것(ELT!)보통 여기서 추가 transformation이나 데이터 클린업 수행

dimension 테이블을 파일의 형태로(csv 등) 데이터 웨어하우스에 적재하는 방법이다.seeds 폴더 밑에 적당히 .csv 파일을 하나 생성dbt seed 명령어 실행실행 결과 확인Sources : 입력 테이블에 별칭을 주고 별칭을 staging테이블에 적용하는

z-score를 계산하면 아래 두가지로 비교가 가능해진다.버킷 크기가 50:50인지 파악할 때 사용.귀무가설 : P(B) = 0.5○ Z-Score = (PB-0.5)/sqrt (PB(1-PB)/N)● Z-score의 값이 -1.96~ 1.96 사이로 나오면 녹색으로

Traffic이 통계적으로 5:5인지 시각화 해보자z-test 공식을 진행하기 위해 아래 필드들을 추가해준다.f_test-0.5sqrt((f_test-f_test^2)/SUM(N))f_test_diff/f_test_errz-score가 1.96 인지 아닌지를 계산!IF

Impression 차트를 생성해 보자n_ctrlA(Control)에 속한 사용자 수를 구한다.ctrln_ctrl의 평균을 구한다.ctrl_var분산을 구해준다. 위의 내용을 test id에도 똑같이 진행.testtest의 평균test_vartest의 분산 계산d