감사합니다!

개발자를 위한 딥링킹 가이드

Deep linking developers guide
서문

어트리뷰션 및 딥링킹 현황

오늘날 어트리뷰션 및 딥링킹을 올바르게 이해하고 있는 사람은 거의 없습니다.

코차바(Kochava), 튠(Tune) 등 기존의 솔루션은 어트리뷰션 분야에서의 경쟁에 뒤쳐지면서 프로세스 및 기술적 차이에 억울한 누명을 씌웠습니다. 새로 시장에 진입한 사람들은 UX에 대해서만 고민할 뿐 각종 연동 및 툴 사용 측면에서의 어트리뷰션, API 접근성, 파트너십 연동, 개인정보보호, 데이터 보안, 견고한 기술적 지원 등에 필요한 기술적 복잡성은 간과하곤 합니다. 몇몇 업체의 세일즈팀은 자신에게 유리한 상황에서는 어트리뷰션과 딥링킹이 어떤 연관성이 있는지, 불리한 상황에서는 왜 연관성이 없는지에 대해 장황한 이야기를 늘어놓으며 생태계 전반에 걸쳐 마케터의 혼란을 초래합니다.

현실을 말하자면, 어트리뷰션과 딥링킹은 서로 관련있으며 이 두 기술을 두 개의 업체에 각각 맡길 필요는 없습니다.

주요 제공업체에서 제공하는 세계적인 어트리뷰션은 내기에 거는 판돈과 같습니다. 고객과 만나는 모든 접점에서 실행되는 캠페인에 효과적인 어트리뷰션을 적용할 수 없다면, 앱의 특정 지점으로 사용자를 유도할 수 있는지 여부는 중요하지 않습니다. 프로덕트 매니저, 마케터, 엔지니어는 “사용자 흐름 최적화” 또는 “완벽한 사용자 경험” 등 현실을 호도하는 단기 선전 문구에 현혹되지 않아야 합니다. 그보다는 적절한 도구를 설정하고 사용하는 일이 효과적인 UX의 시작이자 끝이라는 점을 인지하고 세계적 수준의 기술을 구현하는 데 집중해야 합니다. 오늘날, 효과적인 UX란 모든 OS, OS 버전, 앱 버전, 브라우저, 전환 경험을 관리할 수 있는 UX를 의미합니다. 공통적인 경험에 영향을 미치는 수백만 개의 다양하고 예외적인 사례가 존재합니다.

본 가이드의 목적은 숙련된 기술을 보유한 독자가 어트리뷰션 및 딥링킹에 대한 올바른 정보를 습득하고, 모바일 환경에 관한 최신 트렌드를 학습해 적극적으로 활용할 수 있도록 돕는 것입니다.

Connection between attribution and deep linking
제1장

개념 바로잡기: 어트리뷰션 & 딥링킹

먼저 어트리뷰션 및 딥링킹에 관한 몇 가지 기본적인 사항을 다시 한번 점검하며 이야기를 시작해봅시다.

어트리뷰션이란 무엇이고 왜 존재하는가

앱 스토어들은 사용자가 앱을 검색하는 시점부터 설치 후 실행하는 시점까지의 사용자 데이터를 전달하는 안정적인 방법을 제공하지 않습니다. 사용자 유입 경로 및 앱 다운로드를 유도한 캠페인 링크, 즉, 사용자 출처에 대한 기타 중요 데이터를 ‘포착’하기 위해서는 사용자의 속성값에 대한 정보를 제공하는 제3자 솔루션의 도움이 필요합니다. 이 과정이 바로 어트리뷰션입니다. 그리고 이러한 기술을 제공하는 외부 협력업체를 어트리뷰션 제공업체라고 부릅니다.

일반적으로 어트리뷰션 제공업체가 제공하는 SDK는 모바일 웹상의 기기를 ‘핑거프린팅’해 사용자를 어트리뷰션한 다음, 사용자가 앱을 실행할 때 이 정보를 매칭하는 방식을 사용합니다. 예를 들어, 사용자가 AppsFlyer URL을 클릭하면, 링크는 기기 정보를 사진을 찍는 것처럼 순간 포착하는 페이지로 사용자를 리디렉션합니다. 그리고 이 페이지를 통해 사용자 기기의 IP, 휴대전화 사이즈, 스크린 사이즈, OS, OS 버전 정보가 공통적으로 수집됩니다.

그 다음 어트리뷰션 업체는 앱을 다운로드할 수 있는 앱 스토어로 사용자를 안내합니다. 구글 플레이 스토어 리시버를 보유한 안드로이드를 제외하고는 앱 스토어를 통한 데이터 전송은 없습니다. 따라서 앱에 포함된 외부 업체의 SDK는 사용자의 앱과 함께 다운로드됩니다. 그리고 사용자가 앱을 실행하면 SDK가 사용자의 데이터를 포착하고 시스템에 전송해 사용자를 ‘매칭’합니다. 과거에는 외부 어트리뷰션 협력업체 또한 사용자 데이터를 iOS의 IDFA와 안드로이드의 GAID에 연결해 지속적으로 사용자를 트래킹하곤 했습니다.

이것이 중요한 이유는 무엇일까요? 다양한 설명이 가능하지만, 가장 설득력 있는 몇 가지 이유만을 살펴보도록 하겠습니다.

  1. 유료 미디어 채널이 보고하는 데이터는 정확성을 신뢰할 수 없는 경우가 있습니다. 필연적으로 이해 관계가 상충할 수밖에 없는 구조이기 때문입니다. 
  2. 미디어 소스 전반으로부터 데이터를 집계하고 데이터 수집업체(Data Aggregator)에 데이터를 전달할 수 있는 편향되지 않은 단일 솔루션이 필요합니다.
  3. 어트리뷰션을 인정받은 유료 채널을 통해 들어온 딥링킹 사용자의 앱 잔존율이 31% 증가합니다.
  4. 일반적인 어트리뷰션 링크 사용자와 비교했을 때, 딥링킹 사용자의 전환율은 2.5배 더 높았습니다.
  5. 딥링킹 과정에는 사용자의 의도가 더욱 잘 반영되므로 높은 수익으로 이어집니다. 실제로 연구 결과에 따르면 딥링킹을 사용할 경우 사용자 1명 당 평균 수익(APRU)이 148% 증가합니다.

딥링킹은 어트리뷰션의 확장입니다.

어트리뷰션과 딥링킹이 서로 다른 개념 또는 기술이라는 오해가 시장에 만연하지만, 이는 사실이 아닙니다.

딥링킹은 어트리뷰션 데이터의 확장 또는 활용을 의미합니다.

기본적인 예시를 바탕으로 딥링킹 기술 작동 방식을 살펴봅시다. 앞에서 우리는 사용자가 링크 또는 광고를 클릭하는 방식을 설명했습니다. 그 다음 어트리뷰션 제공업체는 앱을 다운로드할 수 있는 적절한 앱 스토어로 사용자를 유도합니다.

