개발/책

「Trustworthy Online Controlled Experiments」를 읽고 : 모두를 위한 입문 2

우리로 2021. 12. 14. 14:57

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=202962149

 

Trustworthy Online Controlled Experiments : A Practical Guide to A/B Testing (Paperback)

Trustworthy Online Controlled Experiments : A Practical Guide to A/B Testing (Paperback)

www.aladin.co.kr

 

 

 

앞으로 글 네개에 걸쳐서 이 책 내용을 정리해보려한다. 

지은이가 Ron Kohavi ,Ya Xu ,Diane Tang 인데 이 분들 약력을 보면 책에 굉장히 신뢰가 간다.

 

Part I : 모두를 위한 입문 주제 : https://for-development.tistory.com/155

1. 도입 및 동기

2. 실험 시작과 분석

3. Twyman의 법칙과 실험 신뢰성

4. 실험 플랫폼 및 문화

 

Part II : 모두를 위한 선택된 주제 : 현재 글

5. 속도의 문제

6. 구조적 지표 

7. 실험과 전체 평가 기준으로 쓰일만한 지표들

8. Instituonal Memory(제도적인 기억...? 잘 모르겠다)과 메타 분석

9. 통제 실험에서의 윤리

 

Part III : 통제된 실험을 위한 보완책

10. 대안적 기술들

11. 관찰가능한 인과적 연구

 

Part IV : 실험플랫폼을 만들기 위한 고급 주제

12. 클라이언트 측면에서의 실험

13. 계측(Instrumentation)

14. 임의 추출 단위

15. Ramping Experiment Exposure : 퀄리티와, 스피드, 위험도간의 취사선택

16. 실험 분석의 규모 조절

 

Part V : 실험 분석을 위한 고급 주제

17. 온라인 통제 실험의 통계학

18. 분산 평가와 향상된 민감도: 함정과 그 대안

19. A/A 테스트

20. 향상된 민감도를 위한 트리거

21. 잘못된 샘플 비율과 신뢰성과 연관된 다른 가드레일 지표

22. 변인들간의 상호간섭

 

