Part 4. Advanced Topics for Building anExperimentation Platform

론 코하비, 다이앤 탕, 야 쉬, 『A/B 테스트 신뢰할 수 있는 온라인 종합 대조 실험』, 이기홍, 김기영, 에이콘출판사-MANNING(2022), p219-257.

 

Client-Side Experiments

Differences between Server and Client Side

• Release Process
  • server: continuous integration and deployment (CI/CD)
  • client: 앱 소유자, 앱 스토어, 사용자가 관련됨
• Data Communication
  • Internet connectivity: 서버 측 데이터 변경사항이 클라이언트로 전송되지 않거나 지연될 수 있음
  • Cellular data bandwidth
  • Battery: 데이터 통신이 많을수록 배터리 소모 증가
  • CPU, latency, and performance
  • Memory and storage

 

Implications for Experiments

• Anticipate changes early and Parameterize
  • 각 실험별 모든 변수들은 코딩되어 app build와 함께 제공되어야 함
    • 기존 변수의 버그 수정이나 신규 변수는 next release를 기다려야 함
  • 특정 기능이 완성되기 전에 새로운 앱을 출시할 수 있음
    • feature flag라는 설정 파라미터를 통해 기능을 제어 → 준비되면 기능을 켤 수 있음
  • 더 많은 기능들이 구축되어도 서버 측에서 조작이 가능
    • A/B test에서 사용 가능 → 성능 측정 및 안전망 제공
    • 기능이 제대로 작동하지 않으면, 클라이언트 release cycle 없이 기능을 종료해서 원복 가능
  • 세분화된 파라미터로 client 배포 없이 신규 변수로 확장이 용이함
    • ex. 윈도우10은 작업 표시 줄의 ‘검색 상자 텍스트’를 매개 변수화 → 배포 후 1년 동안 실험 실행함
• Expect a delayed logging and effective starting time
  • 지연되는 시간과 실험 시작 시간은 ‘실시간 실험 분석’에 영향을 줄 수 있음
  • 비교할 기간을 신중하게 선택해야 함
• Create a failsafe to handle offline or startup cases
  • 사용자가 앱을 실행할 때, 기기가 오프라인일 수 있음 → 실험 할당 값을 cache로 남겨두어야 함
• Triggered analysis may need Client-Side experiment assignment tracking
  • triggering information을 포착하려면 실험이 수행될 때 추적 데이터를 서버에 보내야 함
    • 서버 통신을 줄이기 위해, 실험 트리거 여부와 관계없이 모든 활성 실험에 대해 한 번에 데이터를 가져오는 경우 과도한 트리거 유발 가능
  • 기능이 실제로 사용될 때 할당 정보를 전송하는 것으로 해결 가능 → 양이 많아지면 지연 시간 및 성능 문제 발생 가능
• Track important guardrails on device and app level health
  • 사용자 참여 데이터만 추적하면 배터리 소모 문제를 발견하지 못할 수 있음
    • 실험에 의해 더 많은 CPU 및 배터리 전력이 소모될 수 있음
  • 실험군 사용자에게 많은 푸시 알림 전송으로 알림 비활성화 수준이 높아질 수 있음
• Monitor overall app release through Quasi-experimental methods
  • 전체적으로 신규 앱에서 randomized controlled experiment을 진행하려면, 두 버전을 동일한 앱 안에서 번들로 묶어야 함
  • 실용적이거나 이상적이지는 않은 방식임
• Watch out for multiple devices/platforms and interactions between them
  • 사용자는 여러 기기 및 플랫폼을 활용할 수 있음
    • 다른 기기 ID ⇒ 같은 사용자
  • 다른 기기 간의 상호작용이 발생할 수 있음
    • ex. ‘Continue on mobile/desktop’

 

Instrumentation

Client-Side vs Server-Side

• client: 사용자가 경험하는 것에 초점
  • user action, performance, errors and crashes
  • 데이터 정확도와 사용자 비용 측면의 단점이 있음
• server: 시스템이 수행하는 작업에 초점
  • performance, system response rate, system information

Processing logs from Multiple sources

• instrumentation streams
  • client types (e.g. browser, mobile)
  • servers
  • user state (e.g. opt-ins, opt-outs)
• 로그를 쉽게 활용하고 결합할 수 있어야 함 → common identifier 활용
• shared format을 사용하는 것이 유용하다 → 공통/사용자 정의 field (e.g. timestamp, platform)

