동시 실험을 실행해야 합니까? 상충되는 결과를 피하기 위한 가이드

게시 됨: 2022-09-06

동시 실험을 실행할지 여부에 대해 최적화 세계에서 약간의 논쟁이 있습니다. 일부는 동시 A/B 테스트를 실행하면 결과가 흐려지고 부정확한 데이터가 생성될 것이라고 생각합니다. 다른 사람들은 웹사이트의 다양한 페이지에서 동시에 A/B 경험을 실행하면 더 많은 것을 테스트하고 성공 전략을 더 빨리 식별하는 데 도움이 될 수 있다고 주장합니다.

그래서, 어느 것이 맞습니까?

이 블로그 게시물에서는 동시 실험의 장점과 단점을 살펴보고 최적화 프로그램에 가장 적합한 접근 방식을 결정하는 데 도움이 될 것입니다.

이 블로그 기사를 읽고 나면 다음 질문에 답할 수 있습니다.

동시 분할 URL 환경을 실행할 수 있습니까?
A/B 경험을 동시에 실행할 수 있나요?
A/A 경험과 A/B 경험을 동시에 실행할 수 있습니까?

짧은 대답은 예 입니다. 단일 페이지 또는 일련의 페이지에서 여러 경험을 동시에 실행할 수 있습니다. 그러나 한 경험의 버킷팅은 동시에 발생하는 다른 경험의 데이터에 영향을 미칠 수 있습니다.

숨다

경험 중복은 어떻게 발생하며 우려해야 합니까?
- 동일한 요소 테스트
- 같은 페이지에서 테스트
- 동일한 유입경로/흐름에 참여하는 사용자 테스트
- 사이트 전체 경험 실행
- 동일한 청중/방문자 테스트
- 다른 경험과 공유되는 목표에 상당한 영향을 미칠 수 있는 경험 실행
성공적인 테스트 실행을 위한 전략
- 1. 중복 없는 동시 경험(격리)
- 2. 비동시적(순차적) 경험
- 3. 겹침을 통한 동시 체험
  - ㅏ. A/B/N 경험
  - 비. 다변수 경험(MVT): 단일 테스트에서 많은 경험 결합
    - 변환 경험에서 MVT를 설정하는 방법
  - 씨. 상호 배타적 경험
    - 많은 상호 배타적 경험
결론

경험 중복은 어떻게 발생하며 우려해야 합니까?

동시 실험을 할 때 한 가지 명심해야 할 것이 있습니다. 어떤 경우에는 두 가지 변경 사항이 상호 작용할 수 있으며, 결과적으로 분리할 때와 결합할 때 행동에 다른 영향을 미칠 수 있습니다. 이는 실험이 동일한 사용자 흐름 등으로 동일한 페이지에서 실행될 때 발생할 수 있습니다.

경험 중복이 발생할 수 있는 위치와 이것이 문제로 간주되어야 하는지에 대한 몇 가지 예를 살펴보겠습니다.

동일한 요소 테스트

무료 반품 정책 및 무료 배송과 같은 보상 기능을 강조하기 위해 제품 페이지 디자인을 전환하는 것은 실행할 수 있는 A/B 테스트의 한 예입니다.

고객 중 한 명이 이 정확한 시나리오를 테스트했습니다. 고객 서비스 부서의 데이터를 기반으로, 그들은 제품 페이지에 기능이 충분히 표시되지 않았기 때문에 고객이 브랜드의 무료 반품 정책을 인식하지 못했다고 가정했습니다. 그런 다음 기능을 더 눈에 띄게 보여주는 A/B 테스트를 실행하고 고객의 반응을 측정했습니다.

원본과 변형은 다음과 같습니다.

그러나 변경 사항이 모든 제품 페이지에 적용되는 것은 아니었기 때문에 테스트 구현이 조금 더 복잡했습니다. 일부 제품은 무료 반품 자격이 없었고, 특정 판매 중인 품목은 수정할 수 없었습니다. 이러한 이유로 그들은 동일한 요소를 변경하고 많은 제품에 면책 조항을 추가하는 동시에 또 다른 A/B 경험을 실행하기로 결정했습니다. 이 페이지에는 "상품은 반품 불가입니다."라고 표시되어 있습니다.

