모바일용 기여 분석 보고 개요

최신 업데이트

  • 예정된 변경사항 및 알려진 문제 목록 업데이트

  • 전체 버전의 유연한 이벤트 수준 구성에 대한 브리지로 라이트 버전의 유연한 이벤트 수준 구성 도입

  • 2023년 9월부터 registerWebSource, registerWebTrigger, registerAppSource, registerAppTrigger는 숫자 값(예: priority, source_event_id, debug_key, trigger_data, deduplication_key 등)이 예상되는 필드에 문자열을 사용해야 함

  • 2023년 4분기에 Google Cloud의 집계 서비스를 사용하여 요약 보고서를 생성하기 위해 Android Attribution Reporting API의 Google Cloud 지원이 추가됨. 보다 구체적인 시점은 여기에 반영됩니다. Google Cloud에서 집계 서비스를 설정하는 방법에 관한 자세한 내용은 배포 가이드를 참고하세요.

  • 고유한 대상 수에 관한 새로운 개인 정보 보호 비율 제한

  • 전환 확인 기간 트리거 필터의 업데이트된 기능이 2024년 1분기에 제공될 예정입니다. 자세한 내용은 참고를 참고하세요.

개요

지금은 모바일 기여 분석 및 측정 솔루션에서 광고 ID와 같은 교차 파티 식별자를 사용하는 것이 일반적입니다. Attribution Reporting API는 교차 파티 사용자 식별자에 관한 의존성을 제거하여 사용자 개인 정보 보호를 개선하고 앱 및 웹에서 기여 분석 및 전환 측정을 위한 주요 사용 사례를 지원하도록 설계되었습니다.

이 API에는 개인 정보 보호 개선을 위한 프레임워크를 제공하는 다음과 같은 구조 메커니즘이 있습니다. 이 페이지의 뒷부분에서 자세히 설명합니다.

앞의 메커니즘은 서로 다른 두 앱 또는 도메인에서 사용자 ID를 연결하는 기능을 제한합니다.

Attribution Reporting API는 다음과 같은 사용 사례를 지원합니다.

  • 전환 보고: 캠페인, 광고 그룹, 광고 소재 등 다양한 측정기준에서 전환(트리거) 횟수와 전환(트리거) 값을 표시하여 광고주가 캠페인의 실적을 측정할 수 있도록 지원합니다.
  • 최적화: ML 모델을 학습시키는 데 사용할 수 있는 노출당 기여 분석 데이터를 제공하여 광고비 최적화를 지원하는 이벤트 수준 보고서를 제공합니다.
  • 무효 활동 감지: 무효 트래픽과 광고 사기 감지 및 분석에 사용할 수 있는 보고서를 제공합니다.

상위 수준에서 Attribution Reporting API는 다음과 같이 작동하며, 이 문서의 뒷부분에서 자세히 설명합니다.

  1. 광고 기술이 Attribution Reporting API를 사용하기 위한 등록 프로세스를 완료합니다.
  2. 광고 기술이 Attribution Reporting API에 광고 클릭 또는 조회와 같은 기여 분석 소스를 등록합니다.
  3. 광고 기술이 Attribution Reporting API에 광고주 앱 또는 웹사이트의 사용자 전환과 같은 트리거를 등록합니다.
  4. Attribution Reporting API는 트리거를 기여 분석 소스(전환 기여 분석)와 일치시키며, 하나 이상의 트리거가 이벤트 수준 보고서 및 집계 가능한 보고서를 통해 기기를 벗어나 광고 기술에 전송됩니다.

Attribution Reporting API에 액세스

광고 기술 플랫폼은 Attribution Reporting API에 액세스하려면 등록해야 합니다. 자세한 내용은 개인 정보 보호 샌드박스 계정 등록을 참고하세요.

기여 분석 소스 등록(클릭 또는 조회)

Attribution Reporting API는 광고 클릭 및 조회를 기여 분석 소스로 참조합니다. 광고 클릭이나 광고 조회를 등록하려면 registerSource()를 호출하세요. 이 API에는 다음 매개변수가 필요합니다.

  • 기여 분석 소스 URI: 플랫폼은 기여 분석 소스와 연결된 메타데이터를 가져오기 위해 이 URI에 요청을 보냅니다.
  • 입력 이벤트: InputEvent 객체(클릭 이벤트용) 또는 null(조회 이벤트용)입니다.

API가 기여 분석 소스 URI에 요청하면 광고 기술은 다음 필드와 함께 새 HTTP 헤더 Attribution-Reporting-Register-Source의 기여 분석 소스 메타데이터로 응답해야 합니다.

  • 소스 이벤트 ID: 이 값은 이 기여 분석 소스(광고 클릭 또는 조회)와 연결된 이벤트 수준 데이터를 나타냅니다. 문자열 형식의 부호 없는 64비트 정수여야 합니다.
  • 대상: 트리거 이벤트가 발생하는 출처의 eTLD+1 또는 앱 패키지 이름입니다.
  • 만료 기간(선택사항): 소스가 기기에서 삭제되어야 하는 만료 시간(초)입니다. 기본값은 30일이며 최솟값은 1일, 최댓값은 30일입니다. 가장 가까운 날로 반올림됩니다. 부호 없는 64비트 정수 또는 문자열 형식일 수 있습니다.
  • 이벤트 보고서 기간(선택사항): 소스 등록 후 이 소스에 대한 이벤트 보고서가 생성될 수 있는 기간(초)입니다. 이벤트 보고서 기간이 지났지만 만료일이 아직 지나지 않은 경우 트리거는 소스와 일치될 수 있으며 해당 트리거에 대한 이벤트 보고서는 전송되지 않습니다. 만료 시간 이하여야 합니다. 부호 없는 64비트 정수 또는 문자열 형식일 수 있습니다.
  • 집계 가능한 보고서 기간(선택사항): 소스 등록 후 이 소스에 대한 집계 가능한 보고서가 생성될 수 있는 기간(초)입니다. 만료 시간 이하여야 합니다. 부호 없는 64비트 정수 또는 문자열 형식일 수 있습니다.
  • 소스 우선순위(선택사항): 여러 기여 분석 소스가 트리거와 연결될 수 있는 경우 지정된 트리거가 연결되어야 하는 기여 분석 소스를 선택하는 데 사용됩니다. 문자열 형식의 부호 있는 64비트 정수여야 합니다.

    트리거가 수신되면 API는 소스 우선순위 값이 가장 높은, 일치하는 기여 분석 소스를 찾아 보고서를 생성합니다. 각 광고 기술 플랫폼은 자체 우선순위 지정 전략을 정의할 수 있습니다. 우선순위가 기여 분석에 미치는 영향에 관한 자세한 내용은 우선순위 예 섹션을 참고하세요.

    값이 클수록 우선순위가 높습니다.
  • 설치 및 설치 후 기여 산정 기간(선택사항): 이 페이지의 뒷부분에 설명된 설치 후 이벤트의 기여 분석을 결정하는 데 사용됩니다.
  • 데이터 필터링(선택사항): 일부 트리거를 선택적으로 필터링하는 데 사용됩니다. 그러한 트리거는 사실상 무시됩니다. 자세한 내용은 이 페이지의 트리거 필터 섹션을 참고하세요.
  • 집계 키(선택사항): 집계 가능한 보고서에 사용할 분류 기준을 지정합니다.

선택사항으로 기여 분석 소스 메타데이터 응답은 기여도 보고 리디렉션 헤더에 추가 데이터를 포함할 수 있습니다. 데이터에는 여러 광고 기술을 통해 요청을 등록할 수 있는 리디렉션 URL이 포함됩니다.

개발자 가이드에는 소스 등록을 수락하는 방법을 보여주는 예가 포함되어 있습니다.

다음 단계에서는 워크플로의 예시를 보여줍니다.

  1. 광고 기술 SDK는 이 API를 호출하여 기여 분석 소스 등록을 시작하고 API가 호출할 URI를 지정합니다.

    registerSource(
    Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
    myClickEvent);

  2. API는 다음 헤더 중 하나를 사용하여 https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA에 요청합니다.

    <!-- For click events -->
Attribution-Reporting-Source-Info: navigation

<!-- For view events -->
Attribution-Reporting-Source-Info: event

  3. 이 광고 기술의 HTTPS 서버는 다음을 포함하는 헤더로 응답합니다.

    Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "234",
    "expiry": "60000",
    "priority": "5"
}
Attribution-Reporting-Redirect:
https://adtechpartner1.example?their_ad_click_id=567
Attribution-Reporting-Redirect:
https://adtechpartner2.example?their_ad_click_id=890

  4. API는 Attribution-Reporting-Redirect에 지정된 각 URL에 요청합니다. 이 예에서는 두 개의 광고 기술 파트너 URL을 지정하므로 API가 https://adtechpartner1.example?their_ad_click_id=567과 https://adtechpartner2.example?their_ad_click_id=890에 각각 하나씩 요청합니다.

  5. 이 광고 기술의 HTTPS 서버는 다음을 포함하는 헤더로 응답합니다.

    Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "789",
    "expiry": "120000",
    "priority": "2"
}

탐색(클릭) 기여 분석 소스 세 개가 이전 단계에 표시된 요청에 기반하여 등록됩니다.

WebView에서 기여 분석 소스 등록

WebView는 앱이 WebView 내에서 광고를 렌더링하는 사용 사례를 지원합니다. 이는 WebView에서 registerSource()를 백그라운드 요청으로 직접 호출하는 방식으로 처리됩니다. 이 호출은 기여 분석 소스를 최상위 출처 대신 앱에 연결합니다. 브라우저 컨텍스트 내 삽입된 웹 콘텐츠에서 소스를 등록하는 것도 지원됩니다. 이렇게 하려면 API 호출자와 앱 모두 설정을 조정해야 합니다. API 호출자에 관한 안내는 기여 분석 소스 등록 및 WebView에서 트리거를, 앱에 관한 안내는 WebView에서 기여 분석 소스 및 트리거 등록을 참고하세요.

