클라이언트에 상관없이 통하는 A/B 테스트 프레임워크: 모든 계정에 적용되는 7단계

요약

에이전시는 단일 제품 팀보다 더 가혹한 제약 속에서 A/B 테스트를 실행합니다. 여러 클라이언트, 촉박한 마감, 분산된 지표가 바로 그것입니다. 이 글에서는 모든 계정에 적용할 수 있는 반복 가능한 프레임워크를 제시합니다. 진정한 전환 목표 하나를 정의하는 것부터 시작하세요. 이해관계자의 의견을 쫓는 대신 마찰 지점을 찾는 방법, 예측 가능한 가설을 작성하는 방법, 단일 변수, 다변량, AI 기반 실험 중에서 선택하는 방법을 배우게 됩니다. 또한 실용적인 표본 크기 계획, 클라이언트가 테스트를 조기에 중단하지 않도록 하는 방법, 컨설턴트처럼 애매한 결과를 해석하는 방법을 다룹니다. 마지막 단계는 모든 성공과 실패를 플레이북으로 정리하여 다음 클라이언트의 테스트 주기를 더 빠르게 만드는 것입니다. 이 구조를 사용하면 낭비되는 주를 줄이고 테스트를 에이전시의 경쟁 우위로 전환할 수 있습니다. 테스트를 일회성 요청의 연속이 아닌 시스템으로 취급하면 모든 계정에서 바퀴를 재발명하지 않게 됩니다.

월요일 오전 9시 47분. 클라이언트가 가격 페이지에 대한 "빠른 A/B 테스트"를 요청하는 이메일을 보냅니다. 현재 진행 중인 다른 계정이 세 개나 있고, 각각 다른 애널리틱스 설정, 다른 승인 체계, 다른 "승리" 정의를 가지고 있습니다. 빠른 테스트는 통계적 유의성에 도달하는 데 3주가 걸릴 것입니다. 당신은 이미 이것을 알고 있습니다. 그래서 일정을 늘리고 기대치를 설정한 후 테스트를 실행합니다. 그러고 나서 한 주의 절반을 그것을 방어하는 데 보냅니다.

이것은 테스트 문제가 아닙니다. 시스템 문제입니다. 매 클라이언트마다 테스트 방법을 재발명해야 한다면, 당신은 최적화 파트너가 아니라 테스트 실행자입니다. 다음에 이어지는 내용은 어떤 클라이언트, 어떤 도구, 어떤 트래픽 수준에서도 작동하는 7단계 프레임워크입니다. 이를 사용하여 계정마다 누적되는 더 빠르고 더 똑똑한 테스트 주기를 얻으세요.

1. 변수를 건드리기 전에 성공 지표를 고정하세요

Optimizely 용어집에 정의된 A/B 테스트는 청중을 무작위로 분할하고 각 그룹에 다른 버전의 페이지를 보여줍니다. 이 무작위 분할은 데이터를 생성합니다. 그러나 무엇을 측정하는지 알지 못하면 데이터는 의미가 없습니다. 대부분의 클라이언트는 "더 많은 전환"을 원한다고 말하지만, 전환은 가입, 구매, 데모 요청, 또는 푸터까지 스크롤하는 것일 수도 있습니다. 하나의 지표를 고정하지 않으면, 가져오는 모든 결과는 재해석의 여지가 있습니다.

모든 업무를 15분 목표 감사로 시작하세요. 클라이언트에게 "어떤 단일 행동이 두 배가 된다면 이번 분기가 성공할까요?"라고 물어보세요. 그 답을 주요 지표로 전환하세요. 테스트의 성공 기준으로 사용하세요. 다른 모든 것(이탈률, 페이지 체류 시간, 보조 클릭)은 가드레일 지표로 보고 최적화하지 않습니다.

