테스트를 통과하는 App Store 스크린샷 모범 사례

실제로 App Store 스크린샷 모범 사례로 간주되는 것

App Store 스크린샷 모범 사례는 두 부류로 나뉘며, 이를 혼동하는 것이 흔한 실수입니다.

제약 조건은 Apple이 강제하는 사항과 스토어가 기계적으로 표시하는 사항입니다. 이는 의견이 아닙니다. 한 번만 정확히 맞추고 다시 읽는 데 시간을 쓰지 마세요.

• 검색 결과의 스크린샷. 방향에 따라 첫 번째부터 세 번째 이미지까지 검색 결과에 표시되며, Apple의 제품 페이지 가이드에 따르면 앱 미리보기 비디오를 사용할 수 없을 때만 표시됩니다. 나머지는 사용자가 제품 페이지를 열 때까지 기다립니다.
• 크기 및 형식. Apple의 스크린샷 사양에서 업로드 범위를 정합니다. 실무용 목록은 App Store 스크린샷 크기 및 규격 게시물에서 확인할 수 있습니다.
• 앱 아이콘. 어디에나 표시됩니다. 검색 결과, 페이지, 홈 화면까지입니다. 자세한 내용은 앱 아이콘 디자인 방법에서 확인하세요.
• 앱 미리보기 비디오. 음소거 상태로 자동 재생되며, 한 페이지에 최대 세 개까지 표시할 수 있습니다. 비디오가 있으면 스크린샷이 차지했을 검색 결과 슬롯을 대신 차지합니다. 규칙은 Apple의 앱 미리보기 페이지에서 확인할 수 있습니다.

핵심 포인트: 제약 조건 계층 밖의 스크린샷 규칙은 자체 트래픽이 달리 말하기 전까지 모범 사례가 아니라 가설입니다.

가설은 그 밖의 모든 것입니다. 어두운 배경, 첫 프레임의 캡션, 첫 번째 이미지의 얼굴, 기능 순서 등이 여기에 해당합니다.

각각은 다른 검색 의도를 가진 다른 잠재고객에게서 검증되었습니다. 여러분의 앱에서는 보기 좋은 스크린샷이 곁들여진 추측일 뿐입니다.

따라서 디자이너에게 브리핑하기 전에 모든 규칙을 두 부류 중 하나로 분류하세요. 그리고 가설 부류는 필수 요건이 아니라 출발점으로만 다루세요. 시도해 볼 만한 아이디어는 App Store 스크린샷 최적화 게시물에 있습니다.

스크린샷이 Apple Ads에서 지불하는 비용을 결정하는 이유

Apple Ads는 노출당이 아니라 탭당 비용을 청구하므로, 스크린샷은 지불하는 비용을 결정합니다. 결과를 좌우하는 세 가지 별도 요소가 있으며, 이를 구분해 두는 것이 도움이 됩니다.

• 입찰가는 상한선입니다. 지불할 수 있는 최대 금액을 제한합니다. 실제 지불 금액을 정하지는 않습니다.
• 관련성이 노출을 결정합니다. 크리에이티브 문제가 나오기 전에, 키워드의 의미와 스토어 등록 정보의 일치도가 광고 노출 자격 여부를 결정합니다.
• 에셋 반응이 노출의 가치를 결정합니다. 앱 아이콘과 선행 스크린샷은 탭률을 좌우합니다. 나머지 제품 페이지는 탭 후 다운로드 전환율을 좌우합니다.

핵심 포인트: 입찰가는 탭 비용의 상한을 정합니다. 관련성과 에셋 반응은 노출 여부와 실제 지불 금액을 결정합니다.

이제 문서화된 메커니즘이 아니라 관찰에 관한 부분입니다.

제가 지켜본 바로는 전환이 좋지 않은 앱은 볼륨이 줄어들고 탭 비용이 더 비싸집니다. 이는 사람들이 입찰가를 올려 해결하려는 바로 그 두 가지 문제입니다. Apple은 이 로직을 공개하지 않으므로, 이를 계획의 기반이 되는 규칙이 아니라 관찰해야 할 패턴으로 다루세요.

어느 쪽이든 실무적 결론은 같습니다. 약한 에셋 세트는 디자인 문제일 뿐 아니라 비용 문제입니다.

에셋 작업은 대개 여기서 충분히 마무리되지 못합니다. 리디자인을 출시하고 나면 CPT나 탭률에 어떤 일이 일어났는지 다시 확인하는 사람이 없습니다.

Custom product pages는 각 검색 의도에 맞는 에셋을 제공합니다

Custom product pages는 서로 다른 트래픽에 서로 다른 에셋 세트를 보여주는 제품 페이지 변형이며, Apple Ads 광고 그룹은 특정 페이지를 가리킬 수 있습니다.

이것이 중요한 이유는 모든 사용자에게 하나의 기본 페이지를 제공하는 방식이 평균화 장치이기 때문입니다.

