AEM as a Cloud Service의 컨텍스트 기반 실험 contextual-experimentation

실험은 성능을 개선하고 사이트를 보다 효율적이고 능률적으로 만들기 위해 사이트의 디자인, 기능 및 코드를 테스트하는 방법입니다. 이는 콘텐츠 또는 기능을 변경하고 결과를 이전 버전과 비교하고 측정 가능한 효과가 있는 개선 사항을 선택하여 수행됩니다.

이를 올바르게 수행하면 전환, 참여 및 방문자 경험을 개선하는 강력한 패턴입니다. 일반적으로 이 방법을 채택하려고 할 때 피해야 할 두 가지 문제가 있습니다.

Adobe Experience Manager에서 실행 중인 사이트의 경우 개발자가 사이트에 실험 기능을 추가할 수 있도록 하는 "즉시 사용 가능한" 실험 플러그인 ​이 있습니다. 이 접근 방식은 다른 실험 프레임워크와 다릅니다.

시작하기 전 before-start

실험 플러그인이 Edge Delivery Services의 컨텍스트 내에서 사용되므로 Github 계정이나 SharePoint 또는 Google 드라이브와 같은 콘텐츠 저장소가 필요하고 AEM Sidekick도 필요합니다. 시작하기 - 유니버설 편집기 개발자 자습서 페이지 및 시작하기 - 개발자 자습서를 참조하십시오.

설정이 모두 완료되면 이 비디오를 시청하십시오 제목 즉시 실험을 통해 실험 플러그인의 작동 방식에 대한 간단한 데모를 살펴보십시오.

자주 사용하는 용어 frequently-used-terms

안내서의 나머지 부분을 따라 첫 번째 실험을 설정하기 전에 자주 사용하는 몇 가지 용어를 숙지해야 합니다.

실험 변형 및 일반 워크플로우 experiment-variants-workflow

일반적으로 실험을 설정할 때는 기존 페이지를 컨트롤 페이지로 사용합니다. 그런 다음 일부 방문자에 대한 제어 페이지를 대체할 챌린저 페이지를 만듭니다. 챌린저 페이지에서 컨텐츠 변형, 다양한 페이지 레이아웃, call-to-action(CTA) 등과 같은 다양한 항목을 테스트할 수 있습니다. 컨트롤 페이지(아래 참조)에서 메타데이터 매개 변수를 추가하여 이러한 실험 변형을 구성할 수 있습니다.

그런 다음 작동 원격 분석 서비스에서 제어 페이지와 챌린저 페이지의 방문자 수 등의 데이터를 수집합니다. 그런 다음 이 데이터를 사용하여 사이트에 필요한 개선 사항을 선택합니다. 웹 사이트의 확립된 디자인 언어를 사용하고 기존 블록 기능을 사용하는 한 몇 분 안에 실험 변형을 설정하고 프로덕션으로 전송할 수 있어야 합니다.

실험 식별자 experiment-identifier

시작하기 전에 모든 실험에는 추적 및 분석 목적으로 자체 식별자가 있어야 합니다. 좋은 시작점은 "실험 ID"가 될 실험에 대한 좋고 고유한 식별자를 마련하는 것입니다. 실험에는 종종 문제 추적기 또는 관리 시스템에서 해당 문제 ID에 선형적으로 번호가 매겨지거나 상관 관계가 있습니다. 실험 ID는 종종 프로젝트 접두사를 사용합니다(예: OPT-0134, EXP0004 또는 CCX0076).

챌린저 페이지 만들기 create-challenger-page

규칙에 따라 /experiments/ folder에 소문자 실험 ID를 가진 폴더를 만드는 것이 좋습니다(예: /experiments/ccx0076/). 챌린저 변형의 모든 페이지가 이 폴더에 있습니다. 이 폴더는 로컬 저장소(예: Sharepoint 또는 Goggle Drive)에 만듭니다.

실험 폴더는 다음과 같아야 합니다.

폴더가 만들어지면 제어 페이지의 사본을 해당 폴더에 넣고 테스트하려는 페이지의 변경 사항을 실험 변형의 일부로 적용합니다(위의 비디오 참조). 예를 들어 웹 사이트에 실험을 실행하려는 다음 페이지가 있다고 가정해 보겠습니다.

experiments/<experiment-id> 폴더에 배치된 도전자의 복사본은 다음과 같습니다.

사이드 킥을 사용하여 챌린저 페이지를 미리 보고 게시하며, 챌린저 페이지 작성이 완료되면 게시할 수 있습니다. 게시된 도전자의 URL은 다음 섹션( 실험 구성)에서 사용됩니다.

실험 구성 configure-experiment

챌린저 페이지를 전송할 준비가 되면 제어 페이지로 돌아가 페이지가 이제 테스트의 일부임을 나타내는 메타데이터를 추가해야 합니다.

실험 변형을 위해 추가해야 하는 두 개의 메타데이터 행이 있습니다.

아래 예를 참조하십시오.

각 실험에 대해 트래픽은 모든 변형(제어와 챌린저) 간에 분할되고 자동으로 균등 분포로 설정됩니다. 이와 같이 도전자가 한 명일 경우 자동으로 제어와 도전자 간에 50/50씩 분할이 이루어집니다. 도전자가 두 명일 경우 제어 및 각 도전자에게 할당된 트래픽의 1/3을 자동으로 볼 수 있습니다.

