앱 설치 단가를 내리려면 광고 입찰가부터 손대야 하는지 묻는 분이 많습니다. 순서는 반대입니다. 광고비를 그대로 둔 채 스토어 방문 대비 설치율만 25%에서 32%로 올린 가정값 계산에서, 설치 단가는 1,882원에서 1,471원으로 411원 내려갔습니다. 이 글은 아이콘·스크린샷·미리보기 영상·첫 3줄 설명·평점이 “스토어 방문 → 설치” 구간을 어떻게 바꾸는지, 그 전환율이 설치 단가 계산에 어떻게 직결되는지를 다룹니다.

스토어 상세페이지는 설치 단가에 어떻게 작용합니까?

스토어 상세페이지는 광고를 본 사람이 설치 버튼을 누르기 직전에 반드시 거치는 마지막 화면이며, 이 화면의 전환율이 광고비를 설치 건수로 나누는 나눗셈의 분모를 결정합니다.

광고 예산은 스토어 방문까지만 삽니다. 설치는 스토어가 만듭니다.

그래서 같은 예산으로도 설치 건수가 크게 달라집니다. 아래 퍼널은 가정값을 넣은 예시입니다.

노출 축과 전환 축은 서로 다른 지표로 관리합니다

스토어 성과는 두 축으로 나뉩니다. 하나는 검색어와 카테고리를 통해 상세페이지에 사람을 데려오는 노출 축입니다. 다른 하나는 데려온 사람을 설치로 바꾸는 전환 축입니다.

노출 축은 앱 이름, 설명문, 카테고리 같은 텍스트 자산이 담당합니다. 전환 축은 아이콘, 스크린샷, 미리보기 영상, 첫 3줄 설명, 평점이 담당합니다.

광고를 집행하는 동안에는 전환 축의 무게가 훨씬 큽니다. 광고가 이미 노출을 사 왔기 때문입니다. 노출을 늘려도 전환율이 낮으면 예산만 더 씁니다.

설치 단가는 방문 단가를 전환율로 나눈 값입니다

계산식은 두 줄입니다. 방문 단가는 광고비를 스토어 방문 수로 나눈 값입니다. 설치 단가는 방문 단가를 방문 대비 설치율로 나눈 값입니다.

위 퍼널에 숫자를 넣으면 방문 단가는 800만원을 17,000회로 나눈 471원입니다. 설치 단가는 471원을 0.25로 나눈 1,882원입니다.

분자인 광고비를 건드리지 않아도 분모인 전환율을 올리면 설치 단가가 내려갑니다. 이 계산은 광고 채널과 무관하게 같은 방식으로 성립합니다. 검색 유입이든 추천 유입이든 상세페이지를 거치는 것은 동일하기 때문입니다.

전환율 1%p는 설치 단가를 얼마나 내립니까?

1%p라는 숫자는 작아 보입니다. 나눗셈에 들어가면 체감이 달라집니다.

방문 대비 설치율을 25%에서 26%로 올리면 설치는 4,250건에서 4,420건이 됩니다. 설치 단가는 1,882원에서 1,810원으로 72원 내려갑니다. 하락률은 3.8%입니다.

7%p 개선은 광고비 22% 절감과 같은 자리에 놓입니다

설치율을 25%에서 32%로 올리면 설치는 4,250건에서 5,440건이 됩니다. 광고비는 800만원 그대로입니다. 설치 단가는 1,471원으로 411원 내려갑니다.

같은 설치 단가를 입찰가로 만들려면 클릭 단가를 400원에서 313원으로 내려야 합니다. 21.8% 인하입니다. 경매형 매체에서 입찰가를 그만큼 내리면 노출량이 함께 줄어드는 경우가 많습니다.

전환율 개선은 노출량을 줄이지 않습니다. 설치 건수는 오히려 1,190건 늘어납니다. 이 지점이 두 방식의 결정적 차이입니다.

여기가 이 글의 뒤집는 지점입니다