광고 기술은 웹과 WebView에서 공통 코드를 사용하므로 WebView는 HTTP 302 리디렉션을 따르고 유효한 등록을 플랫폼에 전달합니다. 이 시나리오에서는 Attribution-Reporting-Redirect 헤더를 지원할 계획이 없지만, 영향을 받는 사용 사례가 있다면 문의해 주세요.

트리거 등록(전환)

광고 기술 플랫폼은 registerTrigger() 메서드를 사용하여 트리거(설치 또는 설치 후 이벤트와 같은 전환)를 등록할 수 있습니다.

registerTrigger() 메서드에는 트리거 URI 매개변수가 필요합니다. API는 이 URI에 요청을 보내 트리거와 연결된 메타데이터를 가져옵니다.

API는 리디렉션을 따릅니다. 광고 기술 서버 응답에는 Attribution-Reporting-Register-Trigger라는 HTTP 헤더가 포함되어야 하며 이는 등록된 트리거 하나 이상에 관한 정보를 나타냅니다. 헤더의 콘텐츠는 JSON으로 인코딩되어야 하며 다음 필드를 포함해야 합니다.

  • 트리거 데이터: 트리거 이벤트를 식별하는 데이터(클릭의 경우 3비트, 조회의 경우 1비트)입니다. 문자열 형식의 부호 있는 64비트 정수여야 합니다.

  • 트리거 우선순위(선택사항): 동일한 기여 분석 소스의 다른 트리거와 비교하여 이 트리거의 우선순위를 나타냅니다. 문자열 형식의 부호 있는 64비트 정수여야 합니다. 우선순위가 보고에 미치는 영향에 관한 자세한 내용은 우선순위 섹션을 참고하세요.

  • 중복 삭제 키(선택사항): 동일한 기여 분석 소스에 관해 동일한 광고 기술 플랫폼에서 같은 트리거가 여러 번 등록되는 경우를 식별하는 데 사용됩니다. 문자열 형식의 부호 있는 64비트 정수여야 합니다.

  • 집계 키(선택사항): 집계 키를 지정하고 집계 가능한 보고서에 값이 집계되어야 하는 사전 목록입니다.

  • 집계 값(선택사항): 각 키에 기여하는 값의 양 목록입니다.

  • 필터(선택사항): 트리거 또는 트리거 데이터를 선택적으로 필터링하는 데 사용됩니다. 자세한 내용은 이 페이지의 트리거 필터 섹션을 참고하세요.

선택사항으로 광고 기술 서버 응답은 기여도 보고 리디렉션 헤더에 추가 데이터를 포함할 수 있습니다. 데이터에는 여러 광고 기술을 통해 요청을 등록할 수 있는 리디렉션 URL이 포함됩니다.

여러 광고 기술은 Attribution-Reporting-Redirect 필드의 리디렉션 또는 여러 번의 registerTrigger() 메서드 호출을 사용하여 동일한 트리거 이벤트를 등록할 수 있습니다. 동일한 광고 기술이 같은 트리거 이벤트에 관해 여러 응답을 제공하는 경우 중복 삭제 키 필드를 사용하여 보고서에 중복 트리거가 포함되지 않도록 하는 것이 좋습니다. 중복 삭제 키 사용 방법과 사용 시기를 자세히 알아보세요.

개발자 가이드에는 트리거 등록을 수락하는 방법을 보여주는 예가 포함되어 있습니다.

다음 단계에서는 워크플로의 예시를 보여줍니다.

  1. 광고 기술 SDK는 이 API를 호출하여 사전 등록된 URI를 사용하는 트리거 등록을 시작합니다. 자세한 내용은 개인 정보 보호 샌드박스 계정 등록을 참고하세요.

    registerTrigger(
    Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));

  2. API는 https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA에 요청합니다.

  3. 이 광고 기술의 HTTPS 서버는 다음을 포함하는 헤더로 응답합니다.

    Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "1122",
    // This returns 010 for click-through conversions (CTCs) and 0 for
    // view-through conversions (VTCs) in reports
    "priority": "3",
    "deduplication_key": "3344"
    }],
}
Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567

  4. API는 Attribution-Reporting-Redirect에 지정된 각 URL에 요청합니다. 이 예시에서는 URL이 하나만 지정되므로 API가 https://adtechpartner.example?app_install=567에 요청합니다.

  5. 이 광고 기술의 HTTPS 서버는 다음을 포함하는 헤더로 응답합니다.

    Attribution-Reporting-Register-Trigger: {
"event_trigger_data":[{
  "trigger_data": "5566",
  "priority": "3",
  "deduplication_key": "3344"
}]
}

    이전 단계의 요청에 따라 트리거 두 개가 등록됩니다.

기여 분석 기능

다음 섹션에서는 Attribution Reporting API가 전환 트리거를 기여 분석 소스와 일치시키는 방법을 설명합니다.

소스 우선순위 기여 분석 알고리즘 적용

Attribution Reporting API는 소스 우선순위 기여 분석 알고리즘을 사용하여 트리거(전환)를 기여 분석 소스에 일치시킵니다.

우선순위 매개변수는 소스에 대한 트리거의 기여 분석을 맞춤설정하는 방법을 제공합니다.

  • 다른 광고 이벤트보다 특정 광고 이벤트로 인해 트리거가 발생하도록 할 수 있습니다. 예를 들어 조회수보다 클릭수를 더 강조하거나 특정 캠페인의 이벤트에 중점을 둘 수 있습니다.
  • 비율 제한에 도달하면 더 중요한 보고서를 수신할 가능성이 높아지도록 기여 분석 소스와 트리거를 구성할 수 있습니다. 예를 들어 입찰 가능 전환 또는 가치가 높은 전환이 보고서에 표시될 가능성을 높일 수 있습니다.

이 페이지의 뒷부분에 설명된 대로 여러 광고 기술이 기여 분석 소스를 등록하는 경우 이 기여 분석은 각 광고 기술에서 독립적으로 발생합니다. 각 광고 기술의 경우 우선순위가 가장 높은 기여 분석 소스가 트리거 이벤트와 함께 표시됩니다. 우선순위가 동일한 기여 분석 소스가 여러 개 있는 경우 API는 마지막에 등록된 기여 분석 소스를 선택합니다. 선택되지 않은 다른 기여 분석 소스는 삭제되며 더 이상 향후 트리거 기여 분석에 사용할 수 없습니다.

트리거 필터

소스 및 트리거 등록에는 다음을 실행하는 추가 기능(선택사항)이 포함되어 있습니다.

  • 선택적으로 일부 트리거를 필터링. 그러한 트리거는 사실상 무시됩니다.
  • 소스 데이터를 기준으로 이벤트 수준 보고서의 트리거 데이터 선택
  • 이벤트 수준 보고서에서 트리거를 제외하도록 선택

선택적으로 트리거를 필터링하기 위해 광고 기술은 소스 및 트리거 등록 중에 키와 값으로 구성된 필터 데이터를 지정할 수 있습니다. 소스와 트리거에 모두 동일한 키가 지정된 경우 키와 값의 교차점이 비어 있으면 트리거가 무시됩니다. 예를 들어 소스는 "product": ["1234"]를 지정할 수 있습니다. 여기서 product는 필터 키이고 1234는 값입니다. 트리거 필터가 "product": ["1111"]로 설정되면 트리거가 무시됩니다. product와 일치하는 트리거 필터 키가 없으면 필터가 무시됩니다.

광고 기술 플랫폼에서 트리거를 선택적으로 필터링할 수 있는 또 다른 시나리오는 더 짧은 만료 기간을 강제하는 것입니다. 트리거 등록 시 광고 기술은 전환이 발생한 시점부터 전환 확인 기간을 지정(초 단위)할 수 있습니다. 예를 들어 7일 전환 확인 기간은 "_lookback_window": 604800 // 7d로 정의됩니다.

필터가 일치하는지 판단하기 위해 API는 먼저 전환 확인 기간을 확인합니다. 사용 가능한 경우 소스가 등록된 이후의 기간은 전환 확인 기간보다 짧거나 같아야 합니다.

광고 기술 플랫폼은 소스 이벤트 데이터를 기반으로 트리거 데이터를 선택할 수도 있습니다. 예를 들어 source_type은 API에 의해 navigation 또는 event로 자동 생성됩니다. 트리거 등록 동안 trigger_data를 "source_type": ["navigation"]의 특정 값으로 설정하고 "source_type": ["event"]의 다른 값으로 설정할 수 있습니다.

다음에 해당하는 경우 트리거는 이벤트 수준 보고서에서 제외됩니다.

  • 지정된 trigger_data가 없는 경우
  • 소스와 트리거가 동일한 필터 키를 지정하지만 값이 일치하지 않는 경우. 이 경우 트리거는 이벤트 수준 보고서와 집계 가능한 보고서에 모두 무시됩니다.

설치 후 기여 분석

더 최근에 발생한 다른 적합한 기여 분석 소스가 있더라도 설치를 유도한 동일한 기여 분석 소스에 설치 후 트리거가 기인되어야 하는 경우도 있습니다.

API는 광고 기술에서 설치 후 기여 분석 기간을 설정할 수 있도록 하여 이 사용 사례를 지원할 수 있습니다.

  • 기여 분석 소스를 등록할 때 설치가 예상되는 설치 기여 산정 기간(일반적으로 2~7일, 허용 범위는 1~30일)을 지정합니다. 이 기간은 초 단위로 지정합니다.
  • 기여 분석 소스를 등록할 때 설치 후 트리거 이벤트를 설치를 유도한 기여 분석 소스와 연결해야 하는 설치 후 기여 산정 독점 기간(일반적으로 7~30일, 허용 범위는 0~30일)을 지정합니다. 이 기간은 초 단위로 지정합니다.
  • Attribution Reporting API는 앱 설치가 발생하는 시기를 확인하고 소스 우선순위 기여 분석 소스로 인해 설치가 발생한다고 내부적으로 판단합니다. 그러나 설치가 광고 기술로 전송되지 않으며 플랫폼의 각 비율 제한에 포함되지 않습니다.
  • 앱 설치 유효성 검사는 다운로드한 모든 앱에 사용할 수 있습니다.
  • 설치 후 기여 산정 기간 내에 발생하는 향후 트리거는 모두 기여 분석 소스가 요건을 충족하는 한 확인된 설치와 동일한 기여 분석 소스에 기인합니다.