보시다시피 두 A/B 경험은 동일한 웹사이트 요소에 영향을 미치므로 결과에 일종의 중첩이 발생하여 명확한 결론을 내리기가 어렵습니다.

같은 페이지에서 테스트

A/B 경험의 또 다른 예는 당사 고객이 주문 방문수를 늘리기 위해 제품 페이지를 최적화한 경우입니다.

제품 페이지의 각 요소를 분석하고 목표 전환을 추적하면서 기본 탐색 모음 링크, 특히 "지금 쇼핑하기"에서 가장 많은 클릭이 발생했음을 발견했습니다. 우리 고객은 카테고리 페이지에 더 많은 자격을 갖춘 트래픽을 보내는 것이 홈페이지에서 떠돌게 놔두는 것보다 중요하다는 것을 인식했습니다.

결과적으로 고객은 "지금 쇼핑하기" 섹션을 "슈퍼 세이버", "바자회" 등과 같은 다른 카테고리로 교체하기로 결정했습니다. 또한 "지금 쇼핑" 섹션을 사이트 왼쪽으로 이동하여 페이지를 시각적으로 더 매력적으로 만들고 자격을 갖춘 방문자를 유치했습니다.

제품 페이지는 처음에 이렇게 생겼습니다.

한편, "지금 구매" 버튼의 다른 색상이 더 나은 전환으로 이어지는지 확인하기 위해 제품 페이지에서 또 다른 A/B 실험이 수행되고 있었습니다.

이 두 A/B 경험은 동일한 페이지의 동일한 요소에 영향을 미치기 때문에 결과에서 일부 중복은 불가피합니다.

동일한 유입경로/흐름에 참여하는 사용자 테스트

동일한 유입경로에 참여하는 사용자를 테스트할 때도 경험 중복이 발생할 수 있습니다. 대부분의 웹사이트는 여러 유입경로를 통해 전환을 유도합니다. 주요 초점은 구매에 있을 수 있지만 계정 생성 또는 획득도 비즈니스의 중요한 원동력이 될 수 있습니다.

제품 페이지에서 경험을 실행하면 구매 전환에 영향을 미칠 수 있습니다. 그러나 계정 생성 페이지에서 양식 레이아웃을 테스트하면 해당 유입경로를 개선하는 데 도움이 될 수 있습니다. 획득 테스트에는 사이트로 트래픽을 유도하는 것부터 마케팅 목적으로 이메일 주소를 수집하는 것까지 모든 것이 포함됩니다.

웹 사이트의 동일한 페이지에 경험이 있으면 겹치게 되어 버그가 발생할 수 있습니다. 경험 목표가 동일한 유입경로와 일치하는 경우 결과에 영향을 미칠 수 있습니다.

더 많은 완료된 가입을 얻으려고 한다고 가정해 보겠습니다. 사이트에 도착하면 사용자는 다음을 등록해야 합니다.

가입을 위한 전환 유입경로를 설정하기 위해 다음 이벤트를 추적할 수 있습니다.

가입 사용자 수
완료된 가입 수
홈페이지 화면 로딩 횟수

그런 다음 다음 변경 사항을 테스트하여 유입경로를 개선하는 방법에 대한 몇 가지 가설을 공식화할 수 있습니다.

가입 프로세스에 온보딩 추가
가입 양식을 줄여 사용자 친화적으로 만듭니다.
가입을 완전히 제거

그러나 이 경우 A/B 경험이 동일한 유입경로에 영향을 미치므로 A/B 테스트 변경의 정확한 영향을 결정할 수 없으므로 결과 간에 약간의 겹침이 있습니다.

사이트 전체 경험 실행

모든 페이지에 나타나는 요소를 실험해야 하는 경우가 있습니다. 얼마나 많은 전환을 얻을 수 있는지 확인하기 위해 바닥글 클릭 유도문안의 색상이나 글꼴 크기를 변경하는 테스트를 한다고 가정해 보겠습니다.

