Part 2. Selected Topics for Everyone

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

 

5. 속도의 중요성: 엔드투엔드 사례 연구

• 많은 실험이 UI에 초점을 맞추지만, 백엔드 측면에서도 많은 혁신이 일어난다.
  • ex. Bing: 0.1초 개선마다 1억 8천만 달러의 매출 증가 가치
• 성능 개선이 주요 지표에 미치는 영향을 측정하는 것이 중요
  • 어느 부분의 성능 개선이 가장 중요한가??
  • 성능 개선이 어떤 지표 X에 미치는 영향은 무엇인가?
    • 성능 개선이 매출에 미치는 영향은?
    • 새로운 기능의 초기 구현 속도를 높이는 경우, 지표 X가 개선되는가?
  • 성능 개선으로 장기적 영향이 있는가? (ex. 해지 고객 감소)

Slowdown 실험의 주요 가정

• slowdown(속도 저하) 실험의 주요 가정: 국지적 선형 근사
• 성능 그래프가 현시점의 성능값을 중심으로 하는 직선으로 잘 근사된다는 가정이 중요 (= 선형 근사)
• 현시점의 성능(시간) 기준, 속도를 증가, 감소시켰을 때의 변화량은 동일하다는 가정
  • 사용자 경험 측면에서 속도는 빠를수록 좋다.
  • 두 가지 포인트를 샘플링하여 선형 근사치의 타당성을 검증
    • Bing은 100ms, 250ms로 slowdown 실험을 진행

웹사이트 성능 측정 방법

• 서버는 동기화되어야 함
  • 서버 간 시계가 동기화되지 않으면, 데이터 품질에 문제가 생김
• PLT(페이지 로드 시간, Page Load Time) 종류
  • 사용자가 경험한 시간: T6(페이지 로딩/이벤트 활성 + 이벤트 로그 발송) - T0 (request)
  • 사용자 PLT 추측: T7(온로드 이후 요청) - T1(서버가 request를 받은 시간)

Slowdown 실험 설계

• 어느 부분에서 slowdown을 실험할 것인지
  • 해결 방법: 서버로부터 응답을 지연시키는 포인트를 찾는다.
    • ex. 서버가 HTML 쿼리의 의존적인 부분을 생성하는 곳
• 지리적 네트워크 차이를 감안하기 위해, 지연을 일정하게 할 것인가? or 일정 비율로 할 것인가?
  • ex. 남아프리카의 사용자들은 페이지 로드 시간이 매우 느려서 250ms 지연이 느껴지지 않을 수 있음
  • 백엔드 서버 입장에서는 일정한 지연이 좋은 선택 (ex. payload 크기를 기반으로 네트워크 차이 확인)
• 세션 첫 페이지와 후반부 페이지 중에 어느 쪽의 속도 향상이 더 중요한가?
  • 자바스크립트 캐싱은 세션 후반부 페이지의 성능을 향상시킬 수 있음

페이지 구성 요소의 영향의 차이

• Bing의 경우, 검색 결과를 보여주는 페이지만 중요했음
• 인지된 성능: 사용자가 페이지를 충분히 볼 수 있을 때, 해석하기 시작한다는 직관적인 아이디어
• 인지된 성능 추정 방법
  • 첫 번째 결과까지의 시간 (ex. 첫 트윗이 보일 때까지의 시간)
  • 기본 화면 표시 시간 (AFT, Above the Fold Time): 브라우저의 초기영역의 픽셀이 모두 칠해질 때까지의 시간
  • 속도 지수 (Speed Index): 페이지상에 보이는 요소가 표시되는 시간을 평균한 것 (AFT의 일반화)
  • 페이지 단계 시간, 사용자 준비 시간
    • 페이지 단계 시간: 인지된 성능을 만족하는 렌더링 단계 식별 필요
      • 각 단계는 픽셀 변화 속도에 의해 결정됨
    • 사용자 준비 시간: 페이지의 필수 요소가 사용할 준비가 될 때까지의 시간
