클라이언트 측 테스트

클라이언트 측 테스트는 원본 페이지를 브라우저에 전달하고 JavaScript 라이브러리를 사용하여 해당 페이지를 수정하여 변형 페이지를 생성하는 실험 방식입니다. 테스트 도구는 방문자에게 어떤 변형 페이지를 보여줄지 결정하고, 문서에 해당 변경 사항을 적용한 후, 그 결과를 기록합니다. 변경 사항이 애플리케이션이 아닌 브라우저에서 이루어지기 때문에 애플리케이션 코드를 배포하지 않고도 테스트를 구축하고 실행할 수 있으며, 이러한 이유로 상용 최적화 도구에서 이 방식이 주로 사용됩니다.

속도 우위가 바로 이 도구가 인기 있는 이유입니다. 마케팅 또는 최적화 팀은 엔지니어링 백로그에 영향을 주지 않고 시각 편집기를 사용하여 몇 시간 만에 테스트를 구축하고 품질을 보증하고 출시할 수 있습니다. 카피, 레이아웃, 제안 및 시각적 계층 구조에 대한 실험을 지속적으로 실행해야 하는 프로그램의 경우, 이러한 자율성이 의미 있는 실험 속도를 가능하게 하는 핵심 요소입니다. 성공적인 테스트 습관을 구축하는 대부분의 조직은 이 도구에서 시작합니다. 왜냐하면 대안은 그 가치가 입증되기 전에 정당화하기 어려운 엔지니어링 투자를 필요로 하기 때문입니다.

장단점은 이미 잘 알려져 있습니다. 변형된 콘텐츠는 원본 렌더링 후에 적용되므로, 테스트 스크립트가 렌더링을 차단하지 않는 한 방문자는 변경 사항이 나타나기 전에 잠시 원본 콘텐츠를 보게 되는데, 이를 깜빡임 또는 번쩍임 현상이라고 합니다. 깜빡임 현상을 방지하기 위해 렌더링을 차단하면 대조군 방문자를 포함하여 모든 페이지 로드에 지연 시간이 추가됩니다. 광고 차단기와 개인 정보 보호에 초점을 맞춘 브라우저 설정으로 인해 일부 사용자는 스크립트가 실행되지 않을 수 있으며, 이러한 사용자는 무작위로 추출된 것이 아닙니다. 속도가 느린 기기와 불안정한 인터넷 연결은 이러한 모든 영향을 증폭시켜 모바일 결과에 심각한 왜곡을 초래합니다.

클라이언트 측 테스트는 구조적으로 변경할 수 있는 범위에 한계가 있습니다. 서버에서 이미 생성된 내용을 재배열하거나 스타일을 변경하거나 다시 작성할 수는 있지만, 서버가 계산하는 내용은 변경할 수 없습니다. 가격 책정 규칙, 검색 관련성, 재고 가용성, 추천 로직, 그리고 응답 생성 전에 평가되는 모든 비즈니스 규칙은 클라이언트 측 테스트의 적용 범위에서 제외됩니다. 브라우저에서 이러한 변경 사항을 시뮬레이션하려는 시도는 실제 기능이 구현되었을 때와는 다르게 동작하는 변형을 생성하는 경향이 있으며, 이는 결국 테스트가 제안된 기능이 아닌 모의 기능에 대한 질문에 답하는 결과를 낳습니다.

클라이언트 측 테스트에서 좋은 결과를 얻으려면 구현 품질이 매우 중요합니다. 테스트 스니펫은 문서 헤드에 동기적으로 로드되어야 하며, 타임아웃 시간을 엄격하게 설정해야 합니다. 화면 깜빡임 방지 메커니즘은 기본값으로 두기보다는 의도적으로 구성해야 하며, 스크립트의 성능 영향은 추측이 아닌 측정을 통해 확인해야 합니다. 또한 모든 테스트는 샘플 비율 불일치 여부를 검사하여 특정 그룹에서 스크립트가 불균형적으로 실패하는 경우를 찾아내야 합니다. 테스트는 개발자 컴퓨터뿐 아니라 실제 기기와 저속 연결 환경에서도 품질 보증되어야 합니다.

이러한 테스트의 품질 보증에는 특정 루틴이 필요합니다. 변형된 버전은 런타임에 적용되는 수정 사항으로만 존재하며 편집기에서는 보이지 않는 방식으로 오류를 발생시킬 수 있기 때문입니다. 대부분의 문제를 잡아내는 체크리스트에는 실제 사용자가 사용하는 브라우저에서 실제 기기로 변형된 버전을 검증하는 것, 페이지 로딩 속도가 느릴 때와 테스트 스크립트가 차단될 때의 동작을 확인하는 것, 동적 콘텐츠 업데이트 및 단일 페이지 탐색 시 변경 사항이 유지되는지 확인하는 것, 다양한 뷰포트 너비에서 테스트하는 것, 그리고 두 변형 모두에서 관련 이벤트 발생 시 추적이 정확히 한 번만 실행되는지 확인하는 것이 포함됩니다. 또한 테스트는 사이트 자체의 릴리스 일정에 맞춰 점검해야 합니다. 기본 마크업을 변경하는 배포는 해당 마크업에 의존하는 변형 버전을 조용히 무효화하여 일부 방문자가 깨진 페이지를 보게 되는 기간이 발생하고 아무도 알림을 받지 못할 수 있기 때문입니다.

제한적인 범위 내에서 사용될 경우, 클라이언트 측 테스트는 대부분의 최적화 프로그램에서 여전히 핵심적인 역할을 합니다. 일반적인 경우 전환율 최적화 참여팀은 대부분의 실험을 이러한 방식으로 진행하고, 논리 계층 관련 질문은 서버 측 구현으로 넘기며, 테스트 스택의 성능 비용을 지속적으로 검토할 것입니다. 웹 성능 테스트 도구가 페이지 로딩 속도를 300밀리초씩 느리게 만들면, 그 도구로 인해 발생하는 전환 손실이 그 도구를 통해 얻을 수 있는 이득보다 훨씬 클 수 있기 때문에, 이러한 도구는 효과가 없습니다.