향후 더 발전된 고급 기여 분석 모델을 지원하도록 설계를 확장할 수도 있습니다.

다음 표는 광고 기술이 설치 후 기여 분석을 사용하는 방법을 보여주는 예입니다. 모든 기여 분석 소스와 트리거가 동일한 광고 기술 네트워크를 통해 등록되었으며 모든 우선순위가 동일하다고 가정합니다.

이벤트 이벤트 발생일 메모
클릭 1 1 install_attribution_window는 172800(2일)으로 설정되고 post_install_exclusivity_window는 864000(10일)으로 설정됩니다.
확인된 설치 2 API는 내부적으로 확인된 설치를 표시하지만 이러한 설치는 트리거로 간주되지 않습니다. 따라서 이때는 보고서가 전송되지 않습니다.
트리거 1(처음 여는 트리거) 2 광고 기술을 통해 등록된 첫 번째 트리거입니다. 이 예에서는 처음 연 트리거를 나타내지만 어떤 트리거 유형이든 가능합니다.
클릭 1에서 기인됩니다(인증된 설치의 기여 분석과 일치).
클릭 2 4 install_attribution_window 및 post_install_exclusivity_window에 클릭 1과 동일한 값을 사용합니다.
트리거 2(설치 후) 5 광고 기술을 통해 등록된 두 번째 트리거입니다. 이 예에서는 구매와 마찬가지로 설치 후 전환을 나타냅니다.
클릭 1에서 기인됩니다(인증된 설치의 기여 분석과 일치).
클릭 2는 삭제되며 향후 기여 분석에 사용할 수 없습니다.

다음 목록에는 설치 후 기여 분석에 관한 추가 참고사항이 제공되어 있습니다.

  • 인증된 설치가 install_attribution_window로 지정된 기간 내에 발생하지 않으면 설치 후 기여 분석이 적용되지 않습니다.
  • 확인된 설치는 광고 기술을 통해 등록되지 않으며 보고서에 전송되지 않습니다. 이러한 설치는 광고 기술의 비율 제한에 포함되지 않습니다. 확인된 설치는 설치에 기여한 기여 분석 소스를 식별하는 용도로만 사용됩니다.
  • 위 표의 예에서 트리거 1과 트리거 2는 각각 처음 열린 트리거와 설치 후 전환 트리거를 나타냅니다. 그러나 광고 기술 플랫폼은 모든 유형의 트리거를 등록할 수 있습니다. 즉, 첫 번째 트리거가 첫 번째 열린 트리거일 필요는 없습니다.
  • post_install_exclusivity_window 만료 후에 더 많은 트리거가 등록되더라도 클릭 1이 만료되지 않았고 비율 제한에 도달하지 않았다면 여전히 클릭 1을 기여 분석에 사용할 수 있습니다.
    • 우선순위가 높은 기여 분석 소스가 등록되면 클릭 1은 여전히 손실되거나 삭제될 수 있습니다.
  • 광고주 앱이 제거되었다가 재설치된 경우 재설치는 새로 확인된 설치 계산에 포함됩니다.
  • 대신 클릭 1이 조회 이벤트인 경우 '처음 열림' 트리거는 물론 '설치 후' 트리거도 계속해서 클릭 1에 기인하게 됩니다. API는 기여 분석을 조회당 트리거 1개로 제한합니다. 단, 조회당 최대 2개의 트리거가 허용되는 설치 후 기여 분석은 예외입니다. 설치 후 기여 분석 사례에서 광고 기술은 서로 다른 두 개의 보고 기간(2일 차에 또는 소스 만료 시점에)을 수신할 수 있습니다.

앱 기반 트리거 경로와 웹 기반 트리거 경로의 모든 조합 지원

Attribution Reporting API를 사용하면 단일 Android 기기에서 다음 트리거 경로의 기여 분석을 사용 설정할 수 있습니다.

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

Google에서는 웹브라우저에서 새로운 웹 노출 기능(예: 웹 Attribution Reporting API의 개인 정보 보호 샌드박스와 유사한 기능)을 지원하도록 허용하며 이 기능은 Android API를 호출하여 앱과 웹에 걸쳐 기여 분석을 사용 설정할 수 있습니다.

광고 기술 및 앱에서 앱과 웹 간의 교차 측정의 트리거 경로를 지원하기 위해 변경해야 하는 사항에 관해 알아보세요.

단일 기여 분석 소스의 여러 트리거 우선순위 지정

단일 기여 분석 소스가 여러 트리거로 이어질 수 있습니다. 예를 들어 구매 흐름에는 하나의 '앱 설치' 트리거와 하나 이상의 '장바구니에 추가' 트리거, 하나의 '구매' 트리거가 포함될 수 있습니다. 각 트리거는 이 페이지의 뒷부분에서 설명하는 소스 우선순위 기여 분석 알고리즘에 따라 하나 이상의 기여 분석 소스로 인해 발생합니다.

단일 기여 분석 소스로 인해 발생할 수 있는 트리거 수에는 제한이 있습니다. 자세한 내용은 이 페이지 뒷부분에 나오는 기여도 보고서의 측정 데이터 보기 섹션을 참고하세요.

이러한 제한을 초과하는 트리거가 여러 개 있는 경우 우선순위 지정 로직을 도입하여 가장 중요한 트리거를 다시 가져오는 것이 좋습니다. 예를 들어, 광고 기술 개발자는 '장바구니에 추가' 트리거보다 '구매' 트리거를 얻는 것에 우선순위를 두는 것이 좋습니다.

이 로직을 지원하기 위해서는 지정된 보고 기간 내에 트리거에 별도의 우선순위 필드를 설정할 수 있고 제한이 적용되기 전에 가장 높은 우선순위의 트리거를 선택합니다.

여러 광고 기술에서 기여 분석 소스 또는 트리거를 등록하도록 허용

보통 2개 이상의 광고 기술이 기여도 보고서를 수신하며 일반적으로 교차 네트워크 중복 삭제 작업을 수행합니다. 따라서 이 API를 사용하면 여러 광고 기술에서 동일한 기여 분석 소스 또는 트리거를 등록할 수 있습니다. 광고 기술은 API에서 포스트백을 수신하려면 기여 분석 소스와 트리거를 모두 등록해야 하고 기여 분석은 광고 기술이 API에 등록한 기여 분석 소스 및 트리거 중에서 실행됩니다.

서드 파티를 통해 교차 네트워크 중복 삭제를 실행하려는 광고주는 다음과 유사한 기법을 사용하여 작업을 진행할 수 있습니다.

  • API에서 보고서를 받고 등록하도록 내부 서버를 설정
  • 기존 모바일 측정 파트너를 계속 이용

기여 분석 소스

기여 분석 소스 리디렉션은 registerSource() 메서드에서 지원합니다.

  1. registerSource() 메서드를 호출하는 광고 기술은 응답에 추가로 Attribution-Reporting-Redirect 필드를 제공하여 파트너 광고 기술의 리디렉션 URL 집합을 제공할 수 있습니다.
  2. 그러면 API가 리디렉션 URL을 호출하여 파트너 광고 기술에서 기여 분석 소스를 등록할 수 있습니다.

여러 파트너 광고 기술 URL을 Attribution-Reporting-Redirect 필드에 나열할 수 있으며 파트너 광고 기술은 자체 Attribution-Reporting-Redirect 필드를 지정할 수 없습니다.

또한 이 API를 사용하면 다양한 광고 기술이 각각 registerSource()를 호출할 수 있습니다.

트리거

트리거 등록의 경우 유사한 방식으로 서드 파티를 지원합니다. 광고 기술은 추가 Attribution-Reporting-Redirect 필드를 사용하거나 registerTrigger() 메서드를 각각 호출할 수 있습니다.

광고주가 여러 광고 기술을 사용하여 동일한 트리거 이벤트를 등록하는 경우 중복 삭제 키를 사용해야 합니다. 중복 삭제 키는 동일한 광고 기술 플랫폼에서 등록한 동일한 이벤트의 반복되는 보고서를 명확하게 구분하는 역할을 합니다. 예를 들어, 광고 기술은 SDK가 API를 직접 호출하여 트리거를 등록하고 다른 광고 기술 호출의 리디렉션 필드에 URL을 포함하도록 할 수 있습니다. 중복 삭제 키가 제공되지 않으면 각 광고 기술에 중복 트리거가 고유한 것으로 보고될 수 있습니다.

중복 트리거 처리

광고 기술은 API에 동일한 트리거를 여러 번 등록할 수 있습니다. 시나리오는 다음과 같습니다.

  • 사용자가 같은 작업(트리거)을 여러 번 실행합니다. 예를 들어, 사용자가 동일한 보고 기간에 같은 제품을 여러 번 탐색합니다.
  • 광고주 앱이 여러 SDK를 전환 측정에 사용하며 모두 동일한 광고 기술로 리디렉션됩니다. 예를 들어 광고주 앱이 두 가지 측정 파트너(MMP 1 및 MMP 2)를 사용합니다. 두 MMP 모두 광고 기술 3으로 리디렉션됩니다. 트리거가 발생하면 MMP는 모두 Attribution Reporting API에 트리거를 등록합니다. 그러면 광고 기술 3은 동일한 트리거에 관해 두 개의 별도 리디렉션(MMP 1과 MMP 2에서 하나씩)을 수신합니다.

이 경우 중복 트리거에 관한 이벤트 수준 보고서를 억제하여 이벤트 수준 보고서에 적용되는 비율 제한을 초과할 가능성을 줄이는 몇 가지 방법이 있습니다. 권장하는 방법은 중복 삭제 키를 사용하는 것입니다.

권장 방법: 중복 삭제 키

