SKAdNetwork의 전환 값은 누가 관리해야 할까요?

By Barak Witkowski

많은 사람들에게 ‘SKAdNetwork’, 혹은 ‘SKAN’이라는 용어는 생소했습니다. 그런데 최근 상황으로, SKAdNetwork가 iOS14 이후 마케팅 생태계에서 중요한 역할을 할 것이라는 인식이 퍼지고 있습니다.

최근 블로그 포스트에서, 저희는 SKAd의 난제를 극복하고 활용도를 극대화하는 솔루션을 소개했습니다. 앱스플라이어 SKAdnetwork 솔루션은 데이터 수집, 데이터 유효성 검증, 데이터 보강, 데이터 활용성 및 데이터 광고주와 광고 네트워크와의 원활한 연동을 지원합니다.

Apple의 어트리뷰션 프레임워크, SKAdNetwork 메커니즘에는 특별한 필드가 있습니다. 바로 ‘전환 값(conversionValue)’입니다. 이 글에서는 이 필드가 왜 중요한지, 어떻게 최대한 활용할 수 있는지, 그리고 최근에 가장 많이 나오는 질문, 누가, 언제 전환 값을 관리·변경하는가 에 대한 해답을 알아보겠습니다.

전환 값이 중요한 이유

전환 값은 0~63 의 정수만 허용되는 필드이며, 광고를 집행하는 앱이 직접 설정하고 관리합니다. Apple은 SKAN 포스트백을 통해 이 전환 값을 어트리뷰션한 애드 네트워크에 전달합니다. 간단하죠? 그런데 전환 값이 왜 중요할까요?

전환 값이 SKAdNetwork에 없으면 어떤 모습일지 그려보겠습니다. 다음과 같은 상황이 벌어질 것입니다.

지난 주, 캠페인 A를 통해 앱 인스톨이 100건 발생했고, 캠페인 B를 통해서는 200건 발생했습니다. 캠페인 B의 성과가 더 좋다는 뜻일까요? 반드시 그렇지는 않습니다. 캠페인 A로 유입된 사용자의 퍼포먼스가 KPI 기준으로 더 나을 수도 있습니다.

이것이 전환 값의 핵심입니다. 앱 소유주는 전환 값으로 엔드 유저의 ‘등급’을 나눌 수 있습니다.

전환 값이 있어야 마케팅의 현황에 대해 더욱 깊이 알고 개선할 수 있습니다. 앞의 사례에서는 전환 값 덕분에 이런 결론을 내릴 수 있습니다. ‘캠페인 B가 캠페인 A보다 신규 유저를 두 배 많이 유입시켰지만, 매출과 앱 사용량은 캠페인 A가 더 많다’

그럼, 전환 값만 있으면 될까요?

꼭 그렇지만은 않습니다.

첫째, 모든 데이터가 한 필드에서 0~63 범위 내에 ‘인코딩’되어야 합니다. 이는 앱 소유주가 측정할 수 있는 데이터에 제한이 있다는 뜻입니다. 앱 소유주는 꼭 측정이 필요한 중요한 데이터를 선정해야 합니다.

둘째, SKAd 타이머 메커니즘에 따라 시간 제한이 있습니다. 대략 정리하면,

인스톨 이후 24시간이 초과되었을 때 발생한 이벤트를 측정하는 방식이 복잡합니다. 이벤트가 발생할 때까지 매일 앱이 열려있어야 하거나, 타이머를 주기적으로 리셋할 백그라운드 스레드(thread)가 필요합니다.
업데이트가 될때마다 타이머가 리셋되며, 이로 인해 (이미 지연된) 포스트백이 더욱 지연됩니다. 이렇게 포스트백이 많이 지연되면, 단기간 최적화는 거의 불가능합니다.

전환 값은 광고를 집행하는 앱이 관리하는데 여기에 어떤 문제가 있나요?

