광고를 클릭한 사람과 앱을 설치한 사람 사이 — 스토어 랜딩

웹 광고는 다들 랜딩 페이지에 신경을 씁니다. 광고 소재와 랜딩 메시지를 맞추고, 버튼 위치를 고민하고요. 그런데 앱 광고에선 이상하게 이 감각이 사라집니다. 광고 클릭과 설치 사이에 반드시 거치는 페이지가 하나 있는데도요. 바로 앱스토어 상세 페이지입니다.

광고를 클릭한 사람 전부가 이 페이지를 봅니다. 그리고 그중 일부만 설치 버튼을 누르죠. 이 페이지의 전환율이 10%p만 움직여도, 뒤에 있는 모든 캠페인의 CPI(설치당 비용)가 통째로 움직입니다. 광고 소재를 백 번 갈아끼우는 것보다 여기 한 번 손대는 게 클 때가 있어요.

ASO, 그리고 CPP와 CSL

용어부터 정리하면, ASO(App Store Optimization)는 앱스토어 페이지를 최적화하는 작업 전반입니다. 검색 노출(키워드)과 전환(스크린샷·설명·리뷰) 두 축이 있는데, 광고 운영자 입장에서 특히 재밌는 건 전환 쪽이고, 그중에서도 이 두 가지입니다.

• CPP(Custom Product Pages) — iOS 앱스토어에서, 기본 상세 페이지 말고 캠페인별로 다른 버전의 상세 페이지를 만들 수 있는 기능입니다. 스크린샷, 프로모션 텍스트, 미리보기 영상을 버전마다 다르게 구성하고, 각 버전이 고유 URL을 갖습니다. 광고에 이 URL을 연결하면, 그 광고를 클릭한 사람만 그 버전을 보게 되죠.


• CSL(Custom Store Listings, 맞춤 등록정보) — 같은 개념의 구글 플레이 버전입니다. 플레이 콘솔에서 맞춤 등록정보를 만들고 URL이나 캠페인에 연결해, 유입 경로별로 다른 스토어 페이지를 보여줄 수 있습니다.

한 문장으로 하면, 스토어 페이지를 광고 랜딩처럼 캠페인별로 갈아끼울 수 있게 해주는 기능입니다.

이게 왜 필요하냐면 — 양면 플랫폼의 딜레마

제가 맡았던 서비스가 좋은 예입니다. 중고 골프웨어를 "사는 사람"과 "파는(위탁하는) 사람"이 공존하는 양면 플랫폼이었거든요. 광고도 구매 캠페인과 위탁 캠페인이 따로 돌아갑니다.

그런데 스토어 페이지는 하나입니다. 그리고 그 하나는 보통 구매자 관점(상품이 얼마나 좋고 싼지)으로 만들어져 있죠. 그러면 "옷장 속 골프웨어, 팔아보세요"라는 위탁 광고를 클릭한 사람이 스토어에 도착해서 보는 건 온통 쇼핑 이야기입니다. 방금 클릭한 광고와 도착한 페이지의 메시지가 어긋나는 거예요. 웹이었으면 "랜딩이 광고랑 다르잖아요"라고 바로 지적됐을 상황인데, 스토어라서 아무도 문제 삼지 않고 넘어갑니다.

CPP/CSL은 정확히 이 어긋남을 메웁니다. 위탁 캠페인에는 위탁 소구(예상가·수거 과정·판매 후기)로 구성된 스토어 페이지를, 구매 캠페인에는 상품·가격 중심 페이지를 연결하는 식으로요. 광고 → 스토어 → 앱 첫 화면까지 메시지가 한 줄로 이어지게 만드는 겁니다.

스토어가 만드는 유입은 질이 다르기도 합니다

스토어를 "설치 전 통과 지점"으로만 보기 아까운 데이터도 있었습니다. 이 계정의 오가닉 유입을 분석해보니, 구글 플레이 스토어 경유 유입이 세션당 매출 기준으로 일반 검색 유입의 4.5배였어요. 유입량 자체는 검색이 많았지만, 매출의 질은 스토어 쪽이 압도적이었습니다.