무자비하게 구체적으로 하세요. 클라이언트가 "리드"라고 말하면 리드가 무엇인지 정의하세요. 리드는 양식 제출일 수도 있지만, 전화 통화, 라이브 채팅, 다운로드일 수도 있습니다. 각 정의는 어떤 페이지 요소를 테스트해야 하는지 바꿉니다. 양식 제출 목표는 양식 길이와 마찰을 가리킵니다. 전화 통화 목표는 클릭투콜 배치와 신뢰 신호에 관한 최적화가 됩니다. 시작 시점에 이에 대해 합의하지 않으면 잘못된 페이지를 최적화하게 됩니다.

작업 예: B2B 클라이언트가 "더 많은 리드"를 원합니다. 리드가 무엇인지 묻습니다. "적격 잠재 고객"이라고 말합니다. 그건 추적할 수 없습니다. "비즈니스 이메일 주소가 포함된 양식 제출"로 좁힙니다. 이제 주요 지표가 생겼습니다. 나중에 새로운 히어로 헤드라인을 테스트할 때, 그 지표만으로 판단합니다. 더 나은 이탈률을 근거로 승리를 선언하려는 시도도 잡아낼 수 있습니다. 그 명확성은 수 시간의 논쟁을 아껴줍니다.

주요 지표를 정한 후 테스트 브리프에 기록하세요. 브리프는 한 문장으로 "이 테스트는 [지표]로 판단됩니다."라고 말해야 합니다. 모든 이해관계자와 공유하세요. 나중에 부사장이 "글쎄, 참여도는 개선됐잖아"라고 제안하면 브리프를 가리키세요. 골대를 옮긴 것이 아닙니다. 합의한 것입니다.

이것이 신호와 노이즈를 분리하는 지점이기도 합니다. 어떤 테스트가 가장 중요한지 아는 것이 싸움의 절반입니다. 수익을 움직일 가능성이 가장 높은 테스트에 예산을 쓰는 것이 에이전시를 효율적으로 만드는 방법입니다.

2. 선호도가 아닌 마찰을 찾으세요

클라이언트는 "실행하고 싶은 테스트" 목록을 건네겠지만, 그것은 사실 의견입니다. "버튼은 초록색이어야 해요." "헤드라인은 우리 수상 경력을 언급해야 해요." 당신은 그런 테스트를 실행하지 않습니다. 마찰을 줄이거나 신뢰를 높이는 테스트를 실행합니다. CRO 플레이북은 모두 같은 레버를 가리킵니다: 클릭 유도 문구의 명확성, 양식 길이, 레이아웃 명확성, 사회적 증거, 신뢰 신호.

클라이언트 사용자가 이탈하는 지점을 살펴봄으로써 이러한 레버를 찾으세요. 세션 녹화나 기본 이벤트 추적을 아직 설정하지 않았다면 설정하세요. 클라이언트당 실제 사용자 세션을 최소 5개 시청하세요. "사용자가 좋아할 것"이라는 클라이언트의 의견에 의존하지 마세요. 데이터가 의견을 이깁니다.

감사할 일반적인 마찰 원인:

• 너무 많거나 너무 적은 정보를 요구하는 양식
• 다음 행동을 명확히 말하지 않는 CTA (예: "자세히 알아보기" vs. "무료 체험 시작")
• 약속 지점 근처에 없는 신뢰 단서 (후기, 보증, 환불 보장)
• 모바일에서 느리게 로드되는 페이지
• 예상치 못한 추가 단계가 있는 여정 (예: 경고 없이 "가입" 후 "이메일 확인")

작업 예: 이커머스 클라이언트의 체크아웃에는 6개 필드 양식과 선택적인 "계정 만들기" 체크박스가 있습니다. 세션 녹화를 설정하고 다섯 명의 사용자를 시청합니다. 두 명은 할인 코드가 적용될 것이라고 생각해 미리 채워진 쿠폰 코드를 삭제하려고 합니다. 한 명은 전화번호 필드에서 이탈합니다. 마찰은 양식 길이가 아니라 혼란스러운 쿠폰 필드입니다. 테스트는 버튼을 더 크게 만드는 것이 아닙니다. 쿠폰 필드를 최종 검토 단계로 옮깁니다. 이것은 의견이 아닌 관찰에서 탄생한 테스트입니다.

