Go to Docs (EN)Sign in to Dashboard

자주 묻는 질문

Suggest Edits

📘

이 문서에 대하여

이 문서는 SDK 연동 과정 중 어떠한 기능의 지원 여부, 구현 노하우나 조언을 구할 때 참고할 수 있습니다.
비정상 동작으로 의심되거나, 그 외 버그로 의심되는 문제가 발생할 때는 문제 해결 문서를 참고하시기 바랍니다.

1. SDK 연동

1.1. 외부 솔루션을 이용해서 만든 홈페이지에도 SDK 연동이 가능한가요?

해당 홈페이지에 대해 코드 수정이 가능하다면 연동 가능합니다. SDK 연동을 위해서는 코드 작업이 필요하므로 코드 수정 가능 여부에 따라 연동 가능 여부가 달라진다고 볼 수 있습니다.
SDK 연동이 가능한 예시로는 카페24 기반의 웹사이트가 있으며, 불가한 사례로는 네이버 스마트스토어가 있습니다.

1.2. 핵클 인스턴스는 언제 생성해야 하나요? 생성 후 프로젝트 내 다른 파일에서 사용 가능한가요?

인스턴스 생성 시기는 초기 구동 시 생성하는 것을 권장합니다. 싱글톤(Singleton)으로 구현되어 있으므로 다른 파일에서 재차 생성할 필요는 없습니다.
import가 필요한 SDK를 사용할 경우, 사용하려는 파일 내에서 import 하면 됩니다.

1.3. 어떤 SDK 키를 선택해야 할지 모르겠습니다.

우선 환경(운영 or 개발)을 확인해주시고, 해당 환경에 맞는 개발 플랫폼에 따라 Server, App, Browser 중 택하면 됩니다. SDK에서 사용되는 키 문서를 통해 어떤 SDK 키를 선택하면 되는지 알 수 있습니다.
만약 웹 서비스를 웹뷰에 씌워서 앱으로 출시한 경우라면 Browser 키를 선택하면 됩니다.

1.4. 테스트 시작 전에 연동이 잘 되었는지 검증할 수 있나요?

개발/운영 환경 모두 테스트 기기 등록 기능을 활용하여 테스트할 수 있습니다. 테스트 기기 등록 기능은 대시보드에서 지정한 사용자 식별자를 대상으로 특정 테스트 그룹에 강제할당하는 방법으로 수동할당으로 부르기도 합니다.
사용 방법은 A/B 테스트 설정 문서를 참고 바랍니다.

우선 개발 환경의 경우, 검증에 참여할 내부 인원들의 사용자 식별자를 각 테스트 그룹에 입력하여 저장합니다. 그리고 테스트를 시작한 후 각 테스트 그룹에 속한 인원들을 대상으로 의도한 결과가 나타나는지 검증합니다.
운영 환경의 경우에는 트래픽 할당을 0%로 설정한 후 테스트를 시작해야 합니다. 이는 수동할당 대상자를 제외하고는 해당 테스트가 노출되지 않게 하려는 목적입니다. 이후 절차는 개발 환경과 동일합니다.

이벤트 전송이 잘 되고 있는지 알아보려면 대시보드의 이벤트 메뉴에서 해당 이벤트 키의 상세 페이지를 통해 실시간 전송 상황을 알 수 있습니다. 수동할당 대상자에게 이벤트 전송에 해당하는 행동을 하게 한 후 이벤트 메뉴에 진입하여 살펴보면 됩니다.

1.5. 핵클에서 자동으로 수집하는 이벤트에 대하여, 수집을 막고 싶습니다.

JavaScript SDK 혹은 React SDK를 사용하는 경우 핵클에서 웹 페이지 진입 혹은 이동 정보를 수집하고 있습니다. 이를 원치 않으실 경우 아래 문서를 참고하시기 바랍니다.

  • JavaScript: SDK 연동 중 2-1 단계: 설정 추가
  • React: SDK 연동 중 2-1 단계: 설정 추가

2. 사용자 식별자

2.1. 모바일 앱에서 사용자 식별자를 무엇으로 정하면 좋을까요?

핵클에서 제공하는 사용자 식별자를 사용하는 방법이 있습니다. 하지만 핵클의 사용자 식별자는 앱을 지웠다가 다시 설치할 경우 새 식별자를 부여합니다. 즉, 동일 사용자로 보지 않습니다.
위와 같은 사유로 핵클에서 제공하는 사용자 식별자를 사용하기 어려운 경우, 자체적으로 각 사용자를 구분할 수 있는 고윳값을 만들어 해당 값을 사용자 식별자로 정하는 것이 좋습니다.

2.2. 비로그인 사용자의 경우 사용자 식별자를 어떻게 정해야 할까요?

정답은 없습니다만 하나의 예를 들자면, 웹 브라우저 환경인 경우에는 브라우저마다 유니크한 쿠키를 구워서 해당 값을 이용하고, 모바일 앱 환경인 경우에는 사용자가 앱을 설치할 때 유니크한 값을 생성하여 해당 값을 사용하는 방법이 있습니다.
그 외 여러 가지 방법이 있을 수 있으니 서비스에 맞는 방안을 적용해보시기 바랍니다.

2.3. 쿠키 기반으로 사용자 식별자를 만들 때에 대한 tip이 있나요?