브랜드명을 검색하는 사람과 일반 카테고리 용어를 검색하는 사람은 같은 사람이 아닙니다. 현재 이들은 동일한 에셋으로 유입됩니다.

출발 가설은 이렇습니다. 브랜드 검색자는 확신을 원하고, 카테고리 검색자는 첫 번째 이미지에서 여러분의 차별점을 원합니다. 이는 테스트를 시작할 지점이지 사람들이 행동하는 방식에 대한 사실은 아닙니다.

핵심 포인트: 검색 의도별로 에셋을 세분화하는 것은 custom product pages가 가능하게 하는 일입니다. 각 의도에 무엇을 말할지는 테스트가 결정합니다.

필요한 페이지 수는 목표 숫자가 아니라 키워드 테마에서 나옵니다. 자연스러운 후보는 다음과 같습니다.

• 브랜드
• 경쟁사
• 카테고리 및 일반 키워드
• 기능 또는 사용 사례

고유한 의도가 있고 충분한 볼륨이 있는 테마라면 자체 페이지를 가질 수 있습니다. 그 정도 볼륨이 없는 테마는 기본 페이지에 두어도 괜찮습니다.

이는 크리에이티브에 적용한 단일 키워드 광고 그룹 논리입니다. 볼륨이 뒷받침되는 곳에서는 강력한 통제를 제공하고, 그렇지 않은 곳에서는 순수한 오버헤드가 됩니다. 어디에서나 따라야 할 규칙은 아닙니다.

작동 방식은 App Store의 custom product pages와 Apple의 custom product pages 문서에서 확인할 수 있습니다.

추측 없이 App Store 에셋을 A/B 테스트하는 방법

App Store 에셋 테스트는 그 뒤에 있는 광고 그룹에 실제 이력이 있을 때만 답을 제공합니다. 한 달에 몇 건의 설치만으로는 크리에이티브가 아니라 노이즈를 측정합니다.

이 때문에 제대로 된 도구는 이력 없이는 시작을 거부합니다. 먼저 밝히자면, 저는 Adapty에서 일하므로 이는 중립적인 견해가 아닙니다.

• 이력. Adapty Ads Manager의 CPP A/B 테스트는 소스 광고 그룹이 최소 28일 이상 운영되었고, 해당 기간 동안 노출, 탭, 설치 기록이 있어야 합니다.
• 변형. 테스트는 2~4개의 제품 페이지를 비교합니다. custom page가 기준선을 이기는지 알고 싶을 때는 기본 페이지를 대조군으로 사용할 수 있습니다. custom pages만 테스트해도 괜찮습니다.

트래픽 수준은 변형이 교체되는 속도도 결정합니다.

트래픽이 낮다고 테스트를 할 수 없는 것은 아닙니다. 답을 얻는 데 몇 달이 걸린다는 의미일 뿐입니다.

핵심 포인트: 에셋 테스트는 그 뒤에 있는 광고 그룹에 신호와 노이즈를 구분할 충분한 이력이 있을 때만 의미가 있습니다.

실행 방법:

1. 아직 아무도 결과를 보고 있지 않은 출시 전에 판정 지표에 합의하세요. 변형 테이블은 TTR, 탭 후 다운로드 CR, CPT, CPA, 지출, 매출, ROAS를 보고합니다.
2. 이력이 있는 광고 그룹 하나를 선택해 여러 페이지를 서로 비교할 수 있게 하세요.
3. 기본 페이지를 대조군으로 포함하거나 포함하지 않고 2~4개의 변형을 선택하세요.
4. 정밀도, 즉 테스트가 감지할 수 있는 최소 전환 차이를 설정하세요. 옵션은 1%5%이며 기본값은 5%입니다. 34%가 균형 잡힌 선택입니다.
5. 신뢰도를 설정하세요. 범위는 80%~99%이고 기본값은 90%입니다. 신뢰도가 높을수록 더 많은 데이터와 시간이 필요합니다.
6. 시작하세요. 시스템은 변형마다 광고 그룹을 하나씩 복제하고, 한 번에 하나의 복제본을 실행하며, 설정한 일정에 따라 교체합니다. 종료 시 원본이 복원됩니다.
7. 승자 규칙을 엄격하게 해석하세요. 변형이 판정 지표에서 95% 이상의 신뢰도로 앞설 때만 전체 승자가 됩니다. 변형들이 비교 가능한 노출 수를 확보하기 전에는 아무것도 강조 표시되지 않습니다.

Apple의 제품 페이지 최적화는 오가닉 트래픽을 대상으로 한 테스트를 다룹니다. 위 프로세스는 유료 미디어 버전입니다.

아직 개발 중인 것이 하나 있습니다. 제품 페이지만이 아니라 Apple Ads용 광고 크리에이티브 자체를 테스트하는 기능입니다. 아직 출시되지 않았습니다.

Mykola MartynovetsHead of Ads Manager