Search

LINE Corporation이 2023년 10월 1일부로 LY Corporation이 되었습니다. LY Corporation의 새로운 기술 블로그를 소개합니다. LY Corporation Tech Blog

Blog


TRACKIT에서 딥링크를 사용하는 방법

이형중2019-07-10

LINE Game Platform 개발 팀에서 플랫폼 개발을 하고 있는 이형중입니다.

들어가기

안녕하세요. LINE GAME PLATFORM 개발 팀에서 TRACKIT을 개발하고 있는 이형중입니다. TRACKIT은 2018년 말 오픈한 서비스로 웹에서 애플리케이션에 접근하거나 실행한 사용자를 추적하는 서비스입니다. LINE GAME에 마케팅용 추적 기능이 없어서 TRACKIT을 개발하게 되었는데요. 현재 LINE POP2, Jumpti Heroes 등의 게임에 적용하여 서비스하고 있습니다.

이번 글에서는 TRACKIT을 개발하면서 적용한 딥링크(deeplink)의 개념과 종류, 사용 방법에 대해 공유하려고 합니다.

딥링크란?

딥링크란 특정 페이지로 도달할 수 있는 링크(link)를 통칭하는 말이며, 스킴(scheme)과 호스트(host)로 구성된 URL(Uniform Resource Locator) 형태입니다. 링크의 한 종류이기 때문에 다른 링크처럼 간단하게 웹 환경에 적용해 사용할 수 있습니다. 

모바일 환경이 보편화된 최근에는 주로 앱을 실행하는 링크를 의미하며 사용자를 유입시키기 위한 마케팅 방법으로 사용하는데요. 웹 소셜 커머스 광고를 클릭했을 때 앱으로 전환되거나, 게임에서 메신저 친구 초대를 통해 앱을 실행하는 것 등이 딥링크로 구현됩니다. 딥링크는 자연스럽게 사용자를 유도할 수 있는 편리한 기능으로 iOS와 Android, PC와 모바일 등 구동되는 환경만큼이나 다양한 형태로 널리 사용되고 있습니다.

다양한 딥링크의 종류

URL schemes

딥링크의 가장 초기 형태인 URL schemes는 test:// 혹은 scheme://와 같이 스킴을 앱에 정의하는 방식으로 사용합니다. 예를 들어 LINE에서는 line://을 URL schemes로 사용합니다.

그럼 URL schemes를 이용해 여러분의 홈페이지에서 LINE을 실행하려면 어떻게 해야 할까요? 앞서 말씀드렸듯, 딥링크는 기본적으로 링크이기 때문에 아래와 같이 HTML을 작성하여 LINE을 실행할 수 있는 버튼을 쉽게 만들 수 있습니다.

<a href="line://"> open LINE! </a>

이제 여러분의 앱에 사용할 URL schemes를 직접 정의해 봅시다. iOS와 Android 환경에서 직접 정의하려면 각각 앱 설정이 필요합니다.

iOS 설정

iOS에서는 XCode > Info > URL Types 항목에서 설정할 수 있습니다. URL Schemes 항목에 원하는 값을 입력합니다(RFC 3986 표준에 따라 소문자를 권장합니다).

위 화면에서 URL Schemes만 지정해도 앱이 실행되지만, 더 나아가 실행된 딥링크의 정보를 이용해 앱 실행 후 특정 페이지로 이동하는 것과 같은 후속 처리 로직을 추가하는 것도 가능합니다. iOS에서는 AppDelegate.m에서 handleOpenURL 함수와 openURL 함수, 이 두 가지 함수를 작성하면 되는데요. handleOpenURL은 iOS 9.0 이하 버전에서 사용하고 openURL은 iOS 9.1 이상 버전에서 사용합니다. 두 가지 함수 모두 작성하여 모든 버전에 대비해 놓는 것이 좋습니다. 아래 코드는 handleOpenURL 함수와 openURL 함수의 예시입니다.

- (BOOL)application:(UIApplication*)application handleOpenURL:(NSURL *)url
{
    //url variable is deeplink information.
    return YES;
}
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *) sourceApplication annotation:(id)annotation
{
    //url variable is deeplink information.
    return YES;
}

Android 설정

Android에서는 AndroidManifest.xml 파일을 수정하는 방법으로 URL schemes을 사용할 수 있습니다. 딥링크를 통해 앱으로 이동할 때 사용자에게 보여주고 싶은 activity(화면)에 <intent-filter>를 추가합니다.

