[2026 최신] 앱 캠페인(UAC) 딥링크 설정 및 전환 추적 방법 완벽 가이드 | 테라그로스

앱 캠페인 상담을 하다 보면 거의 매번 비슷한 말을 들어요. “광고비는 꼬박꼬박 나가는데 앱 안에서 무슨 일이 있었는지 모르겠다”, “앱 참여 캠페인을 켰는데 클릭만 늘고 구매는 제자리다” 같은 얘기요. 막상 계정을 열어 보면 원인은 대개 두 갈래로 좁혀집니다. 딥링크가 앱을 열지 못하고 모바일 웹으로 새고 있거나, 전환이 두 군데서 겹쳐 잡혀 입찰 알고리즘이 엉뚱한 신호를 배우고 있거나.

과거 UAC(Universal App Campaigns)라고 부르던 시절에는 설치만 제대로 잡혀도 캠페인이 그럭저럭 굴러갔어요. 지금은 사정이 꽤 다릅니다. 구글 애즈 앱 캠페인의 입찰은 설치 이후 행동, 그러니까 가입·구매·구독 같은 인앱 액션을 기준으로 돌아가는 비중이 커졌고, iOS는 ATT 이후 측정 경로가 여러 갈래로 쪼개졌죠. 여기에 2025년 8월 Firebase 동적 링크(Dynamic Links)가 완전히 종료되면서, 예전 세팅을 그대로 쓰던 앱 중에는 지연 딥링크가 조용히 끊긴 곳도 적지 않았어요.

아래 순서는 우리가 새 앱 계정을 받으면 실제로 밟는 흐름 그대로예요. 개발팀에 넘기는 체크리스트로 써도 되게끔 구글 고객센터(support.google.com) 문서와 애플·안드로이드 개발자 문서 기준으로 맞춰 뒀고, 메뉴 위치처럼 자주 바뀌는 부분은 바뀔 수 있다고 따로 적어 두었습니다.

2026년 앱 캠페인 구조 – 딥링크와 전환 추적이 물리는 자리

구글 애즈에서 앱 캠페인을 만들면 하위 유형이 세 가지로 나뉘어요. 신규 사용자를 데려오는 앱 설치, 이미 앱을 깐 사용자를 다시 불러오는 앱 참여, 그리고 출시 전 안드로이드 앱만 쓸 수 있는 앱 사전 등록. 입찰 목표는 다시 설치 수, 인앱 액션(타깃 CPA), 인앱 액션 가치(타깃 ROAS)로 갈립니다.

딥링크가 직접 개입하는 지점은 세 군데예요. 첫째는 앱 참여 캠페인이에요. 광고를 누른 기존 사용자를 앱 안의 특정 화면, 예를 들면 상품 상세나 장바구니, 이벤트 페이지로 보내는 링크라서 딥링크가 없으면 이 캠페인은 돌릴 이유가 거의 없죠. 둘째는 앱 설치 캠페인의 지연 딥링크(deferred deep link). 앱이 없는 사용자가 스토어에서 설치한 뒤 처음 앱을 열 때 광고에서 본 화면으로 보내 주는 장치예요. 셋째는 검색, 쇼핑, 실적 최대화 같은 웹 캠페인이에요. 앱이 이미 깔린 사용자를 웹 대신 앱으로 연결해 줍니다.

전환 추적은 이 흐름의 끝에서 무슨 일이 일어났는지를 구글에 알려 주는 역할을 해요. 우리가 클라이언트한테 자주 쓰는 비유가 있는데, 딥링크는 사용자를 매장 진열대 앞까지 데려다주는 길이고 전환 추적은 계산대에서 찍히는 영수증이에요. 길만 있고 영수증이 없으면 알고리즘은 눈 감고 운전하는 셈이고, 영수증은 잘 나오는데 길이 끊겨 있으면 광고비가 모바일 웹으로 줄줄 새거든요. 둘 중 하나만 고쳐서는 성과가 잘 안 움직이는 이유가 여기 있습니다.