여러 클라이언트에 걸쳐 이를 수행하려면 공유 마찰 로그를 구축하세요. 한 클라이언트 사이트에서 사용자가 막힐 때마다 패턴을 기록하세요. 3주 후 다른 클라이언트 사이트에서 동일한 마찰이 나타나는 것을 볼 수 있습니다. 그것이 에이전시의 개인 연구 라이브러리입니다. 또한 새 클라이언트에게 강력한 제안이 됩니다: "우리는 귀하의 시장 세그먼트에서 이 정확한 문제를 본 적이 있습니다."

사이트 내 행동에만 그치지 마세요. 이탈 경로, 히트맵, 양식 필드 애널리틱스를 살펴보세요. 목표는 사용자가 이탈하는 명확한 지점 하나를 찾는 것입니다. 그 지점이 테스트 변수입니다. 명확한 이탈 지점을 찾을 수 없다면 진단 테스트를 실행하세요: 완전히 다른 CTA, 훨씬 짧은 양식, 또는 근본적으로 다른 가치 제안을 시도하세요. 결과가 무효(null)라도 청중의 진짜 저항 지점을 알려줍니다.

마찰 로그를 최신 상태로 유지하세요. 반복되는 패턴을 발견하면 스크린샷과 한 줄 설명과 함께 로그에 기록하세요. 몇 달 후에는 서비스를 제공하는 모든 클라이언트에 적용되는 사용자 반대 목록이 생깁니다. 그 목록은 판매 포인트입니다: "우리는 귀하의 업계에서 이 정확한 반대를 이미 테스트했습니다. 우리가 배운 것은 다음과 같습니다."

3. 무엇이 아닌 이유를 예측하는 가설을 작성하세요

좋은 테스트는 질문에 답합니다: "우리가 X를 하면, Y가 일어날 것이다. 왜냐하면 Z이기 때문이다." "왜냐하면 Z"가 가설이며, 그것이 결과를 다른 곳에 적용할 수 있게 만듭니다. "이유" 없이 승리한 테스트는 다음 클라이언트에 대해 아무것도 알려주지 않습니다.

모든 테스트를 "만약... 그렇다면... 왜냐하면..." 구조로 공식화하세요. 이는 메커니즘에 대해 생각하게 만듭니다. "양식을 5개 필드에서 3개로 줄인다"는 "양식을 줄이면 완료율이 올라갈 것이다, 왜냐하면 사용자가 노력이 더 적다고 인지하기 때문이다"가 됩니다. 이제 이유를 알게 됩니다. 이 규칙을 긴 양식이 있는 모든 클라이언트에 적용할 수 있습니다.

이제 주의사항이 있습니다. 일반적인 모범 사례는 한 번에 하나의 변수만 테스트하라는 것입니다. 이 규칙은 타당한 이유로 존재합니다: 고립된 변수는 깔끔한 인과적 설명을 제공합니다. 그러나 에이전시가 20개의 개별 단변량 테스트를 실행할 트래픽이나 시간이 있는 경우는 드뭅니다. 트래픽이 적은 계정의 경우 트레이드오프가 필요합니다. 세 가지 옵션이 있습니다.

접근 방식	가장 적합한 경우	트레이드오프
단변량 테스트	트래픽이 많은 페이지, 단일 가설, 시간 여유	가장 깔끔한 인과 스토리, 느림
다변량 테스트	중간 트래픽, 여러 개의 독립 변수	더 빠르지만 교란된 상호작용
AI 기반 실험	낮은 트래픽, 촉박한 마감, 기계가 적응하길 원할 때	새로운 도구, 변형에 대한 통제력 감소