아래 코드를 보면 웹 브라우저에서 intent를 식별할 수 있도록 BROWSABLE 카테고리를 추가했고 패키지명 없이 암시적으로 intent를 실행할 수 있도록 DEFALULT 카테고리를 추가했습니다. 또한 딥링크을 실행할 때 activity를 노출해야 하므로 action을 VIEW로 설정했습니다. 마지막으로 data 엘리먼트를 추가하여 스킴을 지정했습니다(iOS와 마찬가지로 RFC 3986 표준에 따라 소문자를 권장합니다).

<activity
    android:name=".MainActivity"
    android:launchMode="singleTop"
    android:theme="@style/AppTheme.NoActionBar">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
    <intent-filter>
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <action android:name="android.intent.action.VIEW" />
        <data android:scheme="testapp" />
    </intent-filter>
    ...
/>

Android에서는 host, path prefix, path pattern 등과 같은 data 엘리먼트 추가 옵션으로 URL schemes를 더욱 정밀하게 사용할 수 있습니다(자세한 내용은 Android 공식 문서를 참고하세요).

실행된 딥링크 정보는 아래와 같이 AndroidManifest.xml에 딥링크 실행으로 지정한 activity에서 처리할 수 있습니다. 

public class MainActivity extends Activity {
    ...
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        ...
        Intent intent = getIntent();
        Uri data = intent.getData();
        if (data != null) {
            //data variable is deeplink infomation.
        }
        ...
    }
}

URL schemes의 한계

URL schemes는 누구든지 자신이 원하는 URL schemes를 제약 없이 설정할 수 있기 때문에 앱 별로 고유한 딥링크를 점유하는 게 불가능합니다. 만약 다른 앱과 스킴 값이 중복된다면 여러분의 딥링크가 다른 앱으로 하이재킹(hijacking)될 수도 있습니다. 이러한 보안 문제로 iOS에서는 9.1 버전 이후로는 URL schemes에 대해 추가 개발하지 않겠다고 공지했고, 몇몇 웹 브라우저와 앱에서는 URL schemes에 대해 경고 메시지를 띄우거나 URL schemes가 동작하지 않도록 막고 있습니다.

또한 URL schemes만으로는 앱 설치 유무를 제대로 파악할 수가 없습니다. 사용자 입장에서 앱이 설치되어 있지 않으면 앱을 설치할 수 있는 마켓이나 관련 홈페이지 등으로 이동하는 것이 자연스럽습니다. 이를 구현하는 기능을 'fallback URL'이라고 하는데요. 안타깝게도 URL schemes는 이를 공식적으로 지원하지 않습니다. 따라서 TRACKIT에서는 JavaScript를 이용하여 별도로 처리하고 있습니다.

이러한 URL schemes의 한계로 여러 OS와 웹 브라우저, 앱에서는 개별적으로 딥링크를 구현하여 사용하고 있습니다.

Universal Link와 App Link

URL schemes가 가진 문제점을 해결하기 위해 2015년 하반기에 iOS와 Android 플랫폼은 각각 새로운 딥링크를 개발하여 발표했습니다. iOS는 Universal Link, Android는 App Link라고 이름 붙였는데요. 구동되는 환경은 다르지만 개념적으로는 비슷한 형태의 딥링크입니다.

iOS의 Universal Link

Universal Link는 HTTPS가 적용된 도메인을 딥링크로 사용합니다. 도메인의 고유성과 HTTPS의 SSL(secure sockets layer) 인증서를 이용해 딥링크를 안전한 자원으로 관리, 사용하여 기존에 존재했던 보안 문제를 해결했습니다. 예를 들어 https://line.me가 딥링크로 동작하는 것인데요. LINE에서 해당 도메인을 점유하고 있기 때문에 URL schemes과는 다르게 다른 앱에서 하이재킹할 수 없습니다.

그렇다면 URL schemes에서 fallback URL이 지원되지 않던 문제는 어떻게 해결했을까요? Universal Link를 클릭했을 때 사용자의 기기에 앱이 설치되어 있지 않으면 OS에서 Universal Link를 fallback URL을 판단하여 해당 도메인으로 이동하는 방식으로 해결하였습니다. 이를 간단히 도식화하면 아래 그림과 같습니다. 

Universal Link를 실행했을 때 어떤 앱을 실행할지는 클라이언트와 도메인에 연결된 서버에 정의되어 있습니다.

우선 Apple Developer에서 애플리케이션 Capabilities의 Associated Domains를 활성화합니다. 그리고 앱 정보인 App ID Prefix를 기억해 둡니다.

