모바일 앱과 딥링크

단축 링크에서 앱을 열고, 앱이 없으면 스토어로 보내고, 연결 파일을 여러분의 도메인에서 제공하며, 설치 후에 클릭 정보를 읽습니다.

2026년 8월 14일 업데이트

모바일 앱으로 이어지는 단축 링크는 세 부류의 사람을 한꺼번에 상대합니다. 이미 앱을 가진 사람, 갖지 않은 사람, 그리고 브라우저가 다른 앱 안에 들어 있는 사람입니다. 이 페이지는 그 셋을 모두 다루고, 결과를 가르는 두 가지 설정 — 여러분의 도메인에 놓는 연결 파일과, 앱이 첫 실행 때 읽을 수 있는 뒤늦게 전달되는 클릭 정보 — 도 함께 설명합니다.

모바일 항목이 하는 일

링크를 열고 모바일 탭으로 이동해 모바일 도착 주소를 켜십시오. 플랫폼마다 주소를 세 개까지 지정할 수 있습니다.

앱 링크 — 앱 안의 주소입니다. 직접 정한 스킴과 경로(myapp://product/42), Android 인텐트, 또는 유니버설 https 링크를 씁니다.
스토어 주소 — App Store나 Google Play 페이지이며, 앱이 열리지 않을 때 사용됩니다.
웹 대체 주소 — 아예 스토어로 보내고 싶지 않은 방문자를 위한 페이지입니다.

모두 선택 사항입니다. 스토어 주소만 지정한 링크는 평범한 스토어 리디렉션입니다. 앱 링크와 스토어 주소를 함께 지정하면 본래의 동작을 얻습니다. 페이지가 먼저 앱을 시도하고, 아무 일도 일어나지 않으면 스토어로 넘어갑니다.

나머지 두 설정은 평범한 휴대폰 브라우저 밖에서 무슨 일이 일어날지 정합니다.

태블릿 — 휴대폰으로 처리할지(기본값), 데스크톱으로 처리할지 고릅니다.
인앱 브라우저 — Instagram, TikTok, Facebook 같은 앱 안에서 링크가 열렸을 때 어떻게 할지 정합니다.

데스크톱 방문자는 데스크톱 도착 주소를 지정했다면 그곳으로, 지정하지 않았다면 링크의 기본 도착 주소로 갑니다. 여러분이 따로 요구하지 않는 한, 모바일 항목은 데스크톱 방문자가 보는 것을 하나도 바꾸지 않습니다.

인앱 브라우저에 별도의 규칙이 필요한 이유

소셜 피드에서 일어나는 링크 클릭은 대부분 Safari나 Chrome에 닿지 못합니다. 앱 자체 안의 웹뷰에서 열리는데, 그런 웹뷰 가운데 몇몇은 모든 이동을 자기 안에 붙들어 둡니다. 유니버설 링크는 웹뷰에 머무르고, 사용자 지정 스킴은 조용히 아무 일도 하지 않습니다. 이는 링크 쪽에서 고칠 수 있는 결함이 아닙니다. 그 웹뷰를 가진 앱이 내린 결정입니다.

그래서 이 설정은 정직한 선택지를 세 가지 제시합니다.

| 선택지 | 방문자가 받는 것 | | --- | --- | | 앱 열기를 시도 | 중간 페이지가 앱 링크를 시도합니다. 해당 웹뷰가 이를 막는다고 알려져 있으면 기다리지 않고, 휴대폰 브라우저에서 링크를 다시 여는 방법을 안내합니다. | | 바로 스토어로 이동 | 앱을 전혀 시도하지 않습니다. 스토어 페이지가 목적인 설치 캠페인에 알맞습니다. | | 웹 대체 주소로 이동 | 방문자가 웹에 머무릅니다. 콘텐츠 링크에서는 이 편이 가장 나은 답인 경우가 많습니다. |

연결 파일: 링크가 조용히 앱을 열게 만드는 설정

링크가 브라우저를 거치지 않고 앱을 열게 하려면, 여러분의 도메인과 앱이 한 몸이라는 사실을 운영체제가 알아야 합니다. 두 플랫폼 모두 도메인 자체가 제공하는 파일로 그것을 확인합니다.

https://go.brand.com/.well-known/apple-app-site-association
https://go.brand.com/.well-known/assetlinks.json

이 파일들은 여러분이 작성하지 않습니다. 도메인에서 해당 도메인을 열고 모바일 앱 아래에 앱을 추가하십시오.

iOS는 TEAMID.com.company.app 형식의 App ID와, 앱이 처리할 경로(*는 모든 단축 링크를 포함합니다)를 입력합니다.
Android는 패키지 이름과 Play Console에서 확인한 SHA-256 서명 지문을 입력합니다.

플랫폼이 두 파일을 만들어 여러분의 도메인에서 제공하며, 응답은 두 플랫폼이 요구하는 그대로입니다. 상태 200, 리디렉션 없음, application/json, 전송 압축 없음입니다. 마지막 항목은 들리는 것보다 훨씬 중요합니다. 전송 도중에 파일을 gzip으로 압축하는 프록시는 앱 링크가 소리 없이 멈추는 가장 흔한 원인 가운데 하나입니다.

설정 확인하기

파일 확인 버튼은 운영 중인 도메인에서 두 파일을 가져와 플랫폼이 무엇을 보게 될지 알려 줍니다. 확인 결과는 각각 구체적인 해결 방법으로 이어집니다.

| 확인 결과 | 해야 할 일 | | --- | --- | | 도메인이 응답하지 않았습니다 | 도메인이 아직 트래픽을 받지 않거나, DNS가 아직 퍼지는 중입니다. | | 파일이 없습니다 | 이 도메인에 앱이 하나도 설정되지 않았거나, 요청이 플랫폼까지 닿지 않습니다. | | 도메인이 이 주소를 리디렉션합니다 | 도메인 앞에 있는 무언가가 /.well-known/을 고쳐 씁니다. 플랫폼은 여기서 리디렉션을 따라가지 않습니다. | | 형식이 잘못 제공되었습니다 | 응답이 HTML이며, 대개 다른 서비스가 반환하는 404 페이지입니다. | | 응답이 압축된 상태로 도착합니다 | 프록시가 파일을 압축합니다. 두 플랫폼의 검사가 모두 실패할 수 있습니다. | | 선언된 앱이 없습니다 | 파일 자체는 올바르지만 해당 플랫폼용 내용이 비어 있습니다. 대시보드에서 앱을 추가하십시오. |

파일이 자리를 잡은 뒤에는 두 플랫폼이 각자의 CDN에 그것을 캐시하므로, 새로 설치한 앱이 변경을 반영하기까지 시간이 걸릴 수 있습니다. 시험하는 동안 다시 읽게 만드는 확실한 방법은 앱을 지우고 다시 설치하는 것입니다.

설치 뒤에 전달되는 클릭 정보

앱이 없는 방문자가 링크를 눌러 스토어에 도착하고, 앱을 설치해 실행합니다. 그 순간 앱은 이 사람이 어디에서 왔는지 전혀 모릅니다. 브라우저 세션과 앱은 서로 무관한 두 세계이기 때문입니다.

설치 후에 클릭 정보 전달을 켜면 플랫폼이 짧은 기기 지문을 두 시간쯤 보관합니다. 내용은 플랫폼, 운영체제 주 버전, 언어, 국가, 화면 크기, 시간대, 통신사입니다. IP 주소도, 광고 식별자도, 어떤 사람으로 되짚어 갈 수 있는 것도 들어 있지 않습니다.

첫 실행 때 앱은 클릭이 있었는지를 플랫폼에 묻습니다.

curl -X POST https://go.brand.com/__dl/claim \
  -H 'content-type: application/json' \
  -d '{
    "platform": "ios",
    "os_version": "17.4",
    "language": "de",
    "timezone_offset": 120,
    "screen_width": 1170,
    "screen_height": 2532,
    "pixel_ratio": 3
  }'