SKAdNetwork의 전환 값은 광고주가 관리하게 됩니다.

그런데 광고주가 스스로 이 필드를 잘 활용할 수 있을까요? 대답은 ‘No.’ 입니다. 앱 소유주도 잘 알고 있습니다. 그래서 마케팅 테크 업계 기업들이 광고주를 도와 줄 솔루션을 이미 개발하고 있습니다.

세부 내용으로 들어가기 전에, 꼭 알아두셔야 할 주의사항이 있습니다. 전환 값을 두 조직이 동시에 관리하면 대혼란이 발생합니다. 아예 아무것도 동작하지 않습니다. 심지어, 아무도 이런 문제를 알아채지 못하고, 잘못된 정보에 근거하여 마케팅 의사결정을 잘못 내리고 최적화 작업을 엉뚱하게 하게됩니다.

앱 소유주는 SKAdNetwork의 전환 값 필드를 반드시 단일 조직이나 단 한 사람이 관리하도록 해야합니다.

귀하가 전환 값을 제어하고자 하는 서비스 제공사라면, 전환 값을 변경하기 전, 반드시 앱 소유주의 권한을 위임받았음을 명시하세요.

전환 값 활용 극대화하기

언급한 바와 같이, 전환 값을 최대한 활용하는 것이 SKAd를 최대한 활용하는 것과 같습니다. 다음 항목을 고려하여 적절하게 의사결정을 하세요.

1) 관리 단일화
가정: 전환 값 매핑은 앱 소유주에 의해 자주 바뀝니다. 전환 데이터가 6비트(전환 값: 0~63)로 한정되어 있기 때문에, 조작될 가능성이 있습니다. 따라서 UA 매니저는 데이터 무결성을 지키기 위해 전환 값 매핑을 자주 변경해야 하는 상황입니다.
고려사항: 매핑 변경은 한 대시보드의 한 곳에서만 이루어져야 합니다. 앱 소유주가 설정을 바꿀 때마다 여러 곳에서 변경 관리를 해서는 안됩니다.

2) 서버단 완전 캡슐화
가정: 전환 값은 클라이언트 측에서만 변경될 수 있습니다. 그렇다면, 매핑이 변경될 때마다 앱 코드를 변경해야 한다는 뜻일까요? 아니오, 그렇지 않습니다.
고려사항: 언제든지 SaaS(Software as a Service) 대시보드에서 매핑을 변경하세요. 앱스토어에 새 버전을 출시할 필요 없이, 실제 매핑이 앱에 즉시 반영되어야 합니다.

3) 간단한 설정
가정: 전환 값 매핑을 이미 존재하는 인앱 이벤트에 의존하고 있다면 어떻게 해야할까요?
고려사항: 전환 값 설정은 인앱 이벤트를 매핑했던 담당자가 수행해야 합니다. 그래야 설정이 쉽고 오류가 적습니다.

4) 설정 유연성
가정: 이 6비트를 최대한 활용하기 위해, 유연하게 설정할 수 있어야 합니다.
고려사항: 광고주가 전환 값을 다양한 조합으로 설정할 수 있어야 합니다. 수익, 전환, 인게이지먼트 혹은 이 세 가지 조합 모두를 다 측정할 수 있게 말이죠. 예를 들어 다음과 같이 설정할 수 있습니다.

2비트: 수익/ 3비트: 인게이지먼트/ 1비트: 더 정확한 인스톨 시간
4비트: 4가지 서로 다른 이벤트 전환/ 2비트: 사용자 아바타 타입

데이터 설정이 유연한 동시에 간단할 수 있을까요? 답은 ‘YES’입니다.

