Android의 개인 정보 보호 샌드박스 개발자 프리뷰가 출시되었습니다. 시작하는 방법을 알아보고 의견을 제공해 주세요.

기여도 보고: 앱과 웹 간의 교차 측정

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

의견 보내기

Attribution Reporting API 설계 제안에 설명된 대로 API를 사용하여 단일 Android 기기에 관한 다음 트리거 경로의 기여 분석이 가능합니다.

  • 앱에서 앱으로: 사용자가 앱에서 광고를 본 후 해당 앱에서 또는 설치된 다른 앱에서 전환합니다.
  • 앱에서 웹으로: 사용자가 앱에서 광고를 본 후 모바일 또는 앱 브라우저에서 전환합니다.
  • 웹에서 앱으로: 사용자가 모바일 또는 앱 브라우저에서 광고를 본 후 앱에서 전환합니다.
  • 웹에서 웹으로: 사용자가 모바일 또는 앱 브라우저에서 광고를 본 후 동일한 브라우저나 같은 기기의 다른 브라우저에서 전환합니다.

여기서 웹은 앱에 표시되는 웹 콘텐츠로 정의됩니다. 웹 콘텐츠는 모바일 브라우저 앱의 컨텍스트로 표시되거나 브라우저가 아닌 앱에 표시되는 삽입된 웹사이트 형태로 표시될 수 있습니다.

위 트리거 경로는 다음 요구사항으로 변환됩니다.

  • 광고 기술 플랫폼의 경우: 앱에서 웹으로의 경로를 사용 설정하기 위해 API 호출과 보고 업데이트
  • 앱 및 브라우저의 경우: 웹 기여 분석 소스 및 웹 트리거의 등록을 Android에 전달할 수 있어야 함

이 문서에서는 앱에서 웹으로의 트리거 경로, 웹에서 앱으로의 트리거 경로 및 웹에서 웹으로의 트리거 경로를 지원하도록 Attribution Reporting API가 확장되는 방식을 설명합니다. 또한 광고 기술 플랫폼 및 앱이 이러한 트리거 경로를 지원하는 데 필요한 요구사항을 충족하기 위해 변경해야 할 사항에 관해 설명합니다.

광고 기술 플랫폼 변경사항

광고 기술 등록

Attribution Reporting API를 사용하려면 광고 기술 플랫폼을 등록해야 합니다. 등록 절차에 관한 세부정보는 아직 개발 중이며 의견을 보내주시면 감사하겠습니다.

등록 프로세스가 완료되면 등록되지 않은 등록 호출이 수신될 경우 API는 그 등록을 삭제합니다.

등록할 때, 광고 기술 플랫폼은 기여 분석 소스와 트리거를 등록할 때 앱 및 웹에서 사용할 수 있는 모든 서버 URL과 함께 등록되어야 합니다. 여러 개의 서버 등록 URL이 지원되지만 보고 출처는 하나만 지원됩니다. 보고 출처는 서버 등록 URL 중 하나의 도메인에서 파생됩니다.

등록 및 기여 분석 변경사항

기여 분석 소스를 등록할 때 광고 기술 플랫폼은 현재 대상 필드를 지정합니다. 이 대상 필드는 트리거 이벤트가 발생하는 앱 패키지 이름입니다. 앱에서 웹으로의 측정을 사용 설정하기 위해 Google은 앱 대상 필드(앱 패키지 이름) 1개와 웹 대상 필드(eTLD+1) 1개를 지원할 계획입니다.

웹 기여 분석 소스 또는 트리거를 등록할 때 API는 리디렉션을 지원하지 않습니다. 웹 콘텐츠를 호스팅하는 각 앱에 자체 권한 모델이 있을 수 있기 때문입니다. 각 앱은 리디렉션(지원되는 경우)을 따라 각 리디렉션 홉의 웹 컨텍스트 API를 호출하는 일을 담당합니다.

또한 이러한 통합을 통해 광고 기술 플랫폼은 웹 기여 분석 소스에 앱별 기여 분석 로직을 사용할 수 있습니다. 예를 들어 이제 웹 기여 분석 소스에 설치 후 기여 산정 기간을 지정할 수 있습니다.