• 단순한 인지된 성능 추적 방법: 성공한 ‘클릭’과 같은 사용자 행동까지의 시간을 측정

극단적 결과

• 구글 검색 결과 수를 10개에서 30개로 늘리는 실험
  • 트래픽과 매출이 20% 감소
  • 페이지가 생성될 때까지 0.5초 더 걸렸기 때문이라고 함
• Etsy 사례
  • ‘Dan Mckinley’ - 200ms의 지연은 문제가 되지 않다고 주장
  • 실험 차이를 탐지하기에 충분한 통계적 검정력을 갖지 않은 것으로 생각됨
• 실험 결과 검토 주의 사항
  • 신뢰 수준을 잘 정해야 함
  • 어떤 곳의 개선 사례가 다른 곳에서는 적용이 안될 수 있다는 것을 명심해야 함

 

6. 조직 운영을 위한 지표

• 동일한 지표가 팀마다 다른 역할을 할 수 있음
• 지표에 대한 토론은 전사적으로 지표를 이해하고 이해관계를 일치시키기 위해 유용함

지표 종류

• 목표 지표 (goal metrics): 조직이 궁극적으로 무엇을 신경 쓰는지 보여줌
  • 목표 지표를 도출하기 위해 원하는 것을 단어로 표현해 보는 것이 좋다.
  • 목표 지표는 시간이 갈수록 반복적으로 개선할 필요가 있다.
• 동인 지표 (driver metrics): 목표 지표보다 단기적으로 빠르게 움직이고 민감한 지표인 경향이 있음
  • sign post metrics, surrogate metrics, indirect metrics, predictive metrics 등으로 불림
  • 성공 요인이 어떤 가설을 반영하는지 나타냄
  • 2가지 유용한 지표 프레임워크
    • HEART (Happiness, Engagement, Retention, Task Sucess)
    • PIRATE (Acquisition, Activation, Retention, Referred, Revenue)
• 가드레일 지표 (guardrail metric): 가정을 위반하는 것을 방지하기 위한 것
  • 2가지 유형
    • 비즈니스를 보호하는 지표
    • 실험 결과의 신뢰성과 내적 타당성을 평가하는 지표
  • 가드레일 지표는 종종 목표, 동인 지표보다 더 민감함
• Asset vs Engagement metrics:
  • Asset metrics: 총 사용자 수, 총 연결 수와 같이 정적인 자산의 축적을 측정
  • Engagement metrics: 세션 or 페이지뷰와 같은 사용자의 행동 결과로 사용자가 받는 가치를 측정
• Business vs Operational metrics:
  • Business metrics: ARPPU, DAU 같이 비즈니스 상태를 추적
  • Operational metrics: 초당 쿼리와 같이 운영상의 문제가 있는지 추적
• 데이터 품질 지표(Data quality metrics): 기초 실험의 내적 타당성과 신뢰도를 보장
• Diagnosis or debug metrics: 목표, 동인, 가드레일 지표의 문제를 나타내는 시나리오를 디버깅할 때 유용

지표 공식화

• 목표 지표
  • 단순한지: 쉽게 이해하고 폭넓게 수용되어야 함
  • 안정적인지: 새로운 기능을 실행해도 업데이트의 필요가 없어야 함
• 동인 지표
  • 목표와 이해관계 일치 여부: 동인 지표가 사실상 성공의 요인인지 검증하는 것이 중요함
  • 행동 가능 및 관련성 여부: 지표를 움직이기 위해 행동할 수 있다고 느껴야 함
  • 민감성 여부: 목표 지표의 선행 지표로써 민감한지 확인
  • 조작에 대한 내성 여부: 성공을 측정할 때, 쉽게 조작되면 안 됨
