제품 페이지 최적화 덕분에 스크린샷 A/B 테스트는 무료입니다. 어려운 건 무엇을 테스트할지 정하는 일입니다. '스크린샷을 더 좋게 만든다'는 테스트가 아닙니다. '첫 번째 스크린샷에 기능 이름 대신 혜택을 담은 헤드라인을 쓰면 전환율이 더 높을 것이다. 사람들은 검색 결과에서 결과를 찾기 때문이다'는 테스트입니다.
아래 아이디어마다 변경, 가설(이길 수 있는 이유), 승리 기준 세 가지를 붙였습니다. 하나를 골라 변형을 만들고, 판단은 데이터에 맡기세요.
아이디어를 고르기 전에 #
- 변형 하나에는 변경 하나만. 테스트 하나에 변형을 최대 3개까지 넣을 수 있습니다. 서로 관계없는 아이디어 세 개가 아니라, 같은 아이디어의 세 가지 버전을 시도하는 데 쓰세요.
- 트래픽이 적다면 과감하게. 5% 개선을 확인하려면 20% 개선보다 약 15배 많은 노출이 필요합니다. 시작하기 전에 A/B 테스트 계산기로 테스트 기간을 확인하세요.
- 가설을 먼저 적어 두세요. 결과가 나온 뒤에 이유를 끼워 맞추는 걸 막아 줍니다.
첫 번째 스크린샷 #
처음 몇 장의 스크린샷은 검색 결과에 바로 보이고, 대부분의 사람은 페이지를 열지 않고 그것만으로 앱을 판단합니다. 여기서부터 시작하세요.
1. 다른 기능을 앞세우기
- 변경: 두 번째로 강한 기능을 첫 번째 슬롯에 둡니다.
- 가설: 내가 가장 자랑스러워하는 기능이 사람들이 찾는 기능은 아니다.
- 승리 기준: 원본보다 전환율이 높다.
2. 혜택 헤드라인 vs 기능 헤드라인
- 변경: '지출 기록'을 '내 돈이 어디로 가는지 한눈에'로 바꿉니다.
- 가설: 사람들은 기능이 아니라 결과를 산다.
- 승리 기준: 이미지는 그대로인데 전환율이 오른다. 전환율을 높이는 캡션 작성법도 참고하세요.
3. 입력이 아니라 결과를 보여 주기
- 변경: 그것을 만드는 빈 양식 대신 완성된 보고서, 사진, 계획을 보여 줍니다.
- 가설: 과정보다 결과물이 더 설득력 있다.
4. 첫 두 장을 파노라마로
- 변경: 1번과 2번 스크린샷을 두 프레임에 걸친 하나의 이어진 이미지로 만듭니다.
- 가설: 이미지가 이어지면 2번 스크린샷까지 넘겨 보게 된다.
5. 사회적 증거를 맨 앞에
- 변경: 실제 수상 경력, 평점, 다운로드 달성 기록을 첫 번째 스크린샷에 넣습니다.
- 가설: 다운로드를 막는 건 기능이 아니라 신뢰다.
- 참고: 근거를 댈 수 있는 주장만 쓰세요. 그렇지 않으면 App Review에서 거절될 수 있습니다.
캡션 #
6. 더 짧은 캡션
- 변경: 모든 헤드라인을 네 단어 이하로 줄입니다.
- 가설: 헤드라인은 작은 썸네일에서 약 2초 안에 읽히므로 단어가 적을수록 잘 전달된다.
7. 헤드라인에 숫자 넣기
- 변경: '인보이스 작성 시간 절약'을 '30초 만에 인보이스 보내기'로 바꿉니다.
- 가설: 구체적인 숫자는 막연한 주장보다 믿음이 간다.
8. 질문 vs 서술
- 변경: '오늘 밤 푹 주무세요' 대신 '잠이 안 오나요?'를 씁니다.
- 가설: 질문은 읽는 사람의 문제를 짚어 주고 멈춰 서게 만든다.
9. 더 큰 글자
- 변경: 검색 결과 썸네일에서도 읽을 수 있도록 캡션 크기를 키웁니다.
- 가설: 아무도 읽을 수 없는 캡션은 아무것도 팔지 못한다.
10. 캡션을 기기 위에 둘까, 아래에 둘까
- 변경: 캡션을 기기 위에서 아래로 옮깁니다.
- 가설: 가장 먼저 보여야 할 것은 텍스트가 아니라 앱이다. (반대일 수도 있습니다. 테스트해 보세요.)
비주얼 스타일 #
11. 라이트 vs 다크 스크린샷
- 변경: 앱을 다크 모드로 보여 주거나, 라이트 UI를 어두운 배경 위에 둡니다.
- 가설: 스타일 자체보다 검색 결과에서 주변 경쟁 앱들 사이에 눈에 띄는 것이 더 중요하다.
12. 브랜드 색상 vs 대비 색상
- 변경: 브랜드 색상 배경을, 카테고리에서 흔히 보이는 색감과 가장 대비되는 색으로 바꿉니다.
13. 그라디언트 vs 단색 배경
- 변경: 그라디언트 대신 단색을 쓰거나, 그 반대로 합니다. 템플릿에 두 스타일이 모두 있으니 여기서 시작할 수 있습니다.
14. 기기 프레임 있음 vs 없음
- 변경: 기기 프레임을 없애고 UI가 스크린샷을 가득 채우게 합니다.
- 가설: 프레임이 UI에 쓸 수 있는 공간을 차지한다.
15. 기울이거나 3D로 표현한 기기
- 변경: 정면의 평평한 모습 대신 기기를 기울이거나 입체감을 줍니다.
- 가설: 평평한 기기들 사이에서 다르게 생긴 기기가 눈길을 끈다.
16. 핵심 UI 확대
- 변경: 화면 전체 대신 중요한 요소 하나(차트, 버튼, 결과)를 확대합니다.
- 가설: 화면 전체를 썸네일 크기로 줄이면 아무것도 보이지 않는다.
순서와 스토리 #
17. 순서 뒤집기
- 변경: 5번 스크린샷을 맨 앞으로 옮깁니다.
- 가설: 가장 최근에 추가한 기능이 지금 사람들이 가장 원하는 기능일 수 있다.
18. 문제 → 해결 스토리
- 변경: 첫 번째 스크린샷에서 문제를 말하고, 나머지에서 앱이 그 문제를 어떻게 해결하는지 보여 줍니다.
19. 스크린샷마다 기능 하나 vs 전체 개요 먼저
- 변경: 앱 전체를 담은 콜라주로 시작한 뒤 개별 기능으로 들어갑니다.
20. 스크린샷 줄이기
- 변경: 10장에서 5장으로 줄이고 가장 강한 것만 남깁니다.
- 가설: 뒤쪽의 약한 스크린샷이 앞쪽의 강한 스크린샷까지 의심하게 만든다.
- 승리 기준: 보여 주는 게 줄었는데도 전환율이 오른다.
사용자층과 시장 #
21. 다른 사용자에게 말하기
- 변경: 캡션을 직장인 대신 학생 대상으로, 또는 그 반대로 다시 씁니다.
- 가설: 한 그룹이 다른 그룹보다 훨씬 잘 전환된다.
22. 텍스트만이 아니라 비주얼도 현지화
- 변경: 한 시장을 위해 UI 속 콘텐츠(이름, 통화, 장소)를 현지 것으로 바꿉니다.
- 가설: 텍스트를 번역해도 미국식 예시 데이터 그대로면 여전히 외국 앱처럼 보인다. 현지화된 스크린샷 A/B 테스트도 참고하세요.
23. 시즌 변형
- 변경: 첫 번째 스크린샷을 연말연시나 신학기 버전으로 만듭니다.
- 참고: 시즌 테스트의 결과는 나머지 기간에 대해서는 많은 것을 알려 주지 않습니다.
스크린샷 너머 #
24. 앱 미리보기 영상 있음 vs 없음
- 변경: 앱 미리보기를 추가하거나 뺍니다.
- 가설: 맨 앞에 있는 약한 영상이 가장 좋은 스크린샷을 가린다.
- 형식은 앱 미리보기 사양 가이드에서 다룹니다.
25. 대체 앱 아이콘
- 변경: 아이콘의 색상이나 심볼을 바꿉니다.
- 참고: 테스트하는 모든 아이콘은 앱 바이너리에 들어 있어야 하므로, 먼저 앱 업데이트가 필요합니다.
빠르게 실행하는 방법 #
어떤 아이디어든 시간이 걸리는 건 변형을 만드는 일입니다. 모든 언어, 모든 기기 크기로 만든 다음 테스트에 업로드해야 합니다. Screenshot Studio에서는 캡션, 배경, 순서를 바꾸면 모든 언어와 크기에 한 번에 적용됩니다. 그런 다음 App Store Connect에 파일을 끌어다 놓을 필요 없이 제품 페이지 최적화 변형에 바로 업로드하면 됩니다.
시작하기 전에 테스트를 낭비하는 제품 페이지 최적화 실수를 읽고, A/B 테스트 계산기로 기간을 확인하세요.