권장하는 방법은 광고주 앱에서 전환 측정에 사용 중인 광고 기술 또는 SDK에 고유한 중복 삭제 키를 전달하는 것입니다. 전환이 발생하면 앱이 중복 삭제 키를 광고 기술 또는 SDK에 전달합니다. 그러면 이러한 광고 기술 또는 SDK는 Attribution-Reporting-Redirect에 지정된 URL의 매개변수를 사용하여 리디렉션에 중복 삭제 키를 계속 전달합니다.

광고 기술은 지정된 중복 삭제 키를 사용하여 첫 번째 트리거만 등록하도록 선택하거나 여러 트리거 또는 모든 트리거를 등록하도록 선택할 수 있습니다. 광고 기술은 중복 트리거를 등록할 때 deduplication_key를 지정할 수 있습니다.

광고 기술이 동일한 중복 삭제 키와 기여 분석 소스로 여러 트리거를 등록하면 첫 번째 등록된 트리거만 이벤트 수준 보고서에 전송됩니다. 중복 트리거는 암호화된 집계 가능한 보고서에 계속 전송됩니다.

대체 방법: 광고 기술이 광고주별 트리거 유형에 동의

광고 기술이 중복 삭제 키를 사용하지 않으려고 하거나 광고주 앱이 중복 삭제 키를 전달할 수 없는 경우 대체 옵션이 있습니다. 특정 광고주의 전환을 측정하는 모든 광고 기술은 서로 연동하여 각 광고주에 맞게 다른 트리거 유형을 정의해야 합니다.

트리거 등록 호출을 시작하는 광고 기술(예: SDK)에는 Attribution-Reporting-Redirect에 지정된 URL에 매개변수(예: duplicate_trigger_id)가 포함됩니다. duplicate_trigger_id 매개변수에는 SDK 이름과 광고주의 트리거 유형과 같은 정보가 포함될 수 있습니다. 그러면 광고 기술은 이러한 중복 트리거의 하위 집합을 이벤트 수준 보고서에 전송할 수 있습니다. 광고 기술은 이 duplicate_trigger_id를 집계 키에 포함할 수도 있습니다.

교차 네트워크 기여 분석 예

이 섹션에서 설명하는 예에서는 광고주가 게재 광고 기술 플랫폼 두 개(광고 기술 A, 광고 기술 B)와 측정 파트너 하나(MMP)를 사용합니다.

먼저 광고 기술 A, 광고 기술 B, MMP는 Attribution Reporting API를 사용하려면 각각 등록을 완료해야 합니다. 자세한 내용은 개인 정보 보호 샌드박스 계정 등록을 참고하세요.

다음 목록은 각각 하루 간격으로 발생하는 일련의 사용자 작업을 가상으로 제공하고 Attribution Reporting API가 광고 기술 A, 광고 기술 B, MMP와 관련하여 이러한 작업을 처리하는 방법을 제공합니다.

1일 차: 사용자가 광고 기술 A에서 게재한 광고를 클릭합니다.

광고 기술 A는 URI를 사용하여 registerSource()를 호출합니다. API가 URI에 요청하면 클릭이 광고 기술 A의 서버 응답의 메타데이터에 등록됩니다.

광고 기술 A는 Attribution-Reporting-Redirect 헤더에 MMP의 URI도 포함합니다. API가 MMP의 URI에 요청하면 클릭이 MMP의 서버 응답의 메타데이터에 등록됩니다.

2일 차: 사용자가 광고 기술 B에서 게재한 광고를 클릭합니다.

광고 기술 B는 URI를 사용하여 registerSource()를 호출합니다. API가 URI에 요청하면 클릭이 광고 기술 B의 서버 응답의 메타데이터에 등록됩니다.

광고 기술 A와 마찬가지로 광고 기술 B도 Attribution-Reporting-Redirect 헤더에 MMP의 URI를 포함했습니다. API가 MMP의 URI에 요청하면 클릭이 MMP의 서버 응답의 메타데이터에 등록됩니다.

3일 차: 사용자가 광고 기술 A에서 게재한 광고를 조회합니다.

이 API는 조회가 광고 기술 A 및 MMP에 등록된다는 점을 제외하고 1일 차에서와 같은 방식으로 응답합니다.

4일 차: 전환을 측정하는 데 MMP를 사용하는 앱을 사용자가 설치합니다.

MMP는 URI를 사용하여 registerTrigger()을 호출합니다. API가 URL에 요청하고 전환이 MMP의 서버 응답 메타데이터에 등록됩니다.

또한 MMP는 광고 기술 A 및 광고 기술 B의 URI를 Attribution-Reporting-Redirect 헤더에 포함합니다. API가 광고 기술 A 및 광고 기술 B의 서버에 요청하고 전환이 서버 응답의 메타데이터에 적절하게 등록됩니다.

다음 다이어그램은 이전 목록에 설명된 프로세스를 보여줍니다.

Attribution Reporting API가 일련의 사용자 작업에 어떻게 응답하는지 보여주는 예시

기여 분석은 다음과 같이 작동합니다.

  • 광고 기술 A는 조회보다 클릭 우선순위를 더 높게 설정하므로 1일 차의 클릭에 기인한 설치를 얻습니다.
  • 광고 기술 B는 2일 차에 기인한 설치를 얻습니다.
  • MMP는 조회보다 클릭 우선순위를 더 높게 설정하므로 2일 차의 클릭에 기인한 설치를 얻습니다. 2일 차의 클릭은 우선순위가 가장 높은 최신 광고 이벤트입니다.

리디렉션 없는 교차 네트워크 기여 분석

여러 광고 기술에서 기여 분석 소스 및 트리거를 등록할 수 있도록 리디렉션을 활용하는 것이 좋지만 리디렉션 사용이 불가능한 시나리오도 있을 수 있습니다. 이 섹션에서는 리디렉션 없이 교차 네트워크 기여 분석을 지원하는 방법을 자세히 설명합니다.

대략적인 흐름

  1. 소스 등록 시 게재 광고 기술 네트워크는 소스 집계 키를 공유합니다.
  2. 트리거 등록 시 광고주 또는 측정 파트너는 사용할 소스 측 키 조각을 선택하고 기여 분석 구성을 지정합니다.
  3. 기여 분석은 기여 분석 구성, 공유 키, 해당 광고주 또는 측정 파트너가 실제로 등록한 소스(예: 리디렉션을 사용 설정한 다른 게재 광고 기술 네트워크)에 기반합니다.
  4. 리디렉션되지 않는 게재 광고 기술의 소스로 인해 트리거가 발생한 경우 광고주 또는 측정 파트너는 2단계에서 정의된 소스 및 트리거 키 조각을 결합하는 집계 가능한 보고서를 수신할 수 있습니다.

소스 등록

소스 등록 시 게재 광고 기술 네트워크는 리디렉션 대신 소스 집계 키 또는 소스 집계 키의 하위 집합을 공유하도록 선택할 수 있습니다. 게재 광고 기술은 집계 가능한 자체 보고서에서 실제로 이러한 소스 키를 사용하지 않아도 되며 필요한 경우 광고주 또는 측정 파트너를 대신해서만 소스 키를 선언할 수 있습니다.

공유 집계 키는 동일한 광고주의 트리거를 등록하는 모든 광고 기술에서 사용할 수 있습니다. 하지만 게재 광고 기술 및 트리거 측정 광고 기술은 필요한 집계 키 유형, 이름, 키를 읽을 수 있는 측정기준으로 디코딩하는 방법에 관해 협력해야 합니다.

트리거 등록

트리거 등록 시 측정 광고 기술은 광고 기술을 게재하여 공유되는 것을 비롯하여 각 트리거 키 조각에 적용할 소스 측 키 조각을 선택합니다.

또한 측정 광고 기술은 새 기여 분석 구성 API 호출을 사용하여 폭포식 구조 기여 분석 로직도 지정해야 합니다. 이 구성에서 광고 기술은 소스 우선순위, 만료, 확인할 수 없는 소스(예: 리디렉션을 사용하지 않는 소스)에 대한 필터를 지정할 수 있습니다.

기여 분석

Attribution Reporting API는 기여 분석 구성, 공유 키, 등록된 소스를 기반으로 측정 광고 기술에 관한 소스 우선순위의 마지막 터치 기여 분석을 실행합니다. 예를 들면 다음과 같습니다.

  • 사용자가 광고 기술 A, B, C, D에서 게재하는 광고를 클릭합니다. 그런 다음 사용자는 측정 광고 기술 파트너(MMP)를 사용하는 광고주의 앱을 설치합니다.
  • 광고 기술 A는 소스를 MMP로 리디렉션합니다.
  • 광고 기술 B와 C는 리디렉션하지 않지만 집계 키를 공유합니다.
  • 광고 기술 D는 리디렉션하지도, 집계 키를 공유하지도 않습니다.

MMP는 광고 기술 A의 소스를 등록하고 광고 기술 B와 광고 기술 D가 포함된 기여 분석 구성을 정의합니다.

이제 MMP의 기여 분석에는 다음이 포함됩니다.

  • 광고 기술 A. MMP가 해당 광고 기술의 리디렉션으로부터 소스를 등록했기 때문입니다.
  • 광고 기술 B. 광고 기술 B가 키를 공유했고 MMP가 기여 분석 구성에 포함했기 때문입니다.

MMP의 기여 분석에는 다음이 포함되지 않습니다.

  • 광고 기술 C. MMP가 기여 분석 구성에 포함하지 않았기 때문입니다.
  • 광고 기술 D. 리디렉션하거나 집계 키를 공유하지 않았기 때문입니다.

디버깅

리디렉션 없이 교차 네트워크 기여 분석 디버깅을 지원하기 위해 광고 기술에서 소스 등록 시 설정할 수 있는 추가 필드 shared_debug_key를 사용할 수 있습니다. 원래 소스 등록에 설정된 경우 리디렉션이 없는 교차 네트워크 기여 분석을 위한 트리거 등록 중에 상응하는 파생 소스에서도 debug_key로 설정됩니다. 이 디버그 키는 이벤트 및 집계 보고서에 source_debug_key로 첨부됩니다.