설치 또는 클릭을 통해 사용자가 앱을 실행하면 어트리뷰션 SDK가 사용자의 데이터를 순간 포착하고 사용자를 ‘매칭’하기 위해 데이터를 시스템으로 전송합니다. 이 데이터는 또한 사용자를 지속적으로 트래킹하기 위해 iOS의 IDFA 및 안드로이드의 GAID에도 연결됩니다. 매칭은 여러 가지 방식으로 실행될 수 있으며, 그중 한 가지는 ‘핑거프린팅’이라고 불리는 방식입니다. 다른 매칭 방식으로는 구글 플레이 스토어 리퍼러, iOS Safari 뷰 컨트롤러 쿠키를 수신하고 매칭하는 방법이 있습니다. 사용자가 앱을 보유하고 있으면 높은 정확성을 보장하는 결정적 매칭이 가능한데, 이 경우에는 URI 스킴(my-app://), 유니버설 링크, 안드로이드 앱 링크, 크롬 인텐트(manifest를 통한 활동 등록 및 처리) 등 이미 정해진 흐름을 따라 앱이 즉시 실행되기 때문입니다. 이러한 최신 방식을 통해 앱은 사용자 출처에 대한 링크를 획득하므로 AppsFlyer와 같은 어트리뷰션 솔루션은 쌍으로 구성된 결정적 키 값을 쿼리 파라미터 집합에 추가할 수 있습니다. 이 파라미터 집합은 클릭으로 확인 가능하며 앱을 실행하는 순간 즉시 검색됩니다.

ID matching flow - attribution
Probabilistic modeling flow - attribution
Referrer flow - attribution

바로 이 시점에서 SDK는 링크 및 그 외 연관된 어트리뷰션 메타데이터를 포함하는 콜백을 앱에 제공합니다. 다음은 iOS에 제공되는 AppsFlyer SDK 콜백 샘플입니다.

{
campaign: “CAMPAIGN_NAME”, // “None” if not specified on the link
media_source: “MEDIA_SOURCE”, //”None” if not specified on the link
cost_cents_USD : “0”,
is_first_launch: true,
install_time: “2018-12-30 23:59:39.330”,
orig_cost: “0.0”,
af_click_lookback: “7d”,
click_time: “2018-12-30 23:59:09”,
cost_cents_USD: “0”,
af_status: “Non-organic”
}

이제 앱 개발자가 이 콜백 데이터를 가져올 차례입니다. 개발자들은 사용자정의 이벤트를 기록하고, 메시지를 발송하고, 일부 활동에 대한 로그를 남기는 등 원하는 것은 무엇이든 할 수 있습니다. 하지만 가장 중요한 사실은 개발자들이 어트리뷰션 데이터를 확인하고, 사용자를 앱의 특정 지점으로 유도할 수 있다는 점입니다. 이것이 바로 딥링킹입니다.

디퍼드 딥링킹은 사용자가 앱을 설치한 후 처음으로 실행하는 순간에 어트리뷰션 데이터를 불러오고, 링크 또는 정의된 경로에 대한 파싱(parsing) 작업을 수행하고, 사용자를 앱의 특정 페이지로 라우팅하기 위해 데이터를 사용하는 프로세스입니다.

어트리뷰션에 대한 오해 바로잡기

In the methodology described, an attribution partner provides attribution data based on matched devices and deterministic known devices between web and app.

First, let’s talk about deterministic matching and probabilistic modeling.

앞서 설명한 방법론에 따르면 어트리뷰션 파트너는 웹과 앱 사이에서 핑거프린팅된 기기 및 결정적이라고 판단되는 기기를 바탕으로 어트리뷰션 데이터를 제공합니다. 이러한 기기는 사용자를 연속적으로 트래킹하기 위해 IDFA와 GAID를 사용합니다.

먼저 결정적 및 확률적 매칭을 알아보겠습니다. 결정적 매칭은 사용자가 100%의 정확도로 어트리뷰션 및 딥링킹되는 경우입니다. 이는 URI 스킴 런치, 안드로이드 크롬 인텐트, 안드로이드 구글 플레이 스토어 리시버 콜백, 안드로이드 앱 링크, iOS 유니버설 링크 등의 기술을 기반으로 합니다. 이 모든 경우에 클릭을 통해 앱을 동시 실행할 수 있으며, 결정적 지표는 앱 실행 시 100%의 정확도로 제공됩니다. 예를 들어 보겠습니다.

spotify://track/123?click_id=known_user_ABCD123

이 경우 iOS의 크롬 및 안드로이드 운영 플랫폼과 같이 URI 스킴 런치를 지원하는 브라우저에서 링크를 클릭하면 앱은 어트리뷰션 링크를 통한 리디렉션으로 실행됩니다. 즉, 어트리뷰션 링크가 브라우저에서 자바스크립트 앱으로 사용자를 리디렉션하는 작업이 일어나는 것입니다 (생각해 보십시오… window.location.href…). 이는 앱이 실행되고 업스트림 클릭을 위한 식별자가 앱에 제공된다는 것을 의미합니다. 앱 내부의 SDK는 이 값에 대한 파싱 작업을 수행하고 100%의 정확도로 사용자를 즉시 매칭합니다. 이와 동일한 시스템과 방법론이 안드로이드 앱 링크 및 애플 유니버설 링크같이 앞에서 언급한 기술에도 작용합니다. 이것이 바로 결정적 매칭이며, 정확성은 100%입니다.

확률적 매칭은 앞서 설명한 매칭의 한 종류로서, 사용자의 브라우저 프로파일이 클릭을 통해 핑거프린팅되는 것을 말합니다. 사용자가 앱을 설치하고 실행하면, SDK는 유사한 핑거프린트를 매칭시키고 어트리뷰션 소스를 표시하는 서버에서 콜백을 수신합니다. 때로는 핑거프린트가 중복될 가능성이 있으므로 이 매칭을 확률적이라고 간주하는 것입니다. 제3자 어트리뷰션 제공업체가 IP, 휴대전화 사이즈, 스크린 사이즈, OS, OS 버전 등 고도로 예측 가능하지만 때로는 상충하는 파라미터 집합을 바탕으로 매칭을 수행하기 때문입니다.

예상과는 달리 핑거프린팅이 확률적인 이유는 같은 IP로 iPhone을 사용하는 사용자를 비슷한 링크를 클릭하는 또 다른 사용자로 간주할 수 있기 때문입니다. 완벽한 확률적 불일치가 발생할 가능성이 매우 낮긴 하지만 현실에서는 여전히 일어나는 일입니다. 민감한 개인 정보를 포함할 가능성이 있는 UX 플로우에서 딥링킹을 활용하는 기술 전문가들이 어트리뷰션 방법론의 차이를 명확히 이해해야 하는 이유는 바로 이 때문입니다.

두 가지 유형의 매칭 방식에 대해 알아보았으니, 이제는 문제가 되는 사안들을 논의할 차례입니다. 일부 어트리뷰션 제공업체는 ‘높은 매칭률’을 주장하기도 합니다. 또는, 일부 업체는 ‘사람을 기반으로 한 어트리뷰션 방법’에 대해 이야기하며 채널 전반에 걸쳐 사용자를 어트리뷰션할 수 있는 더 좋은 방법이 있다고 주장합니다. 이러한 주장은 어느 정도 사실일 수도 있지만 이를 무턱대고 믿기 보다는 이러한 가정을 낱낱이 살펴보고 왜, 그리고 어떻게 그것이 가능한지를 먼저 이해해야 합니다.

첫째, 매칭률이 높다는 것은 얼마나 많은 기기와 사람이 핑거프린팅되었는지 알려주는 지표로, 다음과 같은 정보의 프록시에 해당합니다.

#1 어트리뷰션 기술을 사용하는 회사의 종류

#2 이 회사들이 어트리뷰션 기술을 사용하는 방법

#3 익명의 어트리뷰션 데이터가 공유 및 활용되는 방법

예를 들면,  AppsFlyer SDK를 사용하는 앱은 전 세계적으로 85,000개 이상이며, AppsFlyer는 가장 규모가 큰 어트리뷰션 제공업체입니다. 하지만 이보다 더 중요한 사실은 AppsFlyer의 SDK를 사용하는 다양한 브랜드가 전 세계에 분포해있어 다양한 채널 전반에서 구조화된 링크를 생성할 수 있다는 점입니다. Walmart, Alibaba, eBay, Epic Games (Fortnite), Microsoft (Minecraft), booking.com, Coca-Cola, Waze, HBO 등의 브랜드는 소규모 브랜드에 비해 핑거프린팅 방식으로 매칭된 사람들에게 도달할 가능성이 더 높습니다.

둘째, 정확도 측정 기준은 생각보다 훨씬 더 중요합니다. 많은 회사가 “사람 중심의 어트리뷰션이 더욱 효율적이다”와 같은 말을 잘못 해석합니다. 이 문장의 진정한 의미는 웹과 앱 전반에 걸친 다양한 터치포인트에서 사용자를 포착할 수 있다면, 해당 사용자를 매칭하고 어트리뷰션할 수 있는 능력이 본질적으로 개선된다는 것입니다. 유료 미디어, 이메일, 스마트 배너, 리퍼럴 전반에 어트리뷰션 링크를 사용한다면 기본적으로 더 많은 터치포인트에서 사용자를 트래킹할 수 있기 때문에 결과적으로 어트리뷰션 능력이 더욱 향상할 것입니다!

셋째, 회사가 사용자 데이터를 공유할지 여부를 결정하는 것 역시 중요합니다. 2018년에 AppsFlyer는 GDPR이 사용자 마케팅 데이터 관리 및 활용의 새로운 기준으로 자리 잡는 현상을 목격했습니다. 미국에서는 페이스북, 구글을 포함해 여러 기업이 국회 청문회에 소환되며 곤란한 상황을 겪었고, 사용자들은 자신의 개인 정보가 담긴 데이터가 악의적인 용도로 사용되었다는 사실에 분노했습니다. 신뢰성이 가장 높은 어트뷰션 제공업체인 AppsFlyer는 외부 업체와 IDFA 및 GAID를 공유하지 않습니다. 그 대신, 웹 쿠키 및 IDFA/GAID와 매칭할 수 있는 익명의 데이터 풀을 형성해 활용합니다. 모든 앱에 걸쳐 사용자를 매칭하기 위해 이 데이터 집합을 외부 회사와 명시적으로 공유하지 않고 내부적으로 사용합니다. 이러한 방식은 매칭 작동 방식과 효율성에 일부 제한을 가할 수도 있지만, 우리는 사용자 데이터를 지키고 보안을 준수하는 일이 중요함을 믿기 때문입니다. 모든 회사가 이러한 암묵적 규칙을 준수하고 사용자 개인정보 보호법을 따르지는 않습니다. 오늘날, OpenGDPR에 소속된 어트리뷰션 제공업체를 선택하는 일이 그 어느 때보다도 중요한 이유입니다.

attribution alert

일부 제3자 어트리뷰션 솔루션이 주장하는 ‘비법 공개’ 등의 과대 선전에 현혹되지 마세요. 일부 사람들이 “기존의 어트리뷰션 시스템은 해답을 주지 못한다”고 주장할 때, 이는 대개 영업 및 마케팅 전략일 뿐 실제 기술을 근거로 하지 않습니다.

제대로 된 어트리뷰션 제공업체는 사용자와 터치포인트를 매칭하기 위해 결정적 방식인 웹 쿠키와 기기 ID 매칭(IDFA 또는 GAID)을 사용합니다. 어트리뷰션 제공업체 풀의 도달 범위에 따라 딥링킹을 활용하거나 활용하지 않기로 결정하는 선택이 달라질 수 있다는 사실이 중요합니다.

Attribution and deep linking tech
제2장

어트리뷰션 & 딥링킹 기술

분류법

어트리뷰션이나 딥링킹 기술과 관련한 문제는 동일한 용어가 너무 다양한 이름으로 불린다는 점입니다. 또한 마케터들이 고객 경험을 고려하긴 하지만, 그러한 고객 경험을 위한 기술 전달 메커니즘은 간과하기 쉽습니다. 대부분 사람들은 ‘딥링킹’을 단순히 고객을 앱의 특정한 지점으로 유도하는 행위로 이해합니다. 하지만 이 글에서는 ‘딥링킹’을 보다 자세하게 다뤄보고자 합니다. 딥링킹은 URI 스킴을 의미할까요? 아니면 Apple 유니버설 링크나 크롬 인텐트 또는 안드로이드 앱 링크를 의미할까요? 

위의 4가지는 모두 딥링크이고, 특정 상황에서 앱 내부의 특정 지점으로 고객을 유도합니다. 이 사실을 기억하면서, 가장 일반적인 딥링킹과 어트리뷰션 분류법을 살펴봅시다. 마케터는 팀원이나 제품, 엔지니어링, 마케팅 담당자와 회의할 때 이러한 분류법을 사용할 수도 있고, 사용해야 하기도 합니다.

크롬 인텐트는 안드로이드 전용 딥링킹으로, 유저가 웹페이지에서 앱을 실행할 수 있도록 도와줍니다. 자세한 작동 방식은 여기에서 확인할 수 있습니다.

딥링크:

어트리뷰션:

원하는 결과나 이벤트로 이어질 수 있는 유저 행동을 식별하고, 그 유저들이 어디서 유입되었는지, 소스를 확인하는 과정. 웹 어트리뷰션은 웹 쿼리 파라미터와 자바스크립트를 통해 처리됩니다. 유저가 링크를 클릭하면 자바스크립트를 통해 “window.location.href.split(“utm_campaign=”)[0]”와 같은 URL 파라미터를 확인하고 저장할 수 있습니다. iOS 앱 어트리뷰션은 안드로이드 앱 어트리뷰션에 비해 훨씬 더 복잡합니다. Apple 앱 스토어에서 앱을 다운로드하면, 쿼리 파라미터가 전송되지 않기 때문입니다. 그래서 제3자 어트리뷰션 서비스를 이용하지 않으면, iOS의 모든 유저는 새로운 유저로 간주됩니다.

제3자 어트리뷰션 서비스:

링크 클릭, 핑거프린트, SDK, 유저 기반 어트리뷰션 서비스를 통해 유저를 어트리뷰션하고 측정하는 도구.

어트리뷰션 핑거프린트:

유저가 광고나 링크를 클릭하면 어트리뷰션 서비스는 IP, 휴대전화 사이즈, 스크린 사이즈, 운영 체제, 운영 체제 버전 등 자바스크립트로 알 수 있는 모든 데이터를 확인합니다. 이렇게 기기 정보를 저장하는 과정을 ‘핑거프린팅’이라고 합니다. 핑거프린팅 데이터는 앱의 어트리뷰션을 위해 사용됩니다. 이러한 어트리뷰션 방식을 ‘확률적 매칭’이라고 합니다. 하지만 정확성이 떨어져서 더 이상 널리 사용되지 않습니다.

매칭:

핑거프린팅이 완료된 후 유저가 앱을 실행하면, 제3자 어트리뷰션 서비스의 SDK가 동일한 파라미터 세트를 찾아내어 유저를 ‘매칭’합니다. 기술적으로 말하면, SDK는 유저를 매칭해달라는 요청을 서버로 보냅니다. 이 서버는 웹에서 생성된 것과 동일한 핑거프린트를 검색합니다. 서버가 동일한 핑거프린트를 찾으면, 그 유저가 웹에서 클릭한 내용과 관련된 링크나 데이터, 캠페인 정보 또는 어트리뷰션을 보내줍니다. 이 정보가 딥링킹에 사용될 수 있습니다. 예를 들어 콜백으로 URL이 제공되면, 개발자는 유저를 앱의 특정 지점으로 유도하기 위해 사용된 웹 URL, URI 또는 다른 파라미터를 파싱할 수 있습니다.

SDK:

SDK(소프트웨어 개발 키트)는 IE 개발자 최대의 적입니다. 일반적으로 SDK는 유저를 어트리뷰션하기 위해 필요합니다. 하지만 제3자 어트리뷰션 서비스의 SDK는 유저 정보를 수집하고 처리하는데 그치지 않습니다. 이러한 SDK는 어트리뷰션 데이터를 받아 사용하기 쉬운 형식으로 바꿉니다. 그래서 이를 콜백으로 실행할 수 있습니다. SDK를 사용하고 싶지 않다면, API를 직접 호출해야 합니다. 하지만 API 공개 호출이 불가능한 경우도 있습니다. 그래서 SDK를 사용하지 않으면, 기능과 성능이 제한됩니다. 이 글을 쓰는 순간에도 어트리뷰션과 딥링킹 기술은 계속 상용화되고 있습니다. 자체적으로 기술을 구축하기보다 제3자 서비스를 활용하는게 훨씬 효율적입니다.

콜백:

반환된 후 다른 코드로 전달되는 응답. 어트리뷰션과 딥링킹 분야에는 ‘콜백’이라는 개념이 있습니다. 제3자 어트리뷰션 서비스가 유저를 매칭하고 어트리뷰션과 딥링크 데이터를 전달하면, 앱에 응답을 제공합니다. 이 응답을 ‘콜백’이라고 합니다. 다음의 두 가지 예를 살펴봅시다. 첫 번째 예시는 AppsFlyer SDK가 제공하는 콜백입니다. 두 번째 예시는 mParticle을 통한 AppsFlyer 어트리뷰션 & 딥링킹을 활용할 때, iOS 앱으로 전송되는 ‘콜백’입니다. 두 예시를 통해, SDK가 JSON을 사용하는 앱에 어떻게 응답하는지 알 수 있습니다. 이 응답은 사용자 정의 이벤트 트리거나 딥링킹에 사용될 수 있습니다.

딥링크의 유형:

딥링크의 ‘유형’을 올바르게 파악하려면, 딥링킹의 ‘메커니즘’을 살펴봐야 합니다. 딥링크는 유저를 앱의 특정 지점으로 유도하는 링크입니다. 하지만 유저를 유도하는 방식은 매우 다양합니다.

URI:

앱의 유니버설 리소스 표시자(Universal Resource Indicator). 앱을 구성하기 위해 전송되는 항목. URI 덕에 앱을 바로 실행할 수 있습니다. 경로 이름을 구성하듯이 “경로”도 구성할 수 있습니다. 대부분의 앱은 URI 스킴과 경로를 갖고 있습니다.

예를 들어,

  • airbnb://
  • walmart://
  • fb://

이 경로는 기본 스킴 뒤에 나오는 URI의 일부입니다.

크롬 인텐트:

크롬 인텐트는 안드로이드 전용 딥링킹으로, 유저가 웹페이지에서 앱을 실행할 수 있도록 도와줍니다. 자세한 작동 방식은 여기에서 확인할 수 있습니다.

Apple 유니버설 링크:

Apple 유니버설 링크는 iPhone 운영체제인 iOS에 배포한 표준 링크입니다. 유저가 앱을 이미 설치했다면, 이 링크를 탭하기만 해도 바로 그 앱으로 이동합니다. 이는 URL이나 링크 측정 서비스를 통한 리디렉션과 달리, 시스템 수준의 경로입니다.

유저 인텐트:

Apple은 유저가 유니버설 링크를 클릭해서 특정 지점으로 유도되어야만 ‘유저 인텐트’를 갖는다고 정의합니다. 그래서 이메일 클릭 레코더와 같은 라우팅 서비스나 기타 클릭 트래킹 서비스에 래핑되면, Apple 유니버설 링크는 작동하지 않습니다. 앱이나 다른 인앱 브라우저도 인텐트에 영향을 주는 유니버설 링크를 사용할지 안 할지 선택할 수 있습니다.

클릭 트래킹(클릭 래핑):

URL이 리디렉션이나 측정을 위해, 다른 URL 또는 웹페이지를 통해 리디렉션 되는 경우. 이는 Apple 유니버설 링크를 망가뜨리고, 이메일이나 유료 채널을 위한 어트리뷰션과 딥링킹을 복잡하게 만듭니다.

안드로이드 앱 링크:

Deep linking chronology
제3장

딥링킹 발전 과정

딥링킹 관련 용어가 처음부터 이렇게 복잡하지는 않았습니다. 애플 유니버설 링크, 안드로이드 앱 링크, 크롬 인텐트가 탄생하기 전에는 특색 없고 밋밋한 URI 스킴과 핑거프린팅만이 존재했습니다.

오늘날 상황이 왜 이렇게 복잡해졌는지를 이해하기 위해서는 어트리뷰션과 딥링킹이 처음에 어떻게 탄생했는지, 그리고 어떻게 진화해 왔는지를 이해하는 과정이 중요합니다.

최초의 딥링킹 – 어떻게 작동했는가

과거에는 링크, 핑거프린트, URI 스킴만이 존재했습니다. 제3자 어트리뷰션 제공업체로서 AppsFlyer가 이 기술 분야를 개척했을 때, 사용자를 어트리뷰션하고 딥링크하는 프로세스는 단순했습니다.

  1. 사용자가 어트리뷰션 링크를 클릭합니다. 링크의 형태와 작동 원리는 지금과 유사했습니다.
  2. 자바스크립트가 사용자의 핑거프린트를 로딩 및 캡처하는 페이지로 사용자를 리디렉션합니다.
  3. 그 짧은 순간에 브라우저가 운영체제를  파악하고, URI 스킴과 경로를 포함하는 플랫폼 설정을 확인하고, 자바스크립트는 타이머를 설정한 후 URI 스킴과 경로를 전송합니다.
  4. 브라우저가 응답하기 전 타이머가 만료되면 사용자가 앱을 다운로드하지 못한 것으로 간주합니다. 이 경우 해당 운영체제와 연관된 적절한 앱 스토어로 브라우저의 리디렉션이 실행됩니다.
  5. 일반적인 어트리뷰션과 마찬가지로 사용자가 앱을 설치하고 실행하면 핑거프린트 매칭이 실행되고, 이 정보가 콜백으로 앱에 전달됩니다.
  6. 만일 사용자 기기에 앱이 설치되어 있다면, URI가 즉시 앱을 실행합니다. 그리고 URI가 열렸을 때, 어트리뷰션 제공업체는 clickId 또는 linkId를 전달해 SDK가 사용자의 유입 경로를 정확하게 파악할 수 있도록 도와줍니다.

위의 과정은 간단하고 명확한 딥링킹 프로세스로, 주요 제3자 어트리뷰션 및 딥링크 서비스업체가 전부 이 프로세스를 활용했습니다.

그렇다면 무엇이 바뀌었을까?

애플이 iOS 9.3에 애플 유니버설 링크를 포함시킨 2015년, 모든 것이 바뀌었습니다. 애플은 iOS 9.3 버전을 선보이며 다음의 두 가지 사항을 적용했습니다.

  1. 유니버설 링크: 앱 경로에 대한 새로운 표준
  2. 차단 방지 자바스크립트를 제거한 새로운 사파리: 위에서 정의된 경로로 iOS에서 사용자를 유도할 수 있는 기능을 삭제했습니다. iOS의 타이머와 자바스크립트 라우팅 메커니즘이 더는 작동하지 않게 되었습니다.

iOS 9.3이 배포되면서 기존 세계의 질서가 무너졌습니다. 바로 이 시점부터 각 운영체제 및 미디어 회사들이 크롬 인텐트, 안드로이드 앱 링크, 페이스북 앱 링크 등 자사의 표준을 적용해 서로 다른 방식을 배포했기 때문에 어트리뷰션 및 딥링킹 기술은 한층 복잡해지게 됩니다.

현재 딥링킹은 고도로 세분화되었으며, 브라우저나 앱 환경뿐 아니라 운영체제, 사용하는 메커니즘에도 상당히 의존하고 있습니다. 아래의 표는 가장 널리 알려진 딥링킹 콘텍스트에 대한 예상값을 간략하게 표시한 것입니다.

iOS안드로이드
페이스북 뉴스피드af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
페이스북 브라우저앱에 대한 딥링크앱에 대한 딥링크
페이스북 메신저af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
페이스북 메신저 브라우저앱에 대한 딥링크앱에 대한 딥링크
인스타그램 프로필af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
인스타그램 브라우저앱에 대한 딥링크앱에 대한 딥링크
인스타그램 스토리af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
트위터 피드af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
트위터 브라우저앱에 대한 딥링크앱에 대한 딥링크
레딧af_web_dp 또는 af_ios_url 폴백에 대한 딥링크af_web_dp 또는 af_android_url 폴백에 대한 딥링크
핀터레스트af_web_dp 또는 af_ios_url 폴백에 대한 딥링크af_web_dp 또는 af_android_url 폴백에 대한 딥링크
핀터레스트 브라우저앱에 대한 딥링크앱에 대한 딥링크
크롬 브라우저앱에 대한 딥링크앱에 대한 딥링크
크롬 주소 표시줄af_web_dp 또는 af_ios_url 폴백에 대한 딥링크af_web_dp 또는 af_android_url 폴백에 대한 딥링크
사파리 브라우저앱에 대한 딥링크N/A
사파리 주소 표시줄af_web_dp 또는 af_ios_url 폴백에 대한 딥링크N/A
파이어폭스 브라우저af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
파이어폭스 주소 표시줄af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
UC 브라우저af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
네이버 브라우저af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
카카오 브라우저af_web_dp 또는 af_ios_url 폴백에 대한 딥링크앱에 대한 딥링크
오페라 브라우저앱에 대한 딥링크앱에 대한 딥링크
애플 iMessage앱에 대한 딥링크N/A
애플 비즈니스 챗앱에 대한 딥링크N/A
슬랙앱에 대한 딥링크앱에 대한 딥링크
위챗af_web_dp 또는 af_ios_url 폴백에 대한 딥링크af_web_dp 또는 af_android_url 폴백에 대한 딥링크
왓츠앱앱에 대한 딥링크앱에 대한 딥링크
Gmail앱에 대한 딥링크앱에 대한 딥링크
Deep linking mechanisms
제4장

딥링킹 메커니즘 심층 탐구

Apple 유니버설 링크

Apple 유니버설 링크(iOS)와 안드로이드 앱 링크(Android)는 기본적으로 같은 개념이지만, 종종 혼용되거나 다른 라우팅 메커니즘과 혼동되기도 합니다. 따라서 이 개념에 대해 이야기할 때는 명확히 해야 합니다. 그렇지 않으면 다른 방식으로 작동하는 기술과 혼동할 수도 있습니다. Apple 유니버설 링크는 iPhone 운영체제인 iOS에 배포된 표준 링크입니다. 유저가 앱을 이미 설치했다면, 이 링크를 탭하기만 해도 바로 그 앱으로 이동합니다. Apple 유니버설 링크에는 리디렉션 기능이 없습니다. 일정 수준의 기술을 갖춘 특별 시스템 설정입니다. 유저가 링크를 탭하면, Apple에 왕복 서버 호출이 전송됩니다. OS는 브라우저를 실행하거나 URL을 로딩하지 않고 바로 앱을 실행합니다. 작동 원리에 대한 자세한 내용은 아래를 참고하세요.

안드로이드 앱 링크는 안드로이드에 설정된 동일한 링크 시스템입니다. Apple 유니버설 링크와 안드로이드 앱 링크는 모두 웹 URL입니다.

Apple Universal Links

이 링크는 웹이나 앱에서 유저가 원하는 최적의 지점으로 연결됩니다. 유저가 앱을 설치하지 않았다면, 링크는 모바일 웹으로 연결됩니다. 하지만 이미 앱이 설치된 상태라면 유저가 원하는 콘텐츠가 있는 앱의 특정 지점으로 이동합니다. 앱이 설치된 모바일 기기에서는 유저가 유니버설 링크를 탭하면 앱으로 바로 이동합니다. 앱이 설치되어 있지 않다면, 시스템이 유저를 모바일 웹사이트로 안내합니다. 일부 예외는 아래를 참고하세요.

링크가 정말 ‘유니버설’하려면, 링크된 기능이 웹, iOS, 안드로이드 모두에서 사용 가능해야 합니다. 또한, 모든 앱이 같은 리소스 경로를 공유해야 합니다.

작동 원리

유니버설 링크는 두 가지 주요 요소로 구성됩니다.

  1. AASA:Apple App Site Association 파일. 이 파일은 유저가 이미 앱을 설치했다면 앱을 바로 실행해주는 링크의 도메인에서 호스팅됩니다. 자세한 내용은 여기를 참고하세요.
  2. Associated Domains: iOS 앱의 Entitlements > Associated Domains 파일에서 코드를 약간 변경.

기본적인 차이를 명확히 구분해야 합니다. 유니버설 링크는 “링크들의 묶음”이 아니라, 도메인이 사용하는 링크에 설치된 시스템입니다.

유니버설 링크는 제3자 어트리뷰션 URL뿐만 아니라 회사 자체 도메인 URL에서도 활성화될 수 있습니다. AppsFlyer는 이 유니버설 링크를 ‘OneLink’라고 부릅니다. AppsFlyer의 성공적인 고객사 사례를 살펴보세요.

Walmart.com 는 다음에서 활성화되는 ‘유니버설 링크’를 포함합니다: https://www.walmart.com/ip/Banana-Dog-Costume/172218418

AppsFlyer OneLink는 다음에서 활성화되는 ‘유니버설 링크’를 포함합니다:
https://walmart.onelink.me?af_dp=walmart://ip/Banana-Dog-Costume/172218418

위의 사례에서 전체 URL이 continueUserActivity를 통해 앱에 전달되면, 유저를 적절히 파싱하고 라우팅할 수 있습니다. 두 가지 사례 모두 개발자가 각 링크에 특정한 유형의 파싱과 라우팅을 한다고 가정합니다. 위의 사례에서 개발자는 도메인 단계 이후의 모든 것을 파싱할 수 있습니다. 아래의 사례에서 개발자는 af_dp 값을 정확히 처리해야 합니다. 이는 정적 값을 포함하는 딥 링크를 처리하는데 매우 중요합니다.

마지막으로 언급해야 할 중요한 사항이 있습니다. 거의 모든 회사의 AASA가 “/apple-app-site-association“을 따르는 주요 도메인에 호스팅됩니다. 그래서 어떤 회사의 AASA 파일이든 쉽게 찾아볼 수 있습니다.

Deep linking callbacks
제5장

예시와 함께 보는 어트리뷰션 & 딥링킹 콜백 처리

어트리뷰션과 딥링킹에 관한 지식을 실제로 실행에 옮기고 싶다면 아래 예시를 참고해보세요.

고객 사례 #1: 표준 어트리뷰션 & 라우팅 처리

이 예시에서는 SDK 설정을 완료하고, 딥링크를 성공적으로 테스트할 준비가 끝났다고 가정합니다. 따라서 이러한 준비가 되지 않았다면, 이 가이드의 테스트 & QA 섹션을 먼저 확인하세요. 이 섹션에서는 딥링크 QA를 수행하는 방법과 흔히 저지르는 실수를 자세히 설명합니다. QA 팀과 함께 살펴볼 간결한 체크리스트도 제공합니다. 이제 SDK 설정을 완료했다고 가정하고, 사례를 통해 유저 딥링킹 방법을 자세히 알아봅시다. AppsFlyer는 앱에서 설치 데이터를 수신하기 위한 2가지 기능을 제공합니다.

  • 안드로이드onInstallConversionDataLoaded
  • iOS: onConversionDataReceived

이 기능에서 반환된 전환 데이터는 기존 트래킹 링크나 추가적인 서버 파라미터로 이루어집니다. 이 파라미터는 클릭이나 설치 시점에 생성됩니다. 전환 데이터가 트래킹 링크에 의존하기 때문에, 여러 소스와 트래킹 링크는 다양한 전환 데이터 파라미터를 생성할 수 있습니다.

또한, 설치 유형에 따라 3가지 다른 결과가 나타날 수 있습니다.

  1. 논오가닉 설치: 설치와 관련한 기존 어트리뷰션 데이터를 반환합니다. 아래 예시를 참고하세요.
  2. 오가닉 설치(또는 재설치): ‘오가닉 설치’를 반환합니다.
  3. 리어트리뷰션: 리어트리뷰션 전환에 관한 세부 정보를 반환합니다.

실제 사례

다음은 iOS에서 onConversionDataReceived 를 호출하면 받게 되는 콜백의 예시입니다. 이 예시는 유료 광고에 AppsFlyer의 딥링킹 서비스를 사용하는 쇼핑 앱 Jet의 사례입니다.

  1. ▿ 0 : 2 elements
  2. – key : click_time
  3. – value : 2018-08-14 02:37:30.798
  4. ▿ 1 : 2 elements
  5. – key : orig_cost
  6. – value : 0.0
  7. ▿ 2 : 2 elements
  8. – key : cost_cents_USD
  9. – value : 0
  10. ▿ 3 : 2 elements
  11. – key : is_first_launch
  12. – value : 0
  13. ▿ 4 : 2 elements
  14. – key : campaign
  15. – value : Test
  16. ▿ 5 : 2 elements
  17. – key : af_click_lookback
  18. – value : 7d
  19. ▿ 6 : 2 elements
  20. – key : af_dp
  21. – value : jet://product/Carbona-Washing-Machine-Cleaner-3-Count/d1909b8fb76240d480df7c983452a913
  22. ▿ 7 : 2 elements
  23. – key : idfa
  24. – value : 00000-0000-0000-0000-0000000000000
  25. ▿ 8 : 2 elements
  26. – key : media_source
  27. – value : Email
  28. ▿ 9 : 2 elements
  29. – key : install_time
  30. – value : 2018-08-14 02:38:40.012
  31. ▿ 10 : 2 elements
  32. – key : af_status

몇 가지 사항은 즉각적으로 나타나야 하며, 또한 이 기능의 콜백에서 해당 키 값 구조를 사용할 수 있어야 합니다. 이는 정보를 파싱하고, 유저를 라우팅하고, 사용자 정의 이벤트와 경험을 호출하기 위해 필요합니다. 예를 들어, AppsFlyer 딥링크에 나타나는 af_dp 값을 통해 유저를 즉시 이 URI로 라우팅할 수 있습니다. is_first_launch 값을 통해서는 설치 후 앱을 처음으로 실행했는지 과거에 앱을 실행한 적이 있는지 확인할 수 있습니다.

AppsFlyer는 앱이 실행될 때마다 어트리뷰션 데이터를 수신하기 위해 onAppOpenAttribution을 사용합니다. 이는 iOS와 안드로이드 각각에서 다르게 구현됩니다. 아래의 작업 흐름도는 어떻게 2개의 기능을 결합해 설치할 때는 설치 데이터를, 그렇지 않은 경우에는 오픈 데이터를 수신하는지 보여줍니다. 그 지점에서 af_dp, af_web_dp, af_ios_url, af_android_url와 같이 딥링킹에 사용되는 다양한 키를 파싱할 수 있습니다. URL에 포함되는 링크 파라미터의 전체 목록은 여기에서 확인해주세요.

Attribution and routing with AppsFlyer

이로 인해 미묘한 차이가 나타납니다. SDK나 제3자 어트리뷰션 서비스에 따라 데이터 수신 방법이 달라집니다. 그래프에서 보이듯 AppsFlyer는 2가지 방식으로 서비스를 제공합니다. 다른 업체들은 더 다양한 방식 또는 1가지 방식으로만 서비스를 제공할 수도 있습니다.

하지만 콜백 데이터를 파싱하고 유저를 라우팅하는 과정은 변해선 안 됩니다!

고객 사례 #2: AppsFlyer와 CDP(mParticle) 활용

일부 개발사들은 어트리뷰션 업체든 아니든 상관없이 다양한 업체의 의뢰를 받아 라우팅, 딥링킹, 어트리뷰션을 처리합니다.

어떻게 고객 데이터 플랫폼을 통해 여러 개의 딥링크 응답을 처리하는지, mParticle의 사례를 중심으로 살펴보겠습니다.

이 활용 사례의 핵심은 우선 각 외부 업체에서 제공하는 응답 키를 이해한 다음, 누가 딥링킹의 관점에서 작업을 처리하는지 확인하는 데 있습니다. 마지막으로 어떻게 사용자 정의 이벤트에서 어트리뷰션 콜백 데이터를 기록하는지, 이를 통해 어떻게 푸시 알림을 전송하고 프로모션이나 AppsFlyer 데이터를 이용하는 다른 캠페인을 진행하는지 살펴보겠습니다!

실제 사례

이 앱은 콜백 데이터를 제공하는 2개의 외부 업체와 연동되어 있습니다. 고객 데이터 플랫폼인 mParticle은 웹과 모바일 데이터 처리를 전문으로 합니다. 또한 모든 어트리뷰션과 딥링킹 콜백 데이터를  단 하나의 방법으로 전송합니다.

단일 mParticle API는 다른 모든 어트리뷰션 제공 업체의 콜백뿐만 아니라 AppsFlyer의 콜백도 래핑합니다.  그리고 전송이 완료된 콜백을 알려주기 위해 각각의 AppsFlyer Kit를 상수로 표시합니다.

앱 설치나 다른 프로세스가 진행되는 동안, iOS/안드로이드 Kit는 모든 플랫폼에서 AppsFlyer SDK에 델리게이트나 콜백을 등록합니다. 또한 이용 가능한 신규 전환 데이터가 있을 때마다 iOS의 경우 completion handler block을, 안드로이드의 경우 AttributionListener를 호출합니다.

이 결과에서 반환된 키는 AppsFlyer SDK의 결과와 일치합니다. 관련 문서는 다음을 참고하세요.

AppsFlyer 콜백 응답: https://support.appsflyer.com/hc/en-us/articles/207032096-Accessing-AppsFlyer-Attribution-Conversion-Data-from-the-SDK-iOS-Deferred-Deep Linking-

  1. (lldb) po linkInfo
  2. ▿ 1 element
  3. ▿ 0 : 2 elements
  4. ▿ key : AnyHashable(“mParticle-AppsFlyer App Open Result”)
  5. – value : “mParticle-AppsFlyer App Open Result”
  6. ▿ value : 1 element
  7. ▿ 0 : 2 elements
  8. – key : link
  9. – value : https://jet.bttn.io/product/Carbona-Washing-Machine-Cleaner-3-Count/d1909b8fb76240d480df7c983452a913/?btn_ref=fakesrctoken-1111111111111111Shop
    (lldb) po linkInfo
  10. ▿ 1 element
  11. ▿ 0 : 2 elements
  12. ▿ key : AnyHashable(“mParticle-AppsFlyer Attribution Result”)
  13. – value : “mParticle-AppsFlyer Attribution Result”
  14. ▿ value : 11 elements
  15. ▿ 0 : 2 elements
  16. – key : click_time
  17. – value : 2018-08-14 02:37:30.798
  18. ▿ 1 : 2 elements
  19. – key : orig_cost
  20. – value : 0.0
  21. ▿ 2 : 2 elements
  22. – key : cost_cents_USD
  23. – value : 0
  24. ▿ 3 : 2 elements
  25. – key : is_first_launch
  26. – value : 0
  27. ▿ 4 : 2 elements
  28. – key : campaign
  29. – value : Test
  30. ▿ 5 : 2 elements
  31. – key : af_click_lookback
  32. – value : 7d
  33. ▿ 6 : 2 elements
  34. – key : af_dp
  35. – value : jet://product/Carbona-Washing-Machine-Cleaner-3-Count/d1909b8fb76240d480df7c983452a913
  36. ▿ 7 : 2 elements
  37. – key : idfa
  38. – value : 0000000-0000-0000-0000-00000000000
  39. ▿ 8 : 2 elements
  40. – key : media_source
  41. – value : Email
  42. ▿ 9 : 2 elements
  43. – key : install_time
  44. – value : 2018-08-14 02:38:40.012
  45. ▿ 10 : 2 elements
  46. – key : af_status

이 사례에서는 mParticle의 딥링크 API에서만 콜백 데이터를 수신합니다. AppsFlyer SDK 응답을 직접 처리한 사례와 마찬가지로, 이러한 응답들 가운데 어떤 것을 어떻게 처리할지 고려해야 합니다. 아래 내용을 참고하여 링크 로직을 구조화해보세요.

  1. 다양한 외부 업체에서 콜백 데이터를 수신하고 있다면, 어떤 업체가 우선일까요? 대부분의 마케터는 AppsFlyer처럼 주요 매체의 MMP (공식 측정 파트너) 자격을 갖춘 어트리뷰션 업체를 선호합니다.
  2. AppsFlyer의 설치 응답과 오픈 응답을 모두 확인해야 한다는 사실을 잊지 마세요.
  3. 그 응답이 ‘오가닉’이고, 특히 해당 업체가 AppsFlyer와 직접적으로 연동되어 있지 않다면, 다른 외부업체를 고려해 봐야 합니다.

어트리뷰션과 딥링킹 로직을 충분히 고려하는 것은 물론, 고객 측의 어트리뷰션 이벤트에서 받은 키와 값을 합쳐 사용자 정의 이벤트를 기록해야 합니다. 다음 사례는 AppsFlyer와 함께 또는 mParticle과 같은 CDP를 통해 이를 어떻게 실행하는지 보여줍니다.

AppsFlyer

iOS – (void) trackEvent:(NSString )eventName withValues:(NSDictionary)values

eventName은 ‘어트리뷰션’ 또는 ‘어트리뷰션 데이터’처럼 단순해도 됩니다. 값은 위에 나열된 콜백 값의 전체 또는 일부여야 합니다.

안드로이드 – public static void trackEvent(Context context, String eventName, Map eventValues)

eventName은 ‘어트리뷰션’ 또는 ‘어트리뷰션 데이터’처럼 단순해도 됩니다. eventValues는 위에 나열된 콜백 값의 전체 또는 일부여야 합니다

관련 문서:

https://support.appsflyer.com/hc/en-us/articles/115005544169-AppsFlyer-Rich-In-App-Events-Android-and-iOS/introduction

mParticle

iOS

MPEvent *event = [[MPEvent alloc] initWithName:@”Attribution Data”
                                         type:MPEventTypeTransaction];
event.info = @{@”key”:@”value”};
[[MParticle sharedInstance] logEvent:event]

안드로이드

Map<String, String> eventInfo = new HashMap<String, String>();
eventInfo.put(“key”, “value”);
MPEvent event = new MPEvent.Builder(“Attribution Data”, EventType.Navigation)
   .info(eventInfo)
   .build();
MParticle.getInstance().logEvent(event);

관련 문서:

iOS: https://docs.mparticle.com/developers/sdk/ios/event-tracking/#capture-a-custom-event

안드로이드: https://docs.mparticle.com/developers/sdk/android/event-tracking/#capture-a-custom-event

Deep linking advanced topics
제6장

심화 주제

웹-투-앱 전환 전략: 배너 및 링크

웹에서 앱으로의 전환을 유도하는 방법은 무척 중요하지만 엔지니어가 어트리뷰션을 고려할 때에는 보통 이를 간과하곤 합니다.

일반적으로는 다음과 같은 문제를 면밀히 분석하고 고려하는 데만 집중하기 때문입니다.

모바일 웹에서 앱으로 사용자를 유도할 경우 전체 수익에 부정적인 영향을 미칠까요? 웹 사용자와 앱 사용자를 비교하는 방법은 무엇일까요?

앱보다 모바일 웹의 사용 비율이 높으면, 웹에서 앱으로 전환할 때 수익이 악화될까봐 걱정할 수 있습니다. 하지만 일반적으로 웹 유저보다 앱 유저가 3배 더 많이 구매 전환을 일으킵니다. 앱의 전환율이 더 높은 이유는 앱의 UX가 훨씬 더 좋고 간편하게 구매 퍼널로 이어지기 때문입니다. 모바일 웹보다 앱에서 전환이 쉽다는 점 외에도, 유저를 앱으로 유도해야 하는 다양한 이유가 있습니다.

  • 로그인: 사용자가 앱에 로그인하면 장바구니에 물건을 담고 결제하기가 훨씬 쉽습니다. 앱은 사용자의 로그인 정보를 더 오랜 저장합니다. 또한 네이티브 경험과 관련한 UX 디자인이 웹보다 더 간편하고 품질도 뛰어납니다. 그래서 유저는 모바일 웹보다 앱에서 더 많은 시간을 보내고, 더 많이 전환합니다.
  • 인게이지먼트: 앱은 모바일 웹보다 더 간편하고 편리한 경험을 제공할 뿐만 아니라, 유저가 잊고 있던 상품의 결제를 유도하는 푸시 알림, 메시지 센터, 피드 또는 다른 여러 네이티브 요소를 사용할 수 있습니다. 반면 모바일 웹에서는 이메일이 유저의 구매를 유도하는 유일한 방법입니다. 앱은 다양한 방법으로 유저의 행동을 유도하기 때문에 더 좋은 결과를 보입니다.

모바일 웹에서 앱으로 사용자를 유도할 경우 얻게 되는 비즈니스 측면의 혜택 외에도, 웹에서 앱으로 전환을 유도하는 일관적인 전략이 매우 유리하다는 사실을 보여주는 어트리뷰션 및 기술적 측면의 당위성이 존재합니다.

web-to-app banners

바로 앞서 설명한 유저 중심의 어트리뷰션입니다.

회사는 웹이든 앱이든 광고든 이메일이든, 모든 마케팅 채널에서 동일한 어트리뷰션을 사용합니다. 접점에서 사용자를 더 적절하고 지능적으로 어트리뷰션해야 하기 때문입니다. 앞서 논의한 바와 같이, 단일 어트리뷰션 시스템으로 트래킹할수록 더 많은 트래픽 소스를 식별하고, 플랫폼 전반에서 유저를 더 잘 이해할 수 있습니다.

record users across all your marketing touchpoints

모든 마케팅 접점에서 동일한 어트리뷰션 도구로 유저를 트래킹한다면, 더 좋은 어트리뷰션 결과를 얻을 수 있습니다. 또한 유저 소스와 관련해 더 많고 정확한 데이터를 갖게 됩니다. 이것이 바로 유저 중심 어트리뷰션의 전제이자, 단일 어트리뷰션 제공업체를 사용해야 하는 이유입니다.

훌륭함은 어떤 모습으로 나타나는가?

웹에서 앱으로 전환을 유도하는 우수한 전략에는 어떤 것이 있을까요? 이제 배너가 필요하다는 사실에는 충분히 동의하실 겁니다. 그렇다면 어떤 디자인을 적용해야 하고, 배너를 활용하는 가장 쉬운 방법은 무엇일까요?

여기 몇 가지 옵션이 있습니다.

  1. 사용자정의 디자인 및 사용자정의 트래킹
  2. Out-of-Box 디자인 및 트래킹
  3. 1번과 2번의 결합

첫 번째 옵션은 어트리뷰션 도구를 전혀 사용하지 않으면서 배너를 디자인하고, 사용자정의 트래킹을 실행하는 방식입니다. 이 옵션이 불리한 이유는 여러가지입니다. 하지만 이를 선택하지 말아야할 가장 중요한 이유는 쉬운 옵션에 안주하기보다는 다양한 작업을 많이 해야 하기 때문입니다. 이 경우 속도와 유연성을 잃는 대신 통제권을 갖게 됩니다. 몇몇 회사가 자체적으로 만든 사용자 정의 배너를 확인해보세요.

두 번째 옵션은 가장 쉽고 최적화된 방식으로, Out-of-Box 웹 SDK를 JS 방법의 디자인 및 트래킹 솔루션과 함께 이용하는 것입니다. AppsFlyer는 배너를 만드는데 필요한 일부 정적 코드를 제공합니다. 사용자 정의 디자인과 트래킹을 위한 옵션, 파라미터도 제공합니다.

아래의 코드 샘플은 웹 SDK가 완제품과 같이 복사 및 붙여넣기로 즉시 사용 가능하다는 점을 보여줍니다. 웹 SDK에는 웹사이트 상단에 표시되는 배너를 생성할 방법을 지원합니다. 또한 제목, 아이콘, CTA(Call to Action)을 사용자정의 하기 위한 설정 변수 옵션을 제공할 뿐만 아니라 자바스크립트를 사용하는 정적 및 동적 수준의 사용자정의와 설정이 가능한 트래킹 파라미터 목록을 제공합니다.

이 방법을 활용하면 배너 디자인이 모든 브라우저와 기기에 적합한지, CTA 버튼 아래 표시되는 어트리뷰션 URL이 잘 구성되고 잘 관리되고 있는지를 개발사가 직접 신경 쓸 필요가 없어 편리합니다. 이 경우 AppsFlyer는 어트리뷰션 설정 안에 URL을 만들고 링크를 생성합니다. 이 방식은 특정 페이지의 설정이 매우 다양할 수 있기 때문에 특히 유용합니다. 개발사는 웹사이트가 변경될 때, 2가지 설정 변수를 통해 사용자 경험과 트래킹을 원하는 대로 실행할 수 있습니다.

<html>

<head>

<script type=“text/javascript” src=“appsflyer-banner.min.js”></script>

<link rel=“stylesheet” href=“appsflyer-banner.min.css”>

<script type=“text/javascript”>

var banner = new AFBanner();

var settings = {

   // banner settings

   title: “AppsFlyer”,

   subtitle: “Track campaigns on the go”,

   app_icon: “img/app_icon.png”,

   call_to_action: “Install”,

   show_only_mobile: true,

   // attribution settings

   media_source: “banner_pid”,

   campaign: “banner_c”,

   adset: “banner_adset”,

   adset_id: “banner_adset_id”,

   ad: “banner_ad”,

   ad_id: “banner_ad_id”,

   site_id: “banner_site_id”,

   sub1: “banner_sub1”,

   // routing settings

   onelink_id: “pGHC”,

   subdomain: “appsflyer”,

   mobile_deep link: “appsflyer://”

};

</script>

</head>

<body>

   <div id=“my-banner”></div>

   …

</body>

</html>

어떤 방식을 선택하든 한 가지 사실은 분명합니다. Apple이나 안드로이드가 제공하는 “Out of Box” 메타 태그를 사용해서는 안 됩니다. 이 메타 태그는 트래킹이 없는 경우에만 제공됩니다. 그래서 어트리뷰션 모델 전반에 아무런 도움도 되지 않습니다. 또한 사용자 정의 기능도 제공하지 않습니다. 사이트에 자바스크립트를 설치할 때 문제가 있는 경우, 몇 분 더 기다리거나 배너를 설치해주세요. 배너는 앱 스토어로 사용자를 보내는 기능 그 이상을 수행합니다.

install a banner

딥링크된 이메일

배경

Apple 유니버설 링크가 탄생한 이래로, 수많은 마케터, 프로덕트 매니저, 엔지니어들이 이메일에서 딥링크가 되지 않는 것에 아쉬움을 표했습니다.
부분적으로 이는 앞장에서 간략하게 설명한 링킹 메커니즘의 복잡성에 기인하는 문제입니다. 복잡성을 더욱 가중시키는 요인은 이 메커니즘을 다른 방식으로 처리하는 수많은 이메일 고객이 존재한다는 사실입니다.

그래도 희망이 있습니다! 이메일 딥링킹은 사람들이 말하는 것만큼 복잡하지는 않습니다. iOS에 앱이 설치되어 있을 때, 처리하기 까다로운 사례가 하나 있긴 합니다. 하지만 그 외에는 외부 업체, 고객이나 사용자 관점에서 변경되는 사항은 없습니다. 제3자 어트리뷰션 서비스에서 라우팅을 처리하는 것처럼, 이메일 딥링킹도 직접 처리할 수 있습니다. Apple 유니버설 링크와 안드로이드 앱 링크를 이해하고, URL에서 AppsFlyer나 다른 외부 업체의 링크를 사용할지 선택하고, 이메일 링크를 구체적으로 처리하기 위해 고객 코드를 수정할지 선택하기만 하면 됩니다.

구체적으로는, 이메일 링크를 처리하는 두 가지 옵션이 있습니다.

  1. ESP(Email Service Provider)에서 클릭 트래킹 비활성화: 마케팅팀에게는 상당히 까다로운 작업일 수 있겠지만 프로그래밍 방식을 사용하거나 코드 기반의 ESP를 실행한다면 이것이 가장 쉬운 방법입니다. 이 방식에서 클릭 트래킹 기능을 꺼두면, 사용자를 원하는 지점으로 라우팅해주는 웹 링크나 제3자 어트리뷰션 링크를 이메일에서 직접 사용할 수 있습니다.
  2. ESP 클릭 트래킹 도메인에서 Apple 유니버설 링크와 안드로이드 앱 링크를 처리하세요. ESP 도메인을 처리하기 위해 고객 측의 수정이 약간 필요합니다. 그 다음 이메일에서 기본 URL을 불러오고, 유저를 원하는 지점으로 라우팅할 수 있습니다.

Sendgrid는 URL을 처리하고 확인하기 위해 Out-of-Box 기능을 제공합니다. 이는 두 번째 옵션에 해당합니다. 이 코드는 포괄적이며, 모든 ESP에서 실행됩니다. 올바른 헤더를 가진 URL로 보내는 HTTP 호출입니다. 지금까지 Responsys, Sailthru, Braze, Sendgrid, Salesforce을 포함한 주요 ESP에서 작동하는 것으로 확인되었습니다.

https://sengrid.com/docs/Classroom/Build/Add_Content/universal_links.html#-Resolving-SendGrid-Click-Tracking-Links

ESP 딥링킹 실패 원인

이메일이 새로운 운영체제에서 사용자를 적절하게 딥링킹하지 않는 원인을 요약해 검토해보겠습니다.

요약

  • ESP는 클릭 트래킹에서 링크를 래핑합니다.
  • 이는 Apple 유니버설 링크를 망가뜨리고, 안드로이드를 복잡하게 만듭니다.
  • OneLink와 달리, ESP는 다양한 상황에서 앱 또는 웹으로 신뢰할 만한 라우팅을 제공하지 않습니다.

유일하게 딥링킹이 제대로 작동하지 않은 경우는 유저의 iOS에 앱이 설치된 경우입니다. 이 경우 클릭을 트래킹하는 ESP 링크가 유니버설 링크 기능을 망가뜨립니다. 따라서 이를 처리할 시스템을 개발해야 합니다. 이메일 때문에 ‘이메일 딥링크’나 ‘유니버설 링크’가 작동하지 않는 경우 바로 이 문제에 해당합니다.

많은 사람들이 “그럼 데스크톱 링크는요?”라고 질문하지만, 데스크톱 링크는 모든 경우에 정상적으로 작동합니다. ESP 링크는 모든 리디렉션을 래핑할 뿐입니다. 데스크톱의 리디렉션은 앱에 적용되지 않습니다. 대부분의 데스크톱 경험은 그대로 웹으로 이동하므로 수정이 필요하지 않습니다.

email to app journey

이메일 내 딥링킹을 구현하기 위해 비싼 딥링킹 솔루션이 필요하다고 과대광고하는 업체의 말에 현혹되지 마세요. AppsFlyer의 어트리뷰션 링크나 딥링크, 또는 다른 표준 제3자 어트리뷰션 서비스를 사용하면 아래의 가정을 바탕으로 한 거의 모든 사례에서 추가 비용 없이 손쉽게 링크가 작동합니다.

  1. 디퍼드 딥링킹과 일반 딥링킹을 설정해야 합니다. AppsFlyer의 경우 “OneLink”도 포함됩니다.
  2. 개별 외부 업체와 함께 Apple 유니버설 링크와 안드로이드 앱 링크를 설정해야 합니다.

이 2가지 요구사항이 모두 충족됐다면, 앱이 설치되어 있지 않아도 이메일에 포함된 일반 딥링크가 iOS와 안드로이드에서 정상적으로 작동합니다. 이 경우 설정에 따라 유저가 모바일 웹이나 앱 스토어로 유도될 수 있습니다.

안드로이드 운영체제 유저가 앱을 설치했다면 이 링크는 크롬 인텐트를 통해 앱을 바로 실행하거나, ESP 링크가 어트리뷰션 링크로 라우팅합니다. 이 어트리뷰션 링크는 URI 스킴을 통해 앱을 실행합니다. 또한, 안드로이드 앱 링크를 사용해 iOS와 완전히 똑같은 기능을 안드로이드에 복제할 수 있습니다.

작동 원리

  1. 클릭 트래킹 기능이 활성화된 상태를 유지합니다.
  2. ESP 도메인에서 Apple 유니버설 링크와 안드로이드 앱 링크를 설정합니다. 대부분 ESP는 공식 문서로 설정 방법을 안내합니다. 예를 들어, Sendgrid는 사이트에서 어떻게 이 기능을 실행하는지 매우 자세하게 설명합니다: https://sendgrid.com/docs/ui/sending-email/universal-links/#setting-up-universal-links-using-cloudfront
  3. 유니버설 링크가 활성화되면, ESP 클릭 트래킹 도메인에서 앱이 실행됩니다. 이제 마케팅팀이 이메일 HTML에 입력한 URL을 검색해야 합니다. Sendgrid의 Out-of-Box URL Resoluton Code를 사용하면 됩니다.

iOS

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler {
   if (userActivity.activityType == NSUserActivityTypeBrowsingWeb) {
       NSURL *encodedURL = userActivity.webpageURL;
       if (encodedURL == nil) {
           NSLog(@"Unable to handle user activity: No URL provided");
           return false;
       }
       NSURLSession *session = [NSURLSession sharedSession];
       NSURLSessionDataTask *task = [session dataTaskWithURL:encodedURL completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
           if (response == nil || [response URL] == nil) {
               NSLog(@"Unable to handle URL: %@", encodedURL.absoluteString);
               return;
           }
           // Now you have the resolved URL that you can
           // use to navigate somewhere in the app.
           NSURL *resolvedURL = [response URL];
           NSLog(@"Original URL: %@", resolvedURL.absoluteString);
       }];
       [task resume];
   }
   return YES;
}

