SKAdNetwork에 대한 5가지 오해

애플은 올해 모바일 업계에 큰 변화를 발표했고, 거의 사용되고 있지 않던 SKAdNetwork를 되살리려 하고 있습니다. 

재작년에 이미 출시됐지만 그간 주목 받지는 못했던 애플의 어트리뷰션 프레임워크, SKAdNetwork가 갑자기 화제로 떠올랐습니다. 곧 실시될 애플의 새로운 개인정보보호 정책에 대한 기대와 우려가 일고있는 가운데  SKAdNetwork에 대한 광고주의 우려도 큽니다. SKAdNetwork를 매일 수행하는 마케팅 업무에 어떻게 사용할지가 명확하지 않기 때문입니다. 집약형 데이터, 전환 값, 타이머 등 설정도 복잡하고 이것이 애플의 마스터플랜과 어떻게 연결될지도 불확실합니다.

지난 몇 달 간, 저희는 게임에서 이커머스, 금융, 식음료 배달 분야, 중소기업에서 대기업까지 전 세계 수백 곳의 광고주와 SKAdNetwork에 대해 밀도 높은 논의를 이어왔습니다. 폭넓은 논의 결과, 마케팅 업계에 널리 퍼진 SKAdNetwork에 대한 잘못 알려진 사항 몇 가지를 다음과 같이 정리할 수 있었습니다.

1. 타이머에 대한 오해

어떤 오해가 있는지 설명하기 쉬운 타이머, 타이머 연장 그리고 지연에 대해 먼저 알아보겠습니다. SKAdNetwork에는 24시간 타이머가 있습니다. SK 기능이 최초로 호출되면(일반적으로는 앱 최초 실행시 호출) 동작을 시작합니다. 24시간 타이머가 만료되면, 전환 값이 더 이상 변경될 수 없게 동결됩니다. 그런데 다행히, 광고주는 타이머를 연장하고 전환 값 동결 메커니즘을 지연시킴으로써 타이머 제한을 우회할 수 있습니다.

타이머 연장

캠페인 성과 최적화를 위해, 앱 설치 시점으로부터 24시간이 훨씬 지나서까지 유저 활동을 측정해야 하는 경우가 있습니다. 예를 들어, 어떤 게임 앱 광고주는 앱 설치 후 5일째 되는 날까지의 누적 매출에 기반하여 최적화를 하고자 합니다.

타이머를 연장하는 방식은 간단합니다. 앱이 오픈될 때마다 전환 값이 증가하도록 하면, 24시간 이내에 앱이 오픈되기만 하면 타이머가 계속 리셋되어 앱이 오픈될 때마다 24시간씩 타이머가 연장됩니다. 이론적으로는 이 방식을 통해 약 2개월이라는 기간까지 타이머가 연장될 수도 있습니다. (전환값이 0에서 시작해서 1, 2, 3, … 이렇게 24시간마다 1씩 증가한다고 했을 때 최대 63까지 증가할 수 있으므로)

이 방식의 문제는 유저가 과연 24시간 넘게 앱을 켜지 않는 일 없이 사실상 매일 앱을 실행하느냐에 타이머 연장 여부가 달려있다는 것입니다. 하루라도 빠뜨리고 앱을 열지 않으면, 타이머는 리셋되지 않고 전환 값 증가는 거기서 멈춰버립니다. 더군다나 이 방식을 쓰면 전체 유저 가운데 매일 앱을 방문한 소수의 특수한 유저 그룹만 측정하여 이들에게 편향된 최적화를 하게됩니다. 이들이 결코 유저 전체를 대변한다고 할 수는 없는데 말이죠.

타이머를 연장하면 SK 포스트백 1건을 전송 받기까지 시간이 일반적인 1~3일보다 지연되며, 타이머를 연장하기 위해 전환 값을 변경시키느라 전환 값 비트도 소모해야 합니다. 예를 들어, 포스트백을 7일 지연할 경우, SKAdNetwork 전환 값 총 6비트 중 3비트(8(2의 세제곱)가지 값 표현: 0~7일)를 사용하기 때문에, 측정할 수 있는 전환 값은 3비트(총 64(2의 6제곱)가지에서 8(2의 세제곱)가지)로 줄어듭니다.

타이머 지연

타이머 제약 사항에 대한 대한 또 다른 솔루션은 타이머를 늦게 가동하는 것입니다. 타이머가 작동을 시작하는 것 자체를 늦춤으로써 7일 무료 체험 후 구독이나 첫 인앱 구매와 같이 유저가 마케팅 퍼널 깊숙한 단계로 진입했을 때 발생하는 전환 이벤트를 측정하고 최적화할 수 있습니다.

