이 페이지는 Cloud Translation API를 통해 번역되었습니다.

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

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

기여 분석 소스 등록 및 WebView에서 트리거

앱이 WebView를 사용하여 네이티브 Android 광고 대신 웹 콘텐츠를 표시하는 경우, 앱은 registerWebSource()의 허용 목록 가입을 신청하고 앱 패키지 이름이 아닌 기여 분석 소스와 연결될 웹사이트의 최상위 출처를 제공할 수 있습니다.

브라우저와 마찬가지로 WebView는 트리거를 최상위 출처와 연결하는 트리거 등록을 위한 registerWebTrigger()를 지원합니다. WebView에서 앱 트리거를 등록할 수는 없습니다. 이와 같은 사용 사례가 있는 경우 문의하세요. WebView에서 지원하는 조합의 전체 목록은 기여 분석 소스 및 WebView의 트리거 등록을 참고하세요.

브라우저와 달리 WebView는 Android의 Attribution Reporting API를 사용할 수 있는 경우 Attribution-Reporting-Eligible 헤더 내 OS에 등록하는 것만 지원합니다. Android의 Attribution Reporting API를 사용할 수 없는 경우 WebView는 Attribution-Reporting-Eligible 헤더를 설정하지 않고 등록이 이루어지지 않습니다.

OS를 사용하여 기여 분석 소스 / 트리거를 등록하려면 다음 단계를 따르세요.

광고 기술은 WebView에서 registerSource() 또는 registerWebSource()에 대한 보조 API 호출을 시작하는 Attribution-Reporting-Register-OS-Source 헤더를 사용하여 소스 등록에 응답해야 합니다.
광고 기술은 WebView에서 registerWebTrigger() 또는 registerTrigger()에 대한 보조 API 호출을 시작하는 Attribution-Reporting-Register-OS-Trigger 헤더를 사용하여 트리거 등록에 응답할 수도 있습니다.

웹이 지원되지 않는 경우에도 응답에 이전 헤더가 포함되어 있지 않거나 Attribution-Reporting-Register-Source/Attribution-Reporting-Register-Trigger 헤더도 포함되어 있으면 전체 등록이 실패합니다.

WebView에서 registerSource()/registerWebSource() 및 registerTrigger() / registerWebTrigger()를 사용할지와 이 동작을 변경하는 방법에 관한 자세한 내용은 기여 분석 소스 및 WebView의 트리거 등록을 참고하세요.

전환 디버깅 보고서

Attribution Reporting API는 전환 디버깅 보고서라는 선택적 기능을 지원합니다. 이 기능을 사용하면 광고 ID를 사용할 수 있을 때 광고 기술이 기여도 보고서에 관해 자세히 알아볼 수 있습니다. 디버깅 보고서에는 기여 분석 성공 보고서와 상세 보고서, 두 가지 유형이 있습니다. 이러한 보고서는 교차 앱 및 웹 기여 분석에 대해 지원되며 두 보고서 유형에는 모두 동일한 정보가 포함됩니다. 디버깅 보고서가 전송될 때 권한을 제어하는 것만 다릅니다.

단일 앱(예: 동일한 브라우저 앱) 내에서 발생하는 웹에서 웹으로의 기여 분석의 경우, 기여 분석 성공 보고서 및 상세 보고서는 서드 파티 쿠키를 사용할 수 있을 때만 사용할 수 있으며 광고 ID 가용성을 토대로 하지 않습니다.

앱에서 웹, 웹에서 앱, 웹에서 웹으로의 교차 앱 기여 분석의 경우, 광고 ID를 앱 측에서 사용할 수 있고 광고 기술이 동일한 (올바른) 광고 ID를 웹 측에 전달할 수 있다면 기여 분석 성공 보고서와 상세 보고서를 사용할 수 있습니다. 소스는 게시자 앱에서 발생하지만 트리거는 브라우저 앱 내 광고주 사이트에서 발생하는 앱에서 웹으로의 아래 예를 참고하세요.

앱에서 웹으로의 기여 분석 성공 디버깅 보고서를 사용 설정하려면 아래의 세 가지 조건을 모두 충족해야 합니다.

