서버 측 실험 여정에서 0에서 1로 이동하는 방법

Netflix 사용자의 여정을 생각해 보십시오. 나 같은 사람이라면 모닝 커피를 마시면서 휴대 전화로 야생 동물 다큐멘터리를 볼 수 있습니다. 저녁 식사는 노트북의 Forrest Gump와 같이 옛날에 좋아했던 사람과 함께 할 수 있습니다. 주말 밤에는 더 큰 화면에서 새로운 Netflix 프로그램을 시도하면서 귀하의 프로필과 자녀의 프로필 사이를 전환하는 데 보내게 됩니다.

이제 Netflix에서 국가별 할인 캠페인을 실행하고 있다고 가정해 보겠습니다. Netflix에서 운영하는 이 실험 캠페인에 참여하고 있다면 사용 중인 기기와 프로필에 관계없이 로그인할 때마다 동일한 캠페인에 참여하고 모든 곳에서 동일한 프로모션을 볼 수 있도록 하는 방법은 무엇입니까? 제공되는 변형에 대한 경험이 매번 매끄럽고 변형에 참여하는 방법이 일관되게 추적되도록 하는 방법은 무엇입니까?

답은 서버 측 테스트의 일반적인 사용 사례인 옴니채널 실험에 있습니다.

클라이언트 측보다 서버 측 테스트를 선호해야 합니까?

위에 언급된 Netflix 예제는 클라이언트 측에서 수행하기가 매우 복잡하고 사용자 경험을 방해할 수 있습니다. 서버 측에서는 비교적 실행하기 쉽고 사용자에게 일관된 경험을 보장합니다. 또한 페이지 성능에 미치는 영향을 최소화합니다. 이 외에도 브라우저에서 활동이 없기 때문에 개인 정보 관련 문제를 근절합니다.

견고성과 유연성을 위해 서버 측 테스트가 권장되는 다른 사용 사례가 있습니다. 우리는 이 기사에서 이에 대해 이야기할 것입니다. 그러나 먼저 서버 측 테스트가 정확히 무엇이며 더 중요한 것은 누구를 위한 것입니까?

서버 측 테스트에서 테스트 변형은 웹 서버에서 처리됩니다. 방문자가 테스트 중인 페이지를 방문하면 서버에서 직접 변형을 가져와 방문자의 브라우저에 전달합니다. 그런 다음 프런트 엔드 또는 브라우저에서 후속 수정이 발생하지 않습니다. 이와는 대조적으로 클라이언트 측 테스트에서 원본 페이지는 방문자의 브라우저에서 먼저 로드되고 실험 플랫폼은 JavaScript를 사용하여 프런트 엔드 자체에 변형을 생성합니다. 예제를 통해 이 두 가지 테스트 형식의 범위를 이해해 보겠습니다.

Mike와 Bob이 새 자동차의 작동 방식을 실험하려고 하는 두 친구라고 상상해 보십시오. Mike는 운전석에 있으며 브레이크, 가속기, 대시보드 등에 액세스할 수 있습니다. Bob은 엔진, 라디에이터, 배터리 등과 같은 내부 구성 요소를 볼 수 있습니다. 둘 다 다른 방식으로 자동차에 영향을 줄 수 있습니다. Bob이 자동차 구성 요소에 대한 액세스 권한으로 수행하는 작업은 Mike에게 외부에 반영될 수 있습니다. Mike가 테스트하는 변경 사항은 차량의 가시성을 기반으로 합니다. 자동차 구매자의 관점에서 Bob과 Mike 모두가 실행한 실험의 결과는 똑같이 중요하지만 다른 목적을 수행할 수 있습니다.

따라서 다른 테스트보다 한 가지 테스트 형식을 선택할 필요가 없습니다. 사용 사례가 다르고 도구를 사용하는 팀이 다릅니다. 서버 측 테스트는 마케터가 클라이언트 측 테스트를 더 자주 사용하는 것처럼 개발자와 제품 관리자를 위한 실험 수단입니다.

