A/B 테스트를 활용하여 사이트 속도가 비즈니스 측정항목에 미치는 영향을 평가합니다.
지난 몇 년 동안 사이트 속도 성능이 사용자 경험에서 중요한 부분을 차지하며 사이트 속도를 개선하면 전환율과 이탈률 등 다양한 비즈니스 측정항목에 도움이 된다는 점을 잘 알고 있습니다. 이를 뒷받침하기 위해 Cloudflare의 웹사이트 성능이 전환율에 미치는 영향, Deloitte의 Milliseconds Make Millions, eBay.com의 Shopping for Speed 등 여러 기사와 우수사례가 게시되었습니다.
속도에 대한 확신에도 불구하고 많은 기업은 여전히 사이트 속도를 개선하는 작업의 우선순위를 정하는 데 어려움을 겪고 있습니다. 이러한 작업이 사용자와 그 결과 자체 비즈니스에 어떤 영향을 미치는지 정확히 알지 못하기 때문입니다.
데이터가 없으면 사이트 속도 작업을 지연시키고 다른 작업에 집중하기 쉽습니다. 일반적인 시나리오는 회사 내 몇몇 직원이 사이트 속도의 중요성을 인식하되 이를 뒷받침하지 못하고 여러 이해관계자가 이에 따라 투자하도록 설득하는 것입니다.
이 문서에서는 A/B 테스트를 활용하여 사이트 속도가 비즈니스 측정항목에 미치는 영향을 평가하여 보다 효과적인 의사 결정을 내리는 방법을 개략적으로 설명합니다.
1단계: A/B 테스트를 실행할 페이지 선택
페이지 속도가 비즈니스 측정항목과 관련이 있다는 가설을 테스트하는 것이 목적입니다. 편의상 처음에는 분석할 단일 페이지를 식별하도록 제한할 수 있습니다. 향후 작업은 동일한 유형의 여러 페이지로 확장하여 발견 항목을 확인한 다음 사이트의 다른 영역으로 확장할 수 있습니다. 시작 지점에 대한 몇 가지 제안이 이 단계 하단에 제공됩니다. 페이지 선택 프로세스에는 몇 가지 요구사항이 있습니다.
- A/B 테스트는 모바일 사용자의 기기에서만 실행해야 합니다. 전 세계적으로 Google이 지원하는 파트너 사이트는 평균 50%이상(계속 증가)의 트래픽이 모바일에서 발생하고 있지만, 이 수치는 지역 및 카테고리에 따라 크게 증가할 수 있습니다. 휴대기기는 처리 및 메모리 제약과 덜 안정적인 네트워크 때문에 느린 웹사이트에 더 민감합니다. 또한 이동 중 사용 패턴은 속도에 대한 기대치가 더 높다는 것을 의미합니다.
테스트를 위해 선택하는 페이지는 전환 유입경로에서 중요한 부분이어야 합니다. 사이트마다 목적이 다르기 때문에 추적하는 성공 측정항목이 다릅니다. 이러한 측정항목은 일반적으로 유입경로를 사용하여 분석되는 사용자 여정과 관련이 있습니다 예를 들어 전자상거래 웹사이트 사용자가 구매를 완료하려면 홈페이지, 카테고리 페이지, 제품 페이지, 결제 페이지를 탐색해야 합니다. 전환을 기준으로 최적화하는 경우 이 페이지 중 하나를 사용하는 것이 좋습니다.
페이지의 목적은 한 가지여야 합니다. 사이트에 매우 구체적인 임무가 없다면 일반적으로 테스트에 홈페이지를 사용하지 않는 것이 좋습니다. 많은 상용 사이트의 홈페이지는 분석 시 소음을 일으킬 수 있는 다양한 기능으로 연결되는 포털입니다. 예를 들어 뉴스 사이트의 세션당 페이지 조회수를 최적화하는 경우 사이트의 비상업용 부분을 제외하고 수익이 창출되는 섹션과 기사에 초점을 맞추는 것이 좋습니다.
선택한 페이지에 충분한 트래픽이 발생해야 통계적으로 유의미한 결과를 얻기 위해 오래 기다릴 필요가 없습니다.
선택한 페이지가 비교적 느립니다. 오히려 느릴수록 좋습니다. 이렇게 하면 페이지를 더 쉽게 개선할 수 있을 뿐만 아니라 데이터가 훨씬 명확해집니다. Google 애널리틱스 속도 보고서 또는 Search Console 코어 웹 바이탈 보고서를 통해 빠르게 확인하여 어떤 페이지가 가장 느린지 확인할 수 있습니다.
페이지가 비교적 안정적이어야 합니다. 테스트가 완료될 때까지 페이지 (비즈니스 측정항목에 영향을 미치는 모든 항목)를 업데이트하지 마세요. 고려해야 할 외부 요소가 적을수록 분석이 더 명확해집니다.
위의 내용을 가이드로 사용하면 테스트에 적합한 페이지를 좀 더 명확하게 파악할 수 있습니다. 기본 제공되는 비즈니스 측정항목, A/B 테스트, 분석 기능을 원하는 대로 사용할 수 있으므로 광고 방문 페이지도 좋은 선택입니다. 여전히 확실하지 않은 경우를 위해 카테고리별로 다음과 같은 몇 가지 아이디어를 얻으실 수 있습니다.
- 콘텐츠 웹사이트: 섹션, 기사
- 매장: 카테고리 페이지, 제품 페이지
- 미디어 플레이어: 동영상 검색/검색 페이지, 동영상 재생 페이지
- 서비스 및 탐색 (여행, 렌터카, 서비스 등록 등): 최초 양식 입력 페이지
2단계: 실적 측정하기
측정항목을 측정하는 일반적인 방법으로는 실험실과 필드 두 가지가 있습니다. Google은 현장의 측정 측정항목 (RUM (Real User Monitoring)이라고도 함)이 실제 사용자의 경험을 반영하므로 더 유용하다는 점을 확인했습니다. RUM 데이터 보고에 도움이 되는 라이브러리와 서비스의 예로는 Perfume, Firebase Performance Monitoring, Google 애널리틱스 이벤트가 있습니다.
사용자 환경의 다양한 측면을 캡처하기 위해 선택할 수 있는 많은 측정항목이 있습니다. 결국 속도와 비즈니스 측정항목 간에 직접적인 상관관계가 있는지 확인하는 것이 목표이므로 비즈니스 성공과 가장 큰 상관관계가 있는 측정항목을 파악하기 위해 몇 가지 속도 측정항목을 추적하는 것이 유용할 수 있습니다. 일반적으로 코어 웹 바이탈부터 시작하는 것이 좋습니다. web-vitals.js 라이브러리는 현장에서 일부 코어 웹 바이탈을 측정하는 데 도움이 될 수 있지만 브라우저가 100%지원되지는 않습니다. 코어 웹 바이탈 외에 기타 웹 바이탈도 확인해 볼 가치가 있습니다. '첫 광고 클릭까지의 시간'과 같은 맞춤 측정항목을 정의할 수도 있습니다.
3단계: 속도 성능 대안 만들기
이 단계에서는 변경사항을 구현하여 현재 버전과 비교할 수 있는 더 빠른 버전의 페이지를 만듭니다.
다음 사항에 유의하세요.
- UI 또는 UX를 변경하지 마세요. 한 페이지가 다른 페이지보다 빠르다는 점을 제외하고 변경사항은 사용자에게 표시되지 않아야 합니다.
- 측정도 이 단계의 핵심입니다. 개발 중에 Lighthouse와 같은 실험실 테스트 도구를 사용하여 변경사항이 성능에 미치는 영향을 나타내야 합니다. 한 측정항목을 변경하면 다른 측정항목에 영향을 미칠 수 있다는 점에 유의하세요. 페이지가 활성화되면 더 정확한 평가를 위해 RUM을 계속 사용하세요.
성능 대안은 다양한 방법으로 만들 수 있습니다. 이 테스트의 목적상 가능한 한 간단하게 이렇게 하는 것이 좋습니다. 다음은 몇 가지 옵션입니다.
페이지 속도 향상
- Squoosh와 같은 도구를 사용하여 테스트 페이지의 이미지를 수동으로 최적화
- DevTools 코드 적용 범위를 사용하여 해당 페이지에서만 사용되지 않는 JavaScript 또는 CSS를 수동으로 제거합니다.
- 서드 파티 스크립트의 효율적인 로드
- 중요와 같은 도구를 사용하여 중요한 CSS를 분류하고 인라인 처리합니다.
- 사용자 환경에 영향을 미치지 않고 테스트 목적 없이 실행할 수 있는 중요하지 않은 JavaScript 코드 (예: 특정 서드 파티 라이브러리)를 삭제합니다.
- 일부 브라우저에서는 지원되지는 않지만 지원되는 경우 성능을 크게 개선할 수 있는 브라우저 수준의 지연 로드를 구현합니다.
- 중요하지 않은 애널리틱스 태그를 삭제하거나 비동기식으로 로드하세요.
고려할 추가 최적화는 빠른 로드 시간 및 프런트엔드 성능 체크리스트에서 확인할 수 있습니다. PageSpeed Insights를 사용하여 성능 개선 기회를 식별하는 Lighthouse를 실행할 수도 있습니다.
페이지 속도 늦추기
이는 대안을 만드는 가장 쉬운 방법일 수 있으며, 간단한 스크립트를 추가하거나 서버 응답 시간을 늦추거나 더 큰 이미지를 로드하는 등의 방법으로 수행할 수 있습니다. Financial Times는 성능이 비즈니스 측정항목에 미치는 영향을 테스트할 때 이 옵션을 선택했습니다. 더 빠른 FT.com을 참조하세요.
페이지 로드 속도 높이기
테스트 페이지 (예: 제품 세부정보 페이지)가 대부분 다른 페이지 (예: 홈페이지)에서 연결되는 경우 테스트 그룹의 홈페이지에서 직접 제품 페이지를 미리 가져오기하거나 사전 렌더링하면 페이지의 후속 로드 속도가 빨라집니다. 이 경우 A/B 테스트 분할 (4단계)은 홈페이지에서 진행됩니다. 또한 이러한 요인으로 인해 첫 번째 페이지의 속도가 느려질 수 있으므로 이를 측정하고 테스트 결과를 분석할 때 이를 고려해야 합니다 (5단계).
4단계: A/B 테스트 만들기
동일한 페이지의 두 버전이 다른 버전보다 빠른 경우 다음 단계는 트래픽을 분할하여 영향을 측정하는 것입니다. 일반적으로 A/B 테스트를 실행하는 기법과 도구는 많지만 속도 성능 영향을 측정하는 데 적합하지 않은 방법도 있습니다.
Optimizely 또는 Optimize와 같은 A/B 테스트 도구를 사용하는 경우에는 클라이언트 측 테스트 대신 서버 측 테스트를 설정하는 것이 좋습니다. 클라이언트 측 A/B 테스트는 실험이 로드될 때까지 페이지 콘텐츠를 숨기는 방식으로 작동하는 경우가 많으므로 A/B 테스트 자체로 인해 측정하려는 측정항목이 왜곡될 수 있습니다. 클라이언트 측 테스트만 할 수 있는 경우에는 다른 페이지에서 실험을 설정하고 테스트 페이지로 연결되는 링크를 변경하여 트래픽을 분할하는 것이 좋습니다. 이렇게 하면 클라이언트 측 테스트에서 테스트 페이지 자체를 아래로 드래그하지 않습니다.
서버 측 테스트를 통해 특정 제품 세부정보 페이지 (PDP)에서 AB 테스트 성능 변경사항의 예:
요청이 백엔드로 이동하여 사용자를 두 개의 다른 버전의 페이지로 분산합니다. 이는 일반적으로 좋은 설정이지만 서버 측 분할을 설정하려면 IT 리소스가 필요한 경우가 많습니다.
다음은 이전 페이지 (아래 다이어그램의 홈페이지)를 사용하여 테스트 JavaScript를 실행하는 클라이언트 측 테스트 설정의 예입니다.
테스트 자바스크립트는 발신 링크를 조작하여 두 테스트 사용자 그룹에 문제가 되는 두 가지 버전의 PDP로 연결되는 링크를 제공합니다. 최적화 도구나 최적화 도구와 같은 일반적인 A/B 테스트 도구를 통해 쉽게 설정하고 유지관리할 수 있으며, 테스트 자바스크립트가 다른 페이지에서 실행되므로 성능 테스트에 영향을 미치지 않습니다.
또는 동작과 실적이 매우 유사한 두 페이지를 선택할 수도 있습니다(예: 매우 유사한 두 개의 제품). 둘 중 하나에 변경사항을 적용한 다음 시간 경과에 따른 측정항목의 차이를 비교하세요. 이는 적절한 A/B 테스트를 실행하지 않고 있지만 여전히 유용한 정보를 얻을 수 있음을 의미합니다.
테스트 페이지를 광고 캠페인의 방문 페이지로 사용하는 경우 Facebook 광고 분할 테스트 또는 Google Ads 초안 및 실험과 같은 광고 네트워크의 기본 A/B 테스트 도구를 사용하면 편리합니다. 그럴 수 없다면 동일한 설정으로 두 개의 캠페인을 사용하고 서로 다른 방문 페이지를 타겟으로 설정할 수 있습니다.
5단계: A/B 테스트 분석하기
충분히 오랫동안 테스트를 실행하고 결과에 대한 확신을 가질 수 있을 만큼 충분한 데이터를 확보했다면 이제 종합적으로 분석을 실행할 차례입니다. 실행 방법은 테스트 실행 방식에 따라 달라지므로 옵션을 살펴보겠습니다.
위에서 언급한 도구를 사용하여 광고 방문 페이지에서 테스트를 실행한 경우 분석은 결과를 읽는 것만큼 간단해야 합니다. Google의 초안 및 실험을 사용 중인 경우 ScoreCard를 사용하여 비교를 살펴보세요.
최적화 도구나 최적화 도구와 같은 플랫폼에서도 결과를 해석하고 속도가 페이지에 미치는 영향을 파악할 수 있는 손쉬운 방법을 제공합니다.
Google 애널리틱스 또는 유사한 도구를 사용하는 경우 보고서를 직접 가져와야 합니다. 다행히 Google 애널리틱스를 사용하면 맞춤 보고서를 쉽게 만들 수 있으므로 바로 시작해야 합니다. 맞춤 측정기준을 사용하여 Google 애널리틱스로 속도 데이터를 전송한 경우 보고 가이드에서 이러한 데이터를 설정하고 맞춤 보고서에 포함하는 방법을 알아보세요. 보고서에서 실험 날짜를 다루고 두 대안을 모두 표시하도록 구성되어 있는지 확인하세요. 이 보고서에는 어떤 내용이 포함되어야 하나요?
- 1차적으로 전환수, 페이지 조회수, 조회한 광고 수, 전환율, 전자상거래 측정항목, 클릭률 등 가장 관심 있는 비즈니스 측정항목을 포함해야 합니다.
- 또한 사이트 속도를 개선하는 데 적합한 다른 표준 페이지 측정항목으로는 이탈률, 평균 세션 시간, 종료율 등이 있습니다.
모바일을 필터링하고 봇 및 기타 비사용자 트래픽을 제외해야 할 수도 있습니다. 또한 지역, 네트워크, 기기, 트래픽 소스, 사용자 프로필 및 유형(예: 신규 사용자 및 재방문자)을 기준으로 필터링할 수도 있습니다. 각 사용자 그룹은 느린 속도에 어느 정도 민감할 수 있으며 이를 파악하는 것도 매우 유용합니다.
Looker Studio (이전의 데이터 스튜디오) 또는 기타 데이터 시각화 도구를 사용하면 Google 애널리틱스를 비롯한 다양한 데이터 소스를 쉽게 통합할 수 있습니다. 이렇게 하면 분석을 쉽게 수행할 수 있고 추가 승인을 위해 최신 웹사이트를 실행하는 데 관여하는 많은 이해관계자와 공유할 수 있는 대시보드를 만들 수 있습니다. 예를 들어 Guardian은 자동 알림 시스템을 만들어 최근 게시된 콘텐츠가 페이지 크기 또는 속도 기준점을 초과하여 사용자가 만족할 수 없을 때 편집팀에 경고했습니다.
6단계: 결론 도출 및 다음 단계 결정
실적과 비즈니스 측정항목을 연결하는 데이터를 확보하면 결과를 검토하고 결론을 도출할 수 있습니다.
성과 개선과 비즈니스 측정항목 개선 간의 상관관계를 명확하게 파악할 수 있다면 결과를 요약하여 회사 전체에 보고합니다. 이제 '비즈니스 언어'로 속도 성능에 대해 이야기할 수 있으므로 다양한 이해관계자의 관심을 끌고 사이트 속도 성능을 모두의 관점에서 판단할 수 있습니다. 다음 단계는 결과에 따라 성능 예산을 설정하고 해당 예산을 충족하기 위한 작업을 계획하는 것입니다. 이러한 작업이 가져다줄 가치를 알고 있으므로 그에 따라 우선순위를 지정할 수 있습니다.
상관관계를 확인할 수 없는 경우 아래의 주의사항을 살펴보고 유사한 테스트를 사이트의 다른 위치 (예: 전체 구매 유입경로 또는 다른 유형의 페이지)에서 실행해야 하는지 평가하세요.
주의사항
사이트 속도 측정항목과 비즈니스 측정항목 간에 유의미한 상관관계가 발견되지 않는 데에는 여러 가지 이유가 있을 수 있습니다.
- 선택한 페이지가 검사하는 비즈니스 측정항목에 충분한 영향을 미치지 않습니다. 예를 들어 결제 페이지가 매우 불편하거나 느린 경우 제품 페이지의 속도가 빨라도 전환율에 큰 영향을 미치지 않을 수 있습니다. 이탈률, 장바구니에 추가 비율 또는 테스트 중인 페이지에 보다 직접적으로 연결된 기타 측정항목과 같이 관련성이 더 높은 측정항목을 살펴보는 것이 좋습니다.
- 두 버전 간의 속도 차이는 크지 않습니다. 이는 측정 중인 RUM 측정항목에 따라 평가되어야 합니다.
- A/B 테스트 메커니즘에 오류가 있습니다. 트래픽이 제대로 분산되지 않거나 분석이 올바르게 보고되지 않을 수 있습니다. 이를 배제하려면 동일한 테스트 메커니즘으로 동일한 버전의 페이지를 테스트하는 A/A 테스트를 실행하고 그렇게 할 때 결과에 차이가 없는지 확인하는 것이 좋습니다.
- 사이트 속도는 비즈니스 측정항목에 실제로 영향을 미치지 않습니다. 이는 드문 경우이지만, 타겟 시장이 속도에 덜 민감하거나 (예: 주로 강력한 네트워크에 연결된 고성능 기기에서 사이트에 액세스하는 경우) 사용자 수요가 매우 많고 선택권이 제한된 경우 (예: 수요가 많은 공연의 티켓을 독점 판매하는 티켓 서비스)에서 발생할 수 있습니다. 하지만 사이트 속도가 빠르다고 해서 사용자 환경이 개선되지 않으며, 그 결과 브랜드 평판에 영향을 미치는 것은 아닙니다.
결론
사이트 전체에 속도 최적화를 실행하고 싶을 수도 있지만, 장기적으로는 사용자와 회사에 더 빠른 웹사이트를 구축하는 것이 어떤 의미인지를 먼저 이해하는 것이 더 좋습니다. 'FCP를 1.5초 개선'하는 것과 'FCP를 1.5초 개선하여 전환율을 5% 높인' 것의 차이입니다. 이를 통해 추가 작업의 우선순위를 지정하고 다양한 이해관계자의 동의를 얻으며 사이트 속도 성능을 전사적으로 수행할 수 있습니다.