심층 분석: GAID 없이 Android 개인정보 보호 샌드박스를 활용한 모바일 기여도 분석

구글은 오랫동안 웹을 중심으로 한 개인정보 보호 샌드박스 프로젝트를 진행해 왔습니다. 어제 구글은 이 프로젝트를 안드로이드 플랫폼으로 확장할 계획도 발표했습니다. 웹 샌드박스가 (주로 외부의 압력 때문에) 제3자 쿠키를 제거하는 데 초점을 맞추고 있다면, 안드로이드 개인정보 보호 샌드박스 안드로이드 이상 사용하지 않도록 하는 것입니다 .

그렇게 되면 측정, 타겟팅, 리타겟팅 등 모바일 마케팅 시스템 전반에 큰 영향을 미칠 것입니다.

다행인 점은 현재 구글이 제안한 측정 방식이 상당히 괜찮아 보인다는 것입니다. 사실, 괜찮은 수준을 넘어 훨씬 더 좋습니다. 놀라울 정도로 사려 깊고 유연하며, 앱 생태계에 큰 혼란을 초래하지 않고도 GAID를 없앨 수 있음을 보여줍니다.

구글이 광고 생태계에 깊이 뿌리내리고 기반을 다져왔으며, 이 분야에 대한 본질적인 이해도를 갖고 있고, 기존 질서를 그대로 유지하고자 하는 의지가 강하다는 점을 고려하면 그다지 놀라운 일은 아닐 것입니다. 또한 웹에서 비슷한 시도를 하면서 얻은 수많은 시행착오가 훌륭한 첫 번째 시도를 만들어내는 데 도움이 되었을 가능성도 큽니다.

구글은 이 프로젝트의 예상 완료 기간이 2년 이상이라고 밝혔으며, 현재 보이는 모습은 그 기간 동안 계속해서 변화할 것으로 예상됩니다. 그럼에도 불구하고, 구글이 이러한 아이디어들을 미리 제안하고 피드백을 구하는 모습을 보여준 것은 칭찬할 만합니다! SKAdNetwork 프로젝트에서는 그런 기회를 갖지 못했는데, 정말 아쉬운 부분입니다

안드로이드 개인정보보호 샌드박스 자체에도 타겟팅 및 리타겟팅과 관련된 몇 가지 주제가 있지만, 이 글에서는 주로 어트리뷰션에 초점을 맞출 것입니다. 왜냐하면 Singular 에서는 어트리뷰션을 매우 중요하게 생각하기 때문입니다. 🙂

하지만 먼저 주의사항이 있습니다

이 글은 구글이 공개한 초기의 복잡한 문서를 . 혹시 제가 잘못 이해한 부분이 있다면 알려주세요!

 

요약: 안드로이드 개인정보 보호 샌드박스를 이용한 출처 표기

핵심은 구글이 결국 GAID를 더 이상 사용하지 않겠지만, 광고주들이 효과적으로 사용자 확보를 할 수 있도록 계속 지원하겠다는 것입니다. 세계 최대 광고 네트워크인 구글은 측정의 중요성을 잘 알고 있습니다.

이를 위해 구글은 안드로이드 운영체제에 내장될 온디바이스 서비스를 개발할 예정입니다. 이 서비스를 "어트리뷰션 리포팅 API"라고 부르며, 몇 가지 기능을 수행할 것입니다

• 광고 네트워크에서 보고한 스토어 조회수 및 클릭수(구글은 이를 "소스"라고 부릅니다)
• Apps/Singular 에서 보고하는 설치, 구매, 가입과 같은 스토어 전환 이벤트(Google에서는 이를 "트리거"라고 부릅니다)
• 기기에 저장된 조회수/클릭수와 보고된 전환 이벤트를 일치시킵니다
• 데이터를 네트워크/측정 파트너/광고주에게 두 가지 형태로 전송합니다
  • 이벤트 수준 보고서: 상위 퍼널 분석(캠페인, 하위 캠페인, 크리에이티브, 클릭 ID까지)은 매우 상세하게 제공되지만, 하위 퍼널 데이터(전환 가치 1~3비트)는 매우 제한적으로 제공되는 보고서입니다
  • 집계 가능한 보고서 – 상위 퍼널 분석(지역, 캠페인 등) 데이터와 하위 퍼널 데이터(매출, 구매 건수 등)를 보다 상세하게 포함하는 균형 잡힌 보고서입니다

 