세 번째 옵션은 진지하게 고려할 가치가 있습니다. Optimizely의 AI 실험 설명은 트래픽을 동적으로 할당하고 변형을 생성하는 머신러닝 시스템을 설명합니다. 고정된 분할을 설정하고 기다리는 대신, 시스템은 어떤 변형이 이기고 있는지 학습하고 실시간으로 트래픽을 이동시킵니다. 이렇게 하면 2주 테스트를 며칠로 압축할 수 있습니다 — 약간의 방법론적 순수성을 희생하면서 말이죠. 마감에 쫓기는 에이전시에게는 종종 지불할 만한 비용입니다.

클라이언트에게 어떤 방법이 맞는지 확신이 없나요? 클래식 A/B 테스트와 AI 실험 간의 트레이드오프를 결정하기 전에 이해하는 것이 좋습니다.

결정 방법은 다음과 같습니다: 클라이언트에게 트래픽이 많고 일정이 여유 있다면 단변량 테스트를 사용하세요. 중간 트래픽과 여러 후보 변경 사항이 있다면 가장 유망한 조합으로 다변량 테스트를 실행하세요. 트래픽이 적고 마감이 확실하다면 인플라이트 중 적응할 수 있는 AI 기반 실험을 선택하세요. "진짜 과학"에 대한 선호가 클라이언트의 비즈니스 제약을 보지 못하게 하지 마세요. 올바른 테스트는 예산이 사라지기 전에 실행할 수 있는 결정을 만들어내는 테스트입니다. 클라이언트의 캠페인이 끝난 후에 완료되는 완벽한 검정력의 테스트는 가치가 없습니다.

작업 예: 지역 서비스 클라이언트의 일일 트래픽이 적습니다. 단변량 테스트를 직접 실행하면 의미 있는 차이를 감지하는 데 몇 달이 걸립니다. 가설을 작성한 후 트래픽을 동적으로 할당하는 AI 실험을 사용합니다. 며칠 후 시스템이 한 변형이 앞서가고 있음을 보여주고 더 많은 트래픽을 그쪽으로 보냅니다. 클라이언트의 캠페인 기간 내에 답을 얻습니다. 결과가 6주 클래식 테스트보다 통계적으로 덜 깨끗하다는 것을 받아들입니다. 그것은 타협이 아니라 합리적인 거래입니다.

또한 "한 번에 하나의 변수" 규칙은 단일 버튼이 아닌 급진적인 새 페이지 섹션을 테스트한다면 완화될 수 있습니다. 전체 페이지 리디자인 테스트는 여러 요소를 변경할 수 있지만 가설은 여전히 일관됩니다: "혜택 우선 카피를 중심으로 구축된 레이아웃은 현재 기능 목록 레이아웃보다 더 나은 성과를 낼 것입니다, 왜냐하면 사용자는 결과에 기반해 선택하기 때문입니다." 가설이 메커니즘을 명명하는 한 변경 묶음을 테스트할 수 있습니다. 어떤 요소가 상승을 일으켰는지 알 수 없다는 점은 클라이언트에게 정직하게 말하세요.

4. 통계 교과서가 아닌 클라이언트의 일정에 맞춰 테스트 규모를 정하세요

통계적 유의성은 21일째에 잠금 해제되는 마법의 숫자가 아닙니다. 기준 전환율, 보고 싶은 최소 상승률, 테스트에 라우팅할 수 있는 트래픽량에 따라 달라집니다. 이 분야의 모든 테스트 가이드는 같은 경고를 반복합니다: 충분한 표본 크기와 기간에 도달할 때까지 테스트를 실행하거나, 결론은 노이즈입니다.

테스트를 예약하기 전에 평범한 언어로 계산을 하세요. 클라이언트의 현재 전환율과 신경 쓰는 가장 작은 개선을 추정하세요. 그런 다음 합리적인 신뢰 수준에 필요한 방문자 수를 추정하세요. 그 숫자가 클라이언트의 분기 검토 때까지 도달하지 못할 경우 세 가지 선택이 있습니다: 분할을 넓혀 더 많은 사람을 테스트에 보내거나, 트래픽이 지원할 수 있는 더 큰 최소 감지 효과를 수용하거나, 테스트를 "승자"를 약속하지 않는 학습 실험으로 전환하세요.