5. 속도의 문제 

  • 아마존에서 100msec 느려지니까 1% 판매량 떨어짐
  • 빙에서 100msec 속도 빨라질수록 revenue 0.6% 증가함. 
  • Optimizely에서 code snippet을 상단에 노출하면 page를 느리게만들고, 아래에 배치하면 화면을 깜빡이게 만듬  그래서 이 책에선 서버사이드 개인화와 최적화를 추천함. 서버에서 HTML 코드도 만들고...
  • Metric과 Page LoadTime의 관계는 테일러 급수를 따른다. 페이지 로딩 시간이 0초에서 0.1초로 늘어나는 것보다 5초에서 5.1초로 늘어나는게 메트릭에 더 나쁜 결과를 낳는다. 
  • Performance 향상 실험을 통해 대답가능한 질문들
    • 성능향상으로 인한 즉각적인 이득은 무엇인가?
    • 장기적 효과가 있는가?
    • 특정한 메트릭에 대한 효과는 무엇인가. 보통 새로운 피처는 degradation 하는데 이걸 상쇄할만큼 tradeoff가 있는지 측정 가능한가?
    • 어디서 성능이 제일 유의미한가.
  • 어쨋든 성능은 어떻게 측정하는가?
    • browser onload event의 request가 온 시간 - 첫 html 요청 시간
  • 당연히 Element마다 퍼포먼스가 성과에 미치는 영향이 다르다. 구글에서 검색결과가 늦게 나오는거랑 Gmail이 로딩 늦게되는거랑 유저가 느끼는 바가 많이 다르다.
  • 아주 드물게 페이지 로딩속도가 너무 빨라서 사용자의 신뢰도를 감소시키는 경우도 있다.
  • 때로는 200ms 정도의 속도차이는 uX에 영향을 안미칠 수도 있지만, 한편 조그마한 속도 차이가 큰 영향을 미칠 수도 있다.
  • 서버와 클라이언트의 차이는?
    • Difference 1 : Release Process
      • Server는 배포가 쉽고 Client는 아니다. 특히 데스크톱앱이랑 모바일은. 배포했다고해도 유저가 업데이트 안하는 경우가 부지기수다.
    • Difference 2: Data Communication between Client and Server
      • Internet Connectivity :
        • Celluar data bandwith : 네트워크 불안정해서 앱 버벅이면 우리가 바꾼 요소랑 상관없이 유저의 참여도가 낮아질 수 있음
        • Battery: 휴대폰을 low battery mode로 하면 app이 할 수 있는것에 제약이 걸릴 수 있다.
        • CPU, latency, and performance : 폰이 꾸데기면 잘 안될 수 있다.
        • Memory and storage : Cache는 참 좋은데, 용량 많이먹어서 이거때문에 앱 지운다는 사람 많다.
    • tradeoff가 많다. 유저폰에 데이터 저장했다가 wifi 터질때만 받을건지, 아니면 그냥 날릴건지 등등
    • Implications for Experiments
  1. 초기변화 예측 및 매개변수화
    1. 클라이언트코드가 유저에게 가닿기 힘들다는 건 세가지 의미가 있다.
    2. 새로운 앱이 배포될 때 아직 미완성인 피처가 있을 수 있다. 그 피처는 feature flag에 의해 off되어있다가 피처가 완성되면 다시 켜질 수 있다. 때때로 서버가 완성되면 그 기능은 활성화된다.
    3. 더 많은 기능이 완성될수록 그들은 server side의 configuration을 받을 수 있다. 이건 꼬ㅒ 좋은 방법인데 네트워크등 이슈로 성능이 잘 안나오면 server에서 해당 기능들을 끌 수 있다. 다시 기나긴 클라이언트 앱 매포 사이클을 거치는 것보단 훨씬 낫다.
    4. 가장 좋은 방법은... new configuration을 활용하는 것이다. 그리고 client code는 이 configuration을 어떻게 parsing할지만 알고 있으면 된다. 예를 들면 윈도우10은 search box를 이렇게 구성했다. 1년넘게 실험한 결과 bing이 가장 많이 사용되도록 했고, 수백만 달러를 벌어들일 수 있었다. 머신러닝 모델도 마찬가지다. Op: 우리가 API 짤 때 paramter를 넘겨주지않나? 그것처럼 A/B 테스트의 variant를 파라미터화한다.
  2. 지연된 로깅 및 유효 시작 시간 예상
    1. 실험시작했다고 바로 되는게 아니다. 디바이스가 오프라인이거나, bandwidth가 낮거나 이런 상황에선 새로운 환경변수를 push하는게 오히려 유저에게 안좋은 경험을 줄 수 있다.
    2. 결국 유저가 앱을 업데이트하지않거나, 여러 이유로 생각보다 데이터가 느리게 쌓일 수 있다. 업데이트 안한 유저는 애초에 실험대상에서 제외되어버리는 문제가 발생한다.
    3. Wifi가 잘되거나, 폰이 좋거나, 데이터가 짱짱한 유저로 편향된 결과가 도출될 수 있다.
    4. Control이 먼저 노출될 경우 Caching 되기때문에 유저에게 더 좋은 경험을 선사할 수 있다(Performance와 성과는 정비례관계다) —> 이것도 왜곡된 결과로 나타날 수 있다.
  3. 오프라인 또는 시작 사례를 처리할 기본값? 만들기
    1. 유저가 오프라인이거나 처음 앱을 깔아서 실행시켰을 때 보여줄 기본 화면이 필요하다. (서버가 제대로 동작안할 수도 있으니까)
  4. Triggered Analysis에는 클라이언트 측 실험 할당 추적이 필요할 수 있다
    1. 유저 액션마다 Server로 시그널을 보내는게 아니라 한 experiment를 통틀어서 한번에 보내는게 낫다.이게아니면 over-triggering 될수있고 유저 경험에 안좋은 영향을 미쳐서 결과를 왜곡할 수 있다.
  5. 장치 및 앱 레벨 상태에 대한 중요 가드레일 추적
    1. 디바이스 상태체크해야한다. 예를 들면 더 많은 push를 보내는 비교군이 있을 때, 지금 당장은 별 영향 없을 수 있지만 장기적으로는 안좋은 결과를 낼 수 있다. 앱 사이즈같은 것도 주의해야한다. 앱 사이즈가 크면 덜 다운로드 받는다.
  6. 준실험적 방법을 통한 전반적인 앱 릴리스 모니터링
    1. 앱을 릴리즈할 때 구버전과 신버전을 둘다해라 .이러면 용량 두배라서 좀 안좋긴한데, 구버전 사용자가 신버전에 익숙해질 시간이 필요하다.
  7. 다양한 기기와 플랫폼이 상호작용하는 걸 주의하라
    1. 한 유저가 다양한 기기(컴퓨터와 휴대폰으로 유튜브보기)로 접속하는건 너무나 익숙하다.
      1. 다른 기기에는 다른 ID를 배급하는 경우가 많다. 그러면 같은 유저가 다른 디바이스에 다른 variation을 할당받는 경우가 있다.
      2. 우리는 카카오톡 쓰다가도 link를 눌러서 카톡을 빠져나올 때도 있다. 이러면 정확한 비교가 힘들다. 그리고 한 플랫폼에서 유저의 액션이 다른 플랫폼보다 더 원활하고 좋을 수도 있다. 그 결과 실험에 의한게 아닌데 유저 참여도가 쑥 떨어질 수 있다.