사용자 식별자 자릿수가 너무 짧거나 길면 좋지 않습니다. 통상 16자리나 32자리로 만듭니다.
또한 쿠키 도메인은 .{회사명}.kr과 같은 형태로 하는 것을 추천합니다. 서브 도메인이 생기더라도 손쉽게 해당 값을 공유할 수 있으며, 클라이언트 및 서버 중 어느 곳에서 이벤트를 전송하더라도 같은 값을 공유하기 용이하기 때문입니다.
참고로, 쿠키를 기반으로 사용자 식별자를 생성하는 예시 코드를 사용자 식별자 문서에서 제공하고 있습니다.

2.4. 세션 단위로 측정하려면 사용자 식별자를 무엇으로 해야 하나요?

일반적으로 사용자 단위로 사용자 식별자를 정의하는 것을 권합니다. 하지만 사용자 식별자를 Session ID로 정하면 세션 단위의 결과 분석 또한 가능합니다. 이 경우 지표 계산의 기준을 잡기 위해 세션에 대한 기준, 세션 로직 등은 직접 정의해야 합니다.

3. A/B 테스트 설계 및 구현

3.1. 서버 측 SDK를 사용하고 있습니다. 분배 결과가 서버 뿐 아니라 클라이언트에도 영향이 있는 경우 어떤 방식으로 구현하는 것이 좋은가요?

쉽게 생각할 수 있는 방법은 서버에서 클라이언트로 테스트 그룹 값을 내려주고, 그룹 별로 별도의 로직을 처리하는 것이겠지만 이는 좋은 방법이 아닙니다. 추후 특정 로직으로 확정했을 경우 서버 뿐 아니라 클라이언트에도 모두 변경이 필요하기 때문입니다.

따라서 서버에서만 코드를 수정하면 되게끔 설계하는 것이 중요합니다. 예를 들어, 그룹 A이면 빨간색을 적용하고 그룹 B이면 파란색을 적용한다고 가정합니다.

# Good case
# 서버에서 그룹에 대한 값을 할당한 후 서버가 클라이언트 측으로 그 값을 내려준다
# 테스트그룹 A인 경우
HTTP/1.1 200 OK
{
  "color" : "red",
  ...
}
# 테스트그룹 B인 경우
HTTP/1.1 200 OK
{
  "color" : "blue",
  ...
}

# 클라이언트 측 처리
fill_color(response.color)

# Bad case
# 서버가 클라이언트 측으로 서버에서 할당된 그룹 값을 바로 내려 줌
HTTP/1.1 200 OK
{
  "variation" : "B"
  ...
}

# 클라이언트 측 처리
if response.variation == 'A'
  fill_color(red)
elif response.variation == 'B'
  fill_color(blue)

예시의 Bad Case를 보면 서버는 분배된 테스트 그룹 값을 클라이언트에 보내고 클라리언트는 그 값에 따라 분기처리하지만, Good Case를 보면 서버에서 분배된 테스트 그룹에 따라 분기처리를 내부적으로 마친 후, 클라이언트에서 처리해야 하는 값을 전송하는 것을 알 수 있습니다.

3.2. 서버 측 SDK를 사용하고 있습니다. 클라이언트 단에서 새로운 기능을 테스트하려는데, 새 기능마다 API를 만들어 사용하는 편이 좋은가요?

두 케이스로 나누어 볼 수 있습니다. 테스트 대상이 되는 값을 관리하는 API가 이미 존재한다면 해당 API에서 테스트 그룹 별 응답을 추가하는 것이 관리에 용이합니다. 하지만 그런 API가 존재하지 않는 상황이라면 새로 API를 만들고 그 안에서 테스트 그룹을 분배한 다음에 그룹 별 응답을 내려주도록 하는 것이 좋습니다.

예를 들어, 입력 가능한 글자수를 변경할 경우의 반응을 보고자 하는 A/B 테스트를 생성했다고 가정합니다. 기존에 있던 API 중 입력 가능한 글자수를 반환하는 API가 있었다면 해당 API 내에서 테스트 그룹 A일 때의 글자수와 테스트 그룹 B일 때의 글자수를 반환하게 합니다.
반면 그동안 입력 가능한 글자수를 바꿀 일이 없었기 때문에 입력 가능한 글자수를 반환하는 API가 없었다면 해당 API를 만들고 그 안에서 테스트 그룹을 분배하도록 합니다. 이 경우 신규 API를 거치는 사용자만 모집단에 들어가게 제어할 수도 있습니다.

3.3. 운영환경에서 A/B 테스트 진행 중인데, 테스트 그룹 분배가 잘 되고 있는지 확인하고 싶습니다.

대시보드의 A/B 테스트 목록에서 해당 A/B 테스트 상세에 진입한 후, 실시간 노출 현황 탭을 선택하면 나오는 그래프에서 테스트 그룹 별 분배 상태를 알 수 있습니다. 실시간 노출 현황 문서를 참고하시기 바랍니다.

4. 데이터

4.1. A/B 테스트에 대한 raw data가 필요합니다.

대시보드를 통해 테스트 그룹 분배 데이터와 이벤트 데이터를 얻을 수 있습니다.
단, 이 기능은 프로 플랜 이상의 유료 요금제인 경우 사용할 수 있습니다.

2250
  1. raw data가 필요한 A/B 테스트에 진입합니다.
  2. 제목 우측의 ... 버튼을 클릭합니다.
  3. 데이터 추출하기 메뉴를 클릭합니다.
  4. 등록된 이메일로 csv 파일을 다운로드 받을 수 있는 링크를 전송합니다.
  5. 이메일에 있는 링크를 클릭하여 csv 파일을 다운로드 받습니다.

Updated 5 months ago