이벤트 수준 보고서가 SKAdNetwork랑 비슷한 것 같은데, 맞나요?

처음 봤을 때는 SKAdNetwork보다 훨씬 좋아 보입니다.

"이벤트 수준 보고서"는 상위 퍼널 데이터(캠페인, 하위 캠페인, 크리에이티브, 클릭 ID까지)를 매우 세분화하여 제공하며, 전환 값은 SKAN의 6비트 전환 값과 달리 3비트 전환 값으로 제한적으로 제공됩니다.

하지만 최대 3개의 전환 이벤트를 서로 다른 시점에 전송할 수 있을 것으로 보입니다. 각 이벤트는 조회 또는 클릭에 기인하는 것으로 간주될 것입니다. 따라서 첫 번째 전환 이벤트는 설치에 사용되고, 이후의 두 전환 이벤트는 사용자 라이프사이클 후반에 발생할 수 있는 의미 있는 KPI에 사용될 가능성이 높습니다. 이는 매우 중요한 기능이며, SKAdNetwork에서 우리가 가장 원했던 기능 중 하나였습니다.

다음은 이벤트 수준 보고서와 SKAN .

 

 

이벤트 수준 보고서를 사용하면 어떤 종류의 보고서를 만들 수 있나요?

이해를 돕기 위해 이벤트 수준 포스트백 세트의 예시를 보여드리겠습니다

 

 

"소스 이벤트 ID"는 네트워크에서 정의하며, 기본적으로 네트워크에서 정의하는 클릭/조회 ID입니다. 즉, 캠페인 이름, 크리에이티브 이름, 국가, 운영 체제, 잠재고객 등 마케터가 중요하게 생각하는 모든 데이터와 1:1로 대응됩니다.

"트리거 유형"은 광고주/MMP가 정의하며 SKAN 전환 값과 매우 유사합니다. SKAN보다 비트 수는 적지만, 최대 3개의 트리거를 서로 다른 시점에 전송할 수 있으므로 코호트 보고에 유리합니다!

광고주/MMP가 "트리거 유형"을 정의하는 방법에 대한 매우 간단한 예시를 보여드리겠습니다

• 001 = 설치
• 010 = 레벨 완료
• 101 = 7일간 매출 > 10달러

이 모든 것을 종합하면 Singular 대시보드의 결과는 다음과 같을 수 있습니다

 

 

따라서 "트리거 유형"(전환 값)은 SKAN보다 제한적이지만, 상위 퍼널 데이터에 대한 놀라운 세부 정보를 얻을 수 있고, 여러 전환 이벤트를 전송할 수 있습니다. 이것만으로도 현재 SKAdNetwork에서 제공하는 것보다 훨씬 강력한 보고서를 생성할 수 있습니다.

그리고 그거 아세요? 아직 끝이 아니에요. 

다음 섹션인 "집계 가능한 보고서"를 확인해 보세요

 

집계 가능한 데이터를 사용하여 어떤 종류의 보고서를 만들 수 있을까요?

이 분야는 특히 흥미롭고 구글이 제안한 구현 방식도 상당히 영리하지만, 현재로서는 불분명한 세부 사항들이 몇 가지 있습니다.

 

 

일반적인 개념은 다음과 같습니다