변환을 사용하면 프로세스를 간단하게 구현할 수 있습니다. 모든 페이지를 타겟팅에 추가하기만 하면 됩니다.

그게 다야!

그러나 사이트 전체 타겟팅은 해당 페이지에서 실행되는 다른 A/B 테스트에 영향을 미치므로 경험이 겹칩니다.

동일한 청중/방문자 테스트

다음 사례 연구를 고려하십시오. 전자 상거래 시스템의 두 가지 측면을 평가하려고 하므로 모바일 사용자와 데스크톱 사용자를 위한 두 가지 A/B 테스트를 개발합니다.

"장바구니에 추가" 버튼을 파란색 대신 빨간색으로 설정하면 클릭이 증가하는지 확인하려고 합니다.
더 많은 가입이 있는지 확인하기 위해 단계 수를 5단계에서 2단계로 줄이는 새로운 결제 프로세스를 시도하고 있습니다.

두 작업 모두 동일한 성공 이벤트(거래 완료)로 이어지는 경우 빨간색 버튼 또는 더 나은 결제 환경이 데스크톱 및 모바일 장치에서 전환을 높였는지 판단하기 어려울 수 있습니다.

결과 중복 및 기타 경험 전달 문제를 방지하려면 다른 대상(예: 모바일 전용 또는 데스크톱 전용)에 대해 위의 테스트를 실행해야 합니다.

세분화 테스트의 유일한 단점은 트래픽 수가 낮아 테스트 실행 시간에 영향을 줄 수 있다는 것입니다. 그러나 개인화 기술을 기반으로 하기 때문에 A/B 테스트 시 경험 중복을 피하기 위해 선호되는 방법입니다. 세그먼트를 신중하게 선택하면 전체 경험에 미치는 영향이 최소화됩니다.

다른 경험과 공유되는 목표에 상당한 영향을 미칠 수 있는 경험 실행

여러 테스트에서 목표가 비슷하면 결과가 이 개별 목표를 중심으로 집중될 것이라는 것은 말할 필요도 없습니다. 각 경험이 목적을 달성하기 위해서는 각각의 목표가 서로 충돌하지 않아야 합니다.

성공적인 테스트 실행을 위한 전략

겹치지 않는 테스트를 실행하는 것과 관련하여 만능 솔루션은 없습니다. 실험 여정의 각 단계를 진행하면서 요구 사항에 따라 진행 방법이 결정됩니다.

정보에 입각한 결정을 내리는 데 도움이 되도록 중복을 처리하는 데 사용할 수 있는 가장 일반적인 전략을 살펴보겠습니다.

1. 중복 없는 동시 경험(격리)

가장 간단한 전략은 일반적으로 지금까지 사용해온 전략인 동시에 실행되는 격리된 경험입니다.

위에서 논의한 바와 같이 고립된 경험은 중복되지 않으며 한 경험의 결과는 다른 경험의 결과에 영향을 미치지 않습니다.

다음과 같은 경우에는 이 전략이 필요합니다.

겹침이 기술적으로 불가능한 경우: 위에서 언급한 가능한 겹침 조합을 모두 제외하는 방식으로 테스트하는 경우.
사용자 경험이 깨질 수 있는 경우 : 경험의 일부 조합은 사용자 경험을 망칠 수 있으므로 이러한 경험은 별도로 실행해야 합니다.
주요 목표가 정확한 메트릭이므로 개별 실험만 의미가 있을 때.

이러한 경우 두 개의 다른 목표를 가진 두 개의 다른 페이지에서 두 개의 경험을 동시에 실행하는 경우 한 경험이 다른 경험에 영향을 줄 수 있는 방법은 없습니다. 체험 1에 참가한 방문자는 체험 2에 참가하지 않으며 그 반대의 경우도 마찬가지입니다.

위의 경우 외에도 효율성 측면에서 동시에 격리된 레인에서 경험을 실행하는 것은 의미가 없습니다. 별도의 레인에서 두 개의 경험을 실행하는 것은 주어진 수의 사용자 또는 세션에 대해 차례로 실행하는 것과 같은 시간이 걸립니다. 매달 10,000명의 사용자가 있고 각각 5,000명이 필요한 두 개의 경험을 실행해야 하는 경우 경험을 완료하는 데 한 달이 걸립니다.