다음으로 XCode > Capabilities의 Associated Domains 항목에 applinks:{your_main}와 같은 형태로 도메인을 입력합니다. 아래 이미지와 같이 여러 개의 도메인을 등록할 수 있습니다.

마지막으로 서버를 설정합니다. 앱을 설치할 때 iOS는 Domains에 할당되어 있는 도메인에 접근하여 Universal Link 메타데이터를 획득합니다. 이때 iOS가 접근하는 경로는 {domain}/.well-known/apple-app-site-association과 {domain}/apple-app-site-association입니다. 설치할 때 두 경로 모두에 접근하여 동일한 메타데이터를 내려줍니다. 메타데이터는 JSON형식으로 아래와 같은 형태입니다.

{
    "applinks": {
        "apps": [ ],
        "details": [
            {
                "appID": "{App Id Prefix}.{Bundle ID}",
                "paths": [ "/example", "*/example2/*", "/detail/*", "NOT /detail/old" ]
            },
        ]
    }
}

앞서 확인했던 App Id Prefix와 번들 아이디를 appId로 지정하고, 앱이 실행되었으면 하는 paths를 JSON 배열 형태로 입력합니다. paths에는 위 예시와 같이 asterisk(*)와 NOT 패턴을 적용할 수 있습니다.

Universal Link에 대한 클라이언트 이벤트는 AppDelegate.m의 continueUserActivity 함수를 통해 처리할 수 있습니다.

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void(^)(NSArray * __nullable restorableObjects))restorationHandler {
    if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) {       
        //userActivity.webpageURL variable is deeplink information.
        return YES;
    }
    return NO;
}

이제 Universal Link 설정이 완료되었습니다. 아래는 메모 앱에서 Universal Link를 테스트해 본 결과입니다.

Universal Link는 기기나 앱 마켓, 혹은 Test Flight에 업로드할 필요 없이 시뮬레이터에서 바로 테스트해 볼 수 있습니다.

Android의 App Link

Android에서 iOS의 Universal Link에 대응하는 딥링크가 App Link입니다. HTTPS뿐만 아니라 HTTP로도 사용 가능하며, Universal Link와 마찬가지로 도메인을 딥링크로 사용하고 도메인은 앱이 설치되지 않은 상황에서는 fallback URL로 동작합니다.

도메인에 연결되어 있는 서버에서 메타 데이터를 획득한다는 점도 같은데요. 이때 서버에 접근하는 경로는 {domain}/.well-known/assetlinks.json입니다. 메타 데이터는 JSON 형식으로 아래와 같은 형태입니다.

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.your.package",
    "sha256_cert_fingerprints": ["1E:46:05:74:B1:B6:A4:06:5C:AB:5C:64:90:81:33:DE:C0:C3:CF:D6"]
  }
}]

번들 아이디 대신 package_name을 사용하며, App Prefix Id 대신 Android APK 파일을 서명할 때 사용하는 KeyStore의 SHA-256 정보를 사용합니다. 아래와 같이 keytool 명령어로 SHA-256 정보를 얻을 수 있습니다.

> keytool -list -keystore my-keystore.keystore

App Link의 메타데이터에는 Universal Link의 메타 데이터에서 paths에 해당하는 정보가 없습니다. App Link에서는 앱의 AndroidManifest.xml 파일에 paths값을 설정합니다.

AndroidManifest.xml 정보는 URL schemes를 설정할 때와 동일합니다. data 엘리먼트의 scheme, host, path attribute에 도메인에 대응하는 값을 넣어주면 App Link를 사용할 수 있습니다.

<intent-filter>
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <action android:name="android.intent.action.VIEW" />
    <data
      android:pathPattern="/document/.*"
      android:host="www.your-domain.com"
      android:scheme="http" />
    <data
      android:path="/category"
      android:host="www.your-domain.com"
      android:scheme="http" />
</intent-filter>

App Link에 대한 클라이언트 이벤트는 URL schemes와 동일하게 아래와 같이 Activity의 Intent 객체에서 확인할 수 있습니다. 기존에 URL schemes를 사용하고 있었다면 보다 쉽게 적용하여 사용할 수 있습니다.

public class MainActivity extends Activity {
    ...
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        ...
        Intent intent = getIntent();
        Uri data = intent.getData();
        if (data != null) {
            //data variable is deeplink infomation.
        }
        ...
    }
}