앱 및 웹 보고서 수신

Android Attribution Reporting API는 앱 전환과 웹 전환을 모두 포함하는 보고서를 전송할 수 있습니다. 광고 기술 플랫폼이 웹 표시 경로과 앱 표시 경로에서 트리거 데이터와 집계 키/값을 정렬하지 않으려는 경우에는 웹 전환과 앱 전환을 구분할 수 있습니다.

  • 이벤트 수준 보고서의 경우 트리거가 웹(대상: eTLD+1)에서 발생했는지 아니면 앱(대상: 앱 패키지 이름)에서 발생했는지 지정하는 대상 필드가 지원됩니다.
  • 집계 가능 보고서의 경우 대상은 일반 텍스트로 전송됩니다.

웹에서 웹으로의 측정 영향

앱은 Attribution Reporting API에 등록을 전달할 시기를 선택하게 됩니다. 여기에는 몇 가지 고려사항이 있습니다.

  • 기기에서 Attribution Reporting API를 사용할 수 있나요? Attribution Reporting API를 기기에서 사용할 수 있는지를 반환하는 새로운 신호가 앱에 노출됩니다. 앱이 Attribution Reporting API에 등록을 전달할 수 있는 자세한 방법은 앱 변경사항 섹션을 참고하세요.
  • API에 기여 분석 소스와 트리거의 어떤 부분이 전달되어야 하나요? 이는 각 앱에 의해 결정됩니다. 또는 앱에서 선택을 허용하는 경우 광고 기술 플랫폼에 의해 결정됩니다. 앱에 자체 측정 솔루션이 있는 경우 그것을 대신 사용하는 것이 좋습니다. 궁극적으로 모든 소스 및 트리거 등록을 Android Attribution Reporting API에 전달(가능한 경우)하면 앱과 웹에 가장 정확한 기여 분석이 사용됩니다.

다음 예는 사용자가 브라우저 앱과 브라우저가 아닌 앱에서 광고를 클릭할 때 정확한 측정을 제공하기 위해 브라우저 앱이 Attribution Reporting API와 어떻게 작동할 수 있는지 보여줍니다.

3일간 발생한 사용자 클릭과 전환의 예
그림 1. 브라우저와 앱에서의 소스 및 트리거 등록 예
  • 1일 차에 사용자가 브라우저 앱에서 광고를 클릭합니다.
    • 브라우저 앱이 자체 측정 솔루션을 사용하거나 Attribution Reporting API에 웹 광고 클릭 등록을 전달할 수 있습니다.
  • 2일 차에 사용자가 브라우저가 아닌 앱에서 광고를 클릭합니다.
    • 그 클릭이 API를 통해 기여 분석 소스로 등록됩니다. 이벤트가 다른 앱 내에서 발생했으므로 브라우저 앱에서는 이 클릭을 볼 수 없습니다.
  • 3일 차에 사용자가 브라우저 앱에서 전환합니다.
    • 브라우저 앱이 자체 측정 솔루션을 사용하여 클릭과 전환을 모두 등록하고 이 정보를 Attribution Reporting API에 전달하면 광고 기술 플랫폼은 측정 솔루션 간에 전환 보고서를 중복 삭제할 수 없습니다. 또한 광고 기술 플랫폼은 브라우저 앱 비율 제한과 Attribution Reporting API 비율 제한을 모두 사용할 수 있습니다. 따라서 API이 사용 가능할 경우 API에 등록할 모든 광고 이벤트와 전환을 앱에서 전달하는 것이 좋습니다.

앱 변경사항

Google은 새로운 웹 컨텍스트 API 호출 집합을 사용하여 웹 기여 분석 소스와 웹 트리거의 등록을 Android의 Attribution Reporting API에 전달하도록 앱에 허용함으로써 앱 표시 경로와 웹 표시 경로에서 기여 분석을 지원할 예정입니다.