이 디버그 기능은 다음 시나리오에서 리디렉션이 없는 교차 네트워크 기여 분석에만 지원됩니다.

  • 광고 ID가 허용되는 경우 앱 간 측정
  • 광고 ID가 허용되고 앱 소스와 웹 트리거 모두에서 일치하는 경우 앱과 웹 간 측정
  • ar_debug` 가 소스와 트리거에 모두 있는 경우 웹 간 측정 (동일한 브라우저 앱에서)

리디렉션이 없는 교차 네트워크 기여 분석을 위한 키 검색

키 검색은 하나 이상의 게재 광고 기술이 공유 집계 키를 사용할 때 교차 네트워크 기여 분석을 위해 광고 기술(일반적으로 MMP)이 기여 분석 구성을 구현하는 방법을 간소화하기 위한 것입니다(위의 리디렉션 없는 교차 네트워크 기여 분석 참고).

MMP가 집계 서비스에 쿼리하여 파생된 소스가 포함된 캠페인의 요약 보고서를 생성하는 경우 집계 서비스는 집계 작업의 입력으로 가능한 키의 목록을 지정하도록 MMP에 요구합니다. 경우에 따라 잠재적인 소스 집계 키의 목록은 매우 크거나 알 수 없을 수도 있습니다. 가능한 키 목록이 크면 추적하기가 어려우며 처리하기에도 복잡하고 비용이 많이 들 수 있습니다. 다음 예를 고려하세요.

  • 가능한 모든 키 목록이 큽니다.
    • 게재 광고 네트워크에서 복잡한 사용자 획득 이니셔티브를 실행하고 있습니다. 여기에는 각각 10개의 광고 그룹이 있는 캠페인 20개가 포함되어 있으며 각 광고 그룹에는 실적에 따라 매주 새로고침되는 광고 소재가 5개 포함되어 있습니다.
  • 가능한 모든 키 목록을 알 수 없습니다.
    • 게재 광고 네트워크가 캠페인 시작 시 게시자 앱 ID의 전체 목록을 알 수 없는 여러 모바일 앱에 광고를 게재하고 있습니다.
    • 광고주가 소스 등록 시 MMP로 리디렉션되지 않는 여러 게재 광고 네트워크를 운영하고 있습니다. 게재 광고 네트워크마다 키 구조와 값이 다르며 이는 MMP와 미리 공유되지 않을 수 있습니다.

키 검색의 도입으로 다음이 가능해집니다.

  • 집계 서비스에는 더 이상 가능한 집계 키의 전체 열거가 필요하지 않습니다.
  • 가능한 키의 전체 목록을 지정하는 대신 MMP는 빈(또는 부분적으로 비어 있는) 키 집합을 만들고 임곗값을 설정할 수 있습니다. 따라서 임곗값을 초과하는 값(미리 선언되지 않음)이 있는 키만 출력에 포함됩니다.
  • MMP는 설정된 임곗값을 초과하는 기여 값이 있는 키의 노이즈 값이 포함된 요약 보고서를 수신합니다. 관련된 실제 사용자 기여가 없고 노이즈만 있는 키가 보고서에 포함될 수도 있습니다.
  • MMP는 트리거 등록의 x_network_bit_mapping 필드를 사용하여 어떤 광고 기술이 어떤 키에 해당하는지 확인합니다.
  • 그런 다음 MMP는 적절한 게재 광고 기술에 문의하여 소스 키의 값을 파악할 수 있습니다.

요약하면, 키 검색을 통해 MMP는 사전에 집계 키를 모르는 상태에서 집계 키를 얻을 수 있고, 노이즈를 추가하면서 대량의 소스 키를 처리하는 것을 방지할 수 있습니다.

연쇄 리디렉션

소스 또는 트리거 등록 HTTPS 서버 응답에 여러 개의 Attribution-Reporting-Redirect 헤더를 제공하면 광고 기술은 Attribution Reporting API를 사용하여 단일 등록 API 호출로 여러 소스 및 트리거 등록을 실행할 수 있습니다.

서버 응답에서 광고 기술은 URL이 포함된 단일 Location(302 리디렉션) 헤더를 포함할 수도 있으며, 이는 설정된 한도 내에서 다른 등록으로 이어집니다.

두 유형의 헤더 모두 선택사항이며 리디렉션이 필요하지 않은 경우 둘 다 제공하지 않을 수 있습니다. 두 유형의 헤더 중 하나 또는 둘 다를 제공할 수 있습니다. 네트워크 오류가 발생하면 소스 및 트리거 등록 요청 (리디렉션 포함)이 다시 시도됩니다. 기기에 미치는 영향을 최소화하기 위해 요청당 재시도 횟수는 고정된 수로 제한됩니다.

브라우저에서 사용하는 registerWebSource 및 registerWebTrigger에는 리디렉션이 허용되지 않습니다. 자세한 내용은 교차 웹 및 앱 구현 가이드를 참고하세요.

기여도 보고서의 측정 데이터 보기

Attribution Reporting API를 사용하면 다음 유형의 보고서를 사용할 수 있습니다. 이 페이지의 뒷부분에서 자세히 설명합니다.

  • 이벤트 수준 보고서: 특정 기여 분석 소스(클릭 또는 조회)를 제한된 비트의 충실도 높은 트리거 데이터와 연결합니다.
  • 집계 가능한 보고서: 반드시 특정 기여 분석 소스와 연결되는 것은 아닙니다. 이러한 보고서는 이벤트 수준 보고서보다 더 풍부하고 충실도 높은 트리거 데이터를 제공하지만 이 데이터는 집계 형식으로만 제공됩니다.

이 두 보고서 유형은 상호 보완적이며 동시에 사용할 수 있습니다.

이벤트 수준 보고서

기여 분석 소스로 인해 트리거가 발생하면 이벤트 수준 보고서가 생성되고 보고서 전송 기간(이 페이지의 뒷부분에서 자세히 설명)의 하나 중에 각 광고 기술의 포스트백 URL에 다시 전송될 때까지 기기에 저장됩니다.

이벤트 수준 보고서는 트리거에 관해 필요한 정보가 매우 적을 때 유용합니다. 이벤트 수준 트리거 데이터는 클릭의 경우 3비트의 트리거 데이터로 제한되고(즉, 트리거에 8개 카테고리 중 하나를 할당할 수 있음) 조회의 경우 1비트로 제한됩니다. 또한 이벤트 수준 보고서는 특정 가격이나 트리거 시간과 같은 충실도 높은 트리거 측 데이터의 인코딩을 지원하지 않습니다. 기여 분석은 기기에서 발생하므로 이벤트 수준 보고서에서 교차 기기 분석을 지원하지 않습니다.

이벤트 수준 보고서에는 다음과 같은 데이터가 포함됩니다.

  • 대상: 트리거가 발생한 광고주 앱 패키지 이름 또는 eTLD+1입니다.
  • 기여 분석 소스 ID: 기여 분석 소스를 등록하는 데 사용된 것과 동일한 기여 분석 소스 ID입니다.
  • 트리거 유형: 1비트 또는 3비트의 충실도 낮은 트리거 데이터로, 기여 분석 소스 유형에 따라 다릅니다.

모든 보고서에 적용되는 개인 정보 보호 메커니즘

다음 제한은 기여 분석 소스 및 트리거와 관련된 우선순위를 고려한 후에 적용됩니다.

광고 기술 수 제한

API에서 보고서를 등록하거나 수신할 수 있는 광고 기술 수에는 제한이 있으며 현재는 다음과 같이 제안합니다.

  • {소스 앱, 대상 앱, 30일, 기기} 기준으로 기여 분석 소스가 있는 광고 기술 100개
  • {소스 앱, 대상 앱, 30일, 기기} 기준으로 기여 트리거가 있는 광고 기술 10개
  • Attribution-Reporting-Redirect를 통해 단일 기여 분석 소스 또는 트리거를 등록할 수 있는 광고 기술은 20개입니다.

고유한 대상 수 제한

이러한 제한으로 인해 많은 수의 앱을 쿼리하여 특정 사용자의 앱 사용 동작을 이해함으로써 일련의 광고 기술이 공모하기 어려워졌습니다.

  • 등록된 모든 소스와 모든 광고 기술에서 API는 소스 앱별로 분당 200개 이하의 고유한 대상을 지원합니다.
  • 등록된 모든 소스에서 단일 광고 기술의 경우 API는 소스 앱별로 분당 50개 이하의 고유한 대상을 지원합니다. 이 제한으로 인해 한 광고 기술에서 앞에서 언급한 비율 제한의 전체 예산을 소진할 수 없습니다.

만료된 소스는 비율 제한에 포함되지 않습니다.

일일 소스 앱당 보고 출처 1개

특정 기기의 경우 특정 광고 기술 플랫폼은 게시자 앱에서 소스를 등록하는 데 하루에 하나의 보고 출처만 사용할 수 있습니다. 이 비율 제한으로 인해 광고 기술에서 추가 개인 정보 보호 예산에 액세스하는 데 여러 보고 출처를 사용할 수 없습니다.

단일 기기의 경우 단일 광고 기술에서 여러 보고 출처를 사용하여 게시자 앱에 소스를 등록하려고 하는 다음 시나리오를 고려해 보세요.

  1. 광고 기술 A의 보고 출처 1이 앱 B에 소스를 등록함
  2. 12시간 후 광고 기술 A의 보고 출처 2가 앱 B에 소스를 등록하려고 시도함

광고 기술 A의 보고 출처 2의 두 번째 소스가 API에서 거부됩니다. 광고 기술 A의 보고 출처 2는 다음 날까지 앱 B에 대해 동일한 기기에 소스를 등록할 수 없습니다.

쿨다운 및 비율 제한

{소스, 대상} 쌍 간의 사용자 ID 유출 양을 제한하기 위해 API는 지정된 기간에 사용자에 대해 전송되는 정보의 총량을 제한합니다.

현재 제안은 {소스 앱, 대상 앱, 30일, 기기} 기준으로 각 광고 기술의 기여 트리거를 100개로 제한하는 것입니다.

고유한 대상 수

API는 광고 기술에서 측정을 시도할 수 있는 대상의 수를 제한합니다. 제한이 낮을수록 광고 기술이 API를 사용하여, 표시된 광고에 연결되지 않은 사용자 탐색 활동을 측정하기가 더 어렵습니다.

현재 제안은 소스 앱을 기준으로 만료되지 않은 소스가 있는 고유한 대상 100개로 각 광고 기술을 제한하는 것입니다.

이벤트 수준 보고서에 적용되는 개인 정보 보호 메커니즘

제한된 트리거 데이터 충실도

API는 조회 완료 트리거의 경우 1비트를 제공하고 클릭연결 트리거의 경우 3비트를 제공합니다. 기여 분석 소스는 64비트 메타데이터 전체를 계속 지원합니다.

이벤트 수준 보고서에서 사용할 수 있는 제한된 비트 수로 작동하도록 트리거에 표시되는 정보를 줄이는 경우와 방법을 평가해야 합니다.

개인 정보 차등 보호 노이즈 프레임워크

이 API의 목표는 k-무작위 응답을 사용하여 각 소스 이벤트의 노이즈 출력을 생성함으로써 이벤트 수준 측정이 로컬 개인 정보 차등 보호 요구사항을 충족할 수 있도록 하는 것입니다.

노이즈는 기여 분석 소스 이벤트가 사실대로 보고되는지에 적용됩니다. 기여 분석 소스는 기여 분석 소스가 정상적으로 등록될 확률 $ 1-p $, 기기가 가능한 모든 API 출력 상태(아예 아무것도 보고하지 않거나 허위 보고서 여러 개를 보고하는 것 포함) 중에서 임의로 선택할 확률 $ p $로 기기에 등록됩니다.

k-무작위 응답은 다음 방정식이 충족되는 경우 epsilon 개인 정보 차등 보호인 알고리즘입니다.

\[ p = \frac{k}{k + e^ε - 1} \]

값이 낮은 ε인 경우 k-무작위 응답 메커니즘으로 실제 출력이 보호됩니다. 정확한 노이즈 매개변수는 작업 중이며 의견에 따라 변경될 수 있고 현재는 다음과 같이 제안합니다.

  • 탐색 소스의 경우 p=0.24%
  • 이벤트 소스의 경우 p=0.00025%

사용 가능한 트리거 제한(전환)

기여 분석 소스당 트리거 수에는 제한이 있으며 현재 제안된 내용은 다음과 같습니다.

  • 광고 조회 기여 분석 소스의 트리거 1~2개(설치 후 기여 분석인 경우에만 사용할 수 있는 트리거 2개)
  • 클릭 광고 표시 소스의 경우 트리거 3개

보고서 전송을 위한 특정 기간 (기본 동작)

광고 조회 기여 분석 소스의 이벤트 수준 보고서는 소스가 만료되고 1시간 후에 전송됩니다. 이 만료일은 설정할 수 있지만 1일 이상, 30일 이하여야 합니다. 2개의 트리거가 설치 후 기여 분석을 통해 광고 조회 기여 분석 소스로 인해 발생한 경우 다음과 같이 지정된 보고 기간 간격으로 이벤트 수준 보고서를 전송할 수 있습니다.

광고 클릭 기여 분석 소스의 이벤트 수준 보고서는 구성할 수 없으며 소스가 등록된 시점을 기준으로 지정된 시점에 소스가 만료되기 전이나 만료될 때 전송됩니다. 기여 분석 소스와 만료 사이의 시간은 여러 보고 기간으로 분할됩니다. 각 보고 기간에는 기여 분석 소스 시간으로부터의 기한이 있습니다. 각 보고 기간이 끝날 때 기기는 이전 보고 기간 이후 발생한 모든 트리거를 수집하고 예약된 보고서를 보냅니다. API는 다음과 같은 보고 기간을 지원합니다.

  • 2일: 기기가 기여 분석 소스가 등록된 후 최대 2일 동안 발생한 모든 트리거를 수집합니다. 이 보고서는 기여 분석 소스가 등록되고 2일 1시간 후에 전송됩니다.
  • 7일: 기기가 기여 분석 소스가 등록된 후 2일에서 7일 이내에 발생한 모든 트리거를 수집합니다. 이 보고서는 기여 분석 소스가 등록되고 7일 1시간 후에 전송됩니다.
  • 맞춤 기간: 기여 분석 소스의 '만료' 속성으로 정의됩니다. 이 보고서는 지정된 만료 시간 1시간 후에 전송됩니다. 이 값은 1일 이상이고 30일 이하여야 합니다.

유연한 이벤트 수준 구성

이벤트 수준 보고의 기본 구성은 광고 기술이 유틸리티 테스트를 시작할 때 사용하도록 권장되는 것이지만 모든 사용 사례에 적합하지는 않을 수 있습니다. Attribution Reporting API는 보다 유연한 선택적 구성을 지원하므로 광고 기술이 이벤트 수준 보고서의 구조를 더 잘 제어하고 데이터의 유용성을 극대화할 수 있습니다.

이러한 추가 유연성은 다음 두 단계로 Attribution Reporting API에 도입됩니다.

  • 1단계: 유연한 이벤트 수준 구성의 라이트 버전
    • 이 버전은 전체 기능의 하위 집합을 제공하고 2단계와 별개로 사용할 수 있습니다.
  • 2단계: 유연한 이벤트 수준 구성의 전체 버전

1단계(라이트 버전의 유연한 이벤트 수준)는 다음과 같이 사용할 수 있습니다.

  • 보고 기간 수를 지정하여 보고서 실행 빈도 변경
  • 소스 등록당 기여 분석 수 변경
  • 위의 매개변수를 줄여 총 노이즈 양 줄이기
  • 기본값을 사용하는 대신 보고 기간 구성

2단계(전체 버전의 유연한 이벤트 수준)를 사용하여 1단계의 모든 기능과 다음 작업을 실행할 수 있습니다.

  • 보고서에서 트리거 데이터 카디널리티 변경
  • 트리거 데이터 카디널리티를 줄여 총 노이즈 양 줄이기

기본 구성의 한 측정기준을 줄이면 광고 기술이 다른 측정기준을 늘릴 수 있습니다. 또는 이벤트 수준 보고서의 총 노이즈 양을 위에서 언급한 매개변수를 실제로 줄여 감소시킬 수 있습니다.

광고 기술에서 선택한 구성에 따라 노이즈 수준을 동적으로 설정하는 것 외에도, 큰 계산 비용과 너무 많은 출력 상태가 있는 구성(노이즈가 상당히 늘어남)을 방지하기 위해 매개변수에 제한을 둡니다. 다음은 제한사항을 보여주는 예입니다. [디자인 제안서][50]에 관한 의견을 받는 것이 좋습니다.

  • 전역적으로 그리고 trigger_data당 총 보고서 최대 20개
  • trigger_data당 최대 5개의 가능한 보고 기간
  • 최대 32개의 트리거 데이터 카디널리티(1단계: 라이트 버전의 유연한 이벤트 수준에 적용되지 않음)

광고 기술에서 이 기능을 사용하기 시작하면 극값을 사용하면 상당한 노이즈가 발생하거나 개인 정보 보호 수준이 충족되지 않는 경우 등록에 실패할 수 있음에 유의하세요.

집계 가능한 보고서

집계 가능한 보고서를 사용하려면 클라우드 계정을 설정하고 집계 가능한 보고서 수신을 시작해야 합니다.

집계 가능한 보고서는 이벤트 수준 보고서에 제공되는 것보다 더 높은 충실도의 기기 트리거 데이터를 더 빠르게 제공합니다. 이러한 충실도 높은 데이터는 집계로만 알 수 있으며 특정 트리거 또는 사용자와 연결되지 않습니다. 집계 키는 최대 128비트이며 이를 통해 집계 가능한 보고서에서 다음과 같은 보고 사용 사례를 지원할 수 있습니다.

  • 수익 등의 트리거 값에 관한 보고서
  • 더 많은 트리거 유형 처리

또한 집계 가능한 보고서는 이벤트 수준 보고서와 동일한 소스 우선순위 기여 분석 로직을 사용하지만 클릭 또는 조회로 인해 발생한 추가 전환을 지원합니다.

Attribution Reporting API가 집계 가능한 보고서를 준비하고 전송하는 방식에 관한 전반적인 설계(다이어그램 참고)는 다음과 같습니다.

  1. 기기는 암호화된 집계 가능한 보고서를 광고 기술에 전송합니다. 프로덕션 환경에서는 광고 기술이 이러한 보고서를 직접 사용할 수 없습니다.
  2. 광고 기술은 집계 작업을 위해 집계 가능한 보고서 배치를 집계 서비스에 전송합니다.
  3. 집계 서비스는 집계 가능한 보고서 배치를 읽고 복호화하여 집계합니다.
  4. 최종 집계는 요약 보고서를 통해 광고 기술로 다시 전송됩니다.
Attribution Reporting API가 집계 가능한 보고서를 준비하고 전송하는 데 사용하는 프로세스입니다.

집계 가능한 보고서에는 기여 분석 소스와 관련된 다음 데이터가 포함됩니다.

  • 대상: 트리거가 발생한 앱의 패키지 이름 또는 eTLD+1 웹 URL입니다.
  • 날짜: 기여 분석 소스로 표현되는 이벤트가 발생한 날짜입니다.
  • 페이로드: 암호화된 키-값 쌍으로 수집되는 트리거 값으로, 신뢰할 수 있는 집계 서비스에서 집계를 계산하는 데 사용됩니다.

집계 서비스

다음 서비스는 데이터 집계 기능을 제공하고 집계된 데이터에 대한 무단 액세스를 방지합니다.

이러한 서비스는 여러 당사자가 관리하며 이에 관한 내용은 이 페이지의 뒷부분에서 자세히 설명합니다.

  • 집계 서비스는 광고 기술이 배포할 것으로 예상되는 유일한 서비스입니다.
  • 키 관리 및 집계 가능한 보고서 회계 서비스는 코디네이터라고 하는 신뢰할 수 있는 당사자가 실행합니다. 이러한 코디네이터는 집계 서비스를 실행하는 코드가 Google에서 제공하는 공개적으로 사용할 수 있는 코드이고 모든 집계 서비스 사용자에게 동일한 키 및 집계 가능한 보고서 회계 서비스가 적용되었음을 증명합니다.
집계 서비스

광고 기술 플랫폼은 Google에서 제공하는 바이너리를 기반으로 하는 집계 서비스를 사전에 배포해야 합니다.

이 집계 서비스는 클라우드에서 호스팅되는 신뢰할 수 있는 실행 환경(TEE)에서 작동합니다. TEE는 다음과 같은 보안 이점을 제공합니다.

  • TEE에서 작동하는 코드가 Google에서 제공하는 특정 바이너리임을 보장합니다. 이 조건이 충족되지 않으면 집계 서비스는 작동에 필요한 복호화 키에 액세스할 수 없습니다.
  • 외부 모니터링 또는 조작으로부터 격리하여 실행 중인 프로세스 주변에 보안을 제공합니다.

이러한 보안 이점을 통해 집계 서비스는 암호화된 데이터에 액세스하는 것과 같은 민감한 작업을 더 안전하게 실행할 수 있습니다.

집계 서비스의 설계, 워크플로, 보안 고려사항에 관한 자세한 내용은 GitHub의 집계 서비스 문서를 참고하세요.

키 관리 서비스

이 서비스는 집계 서비스가 승인된 바이너리 버전을 실행 중인지 확인하고 광고 기술의 집계 서비스에 트리거 데이터에 관한 올바른 복호화 키를 제공합니다.

집계 가능한 보고서 회계

이 서비스는 광고 기술의 집계 서비스가 특정 트리거(여러 집계 키를 포함할 수 있음)에 액세스하는 빈도를 추적하고 액세스를 적절한 복호화 수로 제한합니다. 자세한 내용은 Attribution Reporting API용 집계 서비스 설계 제안서를 참고하세요.

Aggregatable Reports API

집계 가능한 보고서에 기여하기 위한 이 API는 이벤트 수준 보고서의 기여 분석 소스를 등록할 때와 동일한 기본 API를 사용합니다. 다음 섹션에서는 이 API의 확장 프로그램을 설명합니다.

집계 가능한 소스 데이터 등록

API가 기여 분석 소스 URI에 요청하면 광고 기술은 HTTP 헤더 Attribution-Reporting-Register-Source에서 새 필드 aggregation_keys의 키를 key_name으로, 값을 key_piece로 설정하여 이름이 histogram_contributions인 집계 키 목록을 등록할 수 있습니다.

  • (키) 키 이름: 키 이름 문자열입니다. 트리거 측 키와 결합하여 최종 키를 구성하는 조인 키로 사용됩니다.
  • (값) 키 조각: 키의 비트 문자열 값입니다.

최종 히스토그램 버킷 키는 트리거 시 이러한 조각과 트리거 측 조각에 바이너리 OR 연산을 실행하여 완전히 정의됩니다.

최종 키는 최대 128비트로 제한됩니다. 이보다 긴 키는 잘립니다. 즉, JSON의 16진수 문자열은 최대 32자리로 제한되어야 합니다.

집계 키의 구조화 방식과 집계 키를 구성하는 방법에 관해 자세히 알아보세요.

다음 예에서 광고 기술은 API를 사용하여 다음 항목을 수집합니다.

  • 캠페인 수준에서 전환수 집계
  • 지역 수준에서 구매 가치 집계
// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

집계 가능한 트리거 등록

트리거 등록에는 필드 두 개가 추가로 포함됩니다.

첫 번째 필드는 트리거 측에 집계 키 목록을 등록하는 데 사용됩니다. 광고 기술은 HTTP 헤더 Attribution-Reporting-Register-Trigger의 aggregatable_trigger_data 필드로 응답하고 목록의 각 집계 키에 맞게 다음 필드를 포함해야 합니다.

  • 키 조각: 키의 비트 문자열 값입니다.
  • 소스 키: 최종 키를 구성하기 위해 트리거 키를 결합해야 하는 기여 분석 소스 측 키의 이름이 포함된 문자열 목록입니다.

두 번째 필드는 각 키에 기여해야 하는 값 목록을 등록하는 데 사용됩니다. 광고 기술은 HTTP 헤더 Attribution-Reporting-Register-Trigger의 aggregatable_values 필드로 응답해야 합니다. 두 번째 필드는 각 키에 기여해야 하는 값 목록을 등록하는 데 사용되며, 키는 $ [1, 2^{16}] $ 범위의 정수일 수 있습니다.

각 트리거는 집계 가능한 보고서에 여러 번 기여할 수 있습니다. 주어진 소스 이벤트에 대한 총 기여 금액은 $ L1 $ 매개변수로 제한됩니다. 이는 주어진 소스의 모든 집계 키에서 기여(값)의 최대 합계입니다. $ L1 $는 소스 이벤트별 히스토그램 기여의 L1 민감도 또는 표준을 나타냅니다. 이러한 제한을 초과하면 향후 기여가 자동으로 중단됩니다. 초기 제안은 $ L1 $를 $ 2^{16} $ (65536)으로 설정하는 것입니다.

집계 서비스의 노이즈는 이 매개변수에 따라 조정됩니다. 따라서 할당된 $ L1 $ 예산 부분에 따라, 지정된 집계 키에 관해 보고된 값을 적절하게 조정하는 것이 좋습니다. 이 접근 방식을 사용하면 노이즈가 적용될 때 집계 보고서가 최대한 높은 충실도를 유지할 수 있습니다. 이 메커니즘은 매우 유연하며 여러 집계 전략을 지원할 수 있습니다.

다음 예에서는 개인 정보 보호 예산이 각각 $ L1 $ 기여를 분할하여 campaignCounts 및 geoValue 간에 똑같이 분할됩니다.

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

앞의 예에서는 다음과 같은 히스토그램 기여를 생성합니다.

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

배율은 올바른 값과 적용된 모듈로 노이즈를 얻기 위해 반전될 수 있습니다.

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

개인 정보 차등 보호

이 API의 목표는 개인 정보 차등 보호 집계 측정을 지원할 수 있는 프레임워크를 보유하는 것입니다. 다음과 같은 분포로 노이즈를 선택하는 것과 같이 $ L1 $ 예산에 비례하는 노이즈를 추가하면 됩니다.

\[ Laplace(\frac{L1}{ε}) \]

Protected Audience API 및 Attribution Reporting API 통합

Protected Audience와 Attribution Reporting API가 교차 API 통합되면 광고 기술은 다양한 리마케팅 전략에서 기여 분석 실적을 평가하여 가장 높은 ROI를 제공하는 잠재고객 유형을 파악할 수 있습니다.

이러한 교차 API 통합을 통해 광고 기술에서는 다음을 수행할 수 있습니다.

  • 1) 상호작용 보고 및 2) 소스 등록에 둘 다 사용할 수 있는 URI의 키-값 맵을 만듭니다.
  • Attribution Reporting API를 사용하여 집계 요약 보고를 위해 소스 측 키 매핑에 CustomAudience를 포함합니다.

사용자가 광고를 보거나 클릭할 때:

  • Protected Audience를 사용하여 이러한 상호작용을 보고하는 데 사용되는 URL은 Attribution Reporting API에 조회 또는 클릭을 대상 소스로 등록하는 데도 사용됩니다.
  • 광고 기술에서는 해당 URL을 사용하여 CustomAudience(또는 광고 게재위치 또는 시청 지속 시간과 같은 광고에 관한 기타 관련 문맥 정보)를 전달하도록 선택할 수 있습니다. 그러면 광고 기술에서 전체 캠페인 실적을 검토할 때 이 메타데이터를 요약 보고서로 전파할 수 있습니다.

Protected Audience 내에서의 사용 설정 방법에 관한 자세한 내용은 Protected Audience API 설명의 관련 섹션을 참고하세요.

등록 우선순위, 기여 분석, 보고 예

이 예에서는 사용자 상호작용 집합과 함께, 광고 기술이 정의된 기여 분석 소스와 트리거 우선순위가 기여 보고서에 어떤 영향을 줄 수 있는지 보여줍니다. 이 예에서는 다음을 가정합니다.

  • 모든 기여 분석 소스 및 트리거는 동일한 광고주를 위해 동일한 광고 기술을 통해 등록됩니다.
  • 모든 기여 분석 소스 및 트리거는 첫 번째 이벤트 보고 기간(게시자 앱에 광고를 처음 표시한 후 2일 이내)에 발생합니다.

사용자의 다음 상황을 고려합니다.

  1. 사용자가 광고를 볼 때. 광고 기술은 API를 통해 기여 분석 소스를 우선순위 0으로 등록합니다(조회 1).
  2. 사용자가 우선순위가 0으로 등록된 광고를 볼 때(조회 2)
  3. 사용자가 우선순위 1인 광고를 클릭할 때(클릭 1)
  4. 사용자가 광고주 앱에서 전환(방문 페이지에 도달)될 때. 이 광고 기술은 API를 통해 우선순위 0(전환 1)으로 트리거를 등록합니다.
    • 트리거가 등록되면 API는 보고서를 생성하기 전에 먼저 기여 분석을 실행합니다.
    • 조회 1, 조회 2, 클릭 1의 세 가지 기여 분석 소스를 사용할 수 있습니다. 클릭 1이 우선순위가 가장 높고 최근이므로 API는 이 트리거를 클릭 1에 기인한다고 간주합니다.
    • 조회 1과 조회 2는 삭제되며 더 이상 기여 분석에 사용할 수 없습니다.
  5. 사용자가 우선순위 1로 등록된 광고주 앱의 장바구니에 항목을 추가할 때(전환 2)
    • 클릭 1만 유일하게 사용 가능한 기여 분석 소스입니다. API는 이 트리거를 클릭 1에 기인한다고 간주합니다.
  6. 사용자가 우선순위 1로 등록된 광고주 앱의 장바구니에 항목을 추가할 때(전환 3)
    • 클릭 1만 유일하게 사용 가능한 기여 분석 소스입니다. API는 이 트리거를 클릭 1에 기인한다고 간주합니다.
  7. 사용자가 우선순위 1로 등록된 광고주 앱의 장바구니에 항목을 추가할 때(전환 4)
    • 클릭 1만 유일하게 사용 가능한 기여 분석 소스입니다. API는 이 트리거를 클릭 1에 기인한다고 간주합니다.
  8. 사용자가 우선순위가 2인 광고주 앱에서 구매할 때(전환 5)
    • 클릭 1만 유일하게 사용 가능한 기여 분석 소스입니다. API는 이 트리거를 클릭 1에 기인한다고 간주합니다.

이벤트 수준 보고서에는 다음과 같은 특징이 있습니다.

  • 기본적으로 클릭에 기여한 처음 3개의 트리거와 조회에 기여한 첫 번째 트리거는 관련 보고 기간 후에 전송됩니다.
  • 보고 기간 내에 더 높은 우선순위로 등록된 트리거가 있는 경우 그러한 트리거가 우선하며 가장 최근의 트리거를 대체합니다.
  • 위의 예에서 광고 기술은 2일간의 보고 기간 후에 전환 2, 전환 3, 전환 5에 관한 이벤트 보고서 3개를 수신합니다.
    • 5개의 트리거가 모두 클릭 1에 기인합니다. 기본적으로 API는 처음 3개 트리거 즉, 전환 1, 전환 2, 전환 3에 관한 보고서를 전송합니다.
    • 그러나 전환 4의 우선순위(1)가 전환 1의 우선순위(0)보다 높습니다. 전환 4의 이벤트 보고서가 전송될 전환 1의 이벤트 보고서를 대체합니다.
    • 또한 전환 5의 우선순위(2)가 다른 모든 트리거보다 높습니다. 전환 5의 이벤트 보고서가 전송될 전환 4의 보고서를 대체합니다.

집계 가능한 보고서에는 다음과 같은 특성이 있습니다.

  • 트리거가 등록되고 몇 시간 후, 암호화된 집계 가능한 보고서가 처리되는 즉시 광고 기술 플랫폼으로 전송됩니다.

    광고 기술은 집계 가능한 보고서에 암호화되지 않은 정보를 기반으로 배치를 만듭니다. 그 정보는 집계 가능한 보고서의 shared_info 필드에 포함되어 있으며 타임스탬프와 보고 출처를 포함합니다. 집계 키-값 쌍의 암호화된 정보를 기반으로 일괄 처리를 실행할 수는 없습니다. 가능한 간단한 전략은 보고서를 매일 또는 매주 일괄 처리하는 방법입니다. 배치에 각각 100개 이상의 보고서를 포함하는 것이 이상적입니다.

  • 집계 가능한 보고서를 일괄 처리하고 집계 서비스로 전송하는 시기와 방법은 광고 기술에 따라 다릅니다.

  • 이벤트 수준 보고서와 비교할 때 암호화된 집계 가능 보고서는 소스 하나에 더 많은 트리거를 연결할 수 있습니다.

  • 위의 예에서는 등록된 트리거별로 하나씩, 총 5개의 집계 가능한 보고서가 전송됩니다.

전환 디버깅 보고서

Attribution Reporting API는 교차 앱 식별자 없이 기여 분석을 측정하는 매우 복잡하고 새로운 방법입니다. 따라서 Google에서는 기여도 보고서에 대해 자세히 알아볼 수 있도록 광고 ID를 사용할 수 있는 경우(사용자가 광고 ID를 사용하여 맞춤설정을 선택 해제하지 않았고 게시자 또는 광고주 앱이 광고 ID 권한을 선언한 경우) 전환 메커니즘을 지원하고 있습니다. 이렇게 하면 출시 기간 동안 API를 완전히 이해할 수 있고 버그를 제거하는 데 도움이 되며 실적을 광고 ID 기반 대안과 더 쉽게 비교할 수 있습니다. 디버깅 보고서에는 기여 분석 성공 보고서와 상세 보고서, 두 가지 유형이 있습니다.

앱에서 웹으로의 측정과 웹에서 앱으로의 측정을 사용한 디버깅 보고서에 관해 자세히 알아보려면 전환 디버깅 보고서 가이드를 참고하세요.

기여 분석 성공 디버깅 보고서

소스 및 트리거 등록은 모두 광고 기술이 채우는 새로운 64비트 debug_key 필드(문자열 형식)를 허용합니다. source_debug_key 및 trigger_debug_key는 이벤트 수준 보고서와 집계 보고서에서 모두 변경되지 않고 전달됩니다.

보고서가 소스 디버그 키와 트리거 디버그 키를 모두 사용하여 생성되면 중복 디버그 보고서가 제한된 지연으로 .well-known/attribution-reporting/debug/report-event-attribution 엔드포인트에 전송됩니다. 디버그 보고서는 두 디버그 키 필드를 모두 포함하는 일반 보고서와 동일합니다. 이러한 키를 두 필드에 모두 포함하면 일반 보고서를 별도의 디버그 보고서 스트림에 연결할 수 있습니다.

  • 이벤트 수준 보고서의 경우:
    • 중복 디버그 보고서는 제한된 지연을 사용하여 전송되므로 사용 가능한 트리거의 제한으로 인해 억제되지 않습니다. 따라서 광고 기술에서 이러한 이벤트 수준 보고서 제한의 영향을 파악할 수 있습니다.
    • 거짓 트리거 이벤트와 연결된 이벤트 수준 보고서에는 trigger_debug_key가 없습니다. 이를 통해 광고 기술에서 API에 노이즈가 적용되는 방식을 더 잘 파악할 수 있습니다.
  • 집계 가능한 보고서의 경우:
    • source_debug_key 및 trigger_debug_key가 모두 설정된 경우에만 복호화된 페이로드가 포함된 새 debug_cleartext_payload 필드를 지원합니다.

상세 디버깅 보고서

상세 디버깅 보고서를 통해 개발자는 기여 분석 소스의 특정 실패를 모니터링하거나 등록을 트리거할 수 있습니다. 이러한 디버깅 보고서는 기여 분석 소스 또는 well-known/attribution-reporting/debug/verbose 엔드포인트에 트리거 등록 후 제한된 지연으로 전송됩니다.

각 상세 보고서에는 다음 필드가 포함됩니다.

  • 유형: 보고서가 생성된 이유입니다. 상세 보고서 유형의 전체 목록을 참고하세요.
    • 일반적으로 소스 상세 보고서와 트리거 상세 보고서가 있습니다.
    • 소스 상세 보고서를 사용하려면 게시자 앱에서 사용할 수 있는 광고 ID가 있어야 하고, 트리거 상세 보고서를 사용하려면 광고주 앱에서 사용할 수 있는 광고 ID가 있어야 합니다.
    • 트리거 상세 보고서(trigger-no-matching-source 제외)에는 선택적으로 source_debug_key가 포함될 수 있습니다. 이는 광고 ID가 게시자 앱에도 제공되는 경우에만 포함될 수 있습니다.
  • 본문: 보고서 본문이며 유형에 따라 다릅니다.

광고 기술은 Attribution-Reporting-Register_Source 및 Attribution-Reporting-Register-Trigger 헤더의 새로운 debug_reporting 사전 필드를 통해 상세 디버깅 보고서를 수신하도록 선택해야 합니다.

  • 소스 상세 보고서는 소스 등록 헤더만 선택해야 합니다.
  • 트리거 디버그 보고서는 트리거 등록 헤더에서만 선택해야 합니다.

디버그 보고서 사용 방법

기존 측정 시스템에 따라 전환이 발생하고 해당 전환의 디버그 보고서가 수신되었다면 트리거가 성공적으로 등록되었음을 의미합니다.

각 디버그 기여도 보고서의 경우 두 디버그 키와 일치하는 일반 기여 분석 보고서가 수신되는지 확인합니다.

일치하는 항목이 없으면 여러 이유가 있을 수 있습니다.

의도대로 작동:

  • 개인 정보 보호 API 동작:
    • 사용자가 보고서 비율 제한에 도달하여 모든 후속 보고서가 해당 기간에 전송되지 않습니다. 또는 대기 중인 대상 제한으로 인해 소스가 삭제됩니다.
    • 이벤트 수준 보고서의 경우: 보고서에 무작위 응답(노이즈)이 적용되어 억제되거나 무작위 보고서가 수신될 수 있습니다.
    • 이벤트 수준 보고서의 경우: 보고서가 클릭의 경우 3개 또는 조회의 경우 1개 제한에 도달했으며 후속 보고서에 명시적 우선순위가 설정되어 있지 않거나 기존 보고서보다 낮은 우선순위가 있습니다.
    • 집계 가능한 보고서의 기여 제한을 초과했습니다.
  • 광고 기술에서 정의한 비즈니스 로직:
    • 트리거는 필터 또는 우선순위 규칙을 통해 필터링됩니다.
  • 시간 지연 또는 네트워크 가용성과의 상호작용(예: 사용자가 오랜 시간 기기를 끔)

의도하지 않은 원인:

  • 구현 문제:
    • 소스 헤더가 잘못 구성됨
    • 트리거 헤더가 잘못 구성됨
    • 기타 구성 문제
  • 기기 또는 네트워크 문제:
    • 네트워크 조건으로 인한 실패
    • 소스 또는 트리거 등록 응답이 클라이언트에 도달하지 않음
    • API 버그

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

Attribution Reporting API는 개발 중인 API입니다. 마지막 클릭 이외의 기여 분석 모델 및 교차 기기 측정 사용 사례와 같은 향후 사용 가능한 기능도 살펴보고 있습니다.

또한 다음과 같은 몇 가지 문제에 관한 커뮤니티의 의견을 듣고자 합니다.

  1. 확인된 설치에 관한 보고서를 API가 전송해야 하는 사용 사례가 있나요? 이러한 보고서는 광고 기술 플랫폼의 해당 비율 제한에 포함됩니다.
  2. 소스 등록을 위해 InputEvent를 앱에서 광고 기술로 전달하는 데 어려움이 예상되나요?
  3. 미리 로드된 앱이나 다시 설치된 앱에 특수한 기여 분석 사용 사례가 있나요?