서버 측 테스트로 해결할 수 있는 문제는 무엇입니까?

제품 팀에서 실행하는 서버 측 테스트는 전자 상거래 및 SaaS에서 은행 및 미디어에 이르기까지 수많은 산업과 관련된 문제를 해결합니다. 다양한 산업에서 클라이언트 측 테스트보다 서버 측 테스트가 권장되는 몇 가지 중요한 사용 사례가 아래에 설명되어 있습니다.

제품 추천

방문자가 더 많이 구매하도록 유도하는 추천 제품은 무엇입니까? 서버 측 테스트를 통해 여러 제품 추천 알고리즘을 테스트하여 판매 및 수익 증가로 이어지는 선택을 결정할 수 있습니다. 예를 들어, 유사한 제품을 홍보하는 레이아웃이 가장 인기 있는 제품을 홍보하는 레이아웃보다 더 잘 작동하는지 테스트할 수 있습니다. 또한 서버 측 실험 결과에 따라 상향 판매할지 교차 판매할지 결정할 수 있습니다.

배송비

무료 배송을 위한 주문을 충족해야 하는 이상적인 장바구니 가격은 얼마입니까? 다양한 임계값을 테스트하여 고객의 구매 결정에 긍정적인 영향을 미치는 임계값을 결정할 수 있습니다.

검색 알고리즘

검색 알고리즘을 실험하려면 기존 코드를 수정하고 심층적으로 테스트할 수 있는 유연성이 필요합니다. 방문자가 원하는 것을 빠르게 찾을 수 있기를 원하고 이를 달성하기 위해 서버 측에서 검색 알고리즘을 테스트할 수 있습니다.

형태 길이

무료 평가판 및 데모 요청 양식은 SaaS 비즈니스에 매우 중요합니다. 그러나 필요한 모든 정보를 캡처하면서 더 적은 이탈을 보장하는 이상적인 양식 길이는 얼마입니까? 클라이언트 측 테스트를 통해 필수가 아닌 필드를 테스트할 수 있습니다. 필드가 필수인 경우 JavaScript를 사용하여 필드를 숨기기만 하면 서버 측 논리를 사용한 양식 유효성 검사가 실패하므로 작동하지 않습니다. 따라서 서버 측 테스트는 양식 길이와 복잡성을 최적화하기 위해 필수 필드를 실험하는 것이 좋습니다.

거래 및 할인

스타일, 모양과 느낌, 홈 페이지의 거래 배치는 클라이언트 측에서 쉽게 테스트할 수 있지만, 할인 가치, 기간 또는 자격 기준과 같은 고려해야 할 다른 중요한 요소가 있습니다. 서버 측에서 테스트하여 최적의 값을 결정하고 특정 방문자에 대해 채널 간에 일관성이 있는지 확인할 수 있습니다.

판매 인센티브

기간 한정 제안 또는 재고 정리와 같은 동적 인센티브를 테스트하려면 관련 세부 사항으로 인해 서버 측 테스트의 유연성이 필요합니다.

구독 흐름

구독 프로세스에 이상적으로 포함되어야 하는 단계는 몇 개입니까? 소셜 로그인을 제공해야 합니까? 구독 흐름을 실험하면 이러한 질문에 답하는 데 도움이 될 수 있습니다.

페이월

서버 측 테스트를 통해 다양한 페이월 구성을 쉽게 테스트할 수 있습니다. 게시자는 서버 측 테스트를 실행하여 게이트 콘텐츠를 실험하고 수익을 창출할 수 있습니다. 방문자가 쿠키를 삭제하거나 선택 해제하여 페이월을 우회할 수 있으므로 클라이언트 측에서 동일한 테스트를 실행하는 것은 권장되지 않습니다.

모바일 뱅킹

대출 또는 신용 카드 등록 프로세스 내에서 여러 요소를 최적화할 수 있습니다. 그러나 모바일 뱅킹에서는 데이터 보안이 가장 중요합니다. 클라이언트 측 테스트를 사용하면 은행이나 금융 기관에서 수집한 민감한 데이터가 취약해질 수 있습니다. 이러한 위험을 피하기 위해 일반적으로 뱅킹 애플리케이션에 대해 서버 측 실험이 권장됩니다.