일치하면 원래 링크와 캠페인 태그가 돌아옵니다.

{
  "matched": true,
  "confidence": "high",
  "score": 100,
  "matched_on": ["screen", "timezone_offset", "language", "os_version"],
  "url": "myapp://product/42",
  "domain": "go.brand.com",
  "slug": "promo",
  "link_id": "lnk_...",
  "utm": { "utm_source": "newsletter" },
  "click_id": "...",
  "clicked_at": "2026-08-14T10:00:00.000Z"
}

일치하지 않으면 {"matched": false}가 돌아오며, 같은 클릭에 대한 두 번째 요청도 마찬가지입니다. 이 기록은 정확히 한 번만 넘겨지기 때문입니다.

한계를 있는 그대로

매칭은 확률적입니다. 같은 기종에, 같은 네트워크에, 같은 시간대와 언어를 쓰는 두 기기는 이 방식에서 똑같아 보입니다. 그래서 모든 응답에는 confidence와 판단에 쓰인 속성 목록이 함께 실립니다. high는 방금 일어난 클릭에서 화면 크기와 시간대가 모두 맞았다는 뜻이고, low는 사실이 아니라 단서로 다루라는 뜻입니다.
기간은 날 단위가 아니라 시간 단위입니다. 지문은 클릭 두 시간 뒤에 만료되고, 신뢰도는 처음 15분이 지나면 떨어집니다.
요청은 첫 실행 때 한 번만 보내십시오. 기록은 처음 성공한 매칭에서 소비되며, 두 번째 호출은 아무것도 돌려주지 않습니다.
중간 페이지 없이 스토어로 바로 보내면 모이는 정보가 적습니다. 화면 크기와 시간대는 브라우저에서 도는 페이지만 알 수 있으므로, 곧장 스토어로 가는 링크는 언어와 운영체제 버전만으로 매칭합니다. 응답에도 그렇게 밝히며 신뢰도는 더 낮게 나옵니다.

시험 점검 목록

앱이 설치된 휴대폰에서 링크를 여십시오. 앱 안으로 들어가야 합니다.
앱이 없는 기기에서 여십시오. 페이지가 잠깐 나타났다가 스토어가 열립니다.
소셜 피드에서 여십시오. 여러분이 고른 인앱 브라우저 설정이 예상대로 동작하는지 확인하십시오.
데스크톱 브라우저에서 여십시오. 데스크톱 도착 주소나 기본 도착 주소로 이동합니다.
해당 도메인에서 파일 확인을 실행해 두 파일이 모두 정상으로 돌아오는지 확인하십시오.