사용자가 광고 ID를 사용한 맞춤설정을 선택 해제한 적이 없어야 합니다.
게시자 앱에서 광고 ID 권한을 선언했어야 합니다.
광고 기술은 웹 컨텍스트의 트리거 등록에서 광고 ID 값을 전달해야 합니다.

앱에서 웹으로 상세 디버깅 보고서를 사용 설정하는 방법은 다음과 같습니다.

소스 상세 보고서는 게시자 측 권한만 의존합니다. 소스 상세 보고서가 전송되려면 사용자가 광고 ID 맞춤설정을 선택 해제한 적이 없어야 하고 게시자 앱이 광고 ID 권한을 선언했어야 합니다.
트리거 상세 보고서는 트리거 측 권한에만 의존합니다(이 예에서는 웹). 트리거 상세 보고서를 전송하려면 서드 파티 쿠키를 브라우저에서 사용할 수 있어야 합니다.
source_debug_key를 선택적으로 포함할 수 있는 트리거 상세 보고서의 경우 게시자 앱에서 광고 ID를 사용할 수 있으면 source_debug_key가 포함됩니다.

모든 경우에서 광고 기술은 소스와 트리거 등록 헤더에서 debug_reporting 사전 필드를 통해 상세 디버깅 보고서를 수신하도록 선택해야 합니다.

앱 변경사항

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

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

브라우저가 Android의 Attribution Reporting API와 통합하여 교차 앱 및 웹 측정을 사용 설정하는 방법의 예는 웹 제안서의 개인 정보 보호 샌드박스를 참고하세요. 제안서에서 브라우저는 다음 요청 헤더를 추가합니다.

Attribution-Reporting-Eligible은 OS 수준의 기여 분석 지원 기능을 사용할 수 있는지 여부를 브로드캐스트합니다. 이 경우 헤더는 Android의 Attribution Reporting API를 사용할 수 있는지를 나타냅니다.
가능한 경우 광고 기술은 브라우저 앱에서 registerWebSource()에 대한 보조 API 호출을 시작하는 Attribution-Reporting-Register-OS-Source를 사용하여 선택적으로 응답할 수 있습니다.
광고 기술은 브라우저 앱에서 registerWebTrigger()에 대한 보조 API 호출을 시작하는 Attribution-Reporting-Register-OS-Trigger 헤더를 사용하여 트리거 등록에 응답할 수도 있습니다.

기여 분석 소스 등록

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

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

각 URI에는 기술에서 제공하는 디버그 키를 보고서에 포함해야 하는지 나타내는 불리언 디버그 플래그가 있어야 합니다.
입력 이벤트: InputEvent 객체(클릭 이벤트용) 또는 null(조회 이벤트용)입니다.
소스 출처: 소스가 발생한 출처(게시자 웹사이트)입니다.
OS 대상: 트리거 이벤트가 발생한 앱 패키지 이름입니다.
웹 대상: 트리거 이벤트가 발생한 eTLD+1입니다.
확인된 대상: 사용자 클릭 시 탐색에 사용된 OS 또는 웹 대상 URI 인텐트입니다.

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

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

앱은 웹 컨텍스트 API를 호출하기 전에 웹 대상을 확인해야 합니다. 클릭의 경우 앱은 지정된 대상이 사용자가 탐색하는 대상과 일치하는지 확인해야 합니다.
API는 Attribution-Reporting-Redirects에 제공된 모든 리디렉션 URI를 무시합니다. 앱은 필요에 따라 자체 권한 정책을 적용할 수 있도록 자체적으로 리디렉션을 따르고 각 리디렉션에서 registerWebSource()를 호출해야 합니다.

registerWebSource()를 호출하려면 앱이 허용 목록에 가입해야 합니다. 허용 목록에 가입하려면 이 양식을 작성하세요. 허용 목록의 목적은 웹 컨텍스트의 신뢰 설정과 관련된 개인 정보 보호 고려사항을 완화하는 것입니다.

트리거(전환) 등록

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

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

WebView에서 기여 분석 소스 및 트리거 등록

기본적으로 WebView는 registerSource() 및 registerWebTrigger()를 사용합니다. 이를 통해 소스를 앱과 연결하고 트리거가 발생할 때 WebView의 최상위 출처와 트리거를 연결합니다.

