데이터 기반 제품 개발을 위한 실험 환경을 설정하는 방법

제품 소유자로서 옵션 A를 진행할지, 옵션 B를 진행할지 고민하는 경우가 많습니다. 아니면 더 나은 결과를 얻으려면 어떤 버전의 화면을 구현해야 할까요? 그러한 결정을 내리는 것은 어려울 수 있습니다. 특히 제한된 리소스로 마감 기한이 촉박한 경우에는 더욱 그렇습니다. 또한 그러한 결정은 개인적인 판단이나 경쟁사의 접근 방식을 모방하여 이루어지며, 이는 차선의 결과를 초래할 수 있습니다.

좋은 소식은 비교적 적은 노력이 필요한 간단한 실험 환경을 설정하면 이러한 함정을 피할 수 있다는 것입니다. 이 기사에서는 이를 달성하는 방법을 설명합니다.

목차

• 실험 환경 설정이 중요한 이유.
• 신화
• 실험 환경 설정
  • 향후 실험의 목표 정의
  • 실험 환경의 아키텍처 설계
  • 결과 분석 및 해석
  • 선호하는 옵션을 확대합니다.
• 결론.

실험 환경 설정이 왜 중요한가요?

실험 환경 설정은 다음 두 가지 이유로 중요합니다.

• 첫째, 새로운 기능을 구현한 후 데이터 기반 접근 방식을 기반으로 최상의 옵션을 선택할 수 있습니다.

  
  

• 둘째, '현상태'와 가상의 '예정' 옵션을 비교하고 '가정' 분석을 수행하여 제품의 기존 기능을 지속적으로 개선할 수 있습니다.

신화

접근 방식을 진행하기 전에 일반적으로 제품 소유자를 오해하는 몇 가지 신화를 폭로하겠습니다.

실험과 A/B 테스트를 수행할 수 있는 복잡한 환경을 설정하려면 많은 리소스가 필요합니다.

잘못됨 : 설명된 접근 방식은 소프트웨어 엔지니어의 리소스를 1주일 미만으로 소모합니다.

잘 확립된 데이터 수집 프로세스와 상세한 이벤트 추적이 필요합니다.

잘못됨 : 제품 주요 엔터티의 수명 주기에 대한 정보를 저장하는 기존 데이터베이스에 의존할 수 있습니다. 예를 들어, 배달 서비스를 제공하는 경우 주문 상태입니다.

매일 내 요청을 처리할 전담 분석가 팀이 필요합니다.

틀린 점 : 실험의 접근 방식과 지표를 이해하고 나면 간단한 SQL 쿼리를 사용하여 정기적으로 직접 데이터를 가져올 수 있습니다.

접근하다

실험 환경을 설정하려면 다음 단계를 따르는 것이 좋습니다.

1. 향후 실험의 목표를 정의하고, 옵션을 이해하고, 측정항목을 선택하세요.

제품 디자이너에게 연락하기 전에 실험의 일부로 측정할 목표와 지표를 정의하세요. 전형적인 '옵션 A 또는 옵션 B' 질문의 경우 일반적으로 변경을 구현하여 달성하려는 것이 간단합니다. 예를 들어 퍼널의 특정 부분을 다룰 수 있습니다.

설명을 위해 귀하가 배송 회사에서 일하고 있으며 현재 주문 생성 양식에 집중하고 있다고 가정해 보겠습니다. 배송 주소를 제공한 다음 배송 방법을 선택하는 상대적으로 낮은 비율의 사용자를 처리하려고 합니다. 또한 두 가지 새로운 버전의 여정이 있다고 가정해 보세요.

1. 현재 버전 : 한 화면에서 주소를 입력하고 제공된 주소를 기반으로 핀으로 지도를 표시해야 합니다. 다음 화면에서는 제공된 주소를 기반으로 배송 방법을 선택할 수 있습니다.

   
   

2. 새 버전 : 단일 화면에서 주소를 입력하고 배송 방법을 선택해야 합니다.

목표는 어떤 옵션이 주소를 제공하고 배송 방법을 선택한 사용자의 비율을 높이는지 결정하는 것입니다. 지표는 다소 간단합니다. 주소를 제공하고 배송 방법을 선택한 사용자의 비율입니다.

