디지털 프로덕트의 중요성이 날로 커짐에 따라 이를 분석하고 인사이트를 얻을 수 있는 앰플리튜드(Amplitude)가 기업의 필수 툴로 자리매김하고 있습니다. 시장에서 앰플리튜드가 주목을 받는 이유는 프로덕트를 기획하는 PM 뿐만 아니라, 데이터 분석가, 디자이너 그리고 마케터까지 IT 회사의 모든 구성원이 쉽게 접근하여 사용할 수 있다는 것에 있는데요.
오늘은 그중에서도 마케터가 앰플리튜드를 사용할 때 활용할 수 있는 앱 어트리뷰션 툴 연동에 대한 이야기를 다뤄보도록 하겠습니다.
앱 어트리뷰션 툴과 앰플리튜드는 앱 서비스에 SDK를 설치하여 고객의 행동을 트래킹한다는 점에서 모두 트래킹 툴이라는 범주에 속합니다. 그래서 가끔 앰플리튜드로 서비스 내 유저의 행동 뿐만 아니라 서비스로의 유입(어트리뷰션)을 분석할 수 있다고 생각하는 분들이 계십니다. 그러나 이 이야기는 반은 맞고 반은 틀렸다고 할 수 있습니다. 앰플리튜드로 웹 서비스로의 유입은 트래킹할 수 있지만 앱은 불가능하기 때문입니다.
일단, 앰플리튜드가 웹 SDK와 앱 SDK 모두를 지원하고 있기 때문에 웹, 앱 서비스에서 유저들의 행동을 기록할 수 있는 건 사실입니다. 하지만, 유입을 분석할 수 있는 것은 웹사이트의 UTM과 Referrer에 한정되어 있고, 앱 서비스에 대한 유입을 분석할 수는 없습니다. 앱 어트리뷰션 툴이 등장한 이유는 바로 앱 서비스로의 유입을 트래킹하는데는 URL에 단순히 UTM 파라미터를 붙이는 것과는 다른 추가적인 기술이 필요했기 때문입니다.
모바일 어트리뷰션 툴은 이와 같은 앱에 대한 광고 성과를 트래킹할 수 있는 어트리뷰션 기능을 토대로 시장에 등장했습니다. 트래킹 링크 클릭에서부터 앱 설치, 그리고 그 이후의 인앱 이벤트를 연결하여 광고를 통한 유입을 측정합니다. 이 뿐만이 아니라, 매체 최적화를 위해 데이터를 전송할 수 있는 포스트백 연동 기능을 지원하며, 사기 설치를 방지할 수 있는 Fraud Detection & Protection 기능을 지원하죠.
이에 반해, 앰플리튜드는 프로덕트 분석 툴이기 때문에 앱 내에서의 유저의 행동을 분석할 수는 있지만 자체적으로 유입을 측정하는 것은 불가능합니다. 따라서, 앰플리튜드를 통해 앱으로의 유저 유입을 측정하기 위해서는 반드시 앱 어트리뷰션 툴을 통해 유저 유입에 대한 데이터를 받아와야 합니다.
데이터를 연결하는 과정이 그렇게 어려운 것은 아닙니다. 앰플리튜드와 미리 연동되어 있는 앱 어트리뷰션 툴을 사용하고 있다면 바로 연동이 가능합니다. 연동되어 있는 앱 어트리뷰션 툴로는 AB180에서 개발하여 서비스하고 있는 에어브릿지(Airbridge)와 글로벌 업체들이 있습니다.(국내에서는 에어브릿지가 유일합니다.)
구체적으로 연동을 위해서는 준비물이 필요합니다. 당연히 연동을 하고자 하는 앱 어트리뷰션 툴(이하 에어브릿지를 예시로 활용)과 앰플리튜드가 필요하겠죠. 이 두 개 툴의 SDK가 모두 앱에 설치되어 있어야 합니다. 두 SDK가 모두 설치되어 있다면, 앰플리튜드와 에어브릿지 대시보드에 쌓인 데이터를 모두 확인하실 수 있을 겁니다.
여기서 설정이 필요한 것은 에어브릿지의 대시보드입니다. 위에서 잠깐 이야기했지만 앰플리튜드에는 없는 데이터인 어트리뷰션 데이터를 모바일 앱 트래킹 툴인 에어브릿지에서 보내줘야 하기 때문입니다. 앰플리튜드에서는 데이터를 받을 API 키만 있으면 됩니다. 앰플리튜드의 Project 정보에서 API 키를 가져다가 에어브릿지의 대시보드에서 값을 입력하고 버튼을 누르면 연동이 끝납니다.(물론, 밑에서 언급하겠지만 이 연동은 ADID를 키 값으로 활용하기 때문에, 앰플리튜드 SDK에서 데이터 수집 시 ADID를 사용하도록 설정이 미리 되어있어야 합니다.)
이제 데이터를 확인할 차례입니다. 정상적으로 연동이 되었다면, 앰플리튜드 화면에서 데이터를 확인할 수 있습니다. 앰플리튜드의 User Look-Up 기능으로 들어가서 트래킹이 되었을 만한 유저의 이벤트를 클릭해봅시다. 가장 쉽게 찾을 수 있는 방법은 Filter By Events에서 Airbridge: Install 이벤트를 찾아서 필터를 걸어 해당 유저를 클릭하는 것입니다.
위 이미지와 같이 실제로 Event Stream에서 Airbridge: Install이 기록되어 있고, 이 이벤트를 클릭하면 오른쪽에 보이는 User Properties에는 어트리뷰션 캠페인 파라미터들이 기록된 것을 확인할 수 있습니다. 이처럼 User Property에 어트리뷰션 데이터가 기록이 되었기 때문에, 이후 앰플리튜드의 다양한 차트에서 이 property만 갖고 있는 유저 코호트를 생성하거나, property를 기준으로 데이터를 나눠서 분석하는 등 다양한 방법으로 활용할 수 있습니다.
그런데, 정상적으로 연동을 했는데 데이터를 확인해보니 뭔가 이상하다고 느끼실 수 있습니다. 경우에 따라 어트리뷰션 툴에서 본 데이터와 연동을 통해 앰플리튜드로 들어온 데이터가 수치 차이가 나기 때문인데요. 실제로 앰플리튜드와 어트리뷰션 툴의 연동에는 앰플리튜드의 Attribution API를 활용하는데, 이 API의 스펙과 더불어 어트리뷰션 툴로 트래킹하는 매체들의 특성에 따라 어트리뷰션 툴의 데이터가 앰플리튜드로 전송되지 못하는 상황이 존재합니다.
이런 상황을 파헤치기 위해 먼저, 앰플리튜드에서 제공하는 Attribution API(https://developers.amplitude.com/docs/attribution-api)를 보도록 합시다. 이 API를 쉽게 이해하기 위해 아래와 같은 Sample Request를 가져왔습니다.
간단하게 이야기하자면, 이 API는 ADID를 식별자로 하여 Install 이벤트와 User Property를 앰플리튜드에 전송하는 API인데요. 이 API만 본다면 크게 문제가 없을 것으로 보입니다. ADID를 기반으로 이벤트를 새롭게 생성하고 그에 맞춰 user property도 기록하기 때문입니다. 그래서 결국 어트리뷰션 툴에서 보낸 데이터가 모두 앰플리튜드에 기록되고 두 솔루션 간 데이터 차이는 없어야 정상인 것처럼 생각할 수 있습니다.
그러나 자세히 살펴보면 이 API에는 데이터를 로깅할 때 필요한 가장 중요한 한 가지가 빠진 것을 확인할 수 있습니다. 바로 시간인데요. 실제로 이 설치 이벤트가 발생한 타임스탬프를 갖고 있지 않아 이 이벤트가 발생한 시간이 언제인지 확인할 방법이 없습니다. 이렇게 API 스펙이 정해진 이유는, 이 API가 어트리뷰션 데이터만을 받아올 수 있게 설계된 API이기 때문입니다.
이 Attribution API는 모바일 어트리뷰션 툴에서 ADID를 키 값으로 앰플리튜드 request했을 때, 이 ADID가 앰플리튜드에 있는지 확인하고, 해당 ADID가 존재하면 어트리뷰션 정보를 이벤트와 User Property로 기록합니다. 만약 앰플리튜드에 해당 ADID가 없으면 어트리뷰션 툴에서 데이터를 아무리 보내도 앰플리튜드에서 데이터를 쌓지 않습니다.
그래서 앰플리튜드에 해당 디바이스 데이터가 기록되기 전에 어트리뷰션 툴에서 데이터를 보내게 되면 해당 데이터는 유실될 수 있는 것이죠. 이를 막기 위해 앰플리튜드에서는 최대 72시간동안 해당 어트리뷰션 데이터를 가지고 앰플리튜드의 데이터와 매칭될 때까지 기다립니다. 때문에 매칭되기 전까지는 어트리뷰션 툴과 앰플리튜드의 데이터가 다를 수 있고, 또한 이 72시간이 지나게 되면 해당 데이터는 영영 기록되지 않기 때문에 데이터 차이가 발생하게 됩니다.
위에서 말한 API 스펙에 대한 차이를 감안하고서도 데이터 차이가 나는 경우가 존재합니다. Attribution API 스펙때문에 데이터 차이가 발생하는 경우는 아예 해당 데이터가 기록되지 않은 것인데, 애초에 어트리뷰션 데이터가 연동이 되어서 기록이 되었는데도 수치가 다를 수 있습니다. 바로 일부 매체가 통째로 오가닉(organic or unattributed)으로 기록되는 상황입니다. 일반적으로 페이스북의 앱 광고 데이터에서 이런 현상이 발생하기 때문에 많은 사람들이 원인과 해결책에 대해 궁금해합니다.
이와 같은 현상이 발생하는 이유를 이해하기 위해서는, 먼저 최근의 개인정보 보호 트렌드를 알아야 합니다. 최근 개인정보 보호에 대한 사회적 인식이 높아짐에 따라 기업의 책임도 함께 커지고 있는 상황입니다. 특히 데이터를 활용하여 광고를 최적화하는 광고 미디어 채널들의 경우 더더욱 개인정보 보호에 대한 책임에서 자유로울 수 없습니다. 그 중에서도 빅테크 기업인 구글, 페이스북, 트위터 등의 광고 매체들은 스스로 정보보안 정책을 만들어서 이를 지키려고 노력하고 있습니다.
페이스북, 트위터, 구글과 같은 매체들을 모바일 어트리뷰션 툴에서는 SAN(Self Attributing Network)라고도 부르는데요. SAN이라고 부르는 이유는 어트리뷰션 툴의 트래킹 링크를 활용하는 것이 아니라 독립적으로 어트리뷰션을 진행하고 나중에 이 데이터를 어트리뷰션 툴에 전송하는 방식을 사용하기 때문입니다.
SAN은 자신들의 어트리뷰션 데이터를 받는 어트리뷰션 툴에도 자신들의 정보보안 정책을 준수하도록 요구합니다. 자신들의 데이터를 어트리뷰션 툴 내에서는 분석할 수 있게 해도, 이를 로우데이터 형태로 또다른 외부로 반출하여 분석하거나 활용할 수는 없도록 하고 있습니다. 따라서 제 3자인 앰플리튜드로 데이터를 보낼 때에도 SAN으로부터 받은 데이터는 숨긴 채(organic or unattributed)로 보내게 되는 것입니다.
위에서 앰플리튜드와 어트리뷰션 툴을 연동했음에도 데이터 차이가 나는 이유를 크게 두 가지로 다뤘는데, 그 중 SAN의 데이터 정책에 따른 데이터 차이는 해결이 불가능합니다. SAN에서도 자신들이 수집한 개인정보(페이스북을 예시로 들면, 페이스북 앱에서 유저들이 기입한 개인의 정보를 비롯하여 광고를 보고 클릭하고 글을 쓰는 등의 모든 활동 데이터)를 보호해야 할 의무가 있는데, 이 데이터를 SAN의 컨트롤을 벗어나는 외부로 반출하는 것을 허용할 수 없는 것입니다. 따라서, 이들 SAN의 데이터는 어트리뷰션 툴에서만 분석하는 것이 옳다고 할 수 있습니다.
대신 Attribution API 스펙으로 인한 데이터 차이의 경우 살펴볼 여지가 있는데요. Attribution API에 매칭이 되지 않으면 버려지는 상황이 있다면 아예 매칭이 필요 없는 HTTP API V2를 활용하는 방법입니다. 앰플리튜드는 일반적으로 SDK를 활용해 클라이언트(앱 또는 웹 서비스)의 데이터를 로깅하기를 권장하고 있지만, 서버에서 서버로 데이터를 전달하는 방법도 HTTP API V2를 통해 지원하고 있습니다.
위에서 얘기한 것처럼 Attribution API는 애초에 ADID로 매칭을 하여 매칭되는 유저만 어트리뷰션 데이터를 보내는 방식이라면, 아예 이벤트가 발생한 시점까지 포함하여 이벤트와 이벤트 프로퍼티, 유저 프로퍼티를 모두 보낼 수 있는 것이 이 HTTP API V2입니다. 여기서는 광고식별자 뿐만 아니라 다양한 유저 식별자를 key 값으로 활용할 수 있습니다. 그래서 만약 어트리뷰션 툴에서 이 API를 활용하여 데이터를 전송한다면 매칭 이슈와는 상관없이 모든 데이터가 앰플리튜드에 기록되게 됩니다. 매칭 이슈로 인한 데이터 차이를 차단할 수 있는 셈이죠.
그러나 앰플리튜드와 연동을 지원하는 모든 어트리뷰션 툴에서 이 HTTP API V2를 지원하는 것은 아닙니다. 현재는 에어브릿지만이 HTTP API V2를 활용하여 데이터 연동을 지원하고 있습니다.
에어브릿지의 앰플리튜드V2 연동은 위 이미지와 같이 전송할 이벤트를 선택하고 그 이벤트의 프로퍼티까지 설정하여 앰플리튜드에 전송할 수 있습니다. 이 기능을 활용하면 에어브릿지에서 수집한 모든 데이터를 앰플리튜드에 넘겨주기 때문에 Attribution API로 매칭되지 않은 정보도 전송이 가능합니다.
물론, 위에서 이야기한 것처럼 이 HTTP API V2도 SAN의 정책을 무시할 수는 없기 때문에, SAN 데이터 연동 문제는 해결이 불가능합니다. 따라서 마케터들은 SAN 데이터 분석은 최대한 어트리뷰션 툴에서 끝내고, 앰플리튜드에서는 SAN 데이터를 제외한 나머지 모든 데이터를 분석할 수 있다는 점을 인지하고 있어야 하겠습니다.