다음 섹션의 등록 단계를 완료하면 앱과 웹의 기여 분석 소스 및 트리거가 기기에 저장되고, Attribution Reporting API는 앱 표시 경로와 웹 표시 경로에서 소스 우선순위의 마지막 터치 기여 분석을 수행할 수 있습니다.

기여 분석 소스 등록

기여 분석 소스를 등록할 때 앱은 registerWebSource()를 호출할 수 있으며, 이에는 다음 매개변수가 필요합니다.

  • 기여 분석 소스 URI: 플랫폼은 기여 분석 소스와 연결된 메타데이터를 가져오기 위해 이 목록의 각 URI에 요청을 보냅니다.

    각 URI에는 광고 기술 플랫폼에서 제공한 디버그 키를 보고서에 포함해야 하는지를 나타내는 부울 디버그 플래그가 있어야 합니다.

  • 입력 이벤트: InputEvent 객체(클릭 이벤트용) 또는 null(조회 이벤트용)입니다.

  • 소스 출처: 소스가 발생한 출처(게시자 웹사이트)입니다.

  • OS 대상: 트리거 이벤트가 발생한 앱 패키지 이름입니다.

  • 웹 대상: 트리거 이벤트가 발생한 eTLD+1입니다.

  • 확인된 대상: 사용자 클릭 시 탐색에 사용된 OS 또는 웹 대상 URI/인텐트입니다.

API가 Attribution Source URI에 요청하면 광고 기술 플랫폼은 HTTP 헤더 Attribution-Reporting-Register-Source의 기여 분석 소스 메타데이터로 응답해야 합니다. 이 헤더는 앱에서 앱으로의 기여 분석 소스 등록과 동일한 필드를 사용합니다. 단, 몇 가지 변경사항이 있습니다.

  • API는 앱에서 지정한 대상과 함께 광고 기술 플랫폼에서 지정한 대상을 확인합니다. 대상이 서로 다른 경우 API는 기여 분석 소스 등록을 삭제합니다.

    앱은 웹 컨텍스트 API를 호출하기 전에 웹 대상을 확인해야 합니다. 클릭의 경우 앱은 지정된 대상이 사용자가 탐색하는 대상과 일치하는지 확인해야 합니다.

  • API는 Attribution-Reporting-Redirects에 제공된 모든 리디렉션 URI를 무시합니다. 앱은 필요에 따라 자체 권한 정책을 적용할 수 있도록 자체적으로 리디렉션을 따르고 각 리디렉션에서 registerWebSource()를 호출해야 합니다.

트리거(전환) 등록

트리거 등록 시 앱은 registerWebTrigger()를 호출할 수 있으며 이에는 다음 매개변수가 필요합니다.

  • 트리거 URI: 플랫폼은 트리거와 연결된 메타데이터를 가져오기 위해 이 목록의 각 URI에 요청을 보냅니다.
  • 대상 출처: 트리거가 발생한 출처(광고주 웹사이트)

개인 정보 보호 및 보안 고려사항

보고서에 적용되는 개인 정보 보호 메커니즘에 미치는 영향

기본 설계 제안에 설명된 대로 API는 보고서에 개인 정보 보호 비율 제한을 적용합니다. 일부 제한은 소스 앱과 대상 앱에서 파티션이 나뉩니다. 웹 기여 분석 소스 또는 트리거가 등록되면 비율 제한은 앱이 아닌 소스 사이트 또는 대상 사이트에 의해 파티션이 나뉩니다.

앱이 별도의 비율 제한을 유지하는 경우 공격자는 API의 비율 제한 외에 앱별 비율 제한도 사용할 수 있습니다. 이 문제를 완화하려면 특정 기여 분석 소스가 앱의 측정 솔루션과 Android Attribution Reporting API에 모두 등록되지는 않았는지 앱에서 확인해야 합니다.

웹 컨텍스트에 관한 신뢰 구축