5) 동시·멀티 측정 모드 지원
가정: 앱 소유주가 특정 지점에서 측정하고자 하는 KPI가 두 개 이상 있다고 가정해 보겠습니다.
고려사항: 엔드 유저를 지역에 따라 분류하거나 임의로 나누어 캠페인을 동시에 두 KPI 기준으로 분석하고 최적화합니다. 이렇게 엔드 유저를 나누면 앱 수익과 인게이지먼트, 전환을 동시에 상세히 측정할 수 있습니다. 데이터 필드가 하나 밖에 없는 상황에서 매우 유용한 방법입니다.

중요: 엔드 유저를 임의로 분류할 때, 대시보드에 데이터가 정확히 업데이트되는지 확인하세요.

6) 윈도우 길이(측정 기간) 조절
가정: 어떤 앱 소유주가 인스톨 후 24시간이 초과되었을 때 발생하는 이벤트를 집중 관리해야하는 상황이라고 가정해보겠습니다.
고려사항: 전환 값을 필요에 따라 변경할 수 있도록 윈도우 길이를 (서버 측에서) 쉽게 설정할 수 있어야 합니다. 마찬가지로, 윈도우 길이 변경을 위해 앱 코드를 변경하거나 앱 새 버전을 출시해서는 안됩니다.

7) 서버 간 이벤트와 서버가 트리거한 이벤트

가정: 광고주가 서버/CRM 로직 기준으로 이벤트를 발생시키는 경우를 보겠습니다.
고려사항: 클라이언트 측에 서버가 발생시킨 이벤트에 따라 전환 값을 적절히 변경하도록 공지하는 플로우 (이 조치는 클라이언트 측에서만 가능)가 필요합니다.

8) 앱 최초 인게이지먼트 기반 사용자 가치 예측
가정: 인스톨 후 24시간 초과 시 발생하는 이벤트는 SKAd에서 측정이 제한되어 있습니다. 그래서 사용자의 첫 앱 인게이지먼트에 근거하여 사용자의 가치를 파악하는 것이 매우 중요합니다.
고려사항: 머신러닝 및 AI 알고리즘으로 앱 설치 후 24시간 이내의 데이터에 기반하여 사용자의 향후 LTV와 ROI를 예측합니다.

9) 전송 데이터 조작 가능성 최소화
가정: 광고주는 포스트백을 직접 조회할 수 없습니다. 더군다나, SKAd의 전환 값에는 애플의 서명이 포함되지 않기 때문에 검증이 불가하며 광고주에게 전송되기 전 조작될 가능성이 있습니다.
고려사항: 전환 값 관리자/관리 조직은 앱 광고주가 완전히 신뢰할 수 있어야 합니다. 그들이 공정하고, 광고주의 이익을 대변하며, 광고주 편에서 작업할 수 있는지 확인하세요. 또, 전환 값 관리자가 매핑을 자주 변경시켜 악의적인 조작이 어렵도록 하는지 확인합니다. 매핑이 자주 회전되면, 전환 값 의미를 파악할 수 없고 패턴을 익힐 수도 없습니다.

10) 타 어트리뷰션 모델에 적용하여 데이터 검증
가정: SKAd 데이터를 조작하는 매체가 여전히 있을 수 있습니다.
고려사항: SKAd 데이터를 다른 어트리뷰션 모델에 적용하세요. 예를 들어, SKAd가 특정 캠페인에 대해, 확률적 어트리뷰션 모델 계산법과 수치가 완전히 다르다면, 광고 사기 프로드(fraud)가 발생했을 가능성이 높습니다.

11) 데이터 이용
가정: 앱 소유주가 편리한 대시보드나 API 호출을 통해 마케팅 데이터 분석 자료를 보고 싶어한다면 어떻게 해야할까요?
고려사항: 광고주에게 보내기 전, 전환 값을 해석하는 작업은 쉽지 않습니다. 전환 값 매핑은 시간이 흐름에 따라 변경되며 국가와 사용자에 따라 다를 수 있습니다. 가끔 규모 확장이 필요할 때가 있습니다. 광고주를 대신하여 전환 값 매핑을 하는 주체가 이 모든 사항을 고려하는지 검증하세요.