이제 서버 측에서 기능 테스트를 실행할 수 있는 방법과 VWO로 수행할 때의 이점을 이해하겠습니다.

VWO가 서버 측 테스트를 더 쉽게 만드는 방법

위에서 설명한 서버 측 사용 사례의 경우 VWO는 캠페인을 A/B 테스트 또는 기능 테스트로 구성할 수 있는 유연성을 제공합니다. 기능 테스트는 기능 매개변수의 값을 확인하고 코드를 작성하지 않고도 기능을 빠르게 구성할 수 있는 제어 기능을 제공하는 데 사용됩니다. 어떤 검색 알고리즘이 더 나은지 테스트와 같은 일부 사용 사례에서는 캠페인을 A/B 테스트 또는 기능 테스트로 구성할 수 있습니다.

예를 들어, 귀하의 웹사이트를 위해 구축한 검색 알고리즘에 대해 세 공급업체를 평가하려고 한다고 가정해 보겠습니다.

기능 테스트를 통해 귀하와 같은 제품 관리자는 엔지니어링에 대한 의존도를 최소화하고 구성을 최대한 제어하면서 신속하게 테스트하고 결론을 내릴 수 있습니다. VWO의 기능 테스트 기능을 사용하면 플랫폼이 대부분의 힘든 작업을 수행하므로 적은 코드를 작성해야 하는 세트 프레임워크를 얻을 수 있습니다. 기능 테스트에서 알고리즘은 기능 변수로 정의될 수 있으며 플랫폼 설정 흐름 자체에서 실험의 제어 및 변형으로 구성되어 어떤 검색 알고리즘이 더 효율적인지 테스트할 수 있습니다.

이 실험은 서버 측 A/B 테스트를 통해서도 수행할 수 있습니다. VWO는 서버 측 SDK를 통해 트래픽 분산 및 실험 통계 모델 기능을 용이하게 합니다. 엔지니어링 팀은 이를 사용하여 검색 알고리즘의 코드를 삽입하고 더 영향력 있는 테스트를 수행할 수 있습니다.

다음은 기능 테스트가 유용한 몇 가지 다른 시나리오입니다. 모바일 충전을 처리하는 타사 공급업체가 충전당 사용자에게 소액의 금액을 청구하려고 한다고 가정해 보겠습니다. 그들은 같은 양에 대해 적절한 양을 테스트하기를 원합니다. 또는 소유주가 숙박 시설 비용을 처리하는 Airbnb와 같은 회사는 청소 비용을 추가하여 예약 건수에 영향을 미치는지 확인하려고 합니다. 이것은 북극성 지표에 영향을 미치지 않고 서비스 요금을 삽입할 수 있는 최적의 지점을 찾기 위한 다양한 회사의 일반적인 실험 사용 사례입니다. 편의 요금, 시설 요금, covid 요금, 포장 요금 또는 이와 유사한 형태일 수 있습니다.

위에서 설명한 것과 같은 복잡한 사용 사례는 VWO에서 테스트하기가 매우 쉽습니다. 다음은 편의 수수료 기능을 신속하게 생성하고 이에 값(이 경우 수수료 금액)을 할당하는 방법을 보여주는 설명 동영상입니다. 예약 수에 영향을 주지 않으면서 수익에 추가되는 수수료를 식별한다는 가설을 연결하고 테스트를 실행할 환경을 선택하고 변형을 활성화할 수 있습니다. 그렇게 하면 서버에 적용되는 캠페인 코드가 제공됩니다. 남은 것은 추적하려는 목표를 정의하고 원하는 경우 잠재고객을 분류하는 것입니다. 캠페인이 준비되었습니다.