안드로이드

안드로이드 앱이라면, URL을 확인하기 위해 setInstanceFollowRedirects를 false로 설정하여 HttpURLConnection을 사용할 수 있습니다.

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler {
   if (userActivity.activityType == NSUserActivityTypeBrowsingWeb) {
       NSURL *encodedURL = userActivity.webpageURL;
       if (encodedURL == nil) {
           NSLog(@"Unable to handle user activity: No URL provided");
           return false;
       }
       NSURLSession *session = [NSURLSession sharedSession];
       NSURLSessionDataTask *task = [session dataTaskWithURL:encodedURL completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
           if (response == nil || [response URL] == nil) {
               NSLog(@"Unable to handle URL: %@", encodedURL.absoluteString);
               return;
           }
           // Now you have the resolved URL that you can
           // use to navigate somewhere in the app.
           NSURL *resolvedURL = [response URL];
           NSLog(@"Original URL: %@", resolvedURL.absoluteString);
       }];
       [task resume];
   }
   return YES;
}

보시다시피, 딥링크된 이메일 제품을 구매하거나 원하는 방식으로 외부 업체에 요청하는 데에는 제약이 없습니다. 적어도 링크를 처리할 때만큼은 선호하는 어트리뷰션과 딥링킹 파트너와 협력하면 좋습니다. 하지만 이렇게 잘 알려진 기술을 단순화해 제공하는 척하는 제품이나 시스템에 시간과 비용을 낭비하지 마세요.