12) 캠페인 최적화 지원
가정: 광고 네트워크는 각 앱의 성과 측정 기준인 KPI에 따라 퍼포먼스를 최적화하기 위해 전환 값을 해석하는 상황입니다.
고려사항: 전환 값을 관리하는 주체는 모든 광고 네트워크와 연동해야 하며, 광고 에트워크에 보내는 매 포스트백에 전환 값의 실제 의미를 해석하여 보내는 것이 좋습니다.

13) 애플의 변경 사항 지원
가정: SKAd v2 는 곧 v3, v4, v5로 대체될 것입니다. SKAd는 iOS14 이후 중요한 역할을 할 것이며 애플의 개선 작업이 분명 따를 것입니다.
고려사항: 이런 변경 사항에 가장 신속히 대응하여 앱 코드를 변경하거나 앱 신규 버전을 출시하지 않고 로직을 바꿀 수 있는 주체와 협업하세요.

광고주가 이 작업을 모두 스스로 할 수 있을까요?

일부는 가능하고 일부는 절대 스스로 하기 어렵습니다.

자원이 충분하면, 광고주는 서버 기반 개체(entity)를 생성하여 명령어를 클라이언트 측으로 전송하고, 인앱 이벤트를 수집하고, OS 함수를 호출하고 전환 값 매핑을 필요에 따라 변경할 수 있습니다. 또, 애플의 변경 사항을 파악하고 그에 대응할 수 있습니다.

그러나 어트리뷰션한 다양한 모든 네트워크로부터 포스트백을 수집해야 하는 부분도 있습니다. 광고주가 수십 개의 네트워크로부터 일일이 데이터를 모으고 연동 방식이 각기 다른 대량의 데이터를 정리할 수 있을까요?

이론상 광고주가 이 작업을 모두 다 한다고 하더라도, 거의 불가능한 임무가 있습니다. 최적화를 위해, 각 전환 값의 의미를 각 네트워크에 포스트백 하는 것입니다. 광고주는 이 작업을 위한 메커니즘이 없습니다. 그런데 포스트백은 매우 중요합니다! 포스트백 없이 네트워크는 광고주의 이익을 위한 캠페인 최적화를 할 수 없습니다. 광고주는 이런 연동 구조와 메커니즘을 이미 갖추고 있는 누군가가 필요합니다.

그러면, 전환 값은 누가 관리해야 할까요?

가장 가능성 높은 후보는 광고 네트워크, 애널리틱스 툴, 그리고 모바일 측정 파트너(MMP)입니다.

광고 네트워크가 답이 될 수 없는 이유
광고 네트워크는 다른 네트워크와 연동되어 있지 않기 때문에 캠페인 최적화에 리스크가 있습니다. 어트리뷰션은 그들의 전공이 아니라고 할 수 있습니다.

MMP가 최고의 선택인 이유

신뢰성과 비편향성 – 본질적으로 MMP는 이해관계가 충돌되지 않습니다. MMP의 유일한 목표는 신뢰할 수 있고 정확한 데이터를 광고주에 전달하는 것입니다

캠페인 최적화 – MMP는 모든 네트워크와 이미 연동되어 있는 유일한 주체입니다. MMP 없이 캠페인을 최적화기는 어렵습니다.

다양한 어트리뷰션 모델로 어트리뷰션 보강 – SKAd는 완전히 새로운 개념이 아닙니다. SKAd 외에 다양한 어트리뷰션 모델이 존재합니다. 앱 소유주는 서로 보완할 수 있도록 모든 어트리뷰션 모델을 사용하기를 원할 것입니다. 또, SKAd 외에 다른 어트리뷰션 모델이 있는 주체만이 SKAd 데이터가 정확하고 조작되지 않았음을 보장할 수 있습니다. ‘청정’ 데이터 환경이 정확한 마케팅 의사 결정을 위한 핵심 요소입니다.