• 지표 개발을 위한 고려 사항
  • 확장성이 낮은 방법의 가설로 아이디어를 도출한 후, 데이터 분석에서 가설을 검증
    • 사용자 만족, 작업 성공은 사용자 조사를 통해서만 측정 가능함
    • 직접 조사 or 사용자 경험 연구(UER, User Experience Research)를 실시
      • ex. 웹사이트에서 단기간 체류하는 사용자 비율은 bounce rate
  • 목표, 동인 지표를 정의할 때 품질을 고려해야 함
    • 좋은 지표는 의사결정의 근거가 되는 확고한 해석으로 이어질 가능성이 높다
  • 지표 정의에 통계적 모델을 통합할 경우, 모델을 해석 가능한 상태로 유지하고 시간에 걸친 검증이 필요
    • ex. 장기 매출 측정 - 예측 생존 확률을 기반으로 LTV를 계산
      • 생존 함수가 복잡한 경우, 이해관계자로부터 승인받기가 어려움
      • 지표의 갑작스러운 하락을 조사할 때, 담당자가 파악하기 어려움
  • 원하지 않는 정보를 정확하게 측정하는 것이 쉬울 수도 있다.
    • ex. 사용자 불만족
    • 부정적인 지표는 가드레일 or 디버그 지표로 유용함
  • 지표 자체가 프록시(대안)라는 점을 기억해야 한다.
    • 각 지표는 독자적인 실패 사례를 가지고 있음
      • ex. CTR → click bait(클릭 유도를 위한 허위 광고와 과장 광고) 증가

지표 평가

• 새로운 지표를 추가할 때, 기존 지표와 비교해 추가적인 정보를 제공하는지 평가해야 함
• LTV는 시간 경과에 따라 평가하기 때문에, 예측 오류가 작게 유지되도록 해야 함
• 실험에 많이 의존하는 지표는 주기적으로 평가해 조작을 유발하는지 확인
• 동인 지표의 목표 지표에 대한 인과 관계를 구축하는 것이 중요함
  • UER 등 데이터 소스를 활용해 상관성을 측정
  • 관측 데이터를 기반으로 가설을 무효화할 수 있는지 확인
  • 다른 업체 사례를 참고
  • 지표 평가를 목표로 실험을 진행
    • ex. 고객 충성도 프로그램 → retention → LTV
      • 고객 충성도 프로그램을 줄여서 Retention, LTV와 관련이 있는지 측정
  • 과거 실험 활용

지표의 진화

• 지표가 시간에 따라 변화되는 이유
  • 비즈니스 진화: 경영이 다각화되는 경우, 사용자층이 변화하는 경우
    • 초기 스타트업/제품은 편향된 데이터를 가지고 있을 수 있음
  • 환경 진화: 경쟁 구도의 변화, 새로운 정부 정책, 사용자들의 사생활에 대한 우려
  • 측정 기준에 대한 이해의 진화: 성능을 관찰할 때, 세분화하거나 다른 지표로 개선할 포인트를 찾은 경우
• 동인, 가드레일, 데이터 품질 지표는 방법론 개선에 의해 주도되기 때문에, 목표 지표보다 더 빠르게 진화됨

추가 자료

• 가드레일 지표 예시
  • 지연 시간
  • 페이지당 HTML 응답 크기, 자바스크립트 오류 수
  • 사용자당 매출, 페이지뷰
  • 클라이언트 충돌 - 사용자당 크래시 수, 사용자당 충돌여부
• 조작 가능성 예시
  • 러시아 슈퍼헤비급 역도 선수는 세계 기록을 깨뜨릴 때마다 인센티브를 제공받음 → 한 번에 1, 2그램씩 기록을 올렸음
  • 재고를 낮게 유지하는 것에 대해 보너스 지급 → 예비 부품을 구할 수 없었고, 부품이 입고될 때까지 운영 중단

 

7. 실험을 위한 지표와 종합 평가 기준

비즈니스 지표로 적절한 실험 지표 작성