작동 원리(흐름도)

이메일 생성

  • 마케터가 이메일 캠페인에 URL을 입력합니다. 회사의 일반 도메인 URL이 될 수도 AppsFlyer 링크가 될 수도 있습니다.
  • 이메일이 발송될 때 Sendgrid와 같은 이메일 서비스 제공업체가 이 링크를 래핑합니다.
  • 최종 사용자가 받는 이메일에 ESP URL이 표시됩니다.예시:click.airbnbmail.com
  • shop.jet.com
  • click.go.wholefoods.com
  • Eml.flagship.postmates.com
ESP deep linking flow

유저가 iOS 크롬이나 안드로이드에서, 또는 앱이 설치되어 있지 않은 iOS나 사파리에서 링크를 탭하면 모든 것이 정상적으로 작동합니다. 말 그대로 차이가 전혀 없습니다. 기존의 일반 링크 리디렉션과 같습니다.

이메일 리디렉션 사례

iOS 9.3 이상 사용자가 앱이 설치된 상태에서 링크를 클릭 할 때, 클릭 트래킹 도메인에 유니버설 링크 또는 안드로이드 앱 링크가 설정되어 있으면 앱이 즉시 실행됩니다.

아래의 그림에서 세 가지의 사례를 확인할 수 있습니다.