테스트를 위해 앱 마켓에 업로드할 필요는 없습니다. APK 파일에 코드 서명만 되어있으면 SMS(Short Message Service)와 Gmail 앱에서 가능합니다.

Universal Link와 App Link의 한계

Universal Link와 App Link는 사용자 클릭이 트리거(trigger)되었을 때만 동작합니다. 예를 들어 jQuery 이벤트인 document ready에서 링크를 실행했을 때는 앱이 설치되어 있음에도 불구하고 fallback URL로 동작합니다. 또한 특정 앱에서 동작하지 않도록 막은 경우도 있습니다. 대표적으로 Pinterest, WeChat, Facebook Messenger, Telegram 등의 앱에서는 지원되지 않습니다. 마지막으로 iOS는 9.2 미만, Android는 마시멜로(6.0) 미만 버전에서는 사용할 수 없습니다. 이런 이유 때문에 Universal Link와 App Link가 실행되지 않는 상황에 대응하기 위해 URL schemes와 복합적으로 사용해야 합니다.

Android Intents with Chrome

Android Intents with Chrome은 Android 용 Google Chrome에서만 사용할 수 있는 기능입니다.  이름에서 알 수 있듯 브라우저에서 Intent를 실행하기 위한 기능인데요. Android에서 사용하는 URL Schemes이 결국 Intent를 이용하여 앱을 실행하는 것이므로 클라이언트 측 수정 없이 URL schemes를 완전히 대체할 수 있습니다. 이런 이유 때문인지 Android 용 Google Chrome에서는 URL schemes가 동작하지 않습니다. 

Chrome Intent는 앞서 설명드린 다른 딥링크들과는 다르게 URL 형식이 아니라 별도의 문법(syntax)를 가지고 있습니다.

intent:
   HOST/URI-path // Optional host
   #Intent;
      package=[string];
      action=[string];
      category=[string];
      component=[string];
      scheme=[string];
      S.browser_fallback_url=[encoded_full_url]
   end;

조금 생소한 형태지만 입력해야 하는 값들이 명시적으로 나타나 있어서 쉽게 사용할 수 있습니다. 위 예시를 보면 package 명을 넣는 것을 보실 수 있는데요. 이를 통해 URL schemes에서 스킴이 겹치는 문제로 발생했던 하이재킹을 어느 정도 막을 수 있습니다. 앱 마켓을 통해 배포된 앱은 서로 패키지 명이 겹칠 수 없는 것을 이용한 것인데요. Universal Link나 App Link와 같이 모든 상황에 대해 하이재킹을 막을 순 없지만, 개발자가 별도로 메타 데이터를 서빙(serving)할 필요가 없기 때문에 훨씬 간단하게 사용할 수 있습니다. 또한 fallback URL도 명시적으로 기록하여 사용할 수 있습니다. 사용 방법은 URL과 동일합니다. 아래 예시는 Android Intents with Chrome을 이용하여 LINE을 실행하는 예시 코드입니다.

<a href="intent://#Intent;scheme=line;package=jp.naver.line.android;end"> click </a>
 
window.location = "intent://#Intent;scheme=line;package=jp.naver.line.android;end"

Android Intents with Chrome의 한계

Android Intents with Chrome 역시 한계가 있습니다. 물론 Google Chrome 버전 25 미만에서는 사용이 불가능합니다. 또한 Chrome Intent도 Universal Link와 App Link와 마찬가지로 사용자 클릭을 트리거로 하는 동작에서만 딥링크로 동작합니다.

TRACKIT에서 딥링크를 사용하는 법

앞서 소개 드렸던 것처럼, URL schemes, Universal Link, App Link, Android Intents with Chrome 등 모바일 환경에는 다양한 딥링크가 존재하고, Facebook 딥링크처럼 이번 글에선 언급하지 않은 애플리케이션 단위 딥링크도 있습니다. TRACKIT은 모든 환경의 사용자를 앱으로 이동시키기 위해 각각의 딥링크를 상호 보완하는 형태로 조합하여 사용하는데요. TRACKIT에서 사용하는 딥링크를 순서도와 함께 간단하게 설명하겠습니다.

아래 순서도는 TRACKIT에서 발급된 링크에서 단계 별로 딥링크를 확인한 후 실행하는 흐름을 나타냅니다. TRACKIT에선 사용자의 환경을 랜딩 페이지(landing page)에서 JavaScript를 통해 확인하고 조건에 맞는 딥링크가 무엇인지 판단합니다.