실제로 이러한 데이터를 측정하는 방법에는 두 가지가 있습니다 .

1. 백엔드 설계를 통해 이미 사용 가능한 데이터를 기반으로 합니다. 예를 들어 주문의 수명주기에 대한 정보가 있는 데이터베이스를 생각해 보세요. 주문에는 다음과 같은 상태가 있을 수 있습니다.

   
   

   1. 초안이 생성되었습니다.

   2. 배송 방법을 찾아보세요

   3. 배송 옵션을 찾았습니다/배송 옵션을 찾을 수 없습니다

      
      

2. 이벤트 추적 - 이는 기본적으로 작동하는 기능이 아니므로 구현하려면 추가 노력이 필요합니다. 그러나 이벤트 추적을 사용하면 보다 세부적인 분석이 가능해집니다. 예를 들어 장치 유형과 브라우저 이름을 이벤트의 매개변수로 전달할 수 있습니다.

이 기사의 다음 섹션에서는 첫 번째 접근 방식, 즉 이벤트 추적이 없는 기존 데이터 아키텍처에 중점을 둘 것입니다.

2. 실험 환경의 아키텍처 설계

실험 흐름 내에서 두 가지 주요 단계를 완료해야 합니다.

• 선택한 매개변수를 사용하여 실험 만들기
• 사용자를 두 그룹 중 하나에 할당해야 하는 사용자 경험 단계를 정의하고 결과적으로 관련 UI가 표시되는지 확인합니다.

실험 만들기:

가능한 한 간단하고 다음 매개변수를 사용하여 실험을 만들 수 있는 경량 A/B 테스트 프레임워크를 마련하는 것이 아이디어입니다.

• 실험 ID
• 최대 샘플
• 각 그룹의 번호와 이름
• 각 그룹에 속할 확률

이러한 매개변수를 구성할 수 있으면 샘플 제한을 설정하고 원하는 샘플 크기에 도달할 때까지 무작위로 실험 후보를 선택할 수 있습니다.

이를 위해서는 클라이언트와 서버 모두 변경이 필요합니다. 서버는 실험당 후보자 수를 추적해야 하며 백엔드는 현재 사용자가 실험에 참여해야 하는지 여부를 결정합니다. 백엔드는 현재 샘플 크기와 고정 확률을 기반으로 인증된 사용자가 실험에 참여해야 하는지 여부를 결정합니다. 또한 백엔드는 사용자에게 일관된 경험을 제공하고 실험 결과를 적절하게 계산하기 위해 특정 실험의 일부인 사용자 컬렉션을 유지해야 합니다.

실험 구성의 끝점은 다음과 같습니다.

POST /api/your-service/experiment-create

요구:

 { experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}

응답:

{

200,

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

사용자를 실험 그룹에 할당해야 하는 시기와 방법을 결정합니다.

특정 사용자를 실험 및 해당 그룹에 할당하는 역할을 담당하는 별도의 엔드포인트가 필요합니다. 이를 experiment-enrollments 라고 부르겠습니다.

전체 환경을 설계하는 동안 사용자 여정 experiment-enrollments 엔드포인트의 어느 단계를 호출해야 하는지 명확하게 이해해야 합니다. 또한, 모든 사용자가 실험에 참여해서는 안 되는 경우도 있을 수 있습니다. 그렇기 때문에 엔드포인트에 사용자 인증 토큰을 제공하는 것도 유용합니다.

이 예에서 첫 번째 주문을 수행하는 신규 사용자에게만 집중하려는 경우 user-auth를 사용하면 사용자 유형이 무엇인지, 실험에 등록해야 하는지 여부를 결정할 수 있습니다. 또한 엔드포인트가 호출되면 필요한 모든 정보를 사용할 수 있는지 확인하고 여정 및 수명 주기의 세부 사항을 고려하세요.

experiment-enrollments 엔드포인트는 아래에 설명되어 있습니다. 특정 유형의 사용자(예: 아직 주소를 제공하지 않은 신규 사용자만)에 대해 여정의 특정 단계(예: 배송 주소가 필요한 화면에 도착하기 전)에 호출될 수 있으며 현재 사용자가 참여해야 하는지 여부를 계산합니다. 특정 실험에서 여부:

POST /api/your-service/experiment-enrollments , 사용자 인증 토큰이 필요합니다.

요구:

\ {

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

응답:

 {200, enrolled: true/false, group_name: group_1,}

이론적인 데이터 흐름이 어떻게 나타나는지 설명하기 위해 배송 회사의 주문 생성 흐름과 동일한 예를 가정해 보겠습니다. 귀하는 주문 생성 화면의 2가지 옵션 중에서 선택하고 있습니다.

아래 다이어그램에는 다음 엔드포인트가 언급되어 있습니다.

• /create-order-draft(3단계)

• /find-배송 방법(16단계)

• /submit-order(20단계)

  
  

예시를 뒷받침하기 위해 제공되는 것이며 실험 환경에 꼭 필요한 부분은 아닙니다.

또한 데이터베이스의 예시적이고 단순화된 아키텍처가 아래에 제공됩니다.

3개의 주요 테이블이 있습니다:

1. Experiments set - 이전에 만든 모든 실험이 포함되어 있습니다. 데이터베이스는 /experiment-create 엔드포인트를 호출할 때마다 업데이트됩니다.

   
   

2. Experiments database - 특정 사용자의 각 등록과 관련된 모든 기록이 포함되어 있습니다. experiment-enrollments 포인트를 호출할 때마다 데이터베이스가 업데이트됩니다.

   
   

3. Order lifecycle database - 실험 관련 데이터가 저장될 수 있는 방법에 대한 예시를 지원하기 위해 제공됩니다. 요점은 이 테이블(또는 제품의 세부 사항에 해당하는 유사한 테이블)을 사용하면 실험 그룹 중 하나에 등록된 특정 사용자에 대한 항목(예: 주문 생성)이 성공했는지 여부를 확인할 수 있다는 것입니다. 설정했습니다. 이 예에서는 사용자가 배송 세부 정보를 성공적으로 제공한 다음 제안된 배송 방법 중 하나를 선택했다고 결론을 내릴 수 있는 배송 방법 선택 상태를 사용할 수 있습니다.

   
   

   
   

설계 및 구현 접근 방식 개요

장점:

1. 결과 샘플은 이질적입니다.
2. 표본 크기는 미리 알려져 있습니다.
3. 고정된 샘플링 확률에 따라 결과를 빠르게 계산할 수 있습니다.

단점:

1. 프런트엔드와 백엔드 모두 변경 필요
2. 결과 계산은 여러 데이터베이스에 의존하며, 그 중 일부는 초기에 분석 목적으로 설계할 수 없었습니다.

작업 및 지표 추정:

• [ ] 정의되지 않음 [백엔드] 모델 생성 및 가져오기 카운터 엔드포인트 노출: ~2 스토리 포인트
• [ ] 정의되지 않음 [백엔드] 증분 카운터 끝점 노출: ~2 스토리 포인트
• [ ] 정의되지 않음 [백엔드] 가져오기 및 증가 카운터에 엔드포인트 노출: ~1 스토리 포인트
• [ ] 정의되지 않음 [프런트엔드] 등록 흐름 간 전환을 위한 호출 카운터 엔드포인트: ~3 스토리 포인트

백엔드를 설계한 후에는 프런트엔드 팀이 정보를 받을 수 있는 가장 좋은 방법과 흐름의 어느 단계에 있는지에 대해 조정하세요.

주요 종속성을 염두에 두고 완화하세요.

• 프런트엔드 부분이 백엔드와 병렬로 구현될 수 있도록 팀이 사전에 계약을 체결했는지 확인하세요.
• 전체 백엔드가 완료될 때까지 프런트엔드가 차단되지 않도록 하세요.
• 실험 환경에 관계없이 모든 UI 옵션은 어쨌든 구현되어야 합니다.

3. 결과 분석 및 해석

충분한 시간 동안 실험을 실행한 후에는 결과를 분석하고 해석하여 의미 있는 결론을 도출하는 것이 중요합니다.

이전에 집중하기로 결정한 측정항목에 대한 영향을 계산하는 데 필요한 필드 목록을 정의하세요.

위의 예시에서 데이터 소스는 2개의 테이블이 됩니다.

• Experiments database :

  • 입력 : 결과를 찾고 있는 실험 ID

  • 출력 : 특정 실험에 참여한 모든 사용자 ID 목록, 각 사용자가 할당된 그룹 및 사용자가 할당된 타임스탬프

    
    

• Order lifecycle database
  • 입력 : 실험 범위에 있는 사용자 목록 및 실험에 등록된 타임스탬프
  • 출력 : 해당 사용자와 연결되어 있고 사용자가 실험에 등록된 후 처리된 모든 주문의 최종 상태

이 데이터를 바탕으로 각 실험 그룹에 대해 성공적으로 생성된 주문 비율을 계산할 수 있습니다.

결과를 분석할 때는 단순한 숫자 그 이상을 살펴보는 것이 중요합니다. 또한 테스트 그룹 간에 관찰된 차이가 단지 우연에 의한 것이 아닌지 확인하기 위해 통계적 유의성을 찾고 싶을 것입니다. 이 주제와 다른 온라인 리소스에서 이 주제와 관련된 많은 기사를 이미 봤으므로 이 부분에 너무 집중하지는 않겠습니다. 어쨌든 여기서는 과도한 지식이 필요하지 않습니다. 제 생각에는 Z-Test 나 T-Test를 적용하여 두 그룹 간의 차이의 유의성을 확인하면 충분할 것 같습니다.

그럼에도 불구하고 결과가 통계적으로 유의미하다고 판단되면 제품 중 어떤 옵션이 더 나은 성과를 냈는지 결론을 내릴 수 있습니다.

4. 선호 옵션 확대

실험을 성공적으로 실행하고 최상의 옵션에 대해 충분한 확신을 얻은 후 다음 단계는 제품 전반에 걸쳐 변경 사항을 확대하는 것입니다. 여러 가지 접근 방식이 있을 수 있습니다.

• 가장 쉬운 방법 은 100%의 사용자가 더 나은 결과를 보여주는 그룹에 속하도록 실험 구성을 조정하는 것입니다. UI의 특정 부분을 표시하는 것이 실험 환경과 독립적이도록 나중에 코드를 정리할 시간을 확보해야 합니다.

  
  

• 덜 간단한 것은 제품이 여러 플랫폼에서 사용 가능한 경우입니다. 웹 흐름에 대한 실험 결과가 모바일 앱 흐름에 적용된다고(또는 그 반대) 가정할 때 특히 주의하세요 . 때로는 후회하는 것보다 안전하다고 생각하고 비슷한 방식으로 다른 플랫폼에서 별도의 실험을 실행하는 것이 더 낫습니다.

결론적으로

자신만의 실험 환경을 갖는 것은 모든 제품 관리자에게 매우 편리한 도구입니다. 현재 제품이 어느 성숙 단계에 있는지에 관계없이 실험 환경을 만드는 데 너무 많은 시간이 소요되어서는 안 됩니다. 작업을 수행하기 위해 상당히 낮은 일회성 비용을 지불하면 상당히 빨리 투자 수익을 얻을 수 있습니다.

마지막으로, 실험 결과가 타당한지 확인하기 위한 몇 가지 팁은 다음과 같습니다.

• 우선, 고려 중인 변경 사항을 구현함으로써 어떤 지표가 영향을 받는지 이해하십시오.
• 실험을 시작하기 전에 목표와 측정항목을 명확하게 정의하세요.
• 한 번에 하나의 주요 변경사항에 초점을 맞춰 실험을 최대한 단순하게 유지하세요.
• 다른 플랫폼이나 기타 유사한 서비스에 대한 실험 결과를 추정할 때는 주의하세요.
  

이러한 모범 사례를 따르면 데이터 기반 결정을 내리고 시간이 지남에 따라 전환율을 높이는 데 도움이 되는 효과적인 실험 환경을 설정할 수 있습니다.