메타데이터를 구성하여 트래픽 분할을 재정의할 수 있습니다. 실험에 사용되는 메타데이터를 사용자 지정하는 방법에 대한 자세한 내용은 다음 페이지를 참조하십시오.

실험 변형 미리 보기 및 스테이징 preview-stage-experiment

실험을 미리 보고 스테이징할 준비가 되면 왼쪽 상단의 사이드 킥에서 미리 보기 를 클릭합니다. 실행 중인 실험이 있는 페이지를 미리 볼 때마다 .aem.page 미리 보기 환경에 실험 오버레이가 표시됩니다. 실험 오버레이를 사용하면 실험 변형 간을 전환할 수 있으며 트래픽 데이터도 제공합니다.

각 변형의 효과를 측정하기 위한 데이터 수집은 AEM as a Cloud Service의 Operational Telemetry 서비스를 기반으로 합니다.

실험에 대한 변형을 프로덕션에 보내기 production-experiment

실험 페이지를 선택하고 사이드 킥에서 게시 를 클릭하여 제어 및 챌린저 변형을 라이브로 모두 푸시합니다.

사용 사례 예 use-case-examples

다음은 실험 변형에 대한 몇 가지 사용 사례입니다. 일반적으로 기본 워크플로우는 위에서 설명한 워크플로와 유사하며, 각 사용 사례에 대한 특정 변경 사항(예: 챌린저 페이지 또는 메타데이터 변경 사항)이 있습니다.

전체 페이지 실험 full-page

전체 페이지 실험을 사용하여 동일한 페이지의 두 변형 간을 테스트합니다. 컨트롤 및 챌린저 페이지가 있는 a/b 테스트의 전체 페이지 변형입니다. 챌린저 변형에 있는 "원본" 컨트롤 페이지의 전체 콘텐츠를 다른 유형의 콘텐츠로 교체합니다. 기본적으로 고객 트래픽은 균등하게(50/50) 분할되지만 원하는 경우 사용자 정의 분할을 생성할 수 있습니다.

기타 고려 사항 other-considerations

다음은 컨텍스트 실험을 사용할 때 고려해야 하는 몇 가지 다른 측면입니다.

전환 conversion

실험은 전환을 처리하도록 설정됩니다(페이지에서 클릭 가능한 요소를 추적합니다). 모든 실험은 다음에 대해 정의되어야 합니다.

실험 변형이 색인화되지 않았는지 확인합니다. experiment-not-indexed

실험을 실행할 때 일반적으로 사이트 맵에서 변형을 제외하고 검색 엔진에서 인덱싱되지 않도록 하는 것이 좋습니다. 변형 페이지가 중복된 콘텐츠로 인식되어 SEO에 부정적인 영향을 줄 수 있기 때문입니다.

다음 두 가지 방법 중 하나를 사용하여 이 작업을 수행할 수 있습니다.

개발자 및 기술 리소스 dev-resources

Adobe Experience Manager에서 [운영 원격 분석] 사용(https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/sites/operational-telemetry-for-aem-as-a-cloud-service.html?lang=ko)를 사용하여 Adobe Experience Manager 기반 사이트에서 기능 및 성능 문제를 검색하고 수정하는 데 절대적으로 필요한 작업 데이터를 수집할 수 있습니다. 운영 원격 분석 데이터를 사용하여 성능 문제를 진단할 수 있습니다. 운영 원격 분석은 샘플링을 통해 방문자의 개인 정보를 보존합니다(모든 페이지 보기 중 일부만 모니터링됨).

개인 정보 privacy-experimentation

AEM as a Cloud Service의 작동 원격 분석 서비스는 방문자 개인 정보를 유지하고 데이터 수집을 최소화하도록 설계되었습니다. 이는 Adobe이 방문자로서 귀하에 대한 개인 정보나 귀하에게 다시 추적할 수 있는 정보를 수집하려고 시도하지 않음을 의미합니다. 사이트 운영자는 아래 수집된 데이터 항목을 검토하여 동의가 필요한지 파악합니다.
AEM Operational Telemetry에서는 사용 지표를 수집하기 위해 쿠키나 localStorage, sessionStorage 등과 같은 클라이언트측 상태 또는 ID를 사용하지 않습니다. 데이터는 픽셀이나 유사한 기술을 통해서가 아니라 Navigator.sendBeacon 호출을 통해 투명하게 제출됩니다. 샘플링된 데이터를 캡처할 목적으로 IP 주소, 사용자 에이전트 문자열 또는 기타 모든 데이터를 통해 장치 또는 개인을 "지문"으로 인쇄할 수 없습니다.

운영 원격 분석 데이터 수집에 개인 데이터를 추가하는 것은 허용되지 않으며, 운영 원격 분석 데이터를 꼭 필요한 경우를 초과하는 사용 사례에 사용할 수도 없습니다.

FAQ faq

다음은 FAQ 목록입니다.

Q: 제어의 경우 10%, 도전의 경우 90%와 같은 내 실험의 변형 간 분할 비율을 조정할 수 있습니까?

예. 분할 비율은 메타데이터를 통해 구성할 수 있습니다.

Q: 텍스트와 이미지 모두에서 실험할 수 있습니까?

예. 변형은 완전히 다른 페이지일 수 있으므로 레이아웃 변경을 테스트할 수도 있습니다.