1. 광고 네트워크가 Android Attribution API에 클릭 및 조회수를 보고할 때, 특정 분석을 나타내는 "집계 키"를 포함합니다. 이러한 키는 최대 128비트까지 가능하며, 이는 매우 유용합니다(128비트는 엄청난 용량입니다). 예를 들어, "MobCool"이라는 광고 네트워크가 캠페인 ID와 크리에이티브 ID에 항상 16비트를 사용한다고 가정해 보겠습니다. 그리고 캠페인 ID가 1 이고 크리에이티브 ID가 2 , 분석을 위해 캠페인 ID와 크리에이티브 ID를 비트로 변환하여 연결합니다. 그러면 다음과 같은 32비트 문자열이 생성됩니다:
   0000 0000 0000 0001 0000 0000 0000 0010
2. 앱이 설치된 후 얼마 지나지 않아 광고주/MMP는 앱에서 발생한 전환 이벤트를 Android Attribution API에 보고합니다. 이러한 이벤트는 집계 키에 자체적인 세부 분석 정보를 추가할 수도 있습니다. 예를 들어, 광고주가 기기 모델별로 마케팅 보고서를 더 세분화하려면 10비트(임의로 10비트를 선택했으며, 원한다면 20비트를 사용할 수도 있음)로 키를 생성할 수 있으며, 그 형식은 다음과 같습니다
3. 광고 네트워크에서 제공하는 비트와 광고주/MMP에서 제공하는 비트가 합쳐집니다.  예를 들어 캠페인 1을 통해 유입되어 크리에이티브 1을 보고 Acer Liquid A1을 사용하는 사용자의 경우, 분석 키는 다음과 같습니다: 0000 0000 0000 0001 0000 0000 0000 0010 0000 0010. 이것은 단 40비트일 뿐입니다. 최대 128비트까지 사용할 수 있으므로, 얼마나 다양한 분석이 가능할지 상상해 보세요! (참고: 분석의 개수에 제한이 있는지는 아직 확실하지 않습니다. 128비트는 매우 큰 숫자입니다.)
4. 전환 이벤트를 보고할 때 광고주/MMP는 전환 이벤트 자체에 대한 수치 값도 함께 보고해야 합니다. 설치 수(예: 1)와 같은 간단한 카운터 값이나 수익(예: 100달러)과 같은 임의의 숫자 값을 사용할 수 있습니다. 이 값은 집계 시 합산되는 값입니다(자세한 내용은 나중에 설명). (참고: 여기에 전달할 수 있는 값에는 제한이 있습니다. 이는 Google에서 사용하는 차등 개인정보 보호 메커니즘의 일부입니다.).
5. 전환 이벤트("트리거")와 조회/클릭("소스")이 성공적으로 일치할 때마다 Android의 기기 내 서비스는 이 정보와 연결된 집계 키를 함께 저장합니다. 그런 다음 이 사용자 수준 데이터를 암호화된 형태로 고객의 광고 기술 플랫폼( MMP , 광고 네트워크 )으로 전송합니다.
6. 이제 고객의 애드테크 플랫폼(MMP, 광고 네트워크 등)에는 이러한 "암호화된 집계 가능한 사용자 수준 데이터" 레코드가 많이 있습니다. 이를 집계하기 위해 Google은 훌륭한 아이디어를 생각해냈습니다. "집계 서비스"라는 별도의 네트워크 서버가 미리 정의된 집계 키를 기반으로 사용자 수준 데이터를 동시에 복호화하고 집계합니다. 위 예시의 최종 결과는 다음과 같을 수 있습니다
7. 물론 이는 지나치게 단순화된 설명입니다. 제대로 구현한다면 훨씬 더 다양한 차원을 고려할 수 있을 것이며, Singular 에서는 이 표를 다양한 데이터 소스와 연결하여 실제 ROI를 도출할 것입니다. 구글은 집계 키를 최대 128비트까지 허용하고 있는데, 이는 의미 있는 세부 분석을 추가할 수 있는 여지가 많다는 것을 의미하며, 결과적으로 매우 유용한 보고서를 생성할 수 있을 것입니다.

또한, 집계 서비스에서는 다음과 같은 사항이 적용됩니다 