Culture

• Instrumentation 없이 배포를 금지하는 cultural norm 확립
• 개발 중 instrumentation을 테스트하는 과정 확립
• raw logs 품질을 모니터링

 

Choosing a Randomization Unit

• granularity (세분성)
  • Page-level
  • Session-level: 보통 30 minutes
  • User-level: 사용자가 여러 계정이 있는 경우, 과대 계산될 수 있음
• granularity 결정 시, 고려할 사항
  • How important is the consistency of the user experience?
    • 사용자가 변화를 알아차릴 수 있는지 여부가 중요
  • Which metrics matter?
• metrics과 randomization unit의 선택도 서로 상호작용함
  • 세분화 수준이 높을 수록 더 많은 단위가 생성됨
    • 측정 단위의 평균의 분산이 작아짐
    • 더 작은 변화를 감지하여 통계적 유의성을 보일 수 있음
  • randomization을 위한 finer granularity 선택 시 고려사항
    • 특징 or 지표가 세분화 수준을 걸쳐 작동하는 경우, 사용 불가
      • ex. 페이지 간 종속성 → 독립성 보장 X
    • 1인 사용자가 여러 변형군에 할당되는 것은 실험 집단이 서로 간섭하지 않는다는 가정을 위반 가능
      • SUTVA (Stable Unit Treatment Value Assumption)
      • 엔터프라이즈 service → 기업 군집별 랜덤화
      • SNS → 친구 군집별 랜덤화
• Randomization Unit and Analysis Unit
  • 랜덤화가 분석 단위보다 덜 세분화되어 있다면, bootstrap이나 delta method와 같은 분석이 필요
• User-level Randomization
  • 일관성이 결여된 사용자 경험을 회피할 수 있음
  • user retention과 같은 장기적인 측정할 때 주로 사용됨
  • user ID > device ID > cookies
    • 사용자 온보딩 프로세스: device ID, cookies > user ID

 

Ramping Experiment Exposure

• ramping process: 실험에서 새로운 변수들에 대한 트래픽을 점차 증가시키는 방법
  • 속도, 품질, 위험 3가지의 균형을 효과적으로 유지해야 함
  • 새로운 기능은 소수의 사용자에게만 변수를 노출하여 시작
  • 지표에 문제가 없고 시스템 확장성이 안정적이라면 원하는 수준까지 트래픽을 증가시킴
• (= controlled exposure)
• ramping 과정이 너무 느리면 시간과 자원이 낭비됨
• ramping 과정이 너무 빠르면 사용자에게 피해와 섣부른 결정을 내릴 수 있음

SQR Ramping Framework

• Speed, Quality, Risk (SQR)
• controlled online experiment의 실행 이유
  • treatment의 ROI 측정
  • 위험 감소 → 피해와 비용 최소화
  • 사용자 반응에 대한 학습
• MPR: (Maximum Power Ramp): 실험 목적을 실험군을 100% 증가시키는 것으로 가정하고, 실험군에 50% 트래픽을 할당해서 가장 높은 통계적 민감도를 얻는 것

Four Ramp Phases

• Pre-MPR: 속도와 위험의 trade-off에 포커싱
  • 트래픽이 충분하지 않기 때문에, 대체로 정성적 피드백을 얻음 (통계적 유의성이 낮음)
• MPR: 속도와 품질의 trade-off에 포커싱
  • 1주일 동안 실험을 유지하는 것을 권장
    • 신기 효과 or 초두 효과가 있는 경우 더 길게 권장
    • 시간에 따른 영향을 파악할 수 있어야 함
• Post-MPR: 선택 사항
  • 인프라가 늘어나는 트래픽을 감당할 수 있을지 우려될 때 시행
  • 하루 안에 끝나야 함 + 트래픽이 가장 많은 시간대를 주의 깊게 모니터링
• Long-term holdout: 선택 사항
  • Long-term holdout: 특성 사용자가 오랫동안 Treatment에 노출되지 않는 것
    • 장기적인 성능을 평가하기 위해 보관되는 데이터
    • 시간이 지남에 따라 어떻게 변화하는지 또는 실제 사용 환경에서 어떻게 수행되는지를 모니터링하기 위해 중요함

출처: Trustworthy  Online Controlled Experiments: A Practical Guide to A/B Testing