• 비즈니스 지표는 온라인 실험에 직접적으로 유용하지 않을 수 있음
• 무엇을 위해 최적화하고 있는지 깊이 생각하는 것이 가장 중요하다.
• 실험 지표 조건
  • 측정 가능: 모든 효과를 쉽게 측정할 수는 없음
  • 귀속 가능
  • 민감하고 시기적절함: 민감도는 지표의 분산, 실험 효과의 크기 및 무작위 추출 단위 수에 따라 달라짐
• 위 실험 지표 조건 달성 이후, 추가적으로 고려할 지표
  • goal, driver metric을 위한 surrogate(대리) 지표 추가
  • 기능별 세분화된 지표 → 기능의 움직임을 이해할 수 있는 정도
  • 신뢰도 가드레일, 데이터 품질 지표
  • 진단 및 디버그 지표

주요 지표를 OEC로 결합

• 여러 가지 goal, driver 지표를 갖고 있는 경우 어떻게 해야 할까?
  • Lean Analytics: OMTM (단 하나의 지표)
  • The 4 Disciplines of Execution: WIG(Wildly Important Goal)
  • 제트 비행기 조종사가 봐야 할 지표는 1개만 있지 않다. (비행속도, 고도, 남은 연료 등)
  • 일반적으로 사용자 참여와 금전적 가치를 측정함
    • 사용자 참여: 활성일, 사용자당 세션, 사용자당 클릭수
    • 금전적 가치: 사용자당 매출
• 여러 지표를 가중 조합한 OEC를 고안하는 것이 좋다.
  • ex. 농구 스코어보드는 ‘팀별 합산 점수’만 기록하고 2점/3점 슛 점수를 분리하지 않는다.
  • ex. 신용점수는 여러 개의 지표를 단일 점수로 결합한다.
  • 방법: 여러 지표를 정규화(ex. 0-1) 한 후, 각 지표에 가중치를 할당
• 핵심 지표를 단일 OEC로 결합할 수 없다면, 핵심 지표수를 최소화하는 것이 좋다.
  • 지표가 많을수록 1개 이상의 지표가 통계적으로 유의하게 될 가능성이 커져 잠재적 문제가 발생 가능

아마존 이메일 OEC 예시

• 아마존에서 고객에게 캠페인을 기반으로 이메일을 보내는 시스템 구축
• 시스템 종류
  • 이전에 구입한 저자의 신간 서적: 새로운 출시 넛지
  • 구매 이력: 추천 알고리즘이 구매 이력을 바탕으로 새로운 상품 추천
  • 크로스 폴리네이션(cross pollination): 구매한 제품의 카테고리에 보완이 되는 좋은 아이템을 추천
    • 제품 카테고리 조합을 사전 정의해야 함
• 초기 OEC: 이메일을 클릭한 사용자의 매출
  • 이메일 양과 함께 단조함수로 증가하는 문제 발생
  • 클릭을 통한 수익이 단기 매출에 최적화되고 있었음 → 생애가치를 고려하지 않음
• 신규 OEC:
  • 사용자 생애 기회 손실에 대한 하한을 설정
  • \(OEC = \large( \displaystyle\sum_i{Rev}_i - s*unsubscribe\_lifetime\_loss ) / n\)
  • i: 수신자의 범위
  • s: 이메일 수신 취소자 수
  • unsubscribe lifetime loss: 일생 동안 이메일 보낼 수 없다는 조건 하에 추정되는 매출 손실
  • n: 변형군 내 사용자 수

Bing 검색 엔진 OEC 예시

• Bing은 검색어 점유율과 매출을 사용해 목표 달성도를 측정
  • 순위 알고리즘 버그로 실험군 사용자에게 나쁜 검색 결과를 보여줄 때, 두 지표가 개선되는 상황이 발생함
  • OEC로 두 지표를 활용한다면, 쿼리 점유율과 매출을 올리기 위해 의도적으로 품질을 떨어뜨릴 수 있음
    • 저하된 알고리즘 결과 → 사용자당 검색어 수 증가 → 광고 클릭 증가 (매출 증가)