이 "집계 서비스"는 Google에서 개발하고 서명한 프로그램이지만, "신뢰할 수 있는 실행 환경"이라고 하는 다른 회사 서버에서 실행됩니다. 즉, Singular "집계 서비스"를 실행하는 경우, 우리는 그 작동 방식을 조작할 수 없으며 Google이 의도한 대로 작동하게 됩니다.

 

기여도 분석의 워터폴 로직은 어떻게 작동할까요?

저희는 현재 상황을 어느 정도 이해하고 있지만, 이 글 서두에서 말씀드렸듯이 개발자 문서가 현재로서는 복잡하고 불분명한 부분이 많습니다. 프로젝트가 진행됨에 따라 이러한 부분은 점차 명확해지겠지만, 모든 것이 100% 확정되었거나 완벽하게 설명된 것은 아닙니다.

우리가 생각하는 상황은 다음과 같습니다

1. 모든 광고 네트워크는 자사 광고의 조회수 및/또는 클릭수(구글에서는 이를 "소스"라고 부릅니다)를 보고할 수 있습니다.
2. 네트워크는 각 접점에 우선순위를 지정할 수도 있습니다(예: 대부분의 네트워크는 클릭이 노출보다 높은 우선순위를 가져야 한다는 데 동의할 것입니다).
3. 설치된 앱에서 전환 이벤트(구글에서 "트리거"라고 부르는 것)가 보고되면 안드로이드는 해당 전환 이벤트를 모든 관련 조회 및 클릭과 일치시키려고 시도하고 우선순위가 가장 높은 이벤트를 선택합니다.
4. 별도로 처리되는 것 같습니다. 이는 두 개 이상의 네트워크에서 클릭이나 조회수가 발생한 경우(실제로는 이런 일이 발생하죠) 두 네트워크 모두에 기여도 분석 보고서(이벤트 수준 및 집계 보고서)가 전송된다는 것을 의미하는 것 같습니다.

위의 4번 항목은 광고 네트워크 전반에 걸친 중복 제거 문제를 제기합니다. 모든 네트워크가 이익을 얻고 (수익을 받는) 상황이 반복되면 마케터의 시각이 상당히 왜곡될 수 있으므로, 이는 바람직하지 않습니다.

해당 문서에서는 특히 조회/클릭 이벤트에 대한 리디렉션을 활성화하여 타사 측정 사용 사례를 다룹니다. 따라서 Singular 와 같은 회사가 고객을 위해 네트워크 전반에 걸쳐 데이터 중복 제거를 구현할 수 있는 방법은 이와 같다고 생각합니다