퍼널 깊숙히 있는 해당 이벤트가 발생했을 때에만 타이머가 가동되도록 registerAppForAdNetworkAttribution 및 updateConversionValue 함수 최초 호출을 지연시키는 것입니다.

앞서 말씀드린 방법과 마찬가지로 이 방법도 한계가 있습니다. 타이머 가동을 지연시키면 선택한 이벤트를 측정할 수 있지만, 유저가 해당 이벤트 발생 전 이탈하면, 어떠한 포스트백도 아예 전송되지가 않습니다. 즉, 측정 대상으로 설정한 이벤트를 수행한 유저는 100% 집계할 수 있는 반면, 해당 이벤트를 도달하기 전에 몇 명이 앱을 다운로드하고 몇 명이 이탈했는지는 알 수 없습니다.

2. 6 비트에 대한 오해

사실 SKAdNetwork에서 측정할 수 있는 전환 값은 매우 제한적입니다. 0~63까지의 64개 숫자에 유저 여정에 대한 모든 정보를 담아야 합니다. 제한적이긴 하나, 한 필드에 다양한 KPI를 디코딩할 수 있습니다. 모든 경우에 다 들어맞는 한 가지 솔루션은 없으며 앱마다 KPI마다 전략이 달라야 합니다.

이 제한에 대해서는 솔루션이 두 가지가 있습니다. 비트 분할과 64가지 세그먼트 방식입니다.

비트 분할

비트 분할법은 수익, 인게이지먼트, 전환, 잔존율 등 여러 KPI를 동시에 측정하기 위해 사용합니다. 광고주는 각 KPI에 비트 수를 다르게 분배합니다. 단, 비트를 잘게 분할할수록, KPI 데이터 세분화 수준이 떨어집니다. 예를 들어, 매출에 3비트, 레벨 달성에 3비트를 할당하면 KPI 당 8개 수준으로만 측정할 수 있습니다. 반면, 한 KPI만 측정하면 64개 수준으로 측정할 수 있습니다. 비트를 6가지 KPI로 분할하면, KPI 당 두 가지(이진법 0 아니면 1로 측정) 수준으로 밖에 측정할 수 없습니다.

64가지 세그먼트 방식

64가지 세그먼트 방식은 측정 인앱 이벤트가 6개를 초과할 때 사용할 수 있습니다. 측정 이벤트에 비트를 바로 할당하지 않고 세그먼트에 기반해 엔드유저 등급을 정하는 방식입니다.

유저 세그먼트를 64개로 정의하면 됩니다. 예를 들어 한 유저 세그먼트에 다음과 같은 데이터를 담을 수 있습니다.

• event1이 2~6회 발생
• Event2가 10회 초과 발생
• 총 매출액 2만~6만원

이런 방식으로 각 유저 세그먼트에 대해 측정 KPI를 무한정 정의할 수 있습니다. 이 방식의 한계는 ‘매출’같은 특정 KPI의 구체적인 금액 값을 디코딩할 수 없다는 점에 있습니다. 또, 64개의 세그먼트가 서로 중복되지 않고 앱 유저 전체 범위를 모두 포함시키는지 매우 신중히 검토해야 합니다. 기본적으로 각 유저는 항상 단 하나의 세그먼트에만 속해야 합니다.

3. 설정 변경에 대한 오해

광고주는 SKAdNetwork에 대해 앱스플라이어가 제공하는 것과 같은 서버 기반 솔루션을 이용하여 클라우드에서 전환 값 설정을 변경할 수 있습니다. 클라우드에서 전환 값이 변경되면 즉시 SKAdNetwork 솔루션의 SDK로 명령어가 전송됩니다. 이런 식으로 고객 데이터 로직이 설정에 맞춰 항상 최신 상태로 업데이트 됩니다.

SKAdNetwork에 대한 다른 솔루션들과 마찬가지로 역시 이 방식에도 한계점이 있습니다. 전환 값 설정을 변경하면 수신되는 포스트백이 변경 전의 로직에 따른 데이터인지 변경 후의 로직에 따른 데이터인지 판단할 수 없는 기간이 발생해 데이터 측정에 혼란이 생깁니다. 그래서 전환 값 설정을 너무 자주 변경하지 말 것을 권고드립니다. 예를 들어 일주일에 두 번 이상 변경은 피하는 것이 좋습니다.