게다가 이 전략에는 명백한 단점이 있습니다. 격리된 레인에서 달리는 경험은 의심할 여지 없이 변형 간의 잠재적인 상호 작용을 조사하는 데 방해가 됩니다.

별도의 테스트 레인이 있는 경우 데스크톱 사용자와 모바일 사용자 모두에게 가장 적합한 변형을 제공하기 전에 데스크톱 사용자를 대상으로 실험을 수행하는 것과 같습니다. 모바일 사용자에 대한 영향은 데스크톱 사용자와 동일할 수 있지만 상당한 차이가 있을 수도 있습니다.

2. 비동시적(순차적) 경험

경험 중복을 피할 방법이 없다면 순차적 경험 사용을 고려해야 합니다. 즉, 다른 경험과 겹칠 가능성이 있는 각 경험을 순차적으로 실행해야 합니다.

변환 열 "시작됨/계획됨" 및 "중지됨"을 사용하여 순차 테스트를 볼 수 있습니다.

이 전략은 우선 순위 지정 로드맵을 통해 훨씬 더 효과적일 수 있습니다.

PIE 및 ICE 프레임워크는 팀 경험의 우선순위를 정하기 위한 두 가지 효과적인 옵션입니다.

PIE 프레임워크(Widerfunnel에서 개발)는 잠재성, 중요도 및 용이성의 세 가지 기준에 따라 테스트의 순위를 매기는 인기 있는 우선 순위 지정 방법입니다. PIE 점수를 사용하여 이러한 각 기준의 평균 점수를 기반으로 각 테스트의 순위를 지정하고 우선 순위를 지정할 수 있습니다.

Impact, Confidence, and Ease(ICE) 모델(Growthhackers의 Sean Ellis가 개발함)은 "잠재력" 대신에 신뢰 요소를 사용한다는 점을 제외하고는 PIE와 매우 유사합니다.

로드맵이 없으면 트래픽과 리소스를 최대한 활용할 수 있는 능력이 제한됩니다.

예를 들어, 차례로 구현해야 하는 홈페이지 아이디어의 백로그가 의도치 않게 누적될 수 있습니다. 이 병목 현상이 지속되면 웹사이트의 다른 부분을 동시에 테스트할 수 없는 대신 게임을 기다리게 될 수 있습니다. 또는 의심스러운 결과를 생성할 가능성이 있는 중첩 효과를 고려하지 않고 여러 테스트를 동시에 실행할 수도 있습니다.

3. 겹침을 통한 동시 체험

당신의 경험을 분석한 후, 당신은 그것들이 중복된다는 결론을 내렸습니다. 따라서 이들을 격리해야 합니다. 어떻게 합니까? 간단 해! 첫 번째 테스트를 실행한 다음 두 번째 테스트를 실행합니다. 맞죠? 순차 섹션에서는 이것이 어떻게 작동하는지 설명합니다.

그러나 어떤 이유에서든 더 많은 방문자를 받고 경험이 더 중요한 영향을 미칠 수 있기 때문에 크리스마스 기간이나 휴가철에 몇 가지 테스트를 수행하려고 한다고 상상해 보십시오. 그리고 뭐? 모든 경험을 차례로 실행할 수 있습니까? 분명히, 아닙니다.

아래 전략을 사용하여 중복에 대한 걱정 없이 동시에 경험을 실행할 수 있습니다.

ㅏ. A/B/N 경험

이 범주의 첫 번째 전략은 A/B/N 테스트로, 한 번에 두 가지 이상의 변형을 테스트합니다. A/B/N은 세 번째 변형이 아니라 A/B/C, A/B/C/D 및 기타 확장된 A/B 테스트와 같은 추가 변형을 나타냅니다.

A/B/n 경험 컨버전 비주얼 에디터 — Convert의 Visual Editor에서 A/B/N 경험