딥링크 종류부터 확실히 – 앱 링크, 유니버설 링크, 커스텀 스킴

개발팀이랑 이야기하다 보면 “딥링크 이미 있어요”라는 답이 제일 먼저 나와요. 근데 확인해 보면 앱 내부 테스트용 커스텀 스킴만 있는 경우가 꽤 많습니다. 구글 애즈가 권장하는 건 안드로이드는 앱 링크(App Links), iOS는 유니버설 링크(Universal Links)예요. 둘 다 일반 https 웹 주소를 그대로 쓰면서 앱이 있으면 앱으로 열고, 없으면 같은 주소의 웹페이지로 자연스럽게 떨어지는 구조라서요.

안드로이드 앱 링크 – 도메인 소유 검증이 전부

앱 링크는 웹 도메인과 앱이 서로를 인증하는 방식이에요. 앱 매니페스트의 intent-filter에 autoVerify 속성을 true로 넣고, 웹 서버의 /.well-known/assetlinks.json 위치에 앱 패키지명과 서명 인증서의 SHA-256 지문을 올려 두면 안드로이드가 설치 시점에 둘을 대조합니다.

여기서 제일 많이 틀리는 게 지문이에요. Play 앱 서명(Play App Signing)을 쓰고 있다면 개발자가 가진 업로드 키 지문이 아니라 Play Console 앱 무결성 메뉴에 나오는 앱 서명 키 지문을 넣어야 해요. 사용자 기기에 깔리는 앱은 구글이 다시 서명한 버전이니까요. 안드로이드 12부터는 검증에 실패하면 앱 선택 창도 안 뜨고 그냥 기본 브라우저로 열려 버려서, 문제가 있어도 겉으로는 티가 잘 안 납니다. 검증 상태는 테스트 기기에서 adb shell pm get-app-links 패키지명을 실행해 보면 바로 나오고, 도메인 옆에 verified가 찍혀 있어야 정상이에요.

iOS 유니버설 링크 – AASA 파일과 Associated Domains

iOS는 웹 서버에 apple-app-site-association(줄여서 AASA) 파일을 올리고, Xcode의 Associated Domains 항목에 applinks 접두어를 붙여 도메인을 등록해요. AASA 파일은 확장자 없이 /.well-known/ 경로에 두고, HTTPS로 리다이렉트 없이 바로 응답해야 하며, 콘텐츠 타입은 application/json이어야 합니다.

실무에서 자주 놓치는 포인트가 두 개 있어요. 하나는 iOS 14부터 기기가 AASA 파일을 웹 서버에서 직접 받지 않고 애플 CDN을 거쳐 받는다는 점이에요. 그래서 파일을 고쳐도 바로 반영되지 않고 시간 차가 생깁니다. “고쳤는데 왜 그대로냐”는 문의의 상당수가 사실 이거예요. 다른 하나는 유니버설 링크가 사용자가 직접 탭한 링크에만 반응한다는 점. 사파리 주소창에 주소를 직접 입력하거나 같은 도메인 안에서 페이지를 이동하면 앱이 안 열리고 웹으로 열려요. 카카오톡이나 인스타그램 같은 인앱 브라우저에서도 앱 전환이 안 되는 경우가 있어서, 우리는 테스트할 때 이 경로를 꼭 따로 눌러 봅니다.

커스텀 스킴은 보조 수단으로만

앱 이름으로 시작하는 커스텀 스킴 링크는 만들기는 쉬운데 단점이 분명해요. 앱이 없는 기기에서는 오류 화면이 뜨고, 도메인 소유 검증이 없으니 다른 앱이 같은 스킴을 등록해 가로챌 여지도 있죠. 안드로이드 앱 참여 캠페인에서는 커스텀 스킴도 입력은 받지만, 우리는 앱 링크를 기본으로 두고 커스텀 스킴은 앱 내부 라우팅용 백업 정도로만 씁니다. iOS는 유니버설 링크가 사실상 표준이라고 보시면 돼요.

지연 딥링크 – Firebase 동적 링크 종료 이후