• 월별 쿼리 점유율
  • \(n \displaystyle{Users\over Month}\times {Sessions\over User}\times {Distinct\;queries\over Session}\)
  • 검색 엔진의 목표가 사용자가 원하는 답변을 확인하거나 작업을 빨리 원하는 것이라면, 작업당 고유 쿼리 수를 줄이는 것이 목표 → 쿼리 점유율을 증가시키는 비즈니스 목표와는 상반됨
  • 작업별 고유 쿼리 수는 측정하기 어렵기 때문에, 세션당 고유 쿼리 수를 대리 지표로 사용 가능
    • 세션당 고유 쿼리 수가 낮아지면, 사용자가 포기하는 것으로 나타날 수 있음
    • 작업 성공 완료를 확인한 후, 세션당 고유 쿼리 수를 낮추는 것을 목표로 해야 함
  • 사용자당 세션 수는 증가해야 하는 핵심 지표 → 사용자가 만족할수록 증가
  ⇒ 사용자당 세션 수를 늘리고, 작업 성공 완료를 기반으로 세션당 고유 쿼리 수를 줄이는 것이 목표
• 사용자당 매출
  • 제약 조건을 추가하여 검색 및 광고 실험을 위한 OEC로 사용해야 함
  • 일반적인 제약 조건: 쿼리가 여러 개 있는 경우, 광고가 사용할 수 있는 평균 픽셀 수를 제한

굿하트의 법칙, 캠벨의 법칙, 루카스의 비판

• 많은 조직에서 OEC를 선택할 때, 상관관계를 인과관계로 잘못 판단함
  • 굿하트: 어떤 척도가 목표가 되면, 더 이상 좋은 척도가 되지 못한다
  • 캠벨: 지표가 사회적 의사결정에 이용될수록 부패 압력 대상이 되고, 모니터 하는 사회적 과정이 왜곡되고 부패되기 쉽다.
  • 루카스: 역사적 자료에서 관찰된 관계는 구조적 or 인과관계로 간주될 수 없다.
• 역사적 데이터로 상관관계를 찾는 것은 한 변수를 수정해서 목표하는 변수가 변화될 것으로 예상되는 포인트를 찾을 수 있는 것이 아니다.
• 인과관계를 기반으로 OEC에 대한 지표를 선택해야 한다.

 

8. 제도적 기억과 메타 분석

• 제도적 기억: 모든 실험과 변화의 역사를 담고 있는 것
• 중앙집중식 실험 플랫폼을 갖는 것은 모든 변화에 대해 데이터를 취득하고 정리하기 쉽게 한다.
• 실험의 메타정보를 취득하는 것 또한 중요함
  • 각 실험에 대한 소유자
  • 실험 시작 시간
  • 실행 시간
  • 설명문, 스크린샷

제도적 기억이 왜 유용한가?

• 실험 문화: 과거 실험에 대한 요약된 견해를 갖는 것은 실험의 중요성을 강조하고 문화를 구축한다.
  • 실험이 광범위한 조직 목표 확대에 어떻게 기여했는가?
  • 놀라운 충격을 주는 실험은 무엇인가?
  • 실험이 지표에 긍/부정적인 영향을 주는가?
  • 실험을 거친 기능의 비율은?
• 실험 모범 사례
  • 내부에서 권장하는 베타 확대기간을 거치는지
  • 핵심 지표의 움직임을 감지할 수 있을 만큼 충분한 검정력을 가지는지
  • 충분한 수의 실험을 실행
  • 메타 분석과 요약 통계를 통해 개선 효과 리포트 (팀별 세분화 리포트도 좋다)
• 미래 혁신
  • 과거 자료는 반복적인 실수를 방지하고 효과적인 혁신을 고무한다.
  • 메타 분석으로 더 좋은 아이디어로 안내할 수 있는 패턴이 생김
    • ex. 어떤 종류의 UI 패턴이 사용자의 참여를 유도할 가능성이 높은가?
