CPP, PPO 및 스토어 리스팅 테스트
App Store 맞춤 제품 페이지, 제품 페이지 최적화 테스트, 제품 페이지 변형, 캠페인 페이지 및 전환 테스트 계획에 사용합니다.
MCP 워크플로
app-store-connect-mcp를 사용합니다.- CPP/PPO 도구는 이후에 계획되어 있습니다. CPP/PPO 도구가 이미 존재하는 경우, 수정하기 전에 현재 페이지/테스트를 읽으십시오.
- 활성 로컬호스트 서버에 CPP/PPO MCP 도구가 없는 경우, 저장 가능한 계획을 생성하고 라이브 입력이 아직 불가능함을 명확히 알리십시오.
- 사용자가 명시적으로 요청하지 않는 한, CPP/PPO 초안을 편집하는 동안 기본 제품 페이지 메타데이터를 덮어쓰지 마십시오.
대상 결정
- PPO: 기본 제품 페이지에 대한 네이티브 App Store A/B 테스트입니다.
- CPP: 캠페인, 광고 그룹, 잠재고객, 키워드 클러스터, 국가, 크리에이터/파트너 링크 또는 계절별 프로모션을 위한 타겟 제품 페이지입니다.
- Google Play 스토어 리스팅 실험: Play 전용 실험에는
android-aso를 사용하십시오.
Apple PPO 사실
- 앱 아이콘, 스크린샷 및 앱 미리보기를 테스트합니다.
- 테스트당 최대 3개의 처리군을 사용할 수 있습니다.
- 테스트 처리군에 표시되는 트래픽 비율을 선택합니다.
- 테스트는 최대 90일 동안 실행되거나 수동으로 중단될 때까지 실행됩니다.
- App Analytics는 신뢰도가 90%에 도달하면 결과에 레이블을 지정할 수 있습니다.
- PPO는 맞춤 제품 페이지, Apple Watch 제품 페이지 또는 iMessage 제품 페이지에는 사용할 수 없습니다.
- 앱 아이콘 변형은 현재 앱 바이너리에 포함되어야 하며 아이콘 요구 사항을 충족해야 합니다.
Apple CPP 사실
- 앱당 최대 70개의 맞춤 제품 페이지를 생성할 수 있습니다.
- 각 페이지는 스크린샷, 앱 미리보기, 프로모션 텍스트 및 키워드를 변경할 수 있습니다.
- CPP는 고유 URL이 있는 타겟 페이지이며, 무작위 A/B 테스트가 아닙니다.
- CPP는 Apple Ads에서 사용할 수 있으며 키워드로 구성된 경우 관련 검색 결과에 표시될 수 있습니다.
- CPP 메타데이터는 표시되기 전에 승인을 받아야 합니다.
테스트 설계 프레임워크
변형을 작성하기 전에 가설을 먼저 작성하십시오:
만약 [변경]한다면, [지표]가 개선될 것이다. 왜냐하면 [이유] 때문이다.
좋은 테스트:
- 한 번에 하나의 주요 항목을 변경합니다.
- 변형을 감지할 수 있을 만큼 의미 있게 만듭니다.
- 각 변형을 사용자 의도 또는 전환 장애물과 연결합니다.
- 기준선, 성공 지표, 대상 로케일/국가 및 최소 실질적 개선 폭을 정의합니다.
- 실행 전 신뢰도 임계값과 최소 실행 시간을 결정합니다. PPO의 경우, 사용자가 다른 기준을 제시하지 않는 한 90% 신뢰도를 최소 실용적인 기준으로 간주합니다.
- 결과가 유망해 보인다고 해서 조기에 중단하지 마십시오.
- 테스트가 결정적이지 않더라도 결과와 학습 내용을 문서화합니다.
테스트 우선순위
| 요소 | 테스트 이유 |
|---|---|
| 앱 아이콘 | 검색/리스팅 주목도에 높은 영향; PPO 아이콘 테스트를 위해서는 바이너리 지원 필요 |
| 첫 번째 스크린샷 | 검색 및 제품 페이지 스캔에서 높은 영향 |
| 스크린샷 순서 | 노력이 적고, 가치 전달 순서를 명확히 함 |
| 스크린샷 스타일/메시지 | 혜택 vs 기능, 증거 vs 워크플로, 잠재고객 각도 테스트 |
| 앱 미리보기 | 움직임이 정적 이미지보다 가치를 더 잘 설명할 때 유용 |
앱별 데이터 없이 개선율(%)을 약속하지 마십시오.
전략 체크리스트
- 목표: 전환율 향상, 광고 관련성, 시장 출시, 시즌 캠페인 또는 기능 채택.
- 잠재고객: 페이지/처리군당 하나의 의도 세그먼트.
- 트래픽 소스: Search Ads, 소셜 광고, 웹, 인플루언서, 소유 채널 또는 유기적 테스트.
- 로케일과 국가는 명시적입니다.
- 스크린샷과 앱 미리보기는 광고/키워드 카피의 약속과 일치합니다.
- 메타데이터는 앱이나 에셋이 지원하지 않는 주장을 하지 않습니다.
- 기존 노출수/다운로드 수가 의미 있는 PPO 테스트를 실행하기에 충분하거나, 계획에서 낮은 샘플 위험을 인지합니다.
- CPP 성능은 페이지 조회수, 다운로드, 전환 및 다운스트림 품질로 측정되며, 단순 클릭량만으로 측정하지 않습니다.
결과 해석
결과를 사용할 수 있는 경우:
- 신뢰도, 전환율 및 신뢰 구간/불확실성을 확인합니다.
- 가능한 경우 지역, 소스 유형, 기기 및 현지화별로 비교합니다.
- CPP의 경우 트래픽 품질 및 다운스트림 이벤트, 구독 또는 판매를 사용할 수 있다면 비교합니다.
- 결정: 승자 적용, 반복, 현재 유지 또는 새로운 가설 실행.
- 결과가 결정적이지 않거나 승리 세그먼트가 목표 세그먼트가 아닌 경우 처리군을 적용하지 마십시오.
출력
# 스토어 리스팅 테스트 계획
유형:
앱:
국가:
로케일:
트래픽 소스:
목표:
기준선:
성공 지표:
## 가설
우리가 ..., 그러면 ..., 왜냐하면 ...
## 현재 상태
| 필드 | 값 | 비고 |
|---|---|---|
## 변형
| 변형 | 변경 | 가설 | 필요한 에셋 |
|---|---|---|---|
## 스크린샷/앱 미리보기 시퀀스
| 위치 | 메시지 | 시각적 방향 | 소스 에셋/상태 |
|---:|---|---|---|
## 샘플 및 타이밍
- 일일 노출수:
- 필요 샘플:
- 예상 기간:
- 낮은 샘플 위험:
## 결과 해석
| 변형 | 전환율 | 신뢰도 | 결정 |
|---:|---|---:|---|
## 로드맵
| 월 | 테스트 | 이유 |
|---|---|---|
## 검증
- 올바른 대상 선택: PPO/CPP/Play 실험:
- 명확한 잠재고객:
- 광고/키워드 약속 일치:
- 로케일 준비 완료:
- 에셋 사용 가능:
- 검토/제출 필요:
- 지원되지 않는 주장 제거:
- MCP 입력 가능:
규칙
- 각 CPP/PPO 변형은 하나의 약속에 집중합니다.
- 의미 있는 가설 없이 기본 페이지를 복제하지 마십시오.
- 성과 지표, 잠재고객 데이터 또는 Search Ads 결과를 임의로 만들지 마십시오.
- PPO의 경우 필드를 작성하기 전에 기준선과 성공 지표를 정의하십시오.
- CPP의 경우, 트래픽이 외부적으로 무작위화되고 측정되지 않는 한 A/B 테스트라고 부르지 마십시오.
- Play 스토어 실험의 경우
android-aso를 사용하십시오.