박사 학위는 필요 없습니다. 표본 크기 계산기를 사용하세요. 기준율, 감지하려는 효과, 원하는 신뢰도를 입력하세요. 도구가 변형당 필요한 방문자 수를 알려줍니다. 그런 다음 클라이언트의 예상 테스트 일일 트래픽으로 나누어 필요한 실행 시간을 얻습니다. 그 실행 시간이 클라이언트의 마감에 맞지 않으면 테스트를 시작하기 전에 입력값 중 하나를 조정하세요. 그 대화는 낭비되는 3주 주기보다 훨씬 저렴합니다.

작업 예: SaaS 클라이언트의 무료 체험 가입 페이지는 적당하지만 꾸준한 방문자 흐름을 받습니다. 의미 있는 개선을 감지하고 싶고, 표본 크기 추정에 따르면 테스트에 클라이언트가 주어진 시간에 제공할 수 있는 것보다 훨씬 많은 방문자가 필요한 것으로 나옵니다. 클라이언트는 이사회 회의를 위해 6주 안에 답이 필요합니다. 그래서 분할을 50/50에서 90/10으로 넓힙니다 — 하지만 그래도 충분하지 않습니다. 대신, 큰 성과만 잡기 위해 최소 감지 효과를 낮춥니다. 이제 테스트가 기간 내에 실행 가능해지고, 테스트가 무엇을 잡을 수 있고 무엇을 잡을 수 없는지 클라이언트에게 정확히 말했습니다. 그것이 전문가의 움직임입니다.

또한 중지 규칙이 필요합니다. 테스트가 얼마나 오래 실행될지와 어떤 유의성 임계값을 사용할지 미리 결정하세요. 캘린더 날짜가 유일한 중지 이유가 되어서는 안 됩니다. 실험을 조기에 중단해야 하는 시기 또는 연장해야 하는 시기를 아세요 — 임의의 금요일이 아니라 당신의 판단이 결정해야 합니다.

5. 클라이언트가 테스트를 조기에 중단하지 못하게 하세요

여기 당신이 겪어본 장면이 있습니다: 화요일, 클라이언트가 메시지를 보냅니다. "테스트가 오늘 아침에 올라왔네요. 지금 승자를 배포합시다." 앞서는 변형이 하나 있지만, 아직 필요한 표본 크기에 도달하지 못했습니다. 클라이언트는 승리를 봅니다. 당신은 노이즈를 봅니다. 이것이 에이전시 테스트가 실패하는 가장 흔한 이유입니다 — 잘못된 수학이 아니라 잘못된 이해관계자 관리입니다.

테스트 시작 전에 기본 규칙을 설정하세요. 한 페이지 테스트 브리프를 보내세요: 주요 지표, 계획된 표본 크기, 결과를 처음 볼 수 있는 가장 이른 날짜, 실행 중 변경할 수 있는 것. 클라이언트의 서명을 받으세요. 클라이언트가 훔쳐볼 때, 그것은 개인적인 거절이 아니라 기대 위반임을 지적할 수 있습니다. 이는 적대적이 되는 것이 아니라 실험의 무결성을 보호하는 것입니다.

또한 테스트 환경을 보호하세요. 테스트가 실행되는 동안 다른 사이트 변경이 배포되어서는 안 된다고 클라이언트에게 말하세요. 테스트 페이지에 중단을 알리는 배너, 다른 벤더의 막판 디자인 변경, 심지어 소셜 미디어 급증도 데이터를 오염시킬 수 있습니다. 테스트 외부에서 무언가 변경되는 순간 판독값은 의심스럽습니다.

작업 예: 클라이언트의 개발자가 테스트 중간에 새 파비콘을 푸시합니다. 중요하지 않을 수 있지만, 그래서도 안 됩니다. 기록하고 타임스탬프를 남긴 후 그 시점 이후 결과가 바뀌는지 확인합니다. 바뀌면 테스트를 다시 시작합니다. 클라이언트는 이것이 얼마나 취약한지 이해하지 못하는 경우가 많습니다. 테스트 브리프에서 이를 명시하여 심각하게 받아들이도록 하는 것이 당신의 일입니다.