사례 1: 사례 1은 디퍼드 딥링킹에서 이미 설명한 바 있습니다. AppsFlyer 링크를 통해 어떠한 제3자 리디렉션도 없이 이메일 링크에서 바로 웹 또는 앱 스토어로 이동합니다. 설치 후 고객의 추가 작업 없이 앱의 특정 지점으로 딥링킹이 가능합니다.

사례 2: 사례 2는 이메일 서비스 제공업체가 제3자 클릭 트래킹을 할 수 있다고 가정합니다. AppsFlyer나 자체 도메인 URL을 사용한다면, 고객 측 코드의 일부분이 필요합니다. 기본 URL을 언래핑하고 앱의 특정 지점으로 사용자를 라우팅해야 하기 때문입니다. 기본적으로 앱이 이미 설치되어 있으면, 앱은 유니버설 링크나 안드로이드 앱 링크를 통해 바로 실행됩니다. 그래서 ESP URL을 언래핑하고 확인해야 합니다. 앱이 설치되어 있지 않으면, AppsFlyer나 자체 도메인 URL은 앱 스토어나 모바일 웹의 특정 지점으로 이동합니다.

사례 3: 단순한 솔루션이 필요한 경우, AppsFlyer를 앱 설치 이후 유저를 앱에 지능적으로 직접 유도할 때만 사용할 수도 있습니다. AppsFlyer는 앱이 설치되었음을 확인하면 브라우저에서 URI 스킴을 전송합니다.