생각해보면 자연스러운 게, 스토어까지 와서 앱을 설치하는 사람은 이미 의도가 상당히 깊은 사람입니다. 그래서 저는 이 데이터를 근거로 ASO를 광고와 별개의 독립 과제로 올렸습니다. 광고비가 한 푼도 안 드는데 세션당 매출이 제일 높은 채널을 안 가꿀 이유가 없으니까요. 이건 계정마다 다를 수 있으니, 우리 스토어 유입의 질이 어떤지 GA에서 한 번 확인해보는 걸 권합니다. 의외로 숨은 효자일 수 있어요.

세팅은 대략 이런 흐름입니다

플랫폼 UI는 계속 바뀌니 큰 흐름 위주로 적으면:

iOS(CPP): App Store Connect에서 커스텀 제품 페이지를 생성하고, 버전별로 스크린샷·프로모션 텍스트·미리보기 영상을 구성합니다. 심사를 거쳐 승인되면 버전마다 고유 URL이 나오고, 이걸 광고 캠페인(애플 서치애즈는 물론 메타·구글 앱 캠페인에서도 연결을 지원합니다)에 랜딩으로 지정하면 됩니다.

Android(CSL): 플레이 콘솔의 스토어 등록정보 메뉴에서 맞춤 등록정보를 만들고, 마찬가지로 그래픽·설명을 캠페인 컨셉에 맞게 구성한 뒤 고유 URL 또는 캠페인 연결로 노출 대상을 지정합니다. 플레이 콘솔은 스토어 등록정보 실험(A/B 테스트) 기능도 제공해서, 스크린샷 A안 vs B안의 설치 전환율을 실제 트래픽으로 검증할 수 있습니다. 감으로 고르지 않아도 된다는 게 큰 장점이에요.

만들 때 제가 기준으로 삼는 건 하나입니다. 광고 소재의 첫 메시지가 스토어 첫 스크린샷에서 다시 보이는가. "반값에 새것 같은 골프웨어" 광고를 클릭했으면, 스토어 첫 장에서도 그 약속이 보여야 합니다. 스토어에서 갑자기 다른 얘기가 시작되면, 유저는 잘못 온 줄 알고 나갑니다.

스토어 다음도 있습니다 — 설치 후 첫 화면

내친김에 한 칸 더 가면, 설치 "후"에도 같은 문제가 있습니다. 위탁 광고를 보고 설치한 사람이 앱을 처음 열었을 때 홈 화면에 뚝 떨어지면, 위탁 화면을 스스로 찾아가야 하죠. 여기서 또 한 번 샙니다.

이걸 해결하는 게 디퍼드 딥링크(deferred deeplink)입니다. 광고 클릭 → 스토어 → 설치 → 첫 실행 시, 원래 광고가 가리키던 화면으로 자동 이동시켜주는 기능이에요. "디퍼드(지연된)"라는 이름이 붙은 건, 설치라는 중간 과정을 기다렸다가 나중에 딥링크를 실행하기 때문입니다. 매체 설정만 켠다고 되는 게 아니라 앱 쪽(MMP SDK)에서 수신·이동 처리를 구현해야 작동하는 물건이라 개발 협업이 필요한데, 광고 → 스토어 → 첫 화면까지 이어지는 동선의 마지막 조각이라 챙길 가치가 충분합니다. 제가 맡았던 계정도 이게 미구현이라 위탁 의도로 설치한 유저가 홈에 떨어지고 있었고, 개발팀과 구현을 진행했습니다.

정리하면

앱 광고의 랜딩은 스토어입니다. 그리고 그 랜딩은 CPP/CSL로 캠페인별 커스텀이 가능하고, 플레이는 A/B 테스트까지 됩니다. 광고 성과가 정체됐을 때 소재와 타겟만 백 번 만지는 것보다, 클릭 이후 동선 — 스토어 페이지, 그리고 설치 후 첫 화면 — 을 한 번 점검하는 게 더 큰 레버일 수 있습니다. 특히 우리 서비스가 구매/판매, 신규/기존처럼 성격이 다른 유저를 광고 하나로 다 받고 있다면요.