요약

Amplitude 실험은 기능 플래그 롤아웃, A/B 테스트 및 웹 실험을 실행하므로 모든 사용자에게 제품 변경 사항을 배포하기 전에 제품 변경 사항을 검증할 수 있습니다. 변형을 구성하고, 트래픽의 비율을 할당하고, 평가할 메트릭을 선택하고, Amplitude 실험이 순차적 테스트 모델이나 T-테스트를 사용하여 영향을 측정하도록 하십시오.

Amplitude 실험은 세 가지 사용 사례를 지원합니다.

• 제품 실험: 실험과 A/B 테스트를 통해 신규 사용자를 유치하고, 결제 경험에 대한 마찰을 줄이며, 새로운 기능을 출시하는 등의 작업을 수행함으로써 핵심 KPI를 개선합니다.
• 점진적 기능 제공: 베타 테스터, 사용자 비율 또는 특정 대상 고객을 위해 새로운 기능을 사전 계획하고 준비합니다.
• 동적인 제품 내 경험: 규모에 맞게 맞춤형 경험을 배포하고 조정합니다.

실험은 두 가지 범주를 제공합니다.

• 기능 실험: 기능 플래그를 사용하여 고객에게 기능이나 A/B 옵션을 표시하거나 숨깁니다.
• 웹 실험: 웹 편집기를 사용하여 웹 사이트를 직접 변경하십시오.

기능 플래그와 웹 편집기의 차이점

기능 실험은 기능 플래그를 사용하여 실험 변형을 생성합니다. 플래그는 코드를 변경하지 않고도 제품 환경을 수정할 수 있게 해주는 스위치입니다. 플래그를 사용하여 제품에서 실험을 설정하거나 사용자에게 새로운 기능을 준비하고 배포하십시오. 여러분의 코드는 Amplitude 실험 SDK 또는 REST API를 사용하여 Amplitude 실험과 통신합니다. 기능 플래그에 대한 자세한 내용은 기능 플래그로 이동하십시오.

웹 실험은 시각적 편집기를 사용하여 실험 변형을 만듭니다. 이 편집기는 A/B 또는 멀티 암드 밴딧 실험에 가장 적합합니다. 시각적 편집기를 사용하면 콘텐츠 및 요소 속성을 비롯한 웹 요소를 선택하고 변경할 수 있습니다. 웹 실험을 사용하면 기술력이 부족하거나 시스템에서 권한 관리 부족한 사용자가 엔지니어링 리소스 없이 실험을 만들 수 있습니다.

웹 실험은 페이지를 사용하여 실험의 변형이 웹사이트에서 적용되는 위치를 제어합니다. 페이지를 사용하면 사이트의 관련없는 부분에 영향을 주지 않고 특정 URL로 실험 범위를 지정할 수 있습니다.

기능 가용성

기능, 웹 또는 두 가지 유형의 실험에 사용할 수 있는 기능에 대한 자세한 내용은 기능과 웹 실험의 대상 구간 차이점을 참조하십시오.

실험 만들기

많은 실험 프로그램이 첫 단계에서 실패하는 이유는 아무도 실험이 해결할 수 있는 문제를 명확하게 설명할 수 없기 때문입니다. 왜 실험을 하고 있는지 명확하고 간단한 언어로 설명할 수 없다면, 실험으로부터 유용한 것을 배울 수 있기를 현실적으로 기대할 수 없습니다.

다른 일을 하기 전에, 시간을 투자해 실험을 위한 강력한 사명 선언문을 작성하세요. 이 문장은 두 가지 질문에 답합니다: 문제는 무엇이며, 실험을 실행하면 문제를 해결하는 데 어떻게 도움이 될 수 있습니까? 이 단계에서 기울인 노력은 나중에 성과를 거둘 것입니다.

사명 선언문을 작성한 후에는 실험을 구성할 준비가 되었습니다. 실험을 위해 새 배포를 생성(또는 이전에 생성한 배포를 선택)하고 사용하려는 SDK를 설치합니다.

가설 만들기

다음으로, 실험을 위해 작성한 사명 선언문에 집중하십시오. 사명 선언문은 실험의 가설을 세우는 기초 역할을 합니다. 가설은 실험이 올바른 선택일 가능성이 얼마나 높은지에 대한 예측입니다. 가설은 실험이 성공했는지 실패했는지를 알려줍니다.

문제 정의는 가설의 첫 번째 부분일 뿐입니다. 가설은 제안된 해결책과 예측된 결과라는 두 가지 다른 부분으로 구성됩니다.

제안된 솔루션은 문제를 해결하기 위해 수행하고자 하는 변경 사항에 대한 설명입니다. 예를 들어, "온보딩 프로세스의 두 단계를 하나로 통합하십시오." 예측 결과는 실험에서 예상되는 결과입니다. 예: '온보딩 이탈률을 20% 줄이십시오.'

가설 진술의 예는 다음과 같습니다.

"당사의 온보딩 퍼널에서 사용자 이탈률은 업계 평균보다 훨씬 높습니다. 제품 데이터에 따르면 우리의 퍼널이 너무 혼란스러울 수 있습니다. 퍼널의 2단계와 3단계를 통합하면 문제를 해결할 수 있을 것으로 믿습니다. 이러한 변화의 결과로 온보딩 이탈률은 20% 감소할 것으로 예상됩니다.”