많은 팀이 설치 단가가 오르면 입찰가부터 낮춥니다. 입찰가를 내리면 설치 단가는 내려가지만 설치 건수도 같이 줄어듭니다. 단가표는 좋아지고 성장은 멈춥니다.

전환율 개선은 반대로 움직입니다. 단가는 내려가고 건수는 늘어납니다. 두 지표가 같은 방향으로 좋아지는 손잡이는 상세페이지 쪽에 있습니다.

그리고 상세페이지 개선은 광고를 통해 온 방문자에게만 적용되지 않습니다. 검색으로 들어온 방문자에게도 같이 적용됩니다. 광고비를 한 푼도 쓰지 않은 유입에서도 설치가 늘어납니다.

웹 랜딩에서도 같은 구조가 반복됩니다. 로딩 속도가 실질 클릭 단가를 어떻게 바꾸는지는 랜딩 로딩 속도와 실질 클릭 단가에서 다뤘습니다. 도착 화면이 단가를 만든다는 원리는 앱과 웹이 같습니다.

아래 표는 설치 단가를 내리는 두 방식을 여섯 항목으로 비교한 것입니다.

스토어가 공개한 사양은 어디까지입니까?

상세페이지를 손대기 전에 무엇을 바꿀 수 있는지부터 확정해야 합니다. 두 스토어 모두 공식 문서에 실험 기능과 자산 규격을 공개해 두었습니다.

App Store 제품 페이지 최적화의 공개 사양

Apple은 제품 페이지 최적화를 “App Store 제품 페이지의 요소를 테스트하고 참여도를 극대화할 수 있는 요소를 파악”하는 기능으로 설명합니다. 테스트 대상은 앱 아이콘, 스크린샷, 앱 미리보기 비디오입니다.

한 번의 테스트에 최대 3개의 처리를 넣을 수 있습니다. 처리는 원본 제품 페이지와 비교되는 대체 버전입니다. 테스트는 90일 동안 진행되거나 그 전에 수동으로 중단됩니다.

트래픽은 임의로 배분됩니다. 전체의 40%를 테스트에 배정하고 처리가 2개면 처리별로 20%씩, 원본에 60%가 갑니다. 테스트 기간 동안 같은 사용자는 같은 버전을 계속 봅니다. 표시 대상은 iOS와 iPadOS의 App Store입니다.

Google Play 스토어 등록정보 실험의 공개 사양

Google Play는 아이콘, 그래픽 이미지, 스크린샷, 설명을 실험 대상으로 안내합니다. 앱별로 기본 그래픽 실험 1개 또는 현지화된 실험 5개까지 동시에 실행할 수 있습니다.

각 실험에서는 대조군을 포함해 최대 2개의 변형을 선택합니다. 실험용 변형이 표시될 방문자 비율을 정하면 그 방문자는 변형별로 균등하게 나뉩니다.

실험은 6개월 동안 실행된 뒤 자동으로 중지됩니다. Play Console은 실험 완료에 필요한 시간을 계산하는 도구도 함께 제공합니다.

문자 수와 이미지 규격은 숫자로 확정돼 있습니다

Google Play 스토어 등록정보의 앱 이름은 한글 15자, 영문 30자 제한입니다. 간단한 설명은 영문 기준 80자, 자세한 설명은 4,000자입니다.

앱 아이콘은 512×512 픽셀 32비트 PNG이며 파일 크기는 1,024KB 이하입니다. 기능 그래픽은 1,024×500 픽셀입니다. 스크린샷은 최소 2장이 필요하고 기기 유형당 최대 8장까지 올릴 수 있습니다.

동영상은 YouTube URL로 등록하며 광고를 비활성화해야 노출됩니다. 공개 또는 미등록 상태여야 하고, 처음 10초 안에 핵심 기능을 보여 주도록 권장됩니다.

다섯 개 자산은 각각 어떤 구간을 담당합니까?

상세페이지 전환율을 하나의 덩어리로 보면 어디를 고칠지 정할 수 없습니다. 자산별로 담당 구간을 나눠야 실험 대상이 명확해집니다.