지연 딥링크는 앱이 없는 사용자가 광고를 누르고, 스토어에서 설치하고, 처음 앱을 열었을 때 광고에서 본 화면으로 바로 보내 주는 기능이에요. 예전에는 Firebase 동적 링크로 이걸 처리하는 앱이 많았는데, 구글이 2025년 8월 25일부로 서비스를 완전히 종료했습니다. page.link로 끝나는 예전 링크는 이제 동작하지 않아요.

지금 선택지는 크게 두 가지예요. 앱스플라이어(AppsFlyer), 애드저스트(Adjust), 브랜치(Branch) 같은 앱 분석 파트너(AAP)의 링크 기능을 쓰거나, 안드로이드라면 Firebase용 구글 애널리틱스 SDK를 통한 구글 애즈 자체 지연 딥링크 기능을 켜는 방법. 광고 소재뿐 아니라 이메일, QR코드, 문자 마케팅에 남아 있는 예전 동적 링크도 이번 기회에 한꺼번에 찾아서 교체하길 권해요. 우리가 점검한 계정 중에도 광고 링크는 다 바꿨는데 매장에 붙여 둔 QR코드에 page.link가 그대로 남아 있던 곳이 있었거든요.

구글 애즈에 딥링크 연결하는 실제 순서

1단계 – 실기기에서 링크 동작부터 확인

구글 애즈 화면을 열기 전에 실제 휴대폰으로 먼저 눌러 봐요. 안드로이드는 위의 adb 명령으로 verified 상태를 보고, iOS는 메모 앱이나 메시지에 링크를 붙여 넣은 뒤 탭했을 때 앱이 열리는지 확인합니다. 앱이 깔린 기기와 안 깔린 기기, 두 상태를 모두 봐야 해요. 깔린 기기에서는 정확한 화면이 열려야 하고, 안 깔린 기기에서는 같은 내용의 웹페이지나 스토어로 자연스럽게 넘어가야 정상이죠.

2단계 – 구글 애즈 계정에 앱과 측정 도구 연결

앱 캠페인을 만들 때 앱을 선택하면 스토어 정보는 연결되지만, 인앱 전환 데이터까지 들어오려면 Firebase(GA4) 또는 AAP 연결이 따로 필요해요. 연결 방법은 바로 다음 섹션에 순서대로 적어 뒀습니다.

3단계 – 앱 참여 캠페인 광고그룹마다 딥링크 지정

앱 참여 캠페인은 광고그룹 단위로 딥링크 URL을 넣어요. 여기서 제일 아쉬운 세팅이 전부 앱 홈 화면으로 보내는 거예요. 장바구니 이탈 사용자는 장바구니로, 특정 카테고리를 본 사용자는 그 카테고리로 보내야 참여 캠페인을 하는 의미가 생기거든요. 광고그룹을 의도별로 나누고, 소재 문구도 도착 화면과 맞추세요. 구글 애즈가 딥링크 유효성을 검사해서 경고를 띄우기도 하는데, 그걸 무시하고 게재를 시작하면 대부분 나중에 탈이 납니다.

4단계 – 웹 캠페인에도 딥링크 켜기

검색·쇼핑·실적 최대화 캠페인을 같이 돌리는 커머스라면 이 단계를 꼭 챙기세요. 랜딩 URL이 앱 링크나 유니버설 링크로 매핑돼 있고 구글 애즈에 앱과 앱 전환 추적이 연결돼 있으면, 앱이 깔린 사용자는 광고를 눌렀을 때 웹 대신 앱으로 열립니다. 로그인 상태와 저장된 결제수단이 살아 있는 앱 쪽 전환율이 웹보다 높다는 건 커머스 하시는 분들은 경험으로 다 아실 거예요.

5단계 – 구글 애즈 안의 딥링크 상태 점검

구글 애즈에는 연결된 앱의 딥링크 상태와 예상 영향을 보여 주는 화면이 있어요. 메뉴 위치는 UI 개편 때마다 조금씩 바뀌어서, 상단 검색창에 ‘딥링크’를 쳐서 들어가는 게 제일 빠릅니다. 여기서 문제가 잡히면 대부분 1단계의 도메인 검증 문제로 돌아가요.