먼저 사용자가 웹 배너에 설치된 링크를 클릭하면 각 OS에서 Universal Link나 AppLink 동작 유무를 판단합니다. UniversalLink는 iOS 9.0 이상, AppLink는 Android 6.0 이상에서 작동합니다. 사용자 환경이 각 조건에 맞고 앱이 설치되어 있으면 앱이 실행됩니다. 만약 버전이 낮거나 앱이 설치되어 있지 않으면 TRACKIT의 랜딩 페이지로 이동합니다. 랜딩 페이지에선 가장 먼저 사용자의 OS를 확인합니다.

사용자의 OS가 iOS라면 document ready 이벤트를 받아 URL schemes를 이용해 앱을 실행합니다. 만약 앱이 설치되어 있지 않다면 앱 마켓으로 이동합니다. Android에선 사용자의 클릭 이벤트가 필요합니다. 사용자가 '실행' 버튼을 클릭하면 Chrome Intent 동작 유무를 확인합니다. Chrome Intent는 사용자의 브라우저가 Chrome이고 브라우저의 버전이 25 이상인 경우에 동작합니다. 이 조건에 맞고 앱이 설치되어 있다면 앱을 실행하고, 그렇지 않다면 URL schemes를 이용합니다.

TRACKIT은 이처럼 다양한 딥링크를 사용하여 사용자를 앱으로 유입하고 그 과정을 추적하고 있습니다.

딥링크의 문제점

하지만 이렇게 딥링크를 통해 앱을 실행하더라도 사용자를 추적할 수 없는 경우가 있습니다. 바로 딥링크를 실행했지만 앱이 설치되어 있지 않아 앱 마켓으로 이동 후 새로 설치하는 경우입니다. 이런 경우에는 마켓으로 이동하는 과정에서 딥링크가 유실되어 앱이 설치된 후 어느 딥링크를 통해 앱을 설치했는지 알 수 없습니다. 이런 문제를 해결하기 위한 딥링크를 '데퍼드 딥링크(Deferred Deeplink)'라고 합니다.

신규 설치 사용자의 딥링크 추적 방법 - 데퍼드 딥링크

데퍼드 딥링크(Deferred Deeplink)란 문자 그대로 앱이 설치된 후 '지연(deferred)'되어 실행되는 딥링크입니다.

따라서 데퍼드 딥링크는 앱 마켓으로 이동할 때 유실되는 딥링크를 막을 수 있으며, 이를 통해 아래와 같은 두 가지 장점을 얻을 수 있습니다.

첫 번째로 딥링크가 연결된 광고를 통해 '새로 앱을 설치한 사용자(NRU, Newly Registered User)'를 집계할 수 있습니다. 이를 통해 마케터는 광고의 효율성을 파악할 수 있습니다.

두 번째로 사용자가 원하는 콘텐츠를 설치와 동시에 보여줄 수 있습니다. 따라서 앱 내 콘텐츠를 목적으로 설치한 사용자의 동선을 줄일 수 있습니다.

이런 장점을 지닌 데퍼드 딥링크는 역시 각각의 OS 별로 구현하는 방식이 다릅니다.

Android의 데퍼드 딥링크, Install Referrer

Android의 데퍼드 딥링크는 Google Play Install Referrer라고 합니다. 이 기능은 Android에서 Android 마켓인 Google Play Store를 통해 공식적으로 지원합니다.

사용 방법은 아주 간단합니다. 앱 마켓 URL에 QueryParam으로 referrer={URL Encoded String}를 넣어주기만 하면 됩니다. 예를 들어 https://line.me를 통해 Google Play Store로 접근하는 경우엔 다음과 같이 사용할 수 있습니다. 

<a href="https://play.google.com/store/apps/details?id=jp.naver.line.android&hl=ko&referrer=https%3A%2F%2Fline.me%2Fko%2F"> Download LINE! </a>

Chrome Intent는 아래처럼 S.market_referrer 항목을 추가하여 사용할 수 있습니다.

intent:
   HOST/URI-path // Optional host
   #Intent;
    ...
      S.market_referrer=https%3A%2F%2Fline.me%2Fko%2F"
    ...
   end;

Google Play Store에 전달된 referrer는 앱이 설치된 후 com.android.vending.INSTALL_REFERRER 메시지를 통해 앱으로 전달됩니다. 따라서 이 메시지를 처리하기 위해 아래와 같이 BroadcastReceiver를 상속한 클래스를 작성해야 합니다.

public class InstallReferrerReceiver extends BroadcastReceiver {
    private static final String TAG = "PION_INSTALL_REFERRER";
 
