Google Play Store Listing Experiments: 스크린샷 A/B 테스트하기 (2026)
Google Play에서는 새 첫 번째 스크린샷이 기존보다 전환율이 좋은지 추측할 필요가 없어요 — 실제 Play Store 트래픽으로 직접 테스트할 수 있어요. Store Listing Experiments는 Play Console의 Test and release → Store listing experiments 메뉴에 내장돼 있어요(Google이 메뉴 위치를 여러 번 옮겼는데, 예전 가이드에서는 "Grow → Store listing experiments"라고 부르기도 해요). 무료이고, 실제 라이브 리스팅에서 실행되며, 트래픽 배분과 통계 처리를 대신 해줘요.
두 스토어 모두에 출시한다면 이건 Apple 쪽 설정의 짝이에요. iOS 쪽은 Product Page Experiments로 스크린샷 A/B 테스트하기에서 다뤘어요 — 개념은 같고 작동 방식만 달라요. 이 글은 Play 버전 짝이에요.
Store Listing Experiments가 작동하는 방식
실험을 만들고, 테스트할 에셋(앱 아이콘, 스크린샷, 피처 그래픽, 프로모션 영상, 짧은 설명, 또는 긴 설명)을 선택한 뒤, 현재 라이브 리스팅과 나란히 최대 3개의 변형을 업로드해요 — 현재 리스팅이 컨트롤 역할을 해요. 그러면 Google이 스토어 페이지에 도달한 사용자 일부에게 변형을 노출하고 어느 쪽이 더 많은 설치를 이끄는지 측정해요.
결과에서는 두 가지 지표가 중요해요:
- 획득(스토어 리스팅 전환율). 특정 변형을 본 후 설치까지 이어진 방문자 비율이에요. 스크린샷 테스트의 핵심 지표예요.
- 유지된 첫 설치자(1일 유지율). 변형이 끌어들인 사용자가 하루 뒤에도 실제로 남아 있는지예요. 설치는 더 끌어냈지만 유지율이 나쁜 변형은 과대 약속을 했을 가능성이 있어요.
Google은 변형별로 신뢰 구간을 계산하고, 어떤 변형이 선택한 신뢰 임곗값을 넘으면 승자로 선언해요. 이메일 알림을 신청해 두면 대시보드를 계속 지켜보지 않아도 돼요. 승자를 적용하는 건 클릭 한 번이면 되지만, 리스팅의 나머지 부분과 일관성을 맞추기 위해 보통은 승리한 에셋을 평소의 배포/심사 흐름에 그대로 태우는 게 좋아요.
기본 그래픽 vs 현지화 실험
이 부분에서 많이들 헷갈리는데, 동시에 몇 개의 테스트를 병렬로 돌릴 수 있는지가 여기서 갈려요.
- 기본 그래픽 실험. 기본 스토어 리스팅에서 에셋을 테스트해요 — 현지화된 버전을 받지 않는 모든 사용자에게 보여지는 리스팅이에요. 현지화된 에셋을 받는 사용자는 이 실험의 대상에서 제외돼요. 기본 그래픽 실험은 한 번에 하나만 실행할 수 있어요.
- 현지화된 스토어 리스팅 실험. 특정 언어에 대한 에셋(및/또는 텍스트)을 테스트해요. 최대 5개의 현지화 실험을 동시에 실행할 수 있어요 — 예를 들어 독일어 하나, 일본어 하나, 브라질 포르투갈어 하나, 이런 식으로 한꺼번에 여러 개를 돌릴 수 있어요.
실무적으로는: 설치 기반이 몇몇 시장에 집중돼 있다면 하나의 글로벌 테스트 뒤에서 순서를 기다리는 대신 현지화 실험으로 그 시장들을 병렬 테스트할 수 있어요. 그리고 언어가 곧 국가라고 단정하지 마세요 — "영어(미국)"를 선택해도 대상이 미국으로 한정되지 않아요. 어디에 있든 그 현지화 리스팅을 받는 모든 사용자를 대상으로 해요.
스크린샷 A/B 테스트 설정하기
- Store listing experiments를 열고 실험을 만드세요. 기본 리스팅이나 특정 현지화 리스팅을 선택하고, 3주 후에도 알아볼 수 있는 이름을 붙이세요("메인 스크린샷 — 이점 중심 캡션 v2" 같은 식으로요).
- 에셋을 선택하세요. 스크린샷을 선택하세요. 실험마다 요소 하나만 테스트하세요 — 같은 테스트에서 아이콘과 스크린샷을 동시에 바꾸면 무엇이 결과를 움직였는지 알 수 없어요.
- 최대 3개의 변형을 업로드하세요. 라이브 리스팅이 컨트롤이 돼요. 각 변형은 정확한 Play 규격에 맞춘 전체 스크린샷 세트여야 해요 — 정확한 사양은 Google Play 스크린샷 크기 가이드를 참고하세요.
- 대상, 신뢰 수준, MDE를 설정하세요. 변형 간 트래픽을 배분하세요(보통 균등하게 — 변형 하나 대 컨트롤이면 50/50, 변형이 셋이면 대략 3분의 1씩). 신뢰 수준(90%, 95%, 98%, 또는 99%)과 최소 검출 효과를 선택하세요 — 감지할 가치가 있는 최소 개선폭으로, 대략 0.5%~6% 범위에서 설정할 수 있어요. Play Console은 완료 조건을 보여주기 때문에 시작 전에 무엇을 감수하는지 미리 확인할 수 있어요.
- 시작한 뒤에는 손대지 마세요. 변형이 앞서 나가는 것처럼 보이는 순간 들여다보고 일찍 중단하고 싶은 충동을 이겨내세요. 처음에 정한 조건까지 그대로 실행하세요.
표본 크기, 기간, 그리고 유의미성 도달하기
"얼마나 오래 돌려야 하나요?"에 대한 정직한 답은: 고정된 일수가 아니라 설정한 유의미성 조건에 도달할 때까지예요. 하지만 현실적인 하한선과 상한선은 있어요.
- 최소 7일은 실행하세요. 설치 행태는 평일과 주말 사이에 오르내려요. 일주일이 채 안 되면 결과에 요일 편향이 섞여 들어가요. 2주(14일)가 흔히 쓰이는 안전한 기본값이고, 트래픽이 적은 앱은 28일이 필요한 경우도 많아요.
- 변형별로 의미 있는 만큼의 설치 수를 확보하세요. 유의미성은 설치량, 변형 개수, 신뢰 수준, MDE의 함수예요. 대략적인 기준으로, 결과를 신뢰하기 전에 변형당 1,000건 이상의 설치를 목표로 삼으세요 — 신뢰 수준을 높게 잡거나 MDE를 작게 잡을수록 더 많이 필요해요.
- 설정을 빡빡하게 잡을수록 트래픽 비용이 커져요. 신뢰 수준 99%나 MDE 0.5%는 90%/3%보다 훨씬 많은 설치 수가 필요해요. 앱의 트래픽이 적다면 까다로운 설정으로는 영영 유의미한 수준에 도달하지 못할 수 있어요 — MDE를 완화하거나 90%로 타협하세요.
"결론 없음"으로 끝나는 테스트도 실패가 아니라 하나의 실제 결과예요. 대부분은 트래픽 수준에서 구분하기엔 변형들이 너무 비슷했거나, 충분히 오래 돌리지 않았다는 뜻이에요. 둘 다 고칠 수 있어요 — 변형을 더 뚜렷하게 다르게 만들거나, 시간을 더 주세요.
변형 개수 제한과 그 의미
컨트롤 대비 변형 세 개가 실험당 절대적인 상한선이에요. 이건 맞서 싸워야 할 제약이 아니라 하나의 설계 특징이에요. 변형이 늘어날수록 트래픽이 더 얇게 쪼개지고 유의미성 도달 시점은 더 멀어져요. 도전자 세 개면 이미 스토어 트래픽을 네 갈래(컨트롤 + 3)로 나누고 있는 셈이에요. 대부분의 앱에서는 흐릿한 변형 네 개보다 컨트롤 대비 확실히 다른 도전자 하나를 테스트하는 편이 결론에 더 빨리 도달해요.
슬롯은 진짜로 다른 가설에 써야 해요 — 다른 핵심 이점, 다른 비주얼 스타일, 세로형 vs 넓은 다중 패널 레이아웃 같은 식으로요. 같은 아이디어의 미묘한 변주에는 쓰지 마세요.
피해야 할 함정들
- 변수를 하나 이상 바꾸기. 새 스크린샷과 새 짧은 설명을 한 테스트에 함께 넣으면 결과를 해석할 수 없어요. 변수를 분리하세요.
- "승자"가 보인다고 일찍 중단하기. 초반 리드는 나중에 되돌아오곤 해요. 3일 차에 변형이 8% 앞서 있다고 그대로 확정하는 건 확신을 갖고 더 나쁜 리스팅을 배포하는 지름길이에요.
- 7일 미만으로 실행하기. 주간 주기의 일부만 포착하고 나머지는 놓치게 돼요.
- 트래픽이 적은 앱에 과도하게 빡빡한 통계 기준을 걸기. 설치 수가 적은데 99%/MDE 0.5%를 요구하면 결론도 안 나고 시간만 잡아먹는 테스트가 확정적으로 나와요.
- 1일 유지율을 무시하기. 과대 약속하는 스크린샷은 설치는 늘리고 유지율은 떨어뜨릴 수 있어요. 두 지표를 다 지켜보세요.
- 기본/현지화 구분을 잊기. 기본 그래픽 실험은 현지화된 리스팅을 받는 사용자에게는 영향을 주지 않아요 — 사용자 기반이 대부분 현지화돼 있다면 그쪽에서 테스트하세요.
- 마지막 스크린샷만 계속 테스트하기. Play Store에서는 처음 2~3개 패널이 설득력의 대부분을 만들어요. 그것부터 테스트하세요. (Play와 Apple의 차이에 대해 더 알고 싶다면: Play Store vs App Store 스크린샷 차이점.)
Mokbi가 맞는 지점
Mokbi가 A/B 테스트를 직접 돌리지는 않아요 — 그건 Play Console이 하는 일이고, 무료예요. 대부분의 팀을 늦추는 건 변형을 애초에 만드는 작업이에요. 설득력 있는 도전자를 만들려면 정확한 Play 규격에 맞춘 전체 스크린샷 세트가 필요하고, 캡션과 레이아웃이 실제로 바뀌어야 해요. Mokbi에서는 브라우저에서 세트 하나를 디자인한 다음, 그걸 복제해서 메인 캡션, 레이아웃, 또는 배경을 바꿔 변형 B를 만들 수 있어요 — 여러 시장에서 현지화 실험을 돌린다면 캡션을 원클릭으로 번역할 수도 있어요. 디자인은 워터마크가 있는 미리보기까지 무료이고, 워터마크 없는 무제한 내보내기와 스토어 게시는 구독으로 제공돼요 — Solo €29.99/mo(앱 1개) 또는 Studio €49.99/mo(앱 최대 5개)이고, 일회성 구매는 없어요. 도전자를 빠르게 만들어내는 건 여기서 하고, 어느 쪽이 이길지는 Play Console이 결정해요.