당신이 제품 관리자이고 대시보드에서 변형 3이 사용자에게 작동하지 않는 것을 보는 경우; 수익에 부정적인 영향을 미치므로 VWO의 변형을 비활성화하여 바로 수익을 없앨 수 있습니다. 아래 스크린샷에서 볼 수 있듯이 이는 코드에 영향을 미치지 않으며 엔지니어링 팀이 변경할 필요가 없습니다. 이 기능을 끄고 '저장'을 클릭하면 변형이 트래픽 수신을 중지합니다.

기본적으로 코드는 캠페인당 한 번만 구현하면 됩니다.

서버 측 테스트를 실행하기 위해 플랫폼을 구축하거나 구매해야 합니까?

빌드 대 구매 논쟁을 끝내자. VWO는 다양한 청중에게 다양한 변형을 보여주고 전환 이벤트를 캡처하는 단순한 난수 생성기가 아닙니다. VWO는 강력한 통계 모델을 갖춘 완전한 실험 플랫폼입니다. 사내에서 서버 측 테스트 메커니즘을 구축할지 아니면 VWO와 같은 플랫폼에 투자할지 결정하려면 다음 세 가지 주요 요소를 고려해야 합니다.

1. 소유 비용

기업이 필요한 인프라를 사내에 구축하더라도 이를 관리하고 확장해야 합니다. 핵심 업무에 집중하는 대신 VWO와 같은 실험 엔진을 구축하고 유지하기 위해 개발 팀에 비용을 지불하는 것은 결국 VWO에 투자하는 것보다 더 많은 시간과 비용이 소요될 수 있습니다.

2. 사용의 용이성

특정 청중에게 특정 변형을 보여주는 솔루션을 구축할 수 있지만 엔지니어링 팀뿐만 아니라 제품 관리자도 제어할 수 있는 사용하기 쉬운 인터페이스가 있습니까? 그렇지 않은 경우 서버 측 테스트를 실행하는 또 다른 차단기입니다.

3. 직관적인 보고

일반적으로 사내 솔루션은 방문자 수 및 특정 변형에서 발생하는 전환과 같은 기본적인 정보를 제공합니다. 그러나 필요한 것은 통계적으로 유의미한 결과입니다. VWO SmartStats와 같은 베이지안 통계 엔진으로 보고서를 제공해야 합니다. 이것이 바로 격차가 있는 부분입니다. 유지 관리하기 어려운 기본 솔루션을 구축할 수 있고 p-값을 해독하는 데 시간과 리소스를 할애할 수 있습니다. 또는 유지 관리 및 확장을 전담하는 팀이 있고 베이지안 알고리즘에 수년을 투자하여 쉽게 해석 가능한 결과를 제공하는 VWO와 같은 솔루션을 선택할 수 있습니다. VWO의 인앱 대시보드를 사용하면 비기술적인 팀원도 결과를 이해할 수 있습니다. 실험을 추적하거나 결과 대시보드를 생성하기 위해 Analytics 팀에 의존할 필요가 없으므로 시간을 절약하고 실험 비용을 절감할 수 있습니다.

4. 오류 없는 메커니즘

사내에서 서버 측 테스트 솔루션을 구축하면 오류가 발생하기 쉬우며 그 규모에서는 오류를 쉽게 발견하지 못할 수 있습니다. 이를 글로벌 브랜드에서 사용하는 플랫폼의 품질과 비교하면 오류가 발생할 가능성이 거의 없음을 확인할 수 있습니다. 오류가 있는 경우 가능한 한 유능한 지원 팀에서 최대한 빨리 플래그를 지정하고 수정합니다.

게다가 VWO와 같은 관리형 플랫폼에 투자할 때 중요한 모범 사례가 제품에 내장되어 있습니다. 결과에서 이상치를 제거하거나 데이터를 시각화하거나 버전 업데이트로 인해 발생하는 문제에 대해 걱정할 필요가 없습니다.

복잡한 서버 측 테스트를 무결성으로 실행하기 위한 필수 기능

서버 측 실험을 실행하는 것은 올바르게 실행될 때 매우 유용할 수 있습니다. 그렇게 하려면 올바른 기능 세트가 있어야 합니다. 그 중 일부는 다음과 같습니다.