email redirect cases with deferred deep linking

ESP 유니버설 링크 관리: URL 확인, 클릭 및 라우팅 처리

  • 앱에서 기본 URL을 불러오는 데에는 앞에서 언급한 코드 조각이 활용됩니다.기본 URL이 AppsFlyer 링크거나 쿼리 파라미터를 나열한 자체 링크라면, 비동기 통신 호출은 더 이상 필요하지 않습니다. 손쉽게 링크를 처리하세요. 앱의 루트 처리자 쿼리 파라미터를 파싱할 수 있습니다.
  • 기본 URL이 AppsFlyer OneLink의 단축 URL이라면, AppsFlyer에 비동기 통신을 요청하여 처리 전에 링크 메타데이터를 불러와야 합니다. 그래서 AppsFlyer는 긴 URL을 추천합니다. 이는 URL에 주요 키 값을 표시하기 때문에, 라우팅이 쉽고 별도의 왕복 호출이 필요하지 않습니다.
  • 다른 유형의 URL도 이와 유사하게 처리하면 됩니다.

Apple 유니버설 링크가 현재 갖고 있는 문제점

Apple 유니버설 링크는 앱을 보유한 사용자들에게 향상된 UX를 제공하는 것으로 입증된 유용한 기술입니다. 하지만 Apple 유니버설 링크에는 몇 가지 주요 제약이 존재합니다. 그리고 이러한 제약을 미리 알아두지 않는다면 담당자와 제품팀에서 해결할 수 없는 문제로 시간을 무한히 허비할 수 있습니다. 이 글을 작성하는 시점을 기준으로 네 가지 주요 문제가 있으며, 이 문제들은 거의 모든 Apple 유니버설 링크(iOS 12)에만 해당되고 안드로이드 앱 링크와는 관련이 없습니다.