전환 추적 소스 고르기 – Firebase(GA4), AAP, Google Play

구글 애즈에서 앱 전환 액션을 만들 때 고를 수 있는 데이터 출처는 크게 세 가지예요. Firebase SDK를 통해 GA4로 들어온 앱 이벤트, 앱스플라이어·애드저스트 같은 서드파티 앱 분석(AAP), 그리고 안드로이드 설치와 인앱 구매를 자동으로 잡아 주는 Google Play. 어느 걸 쓸지는 광고 매체 구성으로 정하면 깔끔합니다. 구글 애즈 하나만 돌린다면 Firebase로 충분하고, 메타·틱톡·애플 검색광고까지 여러 매체를 같이 돌린다면 매체 간 중복을 걸러 줄 AAP를 기준으로 삼는 게 맞아요.

Firebase와 GA4로 연결하는 순서

우리가 세팅할 때 밟는 순서는 이래요.

1. 앱에 Firebase SDK(구글 애널리틱스 포함)를 넣고, 설치 직후 자동 수집되는 first_open 이벤트가 들어오는지 확인
2. Firebase 프로젝트를 GA4 속성과 연결해 앱 데이터 스트림 생성
3. GA4 관리 메뉴에서 구글 애즈 계정 연결
4. GA4에서 광고 최적화에 쓸 이벤트를 키 이벤트로 지정
5. 구글 애즈 전환 메뉴에서 새 전환 액션 만들기 → 앱 → 구글 애널리틱스 4(Firebase) 선택 후 이벤트 가져오기

참고로 GA4는 2024년에 ‘전환’이라는 이름을 ‘키 이벤트’로 바꿨어요. 구글 애즈에서는 여전히 ‘전환’이라고 부르니까, GA4에서 키 이벤트로 표시한 걸 구글 애즈로 가져와 전환 액션으로 쓴다고 이해하면 헷갈리지 않습니다. 구매 이벤트는 value와 currency 파라미터를 반드시 같이 보내야 타깃 ROAS를 쓸 수 있어요. 앱스토어·플레이스토어 결제는 in_app_purchase 이벤트로 자동 수집되지만, 자체 결제나 PG 결제를 쓰는 앱이라면 purchase 이벤트를 직접 심어야 하고요.

AAP로 연결하는 순서

AAP를 쓸 때는 구글 애즈의 데이터 관리자 메뉴(예전 이름은 ‘연결된 계정’)에서 서드파티 앱 분석을 선택해 연결 ID를 만들고, 그 ID를 AAP 대시보드의 구글 애즈 연동 화면에 붙여 넣어요. 그다음 AAP에서 어떤 인앱 이벤트를 구글로 보낼지 매핑하면 구글 애즈 전환 메뉴에 해당 이벤트가 전환 액션으로 나타납니다. 이벤트 이름은 AAP와 구글 애즈 양쪽에서 같은 규칙으로 맞춰 두세요. 나중에 리포트를 맞춰 볼 때 시간이 절반으로 줄어요.

설치 전환 중복을 막는 법

여기가 제일 흔한 사고 지점이에요. Firebase의 first_open, Google Play 설치, AAP의 설치 이벤트가 동시에 기본(primary) 전환으로 잡혀 있으면 설치 한 건이 두세 번 계산됩니다. 입찰 알고리즘 입장에서는 싸게 잘 모으고 있다고 착각하게 되고요.

우리가 넘겨받은 한 게임 앱 계정이 딱 그랬어요. 대시보드상 CPI는 1,300원대였는데, 스토어 콘솔의 실제 신규 설치 수로 광고비를 다시 나눠 보니 2,400원 가까이 나왔습니다. 설치는 한 출처만 기본 전환으로 두고 나머지는 보조(secondary)로 내리는 게 원칙이에요. 구글 애즈 하나만 쓰면 Firebase first_open을, 여러 매체를 쓰면 AAP 설치 이벤트를 기본으로 잡는 편입니다. 계정 단위 기본 목표와 캠페인 단위 목표 설정이 서로 엇갈려 있지 않은지도 같이 보세요.

