Apple이 개발자가 사용자를 대상으로 앱을 더 잘 타겟팅하고, 더 많은 사람들이 앱을 발견할 수 있도록 하며, 앱 내에서 어떤 종류의 이벤트가 발생하여 새로운 사용자를 앱을 다운로드하고 기존 사용자의 재방문을 유도합니다.
Apple이 개발자가 사용자를 대상으로 앱을 더 잘 타겟팅하고, 더 많은 사람들이 앱을 발견할 수 있도록 하며, 앱 내에서 어떤 종류의 이벤트가 발생하여 새로운 사용자를 앱을 다운로드하고 기존 사용자의 재방문을 유도합니다. App Store를 통해 앱 제품 페이지의 시각적 요소를 A/B 테스트하여 더 나은 결과를 얻고 앱 다운로드 전환율을 개선할 수 있습니다.
App Store A/B 테스트는 ASO 전략을 개선하는 데 도움이 되며 App Store 제품 페이지에서 다양한 앱 아이콘, 스크린샷 및 미리보기(비디오)를 시도할 수 있습니다. 또한 제품 페이지의 실적을 비교하여 가장 전환율이 높은 항목을 확인할 수 있습니다.
App Store의 새로운 A/B 테스트 기능을 사용하면 최대 3개의 다른 요소를 테스트할 수 있습니다. 노출수 또는 전환율과 같은 App Store Connect의 App Analytics 섹션에서 주요 ASO KPI의 결과를 볼 수 있습니다. 원래 제품 페이지의 성능과 비교할 수 있습니다.
그러나 사용자 정의 제품 페이지(CPP)에는 기본 A/B 테스트가 포함되지 않지만 모바일 마케팅 팀이 테스트를 수동으로 실행할 수 있습니다. 새 설정에서 CPP(사용자 지정 제품 페이지)를 활용하고 모든 유료 UA 트래픽을 사용 가능한 35개의 사용자 지정 제품 페이지 중 하나로 유도하면 트래픽의 나머지 부분인 자연스러운 종료(탐색 및 검색 트래픽) 기본 제품 페이지로 이동합니다.
iOS15 모바일 성장에 대해 자세히 알아보려면 이전 기사의 " iOS15 새로운 기능이 모바일 성장을 이끄는 방법은 무엇입니까? "를 확인하십시오.
지금 ASO World 앱 프로모션 서비스 로 앱 및 게임 비즈니스를 추진하려면 " 자세히 알아보기 "를 클릭 하세요.
개발자는 곧 아이디어 세트의 변경 사항을 테스트할 수 있는 간소화된 방법을 갖게 될 것입니다. 역사적으로 iOS 개발자는 iOS App Store에 크리에이티브 변경 사항을 완전히 배포한 다음 배포 전후에 트래픽을 측정해야 했습니다. 추세와 트래픽은 배포 전에서 배포 후 기간으로 크게 변경될 수 있으므로 이 프로세스가 항상 최상의 통찰력을 제공하는 것은 아닙니다. 제품 페이지 최적화를 통해 앱의 기본 제품 페이지에서 직접 실시간으로 A/B 테스트를 수행할 수 있습니다.
개발자는 제품 페이지 최적화를 사용하여 애플리케이션 아이콘, 스크린샷 및 미리보기 비디오의 변형을 테스트할 수 있습니다. Apple은 각 테스트에 대해 최대 90일 동안 세 가지 다른 치료법을 한 번에 적용할 수 있도록 허용합니다.
가능한 한 많은 변경 사항을 테스트하고 싶을 수 있지만 Apple은 테스트당 창의적인 변경 사항의 수를 제한할 것을 권장합니다. 이는 모든 테스트 반복에 대한 모범 사례입니다. 변수를 제한하면 어떤 특정 변경 사항이 최상의 결과로 이어질지 더 쉽게 분리할 수 있습니다. 성능을 확인하고 기준과 비교하기 위해 개발자는 App Analytics에서 이러한 테스트에 액세스할 수 있습니다.
iOS 15 뒤에 있는 개발자를 위한 흥미로운 새 기능은 맞춤형 제품 페이지입니다. 맞춤형 제품 페이지는 목록을 선별하여 다양한 인구통계에서 동시에 관련성이 있도록 하는 새로운 방법입니다. 이 새로운 도구를 통해 개발자는 모두 동일한 앱을 가리키는 다양한 사용자 그룹에게 가장 관련성이 높은 위치를 표시할 수 있습니다.
Apple은 최대 35개의 고유한 맞춤형 제품 페이지를 허용하며, 각 페이지는 다양한 스크린샷, 앱 미리보기 및 홍보 문구를 통해 다양한 기능에 대한 통찰력을 제공합니다. 그런 다음 개발자는 관련 광고 또는 제3자 평가에 배치될 고유 URL을 사용하여 적절한 제품 페이지로 트래픽을 유도할 수 있습니다.
맞춤형 제품 페이지에 대한 성능 데이터는 App Analytics에서도 사용할 수 있습니다. 타겟 페이지 보기는 노출수, 앱 다운로드, 앱 설치 전환율 및 유지율에 대한 실행 가능한 데이터를 제공합니다.
성능을 최적화할 수 있는 더 많은 도구를 개발자에게 제공하는 것 외에도 새로운 측정항목을 통해 이전에는 App Analytics가 제공할 수 없었던 방식으로 성능을 이해할 수 있습니다. 2020년에 새로운 Google Play 개발자 콘솔로 보고된 많은 측정항목을 변경하는 Google과 달리 Apple은 노출수 및 앱 단위와 같은 친숙한 측정항목을 유지하면서 새로운 측정항목을 추가합니다.
이제 개발자는 지역 및 장치 유형과 같은 친숙한 지표로 구분된 전용 사전 주문 대시보드를 갖게 됩니다. 이제 장치 유형에는 호환되는 앱용 macOS가 포함됩니다. 메트릭 탭에서 시간 경과에 따른 선 그래프에서 선주문을 확인하여 출시 전날까지 선주문 시작 시 참여도를 확인할 수 있습니다.
수익은 개발자가 앱 분석과 "판매" 및 "인앱 구매"를 통해 볼 수 있는 또 다른 새로운 지표입니다. 앱이 수익을 얻는 방법에 대한 추가 통찰력은 개발자가 구매율을 높이기 위해 최적화하는 방법을 더 잘 이해하는 데 도움이 될 수 있습니다.
Apple은 또한 이전에 보고되지 않은 측정항목이었던 "업데이트" 및 "재다운로드"를 App Analytics에 추가할 것입니다. 이를 통해 개발자는 "앱 단위"를 통해 첫 번째 다운로드를 볼 수 있을 뿐만 아니라 전체 다운로드를 볼 수 있으며 신규 사용자와 재방문 사용자를 구분할 수 있습니다. 개발자는 궁극적으로 신규 사용자 참여뿐 아니라 기존 사용자의 재참여 업데이트 및 재다운로드를 통해 진행 중인 기존 사용자 참여에 대한 통찰력을 갖게 됩니다.
사용자 참여 전략에 대해 자세히 알아보려면 이전 기사에서 " 모바일 사용자 참여 전략이 앱 비즈니스를 이끄는 방법 ? "을 확인하세요.
2015년 5월부터 Google Play 스토어는 개발자가 Google Play 실험을 통해 A/B 테스트를 수행할 수 있도록 허용하여 개발자에게 앱 스토어 최적화 전략을 개발하는 데 유용한 도구를 제공합니다. A/B 테스트는 iOS 개발자가 더 이상 새 버전을 배포하고 제품 페이지의 변경 사항이 제품 페이지 전환율에 미치는 영향을 측정하기 위해 이전 및 이후 메트릭을 비교할 필요가 없도록 iOS15에서 곧 사용할 수 있습니다.
그러나 흥미로운 것처럼 보이지만 Apple의 A/B 테스트 플랫폼은 Google의 플랫폼과 동일하지 않습니다. 수반되는 불확실성은 많은 잠재적인 합병증으로 쉽게 이어질 수 있습니다. 이를 조기에 해결하고 그에 따라 미리 계획하는 것이 중요합니다. ASOWorld 기술팀은 여러분이 준비할 수 있도록 아래의 7가지 근본적인 차이점을 기대합니다.
A/B 테스팅은 정량적 조사 방법입니다. 이것은 각 테스트의 이면에 있는 통계가 그 테스트의 혈액임을 의미합니다. 충분한 데이터를 수집하고 분석하면 특정 가설을 과학적으로 검증하거나 거부할 수 있는 신뢰할 수 있는 테스트 결과를 얻을 수 있습니다. 이러한 가설 이면의 아이디어는 궁극적으로 CRO를 이끄는 것입니다. 그렇기 때문에 App Store의 A/B 테스트가 Play Store와 다른 양과 형식의 데이터를 가질 때 전체 CRO가 변경됩니다.
다음은 알아야 할 가장 중요한 차이점입니다.
구글은 테스트 결과에 대해 90%의 통계적 유의 수준을 제공하지만 애플이 비교할 만한 것을 제공할지는 미스터리로 남아 있다. 사실, 그들의 발표에 이 주제가 (아직) 언급되지 않았기 때문에 그들이 신뢰 구간을 제공할지 여부는 알 수 없습니다.
Google은 각 테스트 변형의 타임아웃 실행을 지속적으로 매핑하는 차트를 보여줍니다. 필요한 경우 더 자세한 통찰력을 위해 과거 실적을 보도록 선택할 수 있습니다.
반면에 Apple은 유사한 기능을 제공한다는 증거가 없습니다. 그들은 "테스트 기간 동안 원래 제품 페이지와 [테스트 변형의] 성능을 비교할 수 있다"고만 언급합니다. 이 비교가 현재 및 과거 성능에 적용되는지 여부는 아직 결정되지 않았습니다.
Google은 테스트 변형 간의 설치 수, 확장 설치 및 전환율(CVR) 차이만 표시합니다. 따라서 서로 비교하여 얼마나 잘 또는 잘못되었는지 추정할 수 있습니다. 대신 Apple은 CVR 차이(개선 사항) 위에 각 변형에 대한 트래픽 크기(노출수)와 정확한 CVR을 표시합니다. 즉, 개별 버전을 조사하거나 버전을 비교하는 것은 사용자에게 달려 있습니다.
Google Play에서 앱 제목/이름을 제외한 모든 현지화 가능한 자산은 A/B 테스트 대상입니다. 더 중요한 것은 시각적 요소와 텍스트 요소가 포함된다는 것입니다. 이것은 매우 다양한 CRO 전략을 위한 충분한 용량을 제공합니다.
대조적으로 App Store의 시각적 자산만 A/B 테스트에 적합한 것으로 식별되었습니다. 아이콘, 스크린샷 및 미리보기(동영상)입니다. 텍스트 자산에 대한 추가 정보는 제공되지 않았습니다.
그러나 Product Page Optimization 및 Custom Product Pages에서 허용되는 다양한 자산을 살펴보면 전혀 없을 수도 있습니다. 특히 Apple은 후자와 관련된 홍보 문구를 언급하지만 전자는 언급하지 않습니다. 이 사실에 대해 고려해야 할 요소는 다음과 같습니다.
물론 이것은 아직 확인되지 않았습니다. 그러나 불확실할 때는 최악의 시나리오에 대비하는 것이 가장 안전합니다. 이것이 사실로 판명되면 Play 스토어에 비해 App Store의 A/B 테스트에서 선택할 수 있는 자산의 범위가 훨씬 좁아집니다.
이것은 또한 맞춤 앱 스토어 존재와 A/B 테스트 간의 관계와 관련이 있습니다. 맞춤 Play 스토어 목록에 대한 실험을 확실히 실행할 수 있지만 맞춤 제품 페이지에서도 동일한지 여부는 여전히 문제입니다. 그렇다면 iOS CRO의 가능성은 예를 들어 "맞춤 제품 페이지 최적화"와 같은 것을 사용하여 크게 확장될 것입니다. 그러나 그것은 큰 "만약"입니다.
사실, 일부 증거는 이것이 사실이 아닐 가능성이 있음을 시사할 수 있습니다. 앞서 언급했듯이 프로모션 텍스트는 사용자 정의할 수 있지만 A/B 테스트를 할 수 없기 때문에 사용자 정의 제품 페이지와 제품 페이지 최적화 사이의 단절을 보여줍니다. 또 다른 증거는 테스트 가능하지만 사용자 정의할 수 없는 앱 아이콘입니다. 따라서 A/B 테스트가 사용자 정의 제품 페이지에서 실행될 수 있다면 앱 스토어는 견딜 수 없을 정도로 일관성이 없게 될 것입니다.
여기 문제가 있습니다. Apple이 허용하는 것처럼 들리지 않습니다. 즉, 단순히 두 기능 간의 교차를 허용하지 않습니다. 따라서 사용자 정의 제품 페이지의 A/B 테스트를 기대할 수 없다고 말하는 것이 안전합니다.
프로모션 텍스트와 아이콘은 두 기능의 차이점이지만 스크린샷과 미리보기에서 함께 혼합됩니다. 운이 좋다면 Apple은 맞춤형 제품 페이지에서 이 두 자산 중 하나 또는 둘 다를 테스트할 수 있습니다. 이 시나리오가 터무니없게 들리긴 하지만, 섣부르게 기각되어서는 안 되는 논리적 가능성입니다.
아이콘은 아이덴티티를 표현하는 애플리케이션의 중요한 시각적 자산입니다. 있다면 모든 앱 스토어에서 일관된 자산이어야 합니다. 불행히도 이것은 사실이 아닙니다.
첫째, 테스트용으로 새로운 아이콘을 Google Play에서만 업로드할 수 있지만 App Store에서는 업로드할 수 없습니다. Apple은 아이콘의 모든 변형(기기 및 스토어에 있음)을 사전에 앱 바이너리에 추가하고 새 앱 버전으로 검토하도록 요구할 것입니다. 따라서 거부되거나 지연되는 경우 A/B 테스트에 영향을 받게 됩니다.
둘째, 앱 바이너리 요구 사항과 관련하여 Google은 기기 내 자산과 매장 내 자산 간의 독립적인 변경을 허용하지만 Apple은 이들 간에 일정 수준의 아이콘 종속성을 적용합니다. 특히, 제품 페이지 최적화를 통해 앱 스토어 아이콘 변형을 적용하면 일치하는 온디바이스 아이콘 변형이 자동으로 원래 아이콘을 대체합니다.
현지화는 ASO, 특히 CRO의 경우 중요한 부분이므로 현지화된 제품 페이지에서 A/B 테스트를 실행할 수 있어야 합니다. 가장 중요한 것은 동시에 실행할 수 있는 현지화 테스트가 많을수록 전체 CRO를 보다 효율적으로 확장할 수 있다는 것입니다.
Google Play에서는 이러한 테스트가 최대 5개까지 허용됩니다(맞춤 제품 세부정보 제외). Apple App Store에서는 번호를 알 수 없습니다. 동일하다면 두 스토어에서 동일한 방식으로 CRO를 확장할 수 있으므로 많은 조정이 필요하지 않습니다. 대조적으로, 한 상점에서 다른 상점보다 훨씬 더 많은 테스트를 동시에 실행할 수 있는 경우 정보에 입각한 결정을 내리기 위해 미리 계획하고 둘 간의 차이점을 고려해야 합니다.
이것이 왜 중요합니까? 두 가지 요인.
앱 스토어용 CRO를 업그레이드할 수 있다면 무엇이 작동하고 무엇이 작동하지 않는지 빠르게 배울 수 있습니다. 더 많이 배울수록 더 많은 정보를 바탕으로 결정을 내릴 수 있습니다. 이것이 다른 확장성이 다른 수준의 CRO 성능으로 이어질 수 있는 이유입니다. 궁극적으로 자산 생산, 인적 자원, 시간 및 노력은 앱 스토어마다 다른 가치를 가질 것입니다. 그런 다음 다른 방식으로 관리해야 합니다.
중요하고 관련성 높은 캠페인을 시작하기 전에 모든 자산의 10개 현지화를 3개월 동안 테스트해야 한다고 상상해 보십시오. 동일한 아이디어 또는 가설에 대해 모든 콘텐츠를 다루기 위해 Play 스토어에서 2회 5회의 현지화 실험이 필요합니다. 각 라운드가 통계적으로 유의미한 결과를 생성하는 데 3주가 걸린다면 전체 시리즈를 완료하는 데 1.5개월이 필요합니다.
이는 3개월의 기간이 출시되기 전에 두 가지 아이디어를 테스트할 수 있음을 의미합니다. Apple이 동일한 조건에서 동시에 5개 미만의 테스트를 실행하도록 허용한다면 3개월 동안 10개의 현지화는 너무 많습니다. 더 적은 수의 아이디어를 테스트해야 하거나 더 적은 수의 현지화가 필요하거나 더 많은 시간이 필요합니다.
A/B 테스트를 설정할 때 유연성의 정도는 앱 스토어마다 다릅니다. 사실 차이는 두 가지 요인에 의해 발생합니다.
Google은 시각적 및 텍스트 자산에 대한 A/B 테스트를 허용하지만 Apple은 전자 자산만 테스트할 수 있도록 허용합니다. 즉, 아이디어, 개념, 메시지 또는 가설을 매력적인 카피로 만들 수 있다고 해도 테스트로 설정할 수는 없습니다. 이는 Google Play의 절반에 불과합니다.
Google Play의 테스트 설정은 여러 자산이 함께 결합될 때 더 유연해질 수 있습니다. 특히 텍스트-텍스트, 시각적-시각적 또는 시각적-텍스트 조합 실험이 있을 수 있습니다. App Store에서는 테스트에서 여러 자산을 결합할 수도 있습니다(그렇지 않으면 Apple에서 제한을 제안하지 않을 것입니다). 그러나 할 수 있는 가장 좋은 방법은 시각적-시각적 콤보 실험만 설정하는 것입니다.
우리가 그렇게 유연하지 않을 때 우리는 무엇을 합니까? 깊이를 추가합니다. 테스트에 텍스트 자산을 사용하지 않는다는 것은 시각적 자산으로 더 많이 테스트한다는 것을 의미합니다.
iOS15 사용자 정의 제품 페이지에 대해 자세히 알아보려면 이전 기사의 " iOS 15 ASO용 App Store 사용자 정의 제품 페이지(CPP)를 준비하는 방법은 무엇입니까? " 를 확인하십시오.
A/B 테스팅은 CRO에 영향을 미치는 기술적인 요소 이상을 포함합니다. 테스트의 디자인, 설정 및 가정 외에도 창의적인 아이디어, 개념 및 스토리도 다루어야 합니다. 이는 유형의 앱 스토어 자산으로 변환되며 테스트를 실행하기 전에 업로드해야 합니다. 따라서 대담하고 혁신적인 아이디어를 테스트하고 CVR의 향상에 기여할 수 있도록 충분한 창의적 자유를 갖는 것이 중요합니다.
물론 Apple과 Google은 이러한 창의적인 자유를 다양한 수준으로 허용합니다. Play 스토어에서 테스트 자산은 Google의 조사 대상이 아닌 것 같습니다. 모든 정책 및 메타데이터 가이드라인은 제품 세부정보 실험이 아닌 제품 세부정보에 적용됩니다. 따라서 "위험한" 변형을 적용하지 않는 한 제한 없이 모든 적격 자산으로 거의 모든 것을 테스트할 수 있습니다.
앱스토어에서는 스토리와 스토리텔링의 분리가 불가능합니다. Apple의 발표에 따르면 모든 개별 테스트 변형은 독립적으로 검토됩니다. 당신이 그들과 함께 용감하고 대담하지만 위험한 아이디어를 테스트하고 그들이 거부된다면, 당신은 그 아이디어가 효과가 있었는지 결코 알 수 없을 것입니다. 당신은 단지 구현하지 않았다는 것을 알게 될 것입니다. 또한 테스트 일정이 지연됩니다. 그렇기 때문에 Play 스토어에 비해 App Store A/B 테스트에서 덜 창의적인 자유를 다루어야 합니다.
CRO 전략은 App Store에서는 더 보수적이어야 하고 Play Store에서는 더 공격적이어야 합니다. 이것은 다음을 의미합니다.
상품 세부 실험은 더 높은 수준의 창의적 자유를 허용하기 때문에 대담하고 위험한 아이디어의 테스트 장이 되어야 합니다. 시간이 지나면 어느 것이 CRO에 좋은지 상대적으로 지적할 수 있습니다. 그런 다음 이러한 아이디어를 공개적으로 발표하는 데 사용할 수 있는 방법(Google에서 허용하는 방법)을 테스트하고 학습할 수 있습니다.
이 학습은 제품 페이지 최적화로 더욱 통합될 수 있습니다. 유사한 지침과 정책을 감안할 때 Google이 자산 반복을 수용한다는 사실을 알게 되면 Apple도 이를 수용할 것입니다. 이것이 거절 위험을 최소화하면서 App Store에서 대담한 아이디어를 테스트할 수 있는 방법입니다.
Play 스토어 A/B 테스트가 "선도"하기를 기다리는 동안 App Store A/B 테스트를 독립적으로 실행하여 "길을 찾을 수 있습니다. 안전한 아이디어에서 시작하여 "제한된 영역"에 접근할 때까지 더 위험한 아이디어로 이동 . CRO는 시간이 더 걸리지만 최소한 Android 테스트 결과를 기다리거나 테스트되지 않은 가정에 현혹되지는 않을 것입니다.
현재 버전과 변형 간의 잠재고객 할당입니다. 각 변형에 할당할 트래픽 부분을 결정할 때 현재 전환율, 테스트할 가설, 관련 요소 및 통계적 유의성(현재 Google Play 실험에서 90%)을 염두에 두십시오.
테스트 기간을 분할합니다. 결과에 영향을 줄 수 있는 계절적 급증을 방지하려면 테스트를 최소 7일 동안 실행하십시오. 상당한 잠재 고객이 테스트의 모든 변형에 참여할 때까지 테스트를 실행해야 합니다.
각 변형에 대한 최소 설치. /b 테스트의 성능 결과에 대한 중요한 데이터를 얻으려면 필요한 설치 수에주의를 기울여야합니다. 이는 애플리케이션의 일일 설치율과 밀접한 관련이 있습니다.
현지화 테스트 . 특정 국가에서 분할 테스트를 현지화하는 것이 좋습니다. 전 세계/글로벌 실험은 각 국가가 창의적으로 수행하는 방식이 다르기 때문에 오해의 소지가 있습니다.
닫힌 변경은 많은 학습으로 이어지지 않을 수 있습니다. 그러나 상점 페이지를 지속적으로 개선하려면 아이디어의 모든 요소를 테스트해야 합니다.
이는 WWDC21에서 발표된 새로운 기능 중 일부에 불과합니다. A/B 테스트는 역사적으로 iOS App Store에서 Google Play의 실험적 기능보다 더 복잡한 작업이었습니다. 이러한 새로운 도구는 iOS 개발자가 기다려온 개선 사항이 될 것입니다.
App Analytics, 제품 페이지 최적화 및 맞춤형 제품 페이지, 사용자 분석 및 활동 데이터에서 액세스할 수 있는 성능 데이터는 개발자가 계속 성장하는 데 필요한 통찰력을 제공합니다.
우리는 어떤 아이디어가 CVR을 향상시킬 수 있는지 알아보기 위해 테스트한 다음 정책을 위반하지 않고 이러한 아이디어를 구현하는 방법을 배웁니다. 위에 나열한 대로 iOS15 A/B 테스트 모델을 미리 계획할 수 있습니다.
Get FREE Optimization Consultation
Let's Grow Your App & Get Massive Traffic!
All content, layout and frame code of all ASOWorld blog sections belong to the original content and technical team, all reproduction and references need to indicate the source and link in the obvious position, otherwise legal responsibility will be pursued.