또 다른 흔한 클라이언트의 움직임은 "금요일에 캠페인을 시작해야 하니 테스트를 일찍 끝낼 수 있나요?"입니다. 캠페인이 테스트 자체를 방해하지 않는 한 저항하세요. 일찍 끝내면 잘못된 결정을 내릴 위험이 있습니다. 대신 캠페인을 약간 연기하거나 테스트를 캠페인의 영향을 받지 않는 페이지로 옮길 수 있는지 확인하세요. 테스트 브리프가 협상 도구입니다. 정중하지만 단호하게 거절하는 데 사용하세요.

한 가지 더 습관: 기술적 실패를 찾는 것이 아닌 한 테스트 중에 결과를 절대 확인하지 마세요. 인간의 뇌는 확률에 끔찍합니다. 좋은 날들이 연속되면 증거처럼 느껴지지만, 종종 노이즈일 뿐입니다. 훔쳐보고 싶다면 표본 크기 계산기를 여세요. 아직 얼마나 많은 데이터가 없는지 스스로 상기시키세요.

6. 결과를 판결이 아닌 이야기로 읽으세요

테스트가 끝납니다. 변형이 또 이깁니다. 그러나 "어떤 버튼이 이겼는지"는 당신이 배운 것 중 가장 덜 유용한 것입니다. 유용한 질문은: 왜 이겼는가? 그 설명이 다른 페이지에도 적용되는가? 이 청중에 대해 이전에 몰랐던 것을 무엇을 발견했는가?

이것이 대부분의 에이전시가 멈추는 지점입니다. 승리한 변형을 배포하고 클라이언트에게 PDF를 보낸 후 넘어갑니다. 그것은 놓친 기회입니다. 변형이 대조군을 이기지 못한 무효 결과도 여전히 결과입니다. 청중이 그 변수에 관심이 없거나 원본이 이미 충분히 좋았다는 것을 알려줍니다. 그 학습을 문서화하고 다음 테스트에 적용하세요. 모범 사례 가이드는 모든 실험 후 학습을 문서화하는 것을 일관되게 강조합니다. 그것이 테스트를 일회성의 연속에서 복리 자산으로 바꿉니다.

작업 예: 사진이 있는 추천사와 일반 인용문을 테스트합니다. 일반 인용문이 이깁니다. 이유를 파고듭니다. 이미지가 연출된 것처럼 보입니다. 클라이언트의 청중은 회의적입니다. 교훈은 "추천사는 효과가 없다"가 아니라 "이 청중은 세련된 사진이 아닌 진정성 있고 귀속되지 않은 증거를 원한다"입니다. 다음 달, 다른 클라이언트가 사회적 증거에 대해 묻습니다. 무엇을 보여주지 말아야 할지 이미 알고 있습니다. 그것이 결과를 이야기처럼 읽는 ROI입니다.

결과 해석은 단순히 p-값을 확인하는 것이 아닙니다. 방향, 크기, 세그먼트 차이를 살펴보는 것입니다. 보이는 것을 신뢰할지 확실하지 않다면 기본을 다시 방문하세요. 노이즈에 속지 않고 A/B 테스트 결과를 올바르게 해석하는 방법에 대한 가이드가 정직함을 유지하게 해줄 것입니다.

또한 "그래서 뭐?" 테스트를 고려하세요. 지표를 클라이언트의 언어로 번역하세요. 작은 기준선에서의 큰 상대적 상승은 거의 수익으로 이어지지 않을 수 있는 반면, 트래픽이 많은 페이지에서의 작은 상승은 엄청난 이득을 의미할 수 있습니다. 상대적 변화가 절대적 가치를 보지 못하게 하지 마세요. 클라이언트는 신뢰 구간이 아니라 맨 아래 숫자에 관심이 있습니다.