    @Override
    public void onReceive(final Context context, Intent intent) {
        String referrer = intent.getStringExtra("referrer");
    }
}

작성한 클래스를 com.android.vending.INSTALL_REFERRER로 AndroidManifest.xml에 등록하면 이제 데퍼드 딥링크를 사용할 수 있습니다.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="{your package name}">
 
 
    <application ....>
    ....   
    <receiver android:name="{your package name}.InstallReferrerReceiver" android:exported="true">
        <intent-filter>
            <action android:name="com.android.vending.INSTALL_REFERRER" />
        </intent-filter>
    </receiver>
    ....
    </application>
</manifest>

Google Play Install Referrer는 두 가지 방법으로 테스트할 수 있습니다. 첫 번째는 Google Play Store에서 지원하는 기능으로 Google Play Store Beta에 앱을 설치하여 확인하는 방법입니다. 두 번째는 아래와 같이 adb(Android debug bridge)를 이용한 broadcast 메시지로 테스트하는 방법입니다.

$YOUR_ANDROID_HOME/platform-tools/adb shell am broadcast -a com.android.vending.INSTALL_REFERRER -n {your package name}/{your package name}.InstallReferrerReceiver --es "referrer" "https%3A%2F%2Fline.me%2Fko%2F"

두 번째 방법을 이용하면 로컬 환경에서 간단하게 install referrer를 호출할 수 있습니다. 하지만 adb는 사용자가 쉽게 호출할 수 있고 실제로 설치하지 않은 사용자도 마케팅 집계 서비스에서 설치로 판단하기 때문에 인벤토리(광고가 실리는 공간)를 제공하는 쪽에서 광고 단가를 올리기 위해 어뷰징을 하는 경우가 많았습니다.

이런 이유로 Google에서는 안전한 API를 통해 install referrer를 제공하고 있습니다. Java를 사용하는 경우 이 라이브러리를 사용해 더욱 간단하게 Install Referrer를 얻어올 수 있습니다.

Google Play Install Referrer의 문제점

Google Play Install Referrer는 사용자가 Google Play Store 앱을 이용하여 다운로드한 경우에만 동작합니다. 만약 웹 브라우저를 통해 웹 기반의 Google Play Store에 접근했다면 Google Play Install Referrer는 작동하지 않습니다. TRACKIT은 이를 해결하기 위해 별도로 기능을 구축하여 설치 과정을 추적하고 있습니다.

iOS의 데퍼드 딥링크

안타깝게도 iOS에서는 공식적으로 데퍼드 딥링크를 제공하지 않습니다. 따라서 iOS의 구조적 특징을 이용하여 데퍼드 딥링크를 직접 구현하여 사용해야 합니다. 하지만 이마저도 iOS 버전에 따라 동작하지 않는 경우가 발생하기 때문에 iOS에서는 데퍼드 딥링크를 사용하기가 무척 까다롭습니다.

iOS에서 데퍼드 딥링크를 사용하는 방식은 다양하게 존재하는데요. 그중에서 대중적으로 가장 널리 사용하는 방식을 소개하겠습니다. iOS 버전 11 이전 버전에서는 Safari webview는 브라우저와 앱 내의 webview가 쿠키 저장 공간을 공유합니다.

이를 이용하여 랜딩 페이지에서 쿠키를 저장한 뒤 앱 설치 후 invisible webview를 생성하여 랜딩 페이지에 접근, 쿠키 정보를 확인하여 설치를 확인하는 방법이 있습니다.

하지만 이 방법은 iOS 버전 11에서 앱 별로 개별적인 cookie storage를 사용하도록 바뀌면서 그 이후로는 더 이상 사용할 수 없게 되었습니다. 따라서 현재(iOS 12.3 버전)는 데퍼드 링크를 100% 사용할 수 있는 방법이 없습니다.

TRACKIT은 이를 해결하기 위해 ADID(Advertising ID)나 IDFA(Advertising Identifier), Fingerprint 등을 이용하여 기능을 구축, iOS 앱에서도 최대한 끝까지 딥링크를 추적하고 있습니다. 

마치며

이상으로 TRACKIT에서 딥링크를 사용하는 방법에 대해 소개 드렸습니다. 여기저기 파편화된 딥링크에 대한 정보를 간략히 정리해보았는데요. 처음 딥링크를 적용해 보려는 분에게 이 글이 도움이 됐으면 좋겠습니다.

긴 글 읽어주셔서 감사합니다.