아이콘은 목록 화면에서 판별을 담당합니다

아이콘은 검색 결과와 차트 목록에서 먼저 보입니다. 상세페이지에 들어오기 전 단계입니다. 여기서 걸러지면 방문 자체가 생기지 않습니다.

아이콘 판단 기준은 작게 줄였을 때의 판별력입니다. 512×512로 만든 파일이 목록에서는 훨씬 작게 표시됩니다. 글자를 넣으면 대부분 읽히지 않습니다.

같은 카테고리 상위 앱들의 아이콘을 한 화면에 늘어놓고 비교하면 겹치는 색과 형태가 보입니다. 겹치는 쪽을 피하는 편이 판별에 유리합니다. Apple 제품 페이지 최적화와 Google Play 실험 모두 아이콘을 테스트 대상으로 지원합니다.

스크린샷 앞 3장이 상세페이지 전환의 대부분을 결정합니다

스크린샷은 기기 유형당 최대 8장까지 올릴 수 있습니다. 방문자가 스크롤 없이 보는 것은 앞쪽 몇 장입니다. 8장을 채우는 것보다 앞 3장을 다시 짜는 편이 먼저입니다.

앞 3장에는 앱이 해결하는 문제, 해결 방식, 결과 화면을 각각 하나씩 배치합니다. 기능 나열이 아니라 사용 장면을 보여 주는 구성이 이해에 유리합니다.

스크린샷 위에 얹는 문구는 한 장당 한 문장으로 끊습니다. 화면 캡처만 올리면 방문자가 스스로 해석해야 합니다. 해석 부담이 이탈로 이어집니다.

미리보기 영상은 첫 10초 안에 결론을 냅니다

Google Play는 동영상 처음 10초 안에 핵심 기능을 보여 주도록 권장합니다. App Store 제품 페이지 최적화도 앱 미리보기 비디오를 테스트 대상에 포함합니다.

영상은 제작 비용이 크고 교체 주기가 깁니다. 스크린샷 실험이 끝난 뒤에 손대는 순서가 합리적입니다. 스크린샷에서 검증된 메시지를 영상 첫 10초에 옮기면 제작 방향이 정해집니다.

영상 소재를 여러 벌 만들어 검증하려면 표본 수 기준이 필요합니다. 소재 실험의 표본 계산은 소재 A/B 표본 수와 조기 종료에서 정리했습니다.

첫 3줄 설명은 접힌 상태에서 읽히는 유일한 텍스트입니다

자세한 설명은 4,000자까지 쓸 수 있습니다. 상세페이지에서는 접힌 상태로 시작합니다. 더 보기를 누르지 않은 방문자에게 도달하는 것은 앞 몇 줄뿐입니다.

첫 3줄에는 대상, 해결하는 문제, 사용 시작 조건을 담습니다. 회사 소개와 수상 이력은 뒤로 미룹니다. 간단한 설명 80자도 같은 원칙으로 씁니다.

키워드를 앞줄에 몰아넣으면 문장이 읽히지 않습니다. 노출 축에 필요한 표현은 4,000자 본문 안에서 자연스럽게 배치합니다. 검색과 생성형 답변에 인용되는 문서 구조는 AI 검색이 인용하는 문서 구조에서 다뤘습니다.

평점과 리뷰 수는 방문자가 가장 먼저 확인하는 숫자입니다

평점과 리뷰 수는 상세페이지 상단에 함께 표시됩니다. 방문자는 두 숫자를 같이 봅니다. 평점 4.8에 리뷰 12건과 평점 4.3에 리뷰 3,000건은 다르게 읽힙니다.

리뷰는 개선 항목의 원자료이기도 합니다. 김은희 외(2024)는 앱 리뷰 데이터를 분석하는 기준을 아홉 개로 정리하고, 문제를 찾는 기본 분석과 해결 우선순위를 정하는 핵심 분석 두 단계로 나눴습니다. 리뷰를 평점 관리 대상으로만 보면 이 정보가 버려집니다.