웹 컨텍스트 API 호출에서 API는 소스 출처와 대상 출처를 탐지하고 지정하는 앱을 신뢰합니다. 이를 통해 잠재적인 개인 정보 보호 및 보안 고려사항이 발생할 수 있습니다.

  • 공격자는 소스가 전달할 수 있는 정보량에 관한 비율 제한의 우회를 시도하기 위해 API 소유의 호스팅 웹사이트 소유권을 주장할 수 있습니다.
  • 여러 공격자가 결탁하여 별도의 기여 분석 소스를 등록하고 동일한 소스 사이트의 소유권을 주장할 수 있습니다. 그 결과 소스 사이트가 광고 기술 플랫폼 비율 제한에 도달하여 실제 소스 사이트가 정당한 기여 분석 소스를 등록하지 못할 수 있습니다.

Google은 이 같은 상황을 완화할 방법을 고민하고 있습니다. 한 가지 옵션은 등록에 사용된 소스 사이트가 사용자에게 표시된 실제 사이트라는 것을 증명하는 브라우저나 앱에 대한 registerWebSource()를 호출할 수 있는 브라우저나 앱을 제한하는 것입니다. 또한 내부에서는 웹 콘텐츠를 검증하기 위한 기술 솔루션도 살펴보고 있습니다. 사용 사례는 물론, registerWebSource()를 호출해야 하는 앱 유형에 관한 의견을 보내주시기 바랍니다.

트리거 측의 개인 정보 보호 및 보안 고려사항은 소스 측 결탁이 없으면 적용될 수 없으므로 모든 앱에서 registerWebTrigger()를 호출할 수 있습니다.

사용자 제어

앱은 등록 시 정의할 수 있는 한 사용자 제어 또는 권한 정책을 계속 지원할 수 있습니다. 예를 들어 사이트 수준 권한 또는 사용자 수준 권한을 허용하는 앱은 그러한 권한을 평가하여 웹 컨텍스트 API를 호출할지를 결정해야 합니다.

또한 Google은 기기에 있는 앱과 관련해 저장된 기여 분석 소스, 트리거, 대기 중인 보고서를 삭제할 수 있도록 앱의 새 API 호출을 지원할 예정입니다. 예를 들어 사용자가 방문 기록을 지울 수 있도록 허용되는 경우 앱은 API를 호출하여 사용자 기기에 있는 앱과 관련해 저장된 기여 분석 소스, 트리거 및 대기 중인 보고서를 삭제할 수 있습니다.

향후 고려사항 및 미해결 질문

Attribution Reporting API와 관련해 앱에서 웹으로의 상호 운용성은 현재 진행 중인 작업입니다. Google은 다음과 같은 몇 가지 아이디어에 관한 커뮤니티의 의견을 듣고자 합니다.

  1. Android의 개인 정보 보호 샌드박스 지원 기기에서 Android Attribution Reporting API와 함께 브라우저 측정 솔루션을 어떻게 사용할 계획인가요? Android에 모든 항목을 전달하기를 선호하나요?
  2. 앱 트래픽과 웹 트래픽에 제안된 비율 제한이 적절한가요?
  3. 각 기여 분석 소스와 트리거에 대해 잠재적으로 2개의 핑(하나는 브라우저/앱에서 수신되는 핑, 나머지 하나는 Attribution Reporting API에서 수신되는 핑)을 수신하는 점에 관해 우려 사항이 있나요?
  4. 브라우저/앱 API 등록과 비교해 Android API 등록을 위한 다른 서버 엔드포인트를 제공하고자 하나요?
  5. 서로 다른 API에서의 디버깅을 좀 더 수월하게 하려면 어떻게 하면 좋을까요?
  6. 현재 제안에는 앱 대상과 웹 대상이 연결되었음을 확인하는 방법이 포함되어 있지 않습니다. 향후 디지털 애셋 링크를 사용하여 연결을 확인하는 방법으로 대상의 유효성을 검사할 수 있습니다. 그러면 사용 사례가 차단되나요? 그러한 확인을 위해 디지털 애셋 링크를 사용하는 것이 적절한가요?
  7. 브라우저/앱과 관련해 웹 노출 등록 또는 Android 개인 정보 보호 샌드박스의 Attribution Reporting API와의 통합에 관심이 있다면 문의해 주세요.