다행히, 대안이 있습니다. SKAdNetwork 전환 값 6비트 중 1비트를 사용하여 포스트백이 로직 변경 전 데이터인지 변경 후 데이터인지 표시할 수 있습니다. 그런데 역시 한계점이 있습니다. 전환 값을 설정하는 6 비트 중 1비트를 썼기 때문에 측정 KPI의 상세 수준이 떨어집니다. KPI(전환 값)을 64(2의 6제곱) 가지 측정할 수 있었던 것이 32(2의 5제곱)가지로 줄게 됩니다. 

4. 다양한 KPI를 서로 다른 유저 그룹별 동시 측정하기 어렵다는 오해

각기 다른 유저 세그먼트에 대해 다른 전략을 적용하는 방법이 분명 있습니다. 유저 그룹을 구분하는 파라미터를 (전환 값 변경 시) 클라이언트측과 (전환 값 해독을 위해) 서버측에 모두 알리면 됩니다. 

세그멘테이션에 대해 다음 두 가지 방식을 추천드립니다.

국가 기반 세그멘테이션

국가별로 다른 로직을 적용하고 다른 KPI를 측정합니다. 예를 들어, 프랑스에서는 유저의 매출액을, 미국에서는 유저의 참여도를 측정합니다.

무작위로 A/B 그룹 나누기

엔드유저를 무작위로 A/B 그룹으로 나누어 측정 전환 값 데이터의 상세도를 포기하지 않고 두 그룹에서 동일 KPI를 측정할 수 있습니다. 이 경우, A그룹인지 B그룹인지를 판별하기 위해 1비트를 소모해야 합니다. 즉, 1비트는 나머지 2~6비트가 의미하는 바를 서버측에 알리는 역할을 합니다.

아쉽게도, 유저 그룹을 어떻게 구분하든 간에 이 방식을 다 쓸 수 있는 것은 아닙니다. 예를 들어, 미디어 소스 별 유저 그룹 구분은 불가능합니다. 전환 값이 변경될 때, 미디어 소스 파라미터의 값을 클라이언트 측에서 알 길이 없기 때문입니다. 유입 채널 정보는 서버측만 갖고 있습니다.

유저 그룹을 무작위로 나누는 방식은  포스트백을 애드 네트워크에 전송해야 하기 때문에 데이터 규모를 키워야 합니다.한편, 무작위 그룹 생성은 앱스플라이어의 오디언스 솔루션으로 자동화가 가능합니다. 귀사의 MMP(모바일 측정 파트너)가 이 기능을 지원하는지 확인하세요.  

5. 서버 이벤트에 대한 오해

클라우드 기반 솔루션은 전환 값을 설정 변경에 맞춰 업데이트하여 클라이언트 측에 전달할 수 있습니다. 그러나 클라우드 기반 솔루션은 클라이언트 기반 이벤트에는 없는 한계점이 있습니다. 서버 기반 이벤트가 SKAdnetwork 타이머 만료 전 발생할지라도, 타이머가 만료되기 전 엔드 유저가 앱을 한 번 더 열지 않는 한 해당 이벤트가 전환 값으로 기록될 기회는 찾아오지 않습니다.

그래서 가능하면 클라이언트에서 발생시킨 이벤트를 측정하는 것을 원칙으로 하는 것이 좋습니다.

이러한 한계에도 불구하고 귀사의 서버/CRM 로직에 기반해 측정하고 최적화하려면, SKAdNetwork 프레임워크가 이 옵션을 지원하는지 확인하세요. 앱스플라이어는 업계 최초로 서버 기반 이벤트를 지원하는 SKAdNetwork 솔루션입니다. 

위기를 기회로 

의심할 여지 없이, SKAdNetwork는 마케터에게 새로운 과제입니다. ‘무엇이든 측정 가능’하고 ‘무슨 기준으로든 캠페인을 최적화할 수 있는’ 시대는 지났습니다. 그러나 그렇다고 마케팅 최적화의 종말이 온 것은 아닙니다. 여전히 데이터를 측정하고, 마케팅을 최적화하여 비즈니스를 더욱 탁월하게 발전시킬 기회가 무궁무진합니다.

전환 값의 구조와 의미를 충분히 이해하고, 추측을 검증하고, 계획하고, 테스트하면, 100% 완벽하지 않더라도 솔루션들을 최대한 잘 활용할 수 있을 것입니다. 자사의 데이터 측정 니즈에 부합하는 최적의 프레임워크를 잘 활용하면 변화하는 환경에 미리 대비하고, 남들보다 한 발 앞서 나갈 수 있습니다. SKAdNetwork에 대한 5가지 오해를 바로잡는 것으로 여러분들은 이미 출발을 멋지게 하셨습니다!