포토 리뷰와 이용자 제작 콘텐츠를 모으는 설계는 포토 리뷰·UGC 수집 단가에서 별도로 다뤘습니다. 수집 시점과 요청 문구가 회수율을 바꿉니다.

상세페이지 개선을 어떤 순서로 검증합니까?

자산을 한꺼번에 바꾸면 무엇이 효과를 냈는지 알 수 없습니다. 순서와 종료 기준을 먼저 정해야 실험이 자료로 남습니다.

계측 누수를 먼저 막고 시작합니다

스토어 방문 수와 설치 수가 정확해야 전환율이 의미를 갖습니다. 방문 집계가 새면 전환율이 실제보다 높거나 낮게 나옵니다. 잘못된 기준선 위에서 실험하면 결과 해석이 전부 어긋납니다.

광고 클릭과 스토어 방문 사이에서 사라지는 트래픽부터 확인합니다. 전환 계측이 새는 지점은 전환 계측 누수 다섯 자리 점검에 정리해 두었습니다.

설치 이후의 성과를 함께 보려면 집계 기간 설정도 확인합니다. 기간 설정 기준은 전환 추적 기간 역산에서 다뤘습니다.

한 번에 하나만 바꿉니다

Apple 제품 페이지 최적화는 한 테스트에 최대 3개 처리를 허용합니다. Google Play 실험은 대조군 포함 최대 2개 변형입니다. 두 도구 모두 동시에 비교할 수 있는 안의 수가 정해져 있습니다.

처리 하나에서 아이콘과 스크린샷을 같이 바꾸면 원인 분리가 되지 않습니다. 순서는 스크린샷 앞 3장, 아이콘, 첫 3줄 설명, 미리보기 영상 순을 권합니다. 교체 비용이 낮고 영향 구간이 넓은 쪽부터입니다.

실험 하나가 끝나기 전에 다른 자산을 손대지 않습니다. 중간에 바꾸면 기간 전체의 비교가 무효가 됩니다.

종료 기준을 시작 전에 문서로 적습니다

Apple 테스트는 90일, Google Play 실험은 6개월이 상한입니다. 상한까지 돌린다는 뜻이 아니라 그 안에서 멈출 기준을 정해야 한다는 뜻입니다.

기준에는 최소 관측 표본, 판정 시점, 되돌리는 조건 세 가지를 적습니다. 숫자가 좋아 보인다는 이유로 중간에 종료하면 다음 실험의 기준선이 흔들립니다.

판정 규칙을 세우는 방식은 웹 랜딩과 같습니다. 랜딩 A/B 판정 기준에서 다룬 종료 조건 설계를 그대로 옮겨 쓸 수 있습니다.

업데이트와 리뷰 관리는 전환 축과 어떻게 묶입니까?

상세페이지 자산만 바꾸면 개선 폭이 한 번에 멈춥니다. 앱 자체의 변화가 리뷰와 평점을 통해 상세페이지로 되돌아오기 때문입니다.

업데이트 유형에 따라 나타나는 자리가 다릅니다

조희승·임건신(2016)은 앱 스토어 무료 앱을 대상으로 업데이트 내용을 기능성·신뢰성·편리성으로 나눠 순위 변화를 분석했습니다. 기능성 업데이트는 전체 순위에, 신뢰성 업데이트는 카테고리 순위에 정(+)의 영향을 보였습니다.

이 결과는 특정 스토어의 순위 산출 방식을 설명한 것이 아닙니다. 순위 산출 기준은 두 스토어 모두 비공개입니다. 업데이트 성격에 따라 관측되는 지표가 달랐다는 연구 결과로 읽는 편이 정확합니다.

업데이트 내역을 상세페이지에 적을 때도 같은 구분이 쓰입니다. 무엇을 고쳤는지 유형별로 나눠 적으면 방문자가 최근 관리 상태를 판단할 수 있습니다.