A/B/N 테스트의 원칙은 추가 변형의 수에 관계없이 동일하게 유지됩니다. 사용자를 그룹으로 나누고, 변형(일반적으로 방문 페이지 또는 기타 웹페이지의 변형)을 그룹에 할당하고, 주요 측정항목의 변경(일반적으로 전환율)을 모니터링합니다. ), 통계적 유의성에 대한 경험 결과를 조사하고, 승리한 변형을 배포합니다.

그러나 너무 많은 변형을 실험하면(하나만 선택할 수 있는 경우) 웹사이트에 대한 트래픽이 더 분할될 수 있습니다. 따라서 통계적으로 유의미한 결과를 얻고 "통계 잡음"을 생성하는 데 필요한 시간과 트래픽의 양을 늘릴 수 있습니다.

여러 A/B/N 실험을 실행할 때 큰 그림을 놓치지 않는 것도 중요합니다. 서로 다른 변수가 함께 잘 작동한다는 보장은 없습니다. 단지 실험에서 가장 잘 수행되었기 때문입니다.

이러한 경우 다변수 테스트를 수행하여 모든 변형을 테스트하고 개선 사항이 최상위 메트릭까지 전달되는지 확인하십시오.

비. 다변수 경험(MVT): 단일 테스트에서 많은 경험 결합

다변수 경험(MVT)은 한 번에 다양한 변경 사항의 수많은 조합을 실행합니다.

모든 잠재적인 조합 중 어떤 요소가 목표에 가장 큰 영향을 미치는지 결정하려면 동일한 페이지에서 많은 요소를 동시에 수정해야 합니다.

A/B/N 테스트와 달리 다변수 테스트를 사용하면 방문자의 요구에 가장 적합한 변경 조합을 결정할 수 있습니다. 다변수 테스트를 사용하면 여러 변수가 변경될 때 어떤 변수 조합이 가장 잘 수행되는지 결정할 수 있습니다.

예를 들어 페이지에서 두 개의 다른 헤드라인, 두 개의 이미지, 두 개의 버튼 색상을 테스트하려는 경우 MVT 테스트는 다음과 같습니다.

위의 MVT 테스트는 여러 요소(헤드라인, 색상 및 이미지)를 동시에 다른 조합으로 테스트합니다.

변환 경험에서 MVT를 설정하는 방법

먼저 변환 계정의 경험 탭에서 "새 경험"을 선택합니다.

이제 경험의 이름을 지정할 수 있습니다. "My first MVT"를 사용하고 다변수 옵션을 선택하고 계속을 클릭해 보겠습니다.

MVT에는 섹션과 변형이 있습니다. 섹션은 하나 이상의 유사 콘텐츠를 테스트하려는 페이지의 위치입니다.

다음은 섹션의 예입니다.

심벌 마크
표제
첫 번째 단락
옵트인 양식

다음과 같이 구성된 변형도 있습니다(이 섹션에 있음).

섹션: 로고
- 원래 로고
- 변형 1) 로고 왼쪽
- 변형 2) 로고 오른쪽

섹션: 헤드라인
- 원본 헤드라인
- 변형 1) 제목 "지금 내 친구 검색"
- 대안 2) 제목 '검색해 보세요'
섹션: 첫 번째 단락
- 원본 첫 번째 단락
- 변형 1) 첫 번째 단락 "빨간색"
- 변형 2) 첫 번째 단락 "파란색"
섹션: 옵트인 양식
- 원래 옵트인 양식
- 변형 1) 추가 필드 성이 포함된 옵트인 양식
- 변형 2) "백서" 확인란이 있는 옵트인 양식
- 변형 3) 왼쪽에 떠 있는 옵트인 양식
- 변형 4) 선택 양식 "여자 얼굴"

다음은 위의 구조가 Visual Editor 변환에 나타나는 방식입니다.

테스트하려는 페이지의 URL이 Visual Editor에 로드됩니다. 그런 다음 첫 번째 변형을 편집할 수 있습니다. 내용을 변경하는 것은 주황색으로 강조 표시된 영역을 클릭하는 것만큼 간단합니다. 변형 이름 옆에 있는 녹색 더하기 기호를 클릭하여 새 변형을 추가할 수 있습니다.