앱에 다른 동작이 필요한 경우(예: WebView에서 웹 콘텐츠를 호스팅하는 동작) androidx.webkit.WebViewSettingsCompat 클래스의 setAttributionRegistrationBehavior 메서드를 사용해야 합니다. 이 메서드는 WebView가 registerWebSource() 또는 registerSource() 및 registerWebTrigger() 또는 registerTrigger()를 호출해야 하는지 지정합니다.

setAttributionRegistrationBehavior에 사용할 수 있는 옵션은 다음과 같습니다.

값	설명	사용 사례
APP_SOURCE_AND_WEB_TRIGGER(기본값)	앱이 WebView에서 앱 소스(앱 패키지 이름과 연결된 소스) 및 웹 트리거(eTLD+1과 연결된 트리거)를 등록할 수 있도록 허용합니다.	WebView를 사용하여 웹 탐색을 사용 설정하기보다 광고를 게재하는 앱
WEB_SOURCE_AND_WEB_TRIGGER	앱이 WebView에서 웹 소스 및 웹 트리거를 등록하도록 허용합니다. 참고: 이 옵션을 사용하는 앱은 `registerWebSource()`을(를) 사용하려면 허용 목록에 가입하기 위해 신청해야 합니다.	광고 노출 및 전환이 WebView의 웹사이트에서 모두 발생할 수 있는 WebView 기반 브라우저 앱
APP_SOURCE_AND_APP_TRIGGER	앱이 WebView에서 앱 소스 및 앱 트리거를 등록하도록 허용합니다.	광고 노출 및 전환이 항상 WebView의 eTLD+1이 아니라 앱과 연결되어야 하는 WebView 기반 앱
DISABLED	WebView에서 소스 및 트리거 등록을 사용 중지합니다. 기여 분석 소스 또는 트리거 URI에 대한 최초 네트워크 호출은 계속 발생할 수 있지만 모든 응답은 삭제되며 기기에 아무것도 저장되지 않습니다.

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

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

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

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

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

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

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

이 문제를 완화하기 위해 등록에 사용된 소스 사이트가 사용자에게 표시되는 실제 사이트를 나타내는 브라우저 또는 앱에 대해 registerWebSource()를 호출할 수 있는 브라우저나 앱을 제한합니다. 이 양식을 작성하여 허용 목록에 가입하고 registerWebSource()를 호출하세요.

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

사용자 제어

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

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

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

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

Android의 개인 정보 보호 샌드박스 지원 기기에서 Android Attribution Reporting API와 함께 브라우저 측정 솔루션을 어떻게 사용할 계획인가요? Android에 모든 항목을 전달하는 것을 선호하나요?
각 기여 분석 소스와 트리거에 대해 잠재적으로 2개의 핑(하나는 브라우저/앱에서 수신되는 핑, 나머지 하나는 Attribution Reporting API에서 수신되는 핑)을 수신하는 점에 관해 우려사항이 있나요?
서로 다른 API에서의 디버깅을 좀 더 수월하게 하려면 어떻게 하는 것이 좋을까요?
제안서에는 앱 대상과 웹 대상이 연결되었음을 확인하는 방법이 포함되어 있지 않습니다. 향후 디지털 애셋 링크를 사용하여 연결을 확인하는 방법으로 대상의 유효성을 검사할 수 있습니다. 그러면 차단되는 사용 사례가 있나요? 이러한 확인을 위해 디지털 애셋 링크를 사용하는 것이 적절한가요?
기여 분석 소스를 등록할 때 대상을 지정해야 합니다. 웹에서 앱으로 이어지는 경우에는 앱 링크를 지정하는 것이 좋습니다. 이 앱 링크를 지정하려면 어떤 형식을 사용하나요?
앱에서 웹으로의 기여 분석 소스를 등록할 때 소스 이벤트는 Android Attribution Reporting API를 통해 앱에서 등록해야 합니다. 예를 들어 사용자가 광고를 클릭하고 클릭이 브라우저 또는 브라우저의 맞춤 탭에서 열리는 경우 해당 클릭(소스 이벤트)은 브라우저 컨텍스트가 아닌 앱에서 등록해야 합니다. 이와 관련하여 우려사항이 있거나 지원되는 흐름을 설명하는 이 문제에서 다룬 카테고리에 포함되지 않는 사용 사례가 있는 경우 문의해 주세요.