Ch12 . Client Side Experiments
요약
고객 사이드의 실험은 서버 사이드의 실험과 다르다. 앱 소유자가 통제하지 못하는 부분이 발생한다.
고객 사이드에서의 실험은 앱 발행을 거쳐 고객이 다운로드 받는 과정을 거쳐야 한다. 제한된 시간 내에 실험과 분석을 해야하는 경우 다운로드 받는 시차가 영향을 줄 수 있다. 준실험 방법을 이용해서 bias 를 해결하는 것도 필요하다. 여러 디바이스에서 사용하면서 발생하는 상호작용 문제에 대해서도 고민할 필요가 있다.
어려운 개념이나 궁금했던 내용?
추천 알고리즘 변경에 관한 실험을 할 때는 앱 발행 과정을 거쳐야 할까? 아니면 그냥 서버 사이드의 실험에 불과할까? 데이터를 고객의 앱에 불러오는 쿼리와 관련된 내용들이 서버 사이드라고 볼 수 있는걸까?
만약 앱소유자가 회색 버튼을 빨간색 버튼으로 변경했을 떄, 변경된 사항을 앱에 재배포하는 실험을 한다고 했을 때, 앱 마켓의 승인을 거쳐야 하는가? 그렇다면, randomization 이 문제없이 잘 되는가?
-> 웹뷰의 경우는 업데이트 상황에서 별도 앱 배포 불필요.
실무
고객이 다운 받는지 아닌 지에 대한 변수를 Treatment 변수라고 한다면, 앱소유자가 고객을 randomize 하는 경우를 도구변수 (Z) 로 생각해서 준실험방법론 중에서 도구변수 기법을 사용하면 분석이 용의할 것 같다.
Ch13 . Instrumentation
요약
고객 사이드 instrumentation 은 유저의 행동, 퍼포먼스, 에러나 케시 등에 대한 정보를 담습니다. 고객 사이드 instrumentation 은 자바 스크립트 로딩 속도 등의 문제가 발생할 수 있습니다. 고객의 로그를 웹브라우저, 모바일, 서버 등의 다양한 환경으로 부터 받을 수 있습니다.
비행기에 가스 계량기 없이 비행을 한다면 위험할 것입니다. 마찬가지로 제대로된 instrumentation 없이 프로덕트를 만드는 것은 위험합니다. 올바른 instrumentation 문화를 회사에 안착하는 것이 필요합니다. 로그의 퀄리티에 대한 평가도 필요합니다.
어려운 개념이나 궁금했던 내용?
Instrumentation 의 정의를 한 문장으로 정리하면 무엇일까? 책에서 어떤 주요 개념의 특징이나 중요성은 설명하는데 정의를 명확히 내리지 않는 경향이 있는 것 같다...
실무
파이어베이스로 웹앱을 만들었는데 구글 옵티마이즈에서 AB 테스트가 되는 것 같기도 하다.
요소 하나 누르고 "Edit Element" 누르면, JavaScript 변경 등을 할 수 있다.
구글 애널리틱스에 연결해야하는데 내가 파이어베이스에서 미리 연동을 시켜놔야하는 것 같다 (현재는 프로젝트에 구글 애널리틱스를 할 수 없다는 식으로 나온다).
파이어베이스는 어플의 AB 테스트만 지원하는데 구글 옵티마이즈로 AB 테스트 할 수 있지 않을까 기대가 된다. 그런데, 빅쿼리는 무료 플랜이 되는데 MySQL 은 유료 플랜으로 지원한다...
파이어베이스에서 노티피케이션 서비스가 있다고 하는데 찾아봐야할 듯하다: https://bcho.tistory.com/1145
AWS 의 종류가 너무 많아서 헷갈리기는 하는데, 오늘의집 AB 실험 플랫폼 구축 관련한 내용을 찾아보고 있다: https://www.bucketplace.co.kr/post/2021-10-29-%EC%98%A4%EB%8A%98%EC%9D%98%EC%A7%91-a-b-%EC%8B%A4%ED%97%98-%ED%94%8C%EB%9E%AB%ED%8F%BC-%EA%B5%AC%EC%B6%95%EA%B8%B0/
그리고 AWS Sage Maker 에서도 AB 테스팅과 ML 툴을 모두 다룰 수 있는 것 같기는 한데, 더 찾아봐야할듯하다.
cf. QA 엔지니어 - data QA / 앱 전반 QA?
데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것
- https://zzsza.github.io/data/2021/06/13/data-event-log-definition/
Ch14 . Choosing a Randomization Units
요약
Randomize 할 유닛을 설정해야 합니다. 각 유닛 사이에 연관성이 없어야 합니다. 페이지 단위 유닛 설정은 추천 시스템의 경우 이러한 가정을 만족시키기 어렵습니다. 유저 단위의 유닛 설정이 가장 일반적입니다. 소셜 네트워크의 기능이 있는 경우에는 유저의 클러스터 단위로 randomize 하는 것이 좋스빈다. 가입 아이디가 있는 경우 이를 바탕으로 유저를 정의하는 것이 좋은데, 디바이스 단위를 사용하기도 합니다. IP 주소 단위는 사용자가 이사를 할 수 있어서 추천하지 않습니다.
어려운 개념이나 궁금했던 내용?
분석 단위 (예: click through rate per page) 보다 실험 단위 (unit) 가 더 러프한 경우에는 bootstrap 이나 delta method 를 사용한다고 했는데, 18장이나 19장에 나온다고 하니 그 때 더 공부하면 될 것 같다.
실무
사용자 간에 커뮤니케이션이 자주 이루어지는 경우에는 Cluster 단위의 실험이 필요할 것 같다. 예를 들어, 우버의 경우에는 도시 단위로 클러스터화된 실험을 진행한다.