문제 1: 트래킹 또는 어트리뷰션의 부재

Apple 유니버설 링크는 리디렉션보다는 앱을 실행하기 위해 링크에 적용하는 시스템에 가깝습니다. 그래서 진정한 클릭 트래킹을 구축하기는 매우 어렵습니다. 왜 그럴까요? 앱이 Apple 유니버설 링크에서 바로 실행되기 때문입니다. 웹페이지를 통과하는 리디렉션이 없어서 서버에 나타난 클릭을 집계할 수 없습니다. 대신 앱이 실행되면, 앱을 실행하는 URL이 ‘continueUserActivity’라는 Apple 코드를 통해 리포트를 생성합니다. URL에서 클릭을 집계하려면 마케팅팀은 서버를 구축하고 앱에서 수동으로 클릭을 집계해야 합니다.

훨씬 더 쉽고 간편한 방법을 원한다면, AppsFlyer와 같은 어트리뷰션과 딥링킹 도구를 사용해보세요. 이러한 시스템은 실제 도메인에 your_company_name.onelink.me와 같은 유니버설 링크를 포함합니다. 그리고 이 트래킹을 자동적으로 실행합니다. 요약하자면, 링크를 클릭하는 유저를 트래킹하려면, OneLink와 같은 제3자 어트리뷰션 업체가 제공하는 도구가 필요합니다.

문제 2: 링크 래핑 허용 불가

이 문제는 링크 래핑, 클릭 트래킹, 링크 리디렉트 등 여러 가지 이름으로 알려져 있습니다.  이름은 다르지만 모두 같은 문제를 지칭합니다. 마케터가 광고나 이메일을 보내기 위해 사용하는 서비스는 사용 중인 링크를 ‘래핑’하거나 이를 리디렉션을 통해 전송합니다. 그래서 클릭을 집계할 수 있습니다. 마케터가 시스템에 입력한 최종 목적지 URL로 유저를 유도하기 전에 웹사이트로 리디렉션합니다.

link wrapping and deep linking

Apple 유니버설 링크와 안드로이드 앱 링크는 다른 URL에 래핑될 수 없습니다. 다른 URL에 래핑을 시도할 경우, 사용자는 링크를 통해 앱이 아닌 웹 폴백으로 리디렉션됩니다. 이는 주로 마케터가 URL이 래핑되는 더블클릭(Double Click)과 같은 유료 광고를 운영할 경우 혹은 이메일 마케터가 ESP(Email Service Provider)로 클릭 트래킹을 사용할 경우에 영향을 미칩니다.

두 가지 사례 모두, 제3자 툴들은 URL을 래핑하는데 이로 인해 해당 URL이 유니버설 링크처럼 동작할 수 없게 됩니다. 이로 인해 딥링킹이 실패하고 유니버설 링크 사용 목적을 무효화합니다. 클릭 트래킹을 끄는 것에서부터, 복잡성을 해결하기 위한 전문 컨설턴트 고용까지, 이 문제에 대한 다양한 해결 방안이 존재합니다.

문제 3: 팬텀 배너 신드롬

Apple은 유니버설 링크가 실행되면 사파리에서 열린 사이트에 배너 광고를 무작위로 삽입합니다. 이를 제재하거나, 광고를 직접 지정하거나 트래킹할 방법은 없습니다. 이렇게 Apple이 유니버설 링크에 알 수 없는 기능을 적용하자, 시장은 혼돈에 빠졌습니다. 광고는 일부 경우에만 표시되기 때문에 대부분의 고객이 이를 무시합니다. 유저가 Apple 유니버설에서 클릭하면, 웹사이트가 아닌 앱으로 유도됩니다.

phantom banner and deep linking

문제 4: 일반 성능 불안정성

iOS 11 버전부터 다수의 앱에서 유니버설 링크가 항상 같은 방식으로 작동하지 않는 문제가 발생하기 시작했습니다. iOS는 애플 유니버설 링크로 앱을 실행하기 위해 구축한 AASA(Apple App Site Association) 파일에서 도메인 정보를 이용합니다. iOS에서 새로운 사용자가 앱을 설치하면, 사용자 기기의 저장 공간으로 AASA 파일이 다운로드되고 그다음 기기 수준에서 유니버설 링크 라우팅 구성을 위한 파싱 작업을 수행합니다. 이후 사용자가 링크를 클릭 하면 구성된 도메인으로 적절히 유도합니다. 유감스럽게도 개발사들이 보고한 바에 따르면, iOS 11.2에서 AASA 파일 설치 후 기기 및 로컬 저장 공간에 안정적으로 다운로드되지 않고, 파일이 존재하지 않기 때문에 유니버설 링크도 작동하지 않습니다. 일반적으로 많은 실행 단계를 거쳐 설치를 완료하므로 디버그 수행도 어려운 것으로 알려져 있습니다.