모든 가설 진술은 특히 문제 정의 단계에서 고객의 요구에 따라 고유합니다. 예를 들어 귀하의 질문은 본질적으로 더 탐구적인 것일 수 있습니다: “왜 그렇게 많은 사용자가 우리의 온보딩 퍼널을 탈퇴합니까?” 또는 이미 이해하고 있는 문제에 대한 다양한 솔루션을 테스트하는 데 더 관심이 있을 수도 있습니다. 예를 들어 "우리는 알려진 사용자 불만 사항을 해결하기 위해 몇 가지 잠재적 인 UI 변경 사항을 제안했습니다. 어느 쪽이 가장 효과적입니까?”

이 기본 템플릿을 대부분의 가설에 대한 출발점으로 사용하십시오. 특히 실험을 처음 접하는 경우라면 더욱 그렇습니다.

지표 선택하기

가설 문장의 마지막 문장에 집중하십시오. 이 문장에는 사용자 행동이 어떻게 변화할 것으로 예상되는지에 대한 구체적인 측정값이 포함되어 있습니다. 온보딩 이탈률이 20% 감소합니다. 측정값은 실험의 성공 여부를 결정합니다. 이 숫자를 달성했는지 여부입니다.

이 숫자에 도달했는지 여부를 알기 위해서는 이탈률의 감소를 측정할 수 있는 방법이 필요합니다. 지표가 필요합니다. Experiment에서는 기록한 전체 이벤트를 실험 지표로 사용할 수 있습니다. 위의 예제 실험의 경우, 제품이 퍼널의 손실을 추적하기 위해 사용하는 이벤트를 지표로 사용하세요.

변형 생성

새로운 온보딩 프로세스를 모든 사용자에게 배포하고 그 결과를 관찰할 수 있습니다. 그렇게 할 경우, 제품 변경으로 인해 온보딩 이탈률이 전체 개선되었는지 여부를 알 수 없습니다. 그리고 새로운 퍼널을 구축한 후 이 비율이 떨어진다면 그 원인은 잘못된 디자인 선택, 무작위적인 우연성 또는 고려하지 않은 외부 영향일 수 있습니다. 구체적인 원인을 찾을 방법이 없습니다.

이러한 이유로 실험을 위해 최소 하나의 처리 변형을 만들어야 합니다. 처리 변형은 특정 비율의 사용자에게 표시하는 다른 사용자 경험입니다. 온보딩 예제에서 이 변형은 온보딩 프로세스의 새롭고 간소화된 버전입니다. 일부 사용자는 새 버전을 경험하지만 다른 사용자는 현재 프로세스(대조군이라고 함)를 계속 사용합니다. 각 변형에 대한 사용자의 반응 방식의 차이는 실험의 성공을 결정합니다.

변형을 만들 때는 각 변형의 변경 횟수를 최소화하십시오. 각 변형에는 단일 변경 사항이 포함되어 있는 것이 이상적입니다. 하나의 변경을 통해 어떤 변화가 긍정적인 결과를 가져오는지 이해할 수 있습니다. 또한 변형이 서로 눈에 띄게 다르다는 것을 확인하십시오. 구별되는 변형은 각 세그먼트의 사용자가 서로 다른 경험을 한다는 것을 확인하며, 귀하의 변경 사항이 세그먼트 대상 구간 행동에 전체 차이를 유도한다는 것을 의미합니다.

변형을 수신할 사람을 결정합니다

다음으로, 버킷팅 단위를 정의하며, 이는 어떤 그룹의 사람들이 동일한 변형을 볼 수 있는지를 결정합니다. 가장 일반적인 버킷팅 단위는 ‘사용자’입니다. 그러나 B2B 비즈니스이거나 협업 기능을 사용하는 경우 동일한 조직 내의 모든 사용자가 동일한 변형을 경험하도록 "조직" 또는 company_id과 같은 버킷 설정 단위를 사용해야 할 수도 있습니다. 일관된 버킷 설정은 사람들이 동료 옆에 앉아있을 때 서로 다른 사용자 인터페이스로 인해 발생하는 제품 관련 혼란을 줄이는 데 도움이 됩니다. 버킷을 나누는 또 다른 이유는 고객 지원 팀의 부담을 줄이기 위해서입니다company_id. 지원 팀은 어떤 계정에 어떤 기능이 활성화되어 있는지 보다 쉽게 추적할 수 있습니다. 어느 쪽이든, 추론을 가장 잘 보장하기 위해 선택한 버킷 단위에 대해 SUTVA(안정적인 단위 처리 값 가정)가 유지되는지 확인하십시오.

사용자 할당

변형을 생성한 후 얼마나 많은 사용자가 변형을 수신할지 결정하십시오. 전체 사용자 기반 또는 사용자 중 일부에게 실험을 배포할 수 있습니다. 실험에서 대조군 경험을 수신하는 사용자 수와 변형을 수신하는 사용자 수를 지정합니다. 실험에 포함하거나 제외할 특정 사용자 세그먼트를 정의할 수 있으며, 개별 사용자 또는 기기 ID에 대한 특정 경험을 선택할 수도 있습니다.

실험 활성화

이제 여러분의 사용자에게 실험을 배포할 준비가 되었습니다. 실험 시작을 선택하면 실험이 시작됩니다.

결과 분석

실험이 실행 중이면 전체 시간에 결과를 생성하고 볼 수 있습니다. 실험은 실험이 통계적 유의성에 도달했을 때를 알려줍니다. 즉, 실험이 충분한 결과와 데이터를 가지고 있어 수집하는 정보가 정확하다고 믿을 수 있을 때입니다. 실험은 사용자가 결과를 분석하고 해석할 수 있도록 수집한 모든 데이터를 제공합니다.

실험을 설계, 배포 및 학습하는 방법에 대해 자세히 알아보려면 실험 워크플로우에 관한 다음 문서를 참조하십시오.