무효 결과를 발표할 때 사과하지 마세요. 데이터 포인트로 프레임하세요. "우리는 이 청중에게 헤드라인 길이가 전환을 움직이지 않는다는 것을 배웠습니다. 이는 우리가 이 테스트를 다시 실행하지 않아도 된다는 것을 의미합니다." 무효 결과는 질문에 대한 깔끔한 답입니다. 실패가 아닙니다.

7. 모든 결과를 반복 가능한 규칙으로 전환하세요

이제 마지막 단계이며, 테스트를 실행하는 에이전시와 테스트에 베팅하는 에이전시를 구분하는 단계입니다. 모든 테스트 후 한 페이지 플레이북 항목을 작성하세요. 일관된 형식으로: 클라이언트 유형, 가설, 결과, 권장 사항. 모두가 검색할 수 있는 곳에 저장하세요. 그런 다음 새 테스트를 실행하기 전에 플레이북에서 유사한 상황을 검색하세요. 종종 곧 다시 배우게 될 것을 이미 배웠다는 것을 발견하게 될 것입니다.

이것이 테스트가 에이전시의 경쟁 우위가 되는 방법입니다. 클라이언트 A의 "쿠폰 필드가 혼란스럽다"는 발견은 클라이언트 B의 체크아웃에 대해 동일한 결함 있는 테스트를 설계하는 것을 막아줍니다. 클라이언트 C의 "추천사는 지표를 움직이지 않는다"는 정보는 다른 것을 테스트할 자유를 줍니다. 플레이북은 보고서가 아니라 실제로 판매하는 자산입니다.

플레이북 항목 체크리스트:

• 클라이언트 업계 및 사이트 유형
• 테스트 페이지 및 테스트된 변수
• "만약... 그렇다면... 왜냐하면..." 형태의 가설
• 주요 지표 결과: 승리, 패배 또는 무효
• 결정한 "이유" 설명
• 새 클라이언트에 복제할 하나의 행동
• 다시 시도하지 않을 하나의 행동

작업 예: 피트니스 앱 클라이언트가 단일 이메일 필드가 있는 무료 체험 양식과 이름+이메일 양식을 테스트합니다. 단일 필드 버전이 작지만 일관된 승리를 얻습니다. 플레이북 항목을 작성합니다: "충동 기반 청중(피트니스, 음식)의 경우 초기 필수 필드를 최소화하고 개인 정보는 나중에 수집하세요." 6주 후, 밀키트 클라이언트가 긴 가입 양식에 대해 묻습니다. 플레이북 항목을 꺼내 동일한 축소를 권장하고 이미 가능한 결과를 알고 있으므로 확신을 가지고 테스트를 실행합니다. 이것이 복리 효과입니다.

마지막으로 팀과 함께 월간 "학습 검토"를 개최하세요. 모든 클라이언트에서 배운 것을 검토하세요. 동일한 기본 원칙을 가리키는 항목을 결합하세요. 그 원칙을 향후 테스트 지침으로 전환하세요. 예를 들어, 두 명의 다른 클라이언트가 단일 필드 양식에서 더 높은 전환을 보았다면 "약속 전까지 최소한의 정보를 요청하라"는 원칙은 아마도 그들의 세그먼트 전반에 걸쳐 사실일 것입니다. 그 원칙은 이제 테스트를 실행하기 전에도 모든 새 클라이언트의 랜딩 페이지 권장 사항에 영향을 줍니다.

프레임워크는 효과가 있습니다. 그러나 시스템을 실제로 구축해야만 효과가 있습니다. 한 클라이언트로 시작하세요. 일곱 단계를 모두 적용하세요. 그런 다음 다음 클라이언트에 적용하고 플레이북이 점점 더 많은 작업을 하게 하세요. "무엇을 테스트해야 할까?"라고 묻는 대신 "여기 어떤 알려진 규칙이 적용될까?"라고 묻기 시작할 것입니다. 그것이 테스트를 실행하는 에이전시와 더 나은 결과를 제공하는 에이전시의 차이입니다.