예를 들어 다음을 수행할 수 있습니다.

변경할 요소를 클릭하십시오(요소는 주황색 테두리로 강조 표시됨).
이미지 소스 변경과 같은 메뉴에서 작업 선택

Convert Experiences Visual Editor에서 이미지 소스 변경

MVT 경험 요약은 다음과 같습니다.

그러나 MVT에는 몇 가지 제한 사항이 있습니다.

첫 번째 제한은 다변수 경험의 결과를 통계적으로 유의미하게 만드는 데 필요한 방문자 수와 관련이 있습니다.

다변량 테스트에서 변수 수를 늘리면 많은 변동이 발생할 수 있습니다. 트래픽의 50%가 원본 버전에 할당되고 50%가 변형에 할당되는 표준 A/B 테스트와 달리 다변수 테스트는 각 조합에 트래픽의 5%, 10% 또는 15%만 할당합니다. 실제로 이는 테스트 기간이 더 길어지고 결정을 내리는 데 필요한 통계적 유의성을 달성할 수 없게 됩니다.

또 다른 제한 사항은 MVT의 복잡성입니다. A/B 테스트는 다변수 테스트보다 설정 및 분석이 더 쉬운 경우가 많습니다. 기본적인 다변수 테스트를 만드는 것조차 시간이 많이 걸리고 무언가 잘못되기가 너무 쉽습니다. 경험 디자인의 사소한 결함이 나타나기까지 몇 주 또는 몇 달이 걸릴 수 있습니다.

여러 웹 사이트에서 다양한 유형의 테스트를 실행하는 테스트 경험이 많지 않은 경우 다변수 테스트를 고려하지 않아야 합니다. 내가 다루고 있는 다음 전략인 상호 배타적인 경험을 하는 것이 더 나을 수도 있습니다.

씨. 상호 배타적 경험

또한 상호 배타적인지 확인하여 겹치는 경험을 동시에 실행할 수도 있습니다. A/B 테스트 플랫폼에 따라 경험을 상호 배타적으로 만들 수 있음을 명심하십시오. 기본적으로 경험이 실행되는 만큼 트래픽을 그룹으로 나누고 각 그룹이 하나의 경험에만 참여하도록 해야 합니다.

변환은 상호 배타성을 허용하며 아래에서 경험 A를 보는 방문자가 경험 B를 보지 않도록 구성하는 방법을 보여줍니다.

경험이 실행되는 순서:

이를 설정하는 첫 번째 단계는 변환 경험이 실행되는 방식을 이해하는 것입니다. 경험 조건은 경험 ID를 고려하여 페이지에서 순차적으로 평가됩니다.

ID가 가장 낮은 경험이 먼저 평가되고 모든 조건이 충족된 후 새로운 경험이 시작됩니다. 따라서 아래 스크린샷에서 ID가 100243925인 경험이 먼저 실행되고 나머지가 뒤따릅니다.

두 가지 상호 배타적 경험

두 개의 경험이 동시에 실행되고 있으며 상호 배타적으로 만들려면 다음 단계를 따라야 합니다.

첫 번째 경험에서 트래픽 분포를 100% 미만으로 설정

트래픽의 100% 미만을 사용하도록 ID가 가장 낮은 환경을 설정합니다. 경험 요약의 트래픽 분포 섹션에서 이 작업을 수행할 수 있습니다.

트래픽 분포가 100% 미만인 Convert Experiences에서 두 개의 상호 배타적인 경험 설정

두 번째 경험에서 "Bucket in Experience is No"의 대상 조건 설정

그런 다음 두 번째 경험에서 대상 조건을 "Bucket in Experience is No"로 설정합니다. 방문자 데이터 아래에서 새 잠재고객을 추가하면 찾을 수 있습니다. 이 조건은 방문자가 이전에 검사를 받지 않은 경우에만 검사를 받게 됨을 의미합니다. 이렇게 하면 동일한 방문자가 두 번 테스트되는 것을 방지할 수 있습니다.