iOS 전환 추적 – ATT 이후 세 갈래로 읽는 법

iOS는 솔직히 안드로이드와 같은 잣대로 보면 안 돼요. 2021년 iOS 14.5부터 앱 추적 투명성(ATT) 동의를 받아야 IDFA를 쓸 수 있게 됐고, 동의하는 사용자는 소수에 그칩니다. 그래서 지금 iOS 앱 캠페인 성과는 한 군데서 딱 떨어지는 숫자가 아니라 여러 측정을 겹쳐서 읽어야 하죠.

SKAdNetwork와 AdAttributionKit

애플이 제공하는 집계형 측정이에요. 개별 사용자 단위가 아니라 익명화된 포스트백으로 설치와 전환 값을 돌려받습니다. SKAN 4 기준으로 포스트백은 설치 후 0~2일, 3~7일, 8~35일 세 구간으로 나뉘고, 각 포스트백은 무작위 지연을 거쳐 구간이 끝나고 하루 이상 지나서야 도착해요. 세밀한 전환 값(fine value)은 첫 구간에만 담길 수 있고 뒤 구간은 낮음·중간·높음 수준의 대략값(coarse value)만 오기 때문에, 첫 0~2일 안에 일어나는 가입이나 첫 구매 같은 이벤트로 전환 값 체계를 짜는 게 유리하죠. 애플은 iOS 17.4부터 후속 체계인 AdAttributionKit을 내놨고 SKAN과 호환되게 돌아가는데, 전환 값을 설계하는 원리 자체는 크게 달라지지 않았습니다.

구글 온디바이스 전환 측정

구글 쪽에서 iOS 공백을 메우는 장치가 온디바이스 전환 측정이에요. 앱 로그인 단계에서 사용자가 입력한 이메일이나 전화번호 같은 1st party 정보를 Firebase SDK가 기기 안에서 해시 처리해 광고 상호작용과 매칭하는 방식이라, 개인 식별 정보가 기기 밖으로 나가지 않습니다. 로그인 기반 앱이라면 켜 두는 쪽이 거의 항상 이득이에요. 다만 앱 개발 쪽에서 SDK 버전을 맞추고 해당 API를 호출하는 작업이 필요하니 개발 일정에 미리 넣어 두세요.

모델링 전환과 판단 기준

구글 애즈는 측정이 비는 구간을 모델링 전환으로 채워서 보여 줘요. 그래서 iOS 캠페인은 며칠 단위로 끊어 보면 숫자가 꽤 출렁입니다. 우리는 iOS는 최소 2주 단위로, 가능하면 설치일 기준 코호트로 보고, 판단은 AAP나 내부 데이터의 결제 매출과 교차해서 내려요. 유럽(EEA) 사용자를 대상으로 한다면 Firebase 동의 모드(Consent Mode) v2 신호를 넘기는 것도 필수라는 점, 같이 기억해 두세요.

어떤 이벤트로 최적화할까 – 이벤트 볼륨과 예산 기준

전환 추적이 깔끔하게 들어오기 시작하면 다음 고민은 무엇을 목표로 입찰할지예요. 다들 매출이 제일 궁금하니까 바로 구매로 최적화하고 싶어 하는데, 이벤트 볼륨이 모자라면 알고리즘이 학습을 못 끝냅니다. 구글 가이드도 하루 10회 이상 꾸준히 발생하는 인앱 액션을 고르라고 권하고 있죠.

예산 기준도 같이 봐야 해요. 구글 권장치는 설치 최적화라면 일 예산을 목표 CPI의 50배 이상, 인앱 액션 최적화라면 목표 CPA의 10배 이상으로 잡는 거예요. 목표 CPA가 15,000원이면 하루 15만 원 이상은 써야 학습이 제대로 돈다는 뜻입니다. 일 예산은 3만 원인데 목표 CPA를 2만 원으로 걸어 두고 “왜 노출이 안 나가냐”고 묻는 경우를 생각보다 자주 봐요.