1. 광고 네트워크는 클릭과 조회수를 보고할 때 응답에 "Attribution-Reporting-Redirects" 헤더를 사용합니다( registerAttributionSource Singular 포함됩니다 .
2. 그러면 API가 Singular의 서버에 연결되고, 고객의 워터폴 및 우선순위 선택(예: 클릭이 조회수보다 중요, 어트리뷰션 기간은 X 등으로 설정)에 따라 정확히 동일한 조회수와 클릭수를 등록하게 됩니다.
3. 광고주 앱에서 당사 SDK를 통해 전환 이벤트가 보고되면 Android API는 당사가 보고한 모든 조회수 및 클릭수와 비교하여 당사가 제공한 우선순위에 따라 관련 접점을 선택합니다. 이를 통해 광고 네트워크 전반에 걸쳐 중복을 제거할 수 있습니다.

저희가 제안한 방식대로 이 흐름을 구현한다면, MTA 보고 기능까지 제공받을 수 있다는 추가적인 이점도 얻게 될 것입니다!

 

해결되지 않은 질문들: 배워야 할 것이 훨씬 더 많다

아직 살펴봐야 할 부분이 많고, 진행 과정에서 구글이나 관련 생태계 측으로부터 명확한 설명을 들어야 할 부분도 많습니다. 제가 궁금한 몇 가지 질문은 다음과 같습니다

1. 사기 탐지, 관리 및 완화는 어떻게 이루어질까요?
   현재로서는 기업들이 구글로부터 응답을 받았다고 주장하는 것을 어떻게 막을 수 있는지 불분명합니다. SKAdNetwork에서처럼 암호화 서명에 대한 언급도 찾아볼 수 없었습니다. 또한, 이 API는 악의적인 사용자가 원할 때마다 무제한 클릭과 노출을 등록하는 것(즉, 클릭 스팸)을 어떻게 방지할까요? registerAttributionSource 함수가 클릭을 등록하기 위해 "InputEvent"를 기대한다는 점은 확인했지만, 이것이 광고 클릭인지 아니면 다른 InputEvent인지 어떻게 확인하는지 알 수 없습니다. 또한, 조회수의 경우에는 이러한 이벤트가 필요하지 않습니다.
2. URL을 사용하는 이유는 무엇일까요?
   매개변수를 직접 받는 대신 registerAttributionSource 및 triggerAttribution 메서드를 호출할 때 항상 URL을 요구하는 이유는 무엇일까요? (URL 해석은 다른 프로세스에서 수행되므로 보안상의 이유일 것으로 추측되지만 확실하지 않습니다.)
3. 업계는 집계 키에 대해 어떻게 조율할까요? 위 섹션에서 집계 키는 광고 네트워크(조회수/클릭에 대한 키의 일부를 정의)와 광고주/MMP(전환 이벤트에 대한 키의 나머지 부분을 정의)의 값이 조합된 것이라고 설명했습니다. API를 통해 광고주/MMP는 모든 세부 내역을 덮어쓸 수 있으므로 광고 네트워크에 필요한 정보를 실수로 덮어쓰지 않도록 주의해야 합니다. 이로 인해 다소 복잡성이 발생하며, Google이 API를 개선하여 여러 회사 간의 조율이 필요하지 않도록 할 수 있을 것입니다. (네트워크용 64비트, 광고주/MMP용 64비트? :))
4. 구글 애즈는 이 기능을 어떻게 활용할까요?
   애플은 다른 광고 네트워크와는 다른 방식으로 애플 검색 광고에 대한 프로세스를 운영하고 있습니다. 구글 애즈도 다른 모든 광고 네트워크처럼 안드로이드용 새로운 개인정보 보호 샌드박스를 따를까요? 초기 징후는 그렇지만, 여전히 몇 가지 의문점이 남아 있습니다.
5. 모바일 앱에서 지연 딥 링크 기능을 어떻게 지원할 수 있을까요?
   지연 딥 링크는 기존에는 서버 측 어트리뷰션 처리, Google의 현재 설치 리퍼러 프레임워크, 그리고 일부 온디바이스 방식을 통해 지원되어 왔습니다.  하지만 이러한 방식들은 모두 프라이버시 샌드박스의 개인정보 보호 목표를 우회하는 데 악용될 가능성이 있습니다. 광고주들이 신규 사용자에게 원활한 사용자 경험을 제공할 수 있도록 API에 지연 딥 링크 기능이 내장되는 솔루션을 기대합니다.

 

요약하자면

아직 초기 단계입니다. 구글이 이 계획을 이제 막 발표했기 때문에 앞으로 많은 개선이 있을 것입니다. 구글이 피드백을 구하고 있다는 점이 고무적이며, 이 계획에 대해 구글과 협력하게 되어 기쁩니다. 초기 문서를 보면 SKAdNetwork보다 훨씬 더 나은 보고 기능을 제공할 수 있는 바람직한 접근 방식을 보여주고 있어 매우 기대됩니다. 어쩌면 애플이 SKAN에 포함할 만한 기능도 몇 가지 있을지도 모릅니다

한 가지 확실한 것은, 저희는 앞으로도 이 문제를 지속적으로 다루고 구글 및 고객과 함께 개선해 나갈 것이라는 점입니다.

이 주제에 대해 더 자세히 논의하고 싶으시다면, 모바일 어트리뷰션 개인정보 보호 .