이 문제와 관련해 이미 널리 알려진 Apple의 버그가 존재하며 다음 페이지에서 그 내용을 확인할 수 있습니다: http://www.openradar.me/radar?id=4999496467480576

일반 URL 또는 어트리뷰션 제공업체를 위해 URL에 유니버설 링크 사용을 설정했다고 가정하고 다음의 내용을 테스트하면 유니버설 링크 작동을 재개할 수 있습니다.

  • 앱에서 로그아웃하세요.
  • 앱을 삭제하세요.
  • 앱 스토어 또는 테스트/QA 사이트에서 앱을 설치하세요.
  • 기기를 종료한 후 다시 전원을 켜세요. iOS 11에서 링크를 클릭해도 정상적으로 작동하지 않는 entitlement 문제를 해결할 수 있습니다.
  • 테스트하려는 링크를 생성하거나 검색하세요.
  • 메모 앱이나 iMessage, 또는 Apple Mail Client를 사용하는 이메일에 링크를 붙여넣으세요.
    • Slack, Facebook 등 다른 앱을 사용하여 링크를 클릭하지 마세요.
    • Safari에 링크를 붙여넣지 마세요. 링크가 정상적으로 작동하지 않습니다.
  • 링크를 클릭하세요.
  • 브라우저를 통한 리디렉션 없이 앱이 바로 실행됩니다. 또한 유저를 앱의 특정 지점으로 라우팅합니다.
Deep linking testing and QA
제7장

테스팅 & QA

어트리뷰션이든 딥링킹이든 혹은 둘 다를 사용하든 간에, 프로덕트 팀과 마케팅 팀은 이해하기 쉬운 QA 및 문제 해결 가이드라인을 마련해야 합니다.

어트리뷰션과 딥링킹을 테스트하는 일은 매우 복잡하며 유의해야할 기술적 문제들로 가득차 있습니다.

  • 테스트하는 미디어 소스는 무엇인가요?
  • 쿼리 파라미터가 정확한가요?
  • 링크가 URI 인코딩되어 있나요?
  • 링크에 적절한 API와 리디렉션 파라미터가 포함되어 있나요?
  • Apple Search Ads를 실행한 상태에서 테스트를 진행하나요? 이 때문에 콜백이 지연된다는 점을 알고 계신가요?
  • 디퍼드 딥링킹과 일반 딥링킹 중 어떤 것을 테스트하나요?
  • 일반 딥링킹을 테스트한다면, 어떤 메커니즘을 사용하나요?
  • Slack에서 링크를 클릭하시나요? 그렇지 않다면, 어떤 앱 또는 브라우저를 사용하나요?
  • 테스트 빌드와 프로덕션 빌드 중 어떤 환경을 사용하나요?
  • 링크에 AASA 구성이 완료되었나요?
  • AASA가 올바른 포맷인가요? AASA가 정확한 앱 프리픽스, 번들 ID, 테스트 앱이나 프로덕션 앱과 연동된 경로를 포함하고 있나요?

이 질문들은 링크 QA 작업을 할 때 반드시 해야 할 질문의 일부에 불과합니다. 본 가이드는 링크를 테스트하는 단계를 보여드릴 뿐만 아니라, 이러한 질문에 대한 답도 알려드립니다.

프로세스 정립하기

  • 명확한 테스트 절차와 목표를 정의하세요.
  • 아래와 같이 테스트 절차와 관련한 모든 요소를 명시하세요. 어떤 것도 가정이나 추측으로 남겨두지 마세요. 앞서 제시한 질문을 던져보는 과정도 반드시 필요합니다OS, OS 버전, QA 앱, 앱 버전, 브라우저, 링크, 링크 클릭 방법, 링크 클릭 위치, QA 테스터, 외부 업체, 소유자, 사용자 경험 등
  • iOS, 안드로이드, Web X 앱 보유 여부를 바탕으로 예상 결과를 정의하세요. 예상 가능한 모든 결과를 테스트하려면 명확한 매트릭스를 만들어야 합니다. 이 표에 딥링킹이 생성되는 메커니즘을 잘 정리하세요.
  • 테스트 사례를 보여주는 문서를 작성하고 공유하세요. 이 문서를 이용해 팀원들과 협업하세요.
  • 문서화된 QA 프로세스에 필요한 모든 구성 요소를 기록하세요. 문서화 실패는 곧 QA의 실패입니다.

신규 설치 시뮬레이션 – iOS

iOS에서 신규 앱 설치를 시뮬레이션하려면, 아래의 순서에 따라 테스트하세요.

  1. 앱에서 로그아웃하세요.
  2. 앱을 삭제하세요.
  3. IDFA를 초기화하세요: 설정> 개인정보보호 > 광고 > 광고 식별자 재설정
  4. 쿠키를 삭제하세요: 설정 > Safari > 방문 기록 및 웹 사이트 데이터 지우기
  5. 어트리뷰션 링크를 클릭하세요. Safari 랜딩 페이지를 통해 리디렉션합니다.
  6. “앱 스토어 열기”를 클릭합니다.
  7. 프로덕션 앱 테스트가 아니라면, 앱 스토어에서 앱을 다운로드하지 마세요.
  8. 가능하다면 기기에 테스트/QA 버전 앱을 불러옵니다.
  9. 앱을 실행합니다.
  10. 설정에 따라서 새로운 설치 페이지와 딥링크를 확인할 수 있습니다. 이는 앱의 특정 지점으로 사용자를 라우팅하기 위해 콜백을 사용한 경우입니다.

URI 테스트

URI는 유니버설 리소스 식별자(Universal Resource Indicator)라는 사실을 기억해봅시다. URL이나 링크가 유저를 앱으로 안내합니다. 기술적으로, 앱이 설치되어 있지 않으면 URI에 액세스할 수 없습니다.

가장 쉬운 방식으로 iOS에서 URI 스킴을 전송하거나 라우팅을 실행하려면, Safari에 “이동”이라고 타이핑하면 됩니다. 앱이 설치되어 있다면 앱이 바로 실행됩니다. URI와 루트가 존재하고 앱이 이를 처리하고 있다면, 유저를 앱의 특정 지점으로 안내합니다.

testing URIs

앱이 설치되어 있지 않다면 다음과 같은 오류가 표시됩니다.

error testing URIs

직접 URI 테스트

아래 절차를 통해 URI 스킴과 루트에 대한 QA를 실행할 수 있습니다. 이는 모든 앱의 표준 QA 절차에 포함되어야 합니다. iOS와 안드로이드에 정렬된 루트 목록을 관리해야 합니다.

절차:

  1. 앱에서 로그아웃하세요.
  2. 앱을 삭제하세요.
  3. 사용 중인 테스트 앱 또는 QA 앱을 설치하고 실행하세요.
  4. 앱을 실행합니다.iOS 환경에서는 Safari 브라우저에 URI을 붙여넣으세요.
  5. 안드로이드 환경에서는 <a href=””> 요소 뒤에 링크를 입력한 후, 버튼이나 링크를 클릭하세요.

안드로이드에서는 href 요소에 URI를 랩핑한 후 호스팅하거나, 이메일과 같은 매체에 입력하면 가장 쉽습니다. 크롬에서는 Safari에서처럼 URI를 붙여넣을 수 없습니다.
제3자 어트리뷰션 서비스 제공업체가 작동시키는 URI나 어트리뷰션 링크 URI의 절차도 이와 매우 유사합니다.

  1. 앱에서 로그아웃하세요.
  2. 앱을 삭제하세요.
  3. 사용 중인 테스트 앱 또는 QA 앱을 설치하고 실행하세요.
  4. 앱을 실행합니다.
  5. 이메일이나 메모, 또는 SMS에 링크를 붙여넣으세요.
  6. 링크를 클릭하세요.

유니버설 링크 테스트

Apple 유니버설 링크는 테스트하기 까다로운 딥링킹 메커니즘입니다. 비활성화를 유발하는 수많은 규칙과 이미 널리 알려진 여러 문제들 때문입니다. 이미 Apple이 인지하고 있는 각종 버그에도 해결책은 아직 없습니다.

아래의 내용을 읽기 전에, Apple 유니버설 링크가 지닌 문제점을 기억해주세요.

  • AASA를 확인하세요. AASA가 정확한지, 잘 호스팅되었는지 점검해 보세요.
  • Entitlements 파일을 확인하세요.
  • 도메인이 올바른지, Associated Domains 목록에 포함되어 있는지 확인하세요.
  • 제3자 어트리뷰션 서비스 제공업체에 관한 정보를 모두 입력했는지 확인하세요. AppsFlyer 서비스를 이용하고 있다면, OneLink 구성 메뉴에서 UI를 검색할 수 있습니다.
  • 사용 중인 링크의 도메인과 경로 이름이 올바른지 확인하세요.
  • Slack과 같이 지원되지 않는 앱이나 브라우저에서 링크를 클릭하지 않도록 주의하세요. 확신이 들지 않으면, Apple의 메모 앱이나 SMS를 사용하세요!
  • 유니버설 링크를 어떠한 유형의 클릭 트래킹과도 래핑하지 마세요.

테스트 절차:

  • 유니버설 링크 도메인이 QA 앱의 Entitlements > Associated Domains 위치에 있는지 확인하세요.
  • domain/apple-app-site-association로 이동한 후, 파일들이 제대로 있고 경로 이름이 올바른지 확인하세요.
  • 기기에 있는 앱의 모든 버전을 삭제하세요.
  • 기기의 전원을 종료한 후 다시 켜세요. 이를 통해 기기의 entitlement와 AASA 캐시를 리셋합니다.
  • 앱의 테스트 버전을 설치하세요.
  • 메모 앱이나 iMessage를 사용해 링크를 응용프로그램에 붙여넣으세요.
  • 링크를 탭하세요.
    • 유의사항: Slack, Outlook, 기타 응용프로그램은 사용할 수 없습니다. 유니버설 링크는 특정 앱에서만 작동합니다. 메모와 iMessage에서는 유니버설 링크가 작동합니다.
    • 유의사항: 링크를 브라우저나 크롬에 붙여넣지 마세요! 유니버설 링크는 브라우저나 크롬에서 작동하지 않습니다.
  • 앱은 브라우저를 통한 리디렉션 없이바로 실행되어야 합니다.

모바일 앱 마케팅 성과 향상을 위한 현명한 선택