• 지표
  • 지표 민감도: 실험 중에 의미 있게 측정할 수 있는지 (외생적 변화가 지표에 미치는 영향을 고려해야 함)
  • 관련된 지표: 지표의 움직임으로 지표가 서로 어떻게 관련되는지 식별 가능 (상관관계와는 다름)
  • 베이지안 접근에 대한 확률론적 사전확률:
    • 과거 실험에서 지표의 움직임이 합리적인 사전 분포를 제공한다고 가정
    • 급속도로 진화하는 제품의 경우, 과거의 경험적 분포로 미래를 추정하기 어려움
• 경험적 연구
  • 방대한 실험 데이터는 연구자들에게 이론을 평가하고 연구할 수 있는 경험적 근거를 제공

 

9. 종합 대조 실험의 윤리

• 윤리의 정의: 우리가 해야 하거나 하지 말아야 하는 것을 규정하는 일련의 규칙이나 도덕
• 윤리적 행동에 대한 규칙과 규제의 발전 속도는 과학에 뒤처지고 있음
• 핵심 원칙
  • 스스로에게 질문
  • 관행을 비판적으로 검토
  • 사용자와 비즈니스의 장기적인 최대 이익 고려
• 의료 분야 핵심 원칙
  • 임상시험이 정당화되는지
  • 랜덤화된 대조 실험을 실시하는 것이 비현실적이거나 비윤리적이라고 인식되는 상황이 있는지
• 벨몬트 보고서, 일반 규칙
  • 사람에 대한 존중이 필요
  • 유익성: 위험과 이익을 적절히 평가하고 균형을 맞춰야 함
  • 정의: 실험 참가자가 착취되지 않고, 위험과 이익이 공정하게 분배되어야 함

온라인 A/B test 고려 사항

• 위험
  • 기능을 실험 없이 모든 사용자에게 적용해도 문제가 없는지 확인
  • A/B illusion: 도덕성을 이유로 종합 대조 실험에 대한 저항하는 경우
• 이익
  • 모든 사용자의 경험을 개선한다는 목표를 갖고 실험 참가자들에게 나쁜 경험을 제공하는 실험은 X
  • 실험 참가자의 존중을 생각했을 때, 투명성과 기대를 고려한 실험을 해야 함
• 선택지의 제공
  • 참가자에게 어떤 선택지가 있는지 고려해야 함
    • 제공되는 선택지를 평가
    • 위험과 이익의 균형을 이루어야함

데이터 수집

• 어떤 데이터를 수집하고 있는가?
  • 민감한 자료인가? (ex. 금융/건강 데이터)
  • 수집 목적은 무엇인가?
• 사용자는 해당 데이터 수집에 대해 무엇을 이해하고 있는가?
• 데이터 수집에 어떤 문제가 생길 수 있는가?
  • 데이터의 일부가 공개될 경우, 사용자에게 어떤 해가 될 것인가?
• 개인정보 보호와 유용성에 대한 사용자의 기대는 무엇이고, 어떻게 보장하는가?
  • 참가자들은 어느 수준의 기밀 유지를 원하는가?
  • 데이터 취급에 대한 내부 안전장치는 무엇인가? (ex. 액세스 권한)
  • 보장이 충족되지 않은 경우, 어떤 보상이 발생할 것인가?

문화와 프로세스

• 기업은 모든 사람들이 윤리적 고려가 충족되도록 문화적 규범과 교육 프로세스를 확립해야 한다.
• 도구, 인프라 및 프로세스를 구축하여 모든 데이터가 안전하게 보존되도록 해야함
  • 모든 데이터 사용 기록 및 위반에 대해 정기적인 감사가 시행되어야 함
• 데이터 민감성 이슈를 가진 경우, 처리하는 방법에 대해 명확한 보고 프로세스를 구축해야 함