1. 각 테스트에서 방문자 무작위화 – 테스트에서 잠재고객을 캠페인으로 묶을 때 방문자 무작위화는 의사 무작위가 아니라 진정으로 무작위여야 합니다.
2. 일관된 옴니채널 경험 – 사용자의 버킷팅은 무작위이어야 하지만 한 사용자가 사용 중인 장치에 관계없이 로그인할 때마다 동일한 변화를 경험하도록 해야 합니다. 실험은 결함 없이 진행되어야 합니다.
3. 상호 배타적인 캠페인 – 사용자가 테스트에 참여해야 하는지 여부를 결정할 때 고려해야 할 세 가지 요소가 있다고 가정해 보겠습니다. 사용 규칙, 낮은 이탈 가능성 및 시간대가 여기에 해당합니다. 이러한 변수를 고려하는 것 외에도 독점성을 결정해야 합니다. 따라서 이러한 조건을 충족하는 사용자는 몇 개의 테스트에 참여할 수 있습니까? 이는 왜곡된 데이터로 이어지지 않는 방식으로 결정되어야 하며 편향 없이 올바른 캠페인에 대한 전환율 개선의 원인이 될 수 있도록 해야 합니다.
4. 표준화된 명명 규칙 – 테스트할 새 기능을 설정하든 기능 플래그를 설정하든, 잘못된 기능이나 테스트를 초기화하는 경우와 혼동을 피하기 위해 표준 명명 규칙을 따라야 합니다.
5. 고유하고 번거롭지 않은 캠페인 식별자 – 영숫자 키를 사용하여 코드에서 테스트를 고유하게 식별하고 이후 단계에서 번거로움을 방지해야 합니다.
6. 올바른 환경 선택 – 테스트를 실행할 환경을 지정해야 합니다. 예를 들어 QA 팀이 실험을 검증할 수 있도록 스테이징 또는 QA 환경에 테스트를 배포할 수 있습니다. 테스트의 온전성 검사는 테스트의 성공에 매우 중요하며 테스트에 적합한 환경을 선택할 수 있는 옵션이 있어야 합니다.
7. 논리적 트래픽 할당 – 여러 캠페인을 실행 중이거나 블랙 위크 세일과 같은 중요한 이벤트 발표가 있는 경우 테스트에 페이지에 방문하는 전체 방문자 집합을 포함할 필요가 없습니다. 테스트 캠페인에 포함할 트래픽의 비율과 이 트래픽을 유사 콘텐츠에 분산하는 방법을 선택해야 합니다.
8. 통계적 유의성에 도달하는 시간 계산 – 테스트가 통계적 유의성에 도달하는 데 필요한 예상 시간은 주요 목표의 현재 전환율과 변형을 통해 달성하고자 하는 최소 개선에 의해 결정되어야 합니다. 또한 기준 전환율을 능가할 95%의 확률을 고려해야 합니다.

다음은 서버 측 테스트의 모범 사례이자 필수 기능입니다. 실제 목록은 훨씬 더 깁니다. 앞서 언급했듯이 이러한 기능을 사내에서 구축하거나 VWO를 사용하여 작업을 수행할 수 있습니다.

결론적으로

개발자이든 제품 관리자이든 상관없이 테스트 아이디어를 제한할 필요가 없습니다. 서버 측 테스트를 통해 성능 또는 개인 정보 문제를 두려워하지 않고 복잡한 테스트를 실행하고 고객이 직면한 실제 문제를 해결할 수 있습니다. 모든 디지털 접점을 최적화하여 고객이 최고만을 경험할 수 있도록 합니다.

VWO와 같은 플랫폼을 사용하는 경우 테스트의 복잡성이 당신을 압도하지 않을 것입니다. 캠페인에 대한 모든 입력은 직관적이고 테스트를 뒷받침하는 모범 사례이기 때문입니다. VWO를 사용하여 서버 측 테스트를 쉽게 실행할 수 있는 방법에 대해 자세히 알아보려면 제품 전문가에게 데모를 요청하십시오.