리뷰 대응은 전환 자산 관리의 일부입니다

리뷰는 방문자가 설치 직전에 읽습니다. 답변이 달린 부정 리뷰와 방치된 부정 리뷰는 다르게 읽힙니다. 답변 자체가 상세페이지에 노출되는 콘텐츠입니다.

리뷰 응답에는 처리 시한을 정해 둡니다. 별점 1~2점 리뷰는 영업일 기준 이내에 답변하고, 반복 지적은 개선 항목으로 옮깁니다. 김은희 외(2024)의 기본 분석과 핵심 분석 구분이 이 작업의 틀로 쓰입니다.

설치 이후의 잔존까지 보려면 푸시 설계도 같이 봅니다. 발송 시간대와 빈도가 수신거부로 이어지는 구조는 앱 푸시 시간대·빈도와 수신거부 비용에서 다뤘습니다.

출시 전과 출시 후는 다른 문서로 관리합니다

출시 일정 역산과 상세페이지 전환은 별개의 작업입니다. 사전예약부터 설치까지의 일정 설계는 사전예약 설치 전환 역산 캘린더에 정리돼 있습니다.

출시 이후 단계별로 지표 통과 기준을 두는 방식은 소프트론칭 단계별 지표 게이트에서 다뤘습니다. 이 글은 그 사이에 놓인 상세페이지 전환 구간만 다룹니다.

세 문서를 함께 두면 일정·게이트·전환이 각각 어느 담당자의 일인지 나뉩니다. 한 문서에 섞으면 실행 시점이 흐려집니다.

어느 규모부터 스토어 실험을 돌릴 수 있습니까?

실험은 방문자 수가 있어야 성립합니다. 월 스토어 방문이 수백 회 수준이면 변형 간 차이를 읽기 어렵습니다.

방문이 적을 때는 자산 정리부터 합니다

방문이 적은 단계에서는 실험 대신 명백한 결함을 먼저 없앱니다. 앞 3장 스크린샷에 문제 정의가 없는 경우, 첫 3줄이 회사 소개로 시작하는 경우, 아이콘에 읽히지 않는 글자가 들어간 경우가 여기 해당합니다.

이 정리는 실험 없이도 판단할 수 있습니다. 스토어 공식 실험 기능은 정리가 끝난 다음에 씁니다.

국내 이용 환경은 실험 모수를 만들기 어렵지 않은 편입니다. 과학기술정보통신부(2026)의 조사에서 만 3세 이상 인터넷 이용률은 95.0%로 전년 대비 0.5%p 늘었고, 이용자의 95.2%가 하루 한 번 이상 인터넷을 씁니다. 주 평균 이용 시간은 21.6시간입니다.

현지화 실험은 언어별로 모수를 다시 계산합니다

Apple은 각 처리를 앱이 지원하는 모든 언어나 선택한 몇 개 언어로 현지화할 수 있다고 안내합니다. 동시에 선택한 현지화에 따라 유의미한 결과를 얻는 데 더 오래 걸릴 수 있다고 명시합니다.

Google Play도 현지화된 실험을 최대 5개까지 동시에 허용합니다. 언어를 늘리면 언어별 방문자가 나뉘어 각 실험의 모수가 줄어듭니다.

국내 단일 시장이라면 언어를 늘리기보다 한 언어에서 확실한 차이를 확인하는 편이 빠릅니다. 다국어는 시장 진출 계획이 확정된 뒤에 붙입니다.

스토어 상세페이지 실험은 자산 교체보다 순서 설계에서 갈립니다. 계측 기준선을 세우고 어떤 자산부터 어떤 종료 조건으로 검증할지 정하는 단계에서 외부 시각이 필요하다면, 하단의 광고 문의하기 버튼으로 남겨 주시기 바랍니다. 현재 집행 중인 매체 구성과 스토어 지표를 함께 놓고 개선 순서를 정리해 드립니다. 검색 노출 축까지 함께 볼 경우 AI SEO 컨설팅 페이지를 참고하시면 됩니다.