운영 중 조정은 한 번에 크게 하지 않는 게 원칙이에요. 구글도 목표 CPA·CPI나 예산을 바꿀 때 한 번에 20% 안쪽으로 움직이라고 권하는데, 실제로 그 이상 크게 흔들면 학습이 다시 시작되면서 며칠간 성과가 튀는 걸 여러 번 봤습니다. 타깃 ROAS로 넘어갈 때는 가치 데이터 품질부터 봐야 해요. 통화 코드가 빠져 있거나 환불이 반영되지 않거나 사내 테스트 결제가 섞여 있으면, 알고리즘은 그 숫자를 그대로 믿고 학습하거든요.

우리가 자주 보는 세팅 실수 – 하나씩 짚어 보면

지금까지 이야기한 내용을 실제 계정 점검 경험 위주로 다시 묶어 보면, 반복해서 나오는 실수는 대략 이 정도예요.

클릭 트래커로 딥링크를 감싸 버리는 경우

측정을 한다고 딥링크 앞에 다른 도메인의 리다이렉트 트래커를 붙이는 경우가 있는데, iOS에서는 이게 유니버설 링크를 깨뜨리기 쉬워요. 사용자가 탭한 주소가 앱과 연결된 도메인이 아니니 iOS는 일단 웹으로 열고, 그 뒤에 일어나는 리다이렉트로는 앱이 안 열리는 경우가 많거든요. AAP 링크를 쓴다면 AAP가 제공하는 자체 연결 도메인을 그대로 쓰는 게 맞습니다.

앱은 열리는데 화면이 홈으로 튕기는 경우

링크 검증은 통과했는데 앱 안 라우팅이 경로를 못 받는 경우예요. 특히 로그인이 필요한 화면으로 보냈을 때, 로그인 화면을 거치면서 원래 가려던 경로를 잃어버리고 홈으로 떨어지는 패턴이 흔합니다. 이건 구글 애즈 문제가 아니라 앱 코드 문제라서, 개발팀에 로그인 후 원래 딥링크 경로로 복귀하도록 명시적으로 요청해야 해요.

테스트 데이터가 전환에 섞이는 경우

QA 기간에 직원들이 테스트 결제를 수십 번 돌렸는데 그게 운영 GA4 속성으로 그대로 들어가 구매 전환으로 잡힌 계정도 있었어요. 개발 빌드와 운영 빌드의 Firebase 프로젝트를 분리하거나, 최소한 디버그 기기 트래픽을 걸러 내는 설정은 런칭 전에 끝내 둬야 합니다.

AAP와 구글 애즈 숫자가 안 맞는다고 세팅을 갈아엎는 경우

두 숫자는 원래 딱 맞지 않아요. 기여 기간, 참여 조회 전환(동영상을 일정 시간 이상 본 뒤 설치한 경우) 포함 여부, 전환을 클릭일 기준으로 잡는지 이벤트 발생일 기준으로 잡는지가 서로 다르니까요. 우리는 차이가 10~20% 안쪽이고 추세가 같이 움직이면 정상 범위로 봅니다. 차이가 갑자기 벌어졌다면 그때 SDK 업데이트나 이벤트 매핑 변경 이력을 확인하면 돼요.

런칭 전후 점검 루틴 – 우리가 실제로 쓰는 체크리스트

새 앱 캠페인을 열 때 우리는 아래 항목을 하나씩 체크하고 나서야 예산을 켭니다.

솔직히 딥링크와 전환 추적은 티가 나는 작업이 아니에요. 그런데 앱 캠페인 성과가 정체된 계정을 열어 보면, 소재나 입찰보다 이 기반 세팅에서 먼저 문제가 나오는 경우가 훨씬 많았습니다. 소재 테스트를 열 번 돌리기 전에 링크 한 줄과 전환 액션 하나가 제대로 서 있는지부터 보시길 권해요.

자주 묻는 질문