Attribution Reporting의 집계 키 이해

집계 키의 정의, Attribution Reporting API에서의 사용 방법, 목표를 키로 변환하는 방법

다양한 제품 카테고리에 대해 여러 지역에서 캠페인을 운영하는 광고 기술 회사로서 광고주가 다음 질문에 답할 수 있도록 지원하고자 합니다.

1. 각 지역의 각 캠페인에서 각 제품 카테고리의 구매가 얼마나 발생했나요?
2. 각 지역의 각 캠페인에서 각 제품 카테고리에 대해 발생한 수익은 얼마인가요?

많은 광고 기술 회사에서 광고주에게 다양한 전환 유형을 구성하도록 권장하지만, 구매와 같은 가장 중요한 전환에 집중하면 이러한 중요한 이벤트에 대한 요약 결과가 상세하고 정확한지 확인할 수 있습니다.

이를 위해서는 데이터를 수집하기 전에 어떤 질문에 답하고 싶은지 생각해 봐야 합니다.

측정기준, 키, 값

이러한 질문에 답하기 위해 측정기준, 키, 값을 살펴보겠습니다.

크기

캠페인에서 수익을 창출하는 방식을 파악하려면 여기에 설명된 대로 다음 측정기준을 추적해야 합니다.

• 광고 캠페인 ID: 특정 캠페인의 식별자입니다.
• 지역 ID: 광고가 게재된 지역입니다.
• 제품 카테고리: 정의한 제품 유형입니다.

캠페인 ID와 지역 ID 측정기준은 광고가 게재될 때 (광고 게재 시간) 알 수 있지만, 제품 카테고리는 사용자가 전환을 완료할 때 (전환 시간) 트리거 이벤트에서 알 수 있습니다.

이 예에서 추적할 측정기준은 다음 이미지와 같습니다.

집계 키 (버킷)란 무엇인가요?

집계 키와 버킷은 동일한 것을 의미합니다. 집계 키는 보고서를 구성하는 데 사용되는 브라우저 API에서 사용됩니다. 버킷이라는 용어는 집계 가능 보고서와 요약 보고서, 집계 서비스 API에서 사용됩니다.

집계 키 (줄여서 키)는 추적되는 측정기준의 값을 나타내는 데이터 조각입니다. 데이터는 나중에 각 집계 키를 따라 집계됩니다.

예를 들어 제품 카테고리, 지역 ID, 캠페인 ID 측정기준을 추적한다고 가정해 보겠습니다.

지역 ID 7에 있는 사용자가 캠페인 ID 12의 광고를 보고 나중에 제품 카테고리 25에서 제품을 구매하여 전환하는 경우 다음 이미지와 같은 집계 키를 설정할 수 있습니다.

실제로 집계 키는 이와 정확히 같지 않지만 지금은 키에 포함된 정보에 집중해 보겠습니다.

집계 가능한 값이란 무엇인가요?

앞서 설명한 측정기준에 대한 질문에 답하려면 다음 사항을 알아야 합니다.

• 구매 수입니다 (구매 횟수). 집계되어 요약 보고서에서 사용할 수 있게 되면 총 구매 횟수 (요약 값)가 됩니다.
• 각 구매의 수익 (구매 가치)입니다. 집계되어 요약 보고서에서 사용할 수 있게 되면 총수입 (요약 값)이 됩니다.

각각의 값(1회 전환의 구매 수와 1회 전환의 구매 가치)은 집계 가능한 값입니다. 집계 가능한 값은 측정 목표의 값으로 생각할 수 있습니다.

지리 ID 7에 있는 사용자가 캠페인 ID 12의 광고를 보고 나중에 제품 카테고리 25의 제품을 120달러에 구매하여 전환하는 경우 (통화가 미국 달러라고 가정) 다음과 같은 집계 키와 집계 가능한 값을 설정할 수 있습니다.

집계 가능한 값은 여러 사용자에 걸쳐 키별로 합산되어 요약 보고서의 요약 값 형태로 집계된 통계를 생성합니다.

집계 가능한 값은 합산되어 측정 목표에 대한 집계된 통계를 생성합니다.

이 다이어그램에서는 복호화를 생략하고 노이즈가 적용되지 않은 단순화된 예를 나타냅니다. 다음 섹션에서는 노이즈가 있는 이 예시를 간략하게 설명합니다.

키 및 값에서 보고서까지

이제 집계 가능한 키와 값이 보고서와 어떤 관련이 있는지 알아보겠습니다.

집계 가능한 보고서

사용자가 광고를 클릭하거나 조회한 후 나중에 전환하면 브라우저에 {집계 키, 집계 가능 값} 쌍을 저장하도록 지시합니다.

이 예에서 사용자가 광고를 클릭하거나 조회한 후 나중에 전환하면 브라우저에 측정 목표당 기여도 하나씩 두 개를 생성하도록 지시합니다.

나중에 {집계 키, 집계 가능한 값} 집계 가능 보고서가 이와 정확히 같지 않다는 것을 알게 될 것입니다. 하지만 지금은 보고서에 포함된 정보에 집중해 보겠습니다.

브라우저에 기여도 2개를 생성하도록 지시하면 브라우저가 집계 가능한 보고서를 생성합니다 (이전 조회 또는 클릭과 전환을 매칭할 수 있는 경우).

집계 가능한 보고서에는 다음이 포함됩니다.

• 구성한 기여입니다.
• 클릭 또는 조회 이벤트 및 전환 이벤트에 관한 메타데이터: 전환이 발생한 사이트 등 집계 가능한 보고서의 모든 필드를 확인하세요.

집계 가능한 보고서는 JSON 형식이며 최종 요약 보고서의 데이터 입력으로 사용될 페이로드 필드가 포함됩니다.

페이로드에는 기여 목록이 포함되며 각 기여는 {집계 키, 집계 가능 값} 쌍입니다.

• bucket: 바이트 문자열로 인코딩된 집계 키입니다.
• value: 해당 측정 목표의 집계 가능한 값으로, 바이트 문자열로 인코딩됩니다.

예를 들면 다음과 같습니다.

{
  "data": [
    {
      "bucket": "111001001",
      "value": "11111010000",
    }
  ],
  "operation": "histogram"
}

실제로 집계 가능한 보고서는 버킷과 값이 이전 예시와 다르게 보이도록 인코딩됩니다 (즉, 버킷이 \u0000\u0000\x80\u0000처럼 보일 수 있음). 버킷과 값은 모두 바이트 문자열입니다.

요약 보고서

집계 가능한 보고서는 다음과 같이 여러 브라우저와 기기 (사용자)에 걸쳐 집계됩니다.

• 광고 기술은 지정된 키 집합과 여러 다른 브라우저 (사용자)에서 제공되는 지정된 집계 가능 보고서 집합에 대한 요약 보고서를 요청합니다.
• 집계 가능한 보고서는 집계 서비스에 의해 복호화됩니다.
• 각 키에 대해 집계 가능한 보고서의 집계 가능한 값이 합산됩니다.
• 요약 값에 노이즈가 추가됩니다.

결과는 {집계 키, 요약 값} 쌍의 집합이 포함된 요약 보고서입니다.

요약 보고서에는 JSON 딕셔너리 스타일의 키-값 쌍 집합이 포함됩니다. 각 쌍에는 다음이 포함됩니다.

• bucket: 바이트 문자열로 인코딩된 집계 키입니다.
• value: 사용 가능한 모든 집계 가능 보고서에서 합산되고 노이즈 수준이 추가된 특정 측정 목표의 10진수 요약 값입니다.

예:

[
  {"bucket": "111001001", "value": "2558500"},
  {"bucket": "111101001", "value": "3256211"},
  {...}
]

실제로 요약 보고서는 버킷과 값이 예시에 명시된 것과 다르게 보이도록 인코딩됩니다 (즉, 버킷이 \u0000\u0000\x80\u0000처럼 보일 수 있음). 버킷과 값은 모두 바이트 문자열입니다.

실제 집계 키

집계 키 (버킷)는 일반적으로 광고 기술 회사에서 두 단계로 정의합니다. 광고를 클릭하거나 조회할 때와 사용자가 전환할 때입니다.

키 구조

키로 인코딩된 측정기준 집합을 지정하기 위해 키 구조라는 용어를 사용합니다.

예를 들어 캠페인 ID × 지역 ID × 제품 카테고리가 핵심 구조입니다.

키 유형

집계 가능한 값은 여러 사용자/브라우저에서 지정된 키에 대해 합산됩니다. 하지만 집계 가능한 값은 구매 가치나 구매 수와 같은 다양한 측정 목표를 추적할 수 있습니다. 집계 서비스가 동일한 유형의 집계 가능한 값을 합산하는지 확인하려고 합니다.

이렇게 하려면 각 키 내에서 요약 값이 나타내는 내용(이 키가 참조하는 측정 목표)을 알려주는 데이터를 인코딩합니다. 이를 수행하는 한 가지 방법은 측정 목표 유형을 나타내는 키에 대한 추가 측정기준을 만드는 것입니다.

앞의 예시를 사용하면 이 측정 목표 유형에는 다음과 같은 두 가지 가능한 값이 있습니다.

• 구매 수는 첫 번째 유형의 측정 목표입니다.
• 구매 가치는 두 번째 유형의 측정 목표입니다.

측정 목표가 n개인 경우 측정 목표 유형에는 n개의 서로 다른 값 유형이 있습니다.

키의 측정기준을 측정항목으로 생각할 수 있습니다. 예를 들어 '지역별 캠페인당 특정 제품의 구매 수'를 확인할 수 있습니다.

키 크기, 측정기준 크기

최대 키 크기는 비트로 정의됩니다. 이는 전체 키를 만들기 위한 이진수의 0과 1의 개수입니다. API는 128비트의 키 길이를 허용합니다.

이 크기를 사용하면 매우 세분화된 키를 사용할 수 있지만, 세분화된 키는 노이즈가 많은 값으로 이어질 가능성이 높습니다. 노이즈 이해하기에서 노이즈에 대해 자세히 알아볼 수 있습니다.

앞서 소개한 것처럼 측정기준은 집계 키로 인코딩됩니다. 각 측정기준에는 특정 카디널리티(측정기준이 가질 수 있는 고유 값의 수)가 있습니다. 카디널리티에 따라 각 측정기준은 특정 비트 수로 표현되어야 합니다. n비트를 사용하면 2ⁿ개의 고유한 옵션을 표현할 수 있습니다.

예를 들어 전 세계에 약 200개의 국가가 있으므로 국가 측정기준의 카디널리티는 200일 수 있습니다. 이 차원을 인코딩하는 데 필요한 비트 수는 몇 개인가요?

7비트로는 필요한 200개보다 적은 2⁷ = 128개의 고유 옵션만 저장할 수 있습니다.

8비트는 필요한 200개보다 많은 2⁸ = 256개의 고유한 옵션을 저장하므로 n=8비트를 사용하여 이 차원을 인코딩할 수 있습니다.

키 인코딩

브라우저에서 키를 설정할 때는 16진수로 인코딩해야 합니다. 요약 보고서에서 키는 바이너리로 표시되며 버킷이라고 명명됩니다.

전체 키의 두 키 조각 설정

키를 사용하여 다음 측정기준을 추적한다고 가정해 보겠습니다.

• 캠페인 ID
• 지역 ID
• 제품 카테고리

캠페인 ID 및 지역 ID 측정기준은 광고가 게재될 때 (광고 게재 시간) 알 수 있지만, 제품 카테고리는 사용자가 전환을 완료할 때 (전환 시간) 트리거 이벤트에서 알 수 있습니다.

실제로 이는 다음 두 단계로 키를 설정한다는 의미입니다.

1. 클릭 또는 조회 시 키의 한 부분(캠페인 ID × 지역 ID)을 설정합니다.
2. 키의 두 번째 부분인 제품 카테고리는 전환 시간에 설정합니다.

키의 이러한 여러 부분을 키 조각이라고 합니다.

키는 키 조각의 OR (v)을 취하여 계산됩니다.

예:

• 소스 측 키 부분 = 0x159
• 트리거 측 키 조각 = 0x400
• 키 = 0x159 v 0x400 = 0x559

핵심 요소 정렬

신중하게 배치된 64비트 필러 또는 오프셋 (16개의 0)을 사용하여 128비트로 확장된 두 개의 64비트 키 조각을 사용하면 키 조각을 OR 연산하는 것은 이를 연결하는 것과 동일하며, 이는 추론하고 확인하기가 더 쉽습니다.

• 소스 측 키 부분 = 0xa7e297e7c8c8d0540000000000000000
• 트리거 측 키 조각 = 0x0000000000000000674fbe308a597271
• 키 = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

광고 클릭 또는 조회당 여러 키

실제로 기여 분석 소스 이벤트 (광고 클릭 또는 조회)당 여러 키를 설정할 수 있습니다. 예를 들어 다음과 같이 설정할 수 있습니다.

• 지역 ID × 캠페인 ID를 추적하는 키입니다.
• 광고 소재 유형 × 캠페인 ID를 추적하는 또 다른 키입니다.

다른 예시는 전략 B를 참고하세요.

측정기준을 키로 인코딩

요약 보고서를 요청할 때는 특정 집계 키 세트에 대한 요약 보고서를 요청하여 액세스하려는 측정항목을 집계 서비스에 알려야 합니다.

요약 보고서에는 원시 {키, 요약 값} 쌍이 포함되며 키에 관한 추가 정보는 없습니다. 다시 말하면 다음과 같습니다.

• 사용자가 광고를 보고 클릭한 후 나중에 전환할 때 키를 설정하는 경우, 키가 나타내는 측정기준의 값을 기반으로 키를 안정적으로 설정해야 합니다.
• 요약 보고서를 요청할 키를 정의할 때는 집계된 데이터를 확인할 측정기준의 값을 기반으로 사용자가 광고를 보고 클릭하고 전환했을 때 설정된 키와 동일한 키를 즉시 안정적으로 생성하거나 액세스해야 합니다.

키 구조 맵을 사용하여 측정기준 인코딩

측정기준을 키로 인코딩하려면 광고 게재 시간 전에 키를 정의할 때 미리 키 구조 맵을 만들고 유지하면 됩니다.

키 구조 맵은 각 측정기준과 키에서의 위치를 나타냅니다.

실제로 키 구조 맵을 만들고 유지관리하려면 디코더 로직을 구현하고 유지관리해야 합니다. 이 작업을 수행하지 않아도 되는 방법을 찾고 있다면 해시 기반 접근 방식을 대신 사용하는 것이 좋습니다.

예를 들면 다음과 같습니다.

특정 캠페인, 지역, 제품의 구매수와 구매 금액을 모두 추적한다고 가정해 보겠습니다.

제품 카테고리, 지역 ID, 캠페인 ID는 키의 측정기준이어야 합니다. 또한 구매 수와 구매 금액이라는 두 가지 측정 목표를 추적해야 하므로 키 유형을 추적하는 측정기준을 키 내에 추가해야 합니다. 이렇게 하면 요약 보고서에서 {키, 집계 가능한 값} 쌍을 수신할 때 집계 가능한 값이 실제로 무엇을 나타내는지 정의할 수 있습니다.

이러한 측정 목표를 사용하면 키의 크기는 다음과 같습니다.

• 제품 카테고리
• 측정 목표 유형
• 지역 ID
• 캠페인 ID

이제 각 측정기준을 살펴보겠습니다. 사용 사례에서 다음을 추적해야 한다고 가정해 보겠습니다.

• 29개의 다양한 제품 카테고리
• 8개의 지리적 지역: 북미, 중앙아메리카, 남아메리카, 유럽, 아프리카, 아시아, 카리브해, 오세아니아
• 16개의 서로 다른 캠페인

키에서 각 차원을 인코딩하는 데 필요한 비트 수는 다음과 같습니다.

• 제품 카테고리: 5비트 (2⁵ = 32 > 29)
• 측정 목표 유형: 1비트 측정 목표는 구매 수 또는 구매 금액이므로 두 가지 가능성이 있습니다. 따라서 1비트만으로 이를 저장할 수 있습니다.

• 지역 ID: 3비트 (2³ = 8). 각 바이너리 값이 나타내는 지리적 지역을 알기 위해 지리 ID의 측정기준 맵도 정의합니다. 지역 ID 측정기준의 측정기준 맵은 다음과 같을 수 있습니다.

  키의 바이너리 값	지역
  000	북미
  001	중미
  010	남아메리카
  011	유럽
  100	아프리카
  101	아시아
  110	카리브해
  111	오세아니아

• 캠페인 ID: 4비트 (2⁴ = 16)

이 구조를 따르는 키는 13비트 길이 (5 + 1 + 3 + 4)입니다.

이 예시에서 이러한 키의 키 구조 맵은 다음과 같습니다.

키 내 측정기준의 순서는 사용자가 정할 수 있습니다.

측정기준이 주요 구조를 구성하는 방식을 설명하기 위해 이진 표현을 사용합니다. 따라서 캠페인 ID (첫 번째 비트)가 가장 오른쪽에 있고 제품 카테고리 (마지막 비트)가 가장 왼쪽에 있습니다.

각 차원 내에서 가장 큰 수치를 갖는 최상위 비트는 가장 왼쪽에 있는 비트입니다. 가장 작은 숫자 값을 전달하는 최하위 비트는 가장 오른쪽에 있는 비트입니다.

키 구조 맵을 사용하여 키를 디코딩하는 방법을 살펴보겠습니다.

임의의 예 키로 0b1100100111100을 사용하고 이 키가 이전 그림의 키 구조 맵을 따른다고 가정해 보겠습니다.

키 구조 맵에 따르면 이 키는 다음과 같이 디코딩됩니다.

`11001 0 011 1100`

따라서 키 0b1100100111100은 유럽에서 시작된 캠페인 ID 12의 제품 카테고리 25 구매 수를 나타냅니다.

해시 함수를 사용하여 측정기준 인코딩

키 구조 맵을 사용하는 대신 해싱 함수를 사용하여 일관되고 안정적인 방식으로 키를 동적으로 생성할 수 있습니다.

작동 방식은 다음과 같습니다.

1. 해싱 알고리즘을 선택합니다.
2. 광고 게재 시 추적하려는 모든 측정기준과 해당 값을 포함하는 문자열을 생성합니다. 소스 측 키 부분을 생성하려면 이 문자열을 해싱하고 트리거 측 키 부분과 정렬하고 OR을 더 쉽게 추론할 수 있도록 64비트 0 접미사를 추가하는 것이 좋습니다.
   • 소스 측 키 부분
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • COUNT은 키 구조 맵 접근 방식에서 measurementGoalType=0과 동일한 것을 인코딩합니다. COUNT는 좀 더 간결하고 명시적입니다.
3. 전환 시 추적하려는 모든 측정기준과 해당 값을 포함하는 문자열을 생성합니다. 트리거 측 키 부분을 생성하려면 이 문자열을 해싱하고 0으로 된 64비트 접두사를 추가합니다.
   • 트리거 측 키 조각 = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. 브라우저는 이러한 키 조각을 OR하여 키를 생성합니다.
   • 128비트 집계 키
     = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
5. 나중에 이 키의 요약 보고서를 요청할 준비가 되면 즉석에서 생성합니다.
   • 관심 있는 측정기준을 기반으로 이전과 같이 소스 측 및 트리거 측 키 부분을 생성합니다.
     • 소스 측 키 부분
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • 트리거 측 키 조각
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • 트리거 측 키 조각 = toHex(hash("productCategory=25"))
   • 브라우저와 마찬가지로 이러한 주요 부분을 OR하여 브라우저가 이전에 생성한 것과 동일한 키를 생성합니다.
     • 128비트 집계 키
       = <64-bit source-side key piece hash><64-bit source-side key piece hash>

이 해시 기반 접근 방식을 사용하는 경우 몇 가지 실용적인 팁이 있습니다.

• 항상 동일한 측정기준 순서를 사용합니다. 이렇게 하면 해시를 안정적으로 재생성할 수 있습니다. ("COUNT, CampaignID=12, GeoID=7"는 "COUNT, GeoID=7, CampaignID=12"와 동일한 해시를 생성하지 않습니다.) 이를 달성하는 간단한 방법은 측정기준을 영숫자 순으로 정렬하는 것입니다. 예에서는 항상 COUNT 또는 VALUE을 측정기준의 첫 번째 항목으로 만든다는 점을 제외하고는 이와 동일한 작업을 수행합니다. 이는 COUNT 또는 VALUE이 다른 모든 측정기준과 개념적으로 약간 다른 정보를 인코딩하므로 가독성을 위한 선택입니다.
• 키에 사용 중인 측정기준 집합을 추적합니다. 사용하지 않은 측정기준 세트를 기반으로 키를 생성하지 않는 것이 좋습니다.
• 적절한 해시 함수를 사용하면 해시 충돌이 드물지만 이전에 사용한 해시 (집계 서비스의 결과를 해석하기 위해 저장해야 함)와 비교하면 이전 키와 충돌하는 새 키를 도입하지 않을 수 있습니다.

클릭 또는 조회당 전환 1개 예에서 해시 기반 키를 실제로 사용하는 방법을 확인하세요.

실제 집계 가능한 값

사용자가 전환하면 광고 기술 회사가 집계 가능한 값을 설정합니다.

사용자 개인 정보를 보호하기 위해 각 사용자의 기여에는 상한이 있습니다. 단일 소스 (광고 클릭 또는 조회)와 연결된 모든 집계 가능한 값은 특정 기여도 한도를 초과할 수 없습니다.

이 한도를 CONTRIBUTION_BUDGET라고 하겠습니다. 설명에서는 이 한도를 L1 예산이라고 하지만 CONTRIBUTION_BUDGET와 동일합니다.

기여도 예산에 대한 자세한 내용은 요약 보고서의 기여도 예산을 참고하세요.

예: 클릭 또는 조회당 1건의 전환

이 예에서는 다음 질문에 대한 답을 찾고 있다고 가정해 보겠습니다.

• 각 지역에서 가장 가치 있는 제품 카테고리는 무엇인가요?
• 각 지역에서 가장 효과적인 캠페인 전략은 무엇인가요?

또한 사용 사례에 주간 통계가 필요하다고 가정해 보겠습니다.

다음 항목도 추적해야 합니다.

• 16개의 서로 다른 캠페인
• 8개의 지리적 지역: 북미, 중앙아메리카, 남아메리카, 유럽, 아프리카, 아시아, 카리브해, 오세아니아
• 29개의 다양한 제품 카테고리

측정 항목

많은 광고 기술 회사에서 광고주에게 다양한 전환 유형을 구성하도록 권장하지만, 구매와 같은 가장 중요한 전환에 집중하면 이러한 중요한 전환 이벤트에 대한 집계 결과가 상세하고 정확한지 확인할 수 있습니다. 실제로 측정하는 측정항목이 많을수록 측정항목당 기여 예산이 작아지므로 각 값이 더 노이즈가 많아질 가능성이 높습니다. 따라서 측정할 항목을 신중하게 선택해야 합니다.

이 예에서는 클릭 또는 조회당 하나의 전환(구매)만 측정하는 캠페인 설정에 중점을 두겠습니다.

구매 수와 구매 금액을 모두 측정하고 총 구매 금액, 지역별 분류와 같은 다양한 중요한 집계 통계에 액세스할 수 있습니다. 이렇게 하면 기여 예산의 간단한 확장 방법을 확인하면서 소음을 효과적으로 관리할 수 있습니다.

통화는 어떤가요?

여러 지역에서 캠페인을 운영하는 경우 통화를 고려해야 합니다. 다음과 같은 방법을 사용할 수 있습니다.

• 통화를 집계 키의 전용 측정기준으로 만듭니다.
• 또는 캠페인 ID에서 통화를 추론하고 모든 통화를 참조 통화로 변환합니다.

이 예에서는 캠페인 ID에서 통화를 추론할 수 있다고 가정합니다. 이를 통해 사용자의 현지 통화로 된 구매 금액을 원하는 기준 통화로 변환할 수 있습니다. 사용자가 상품을 구매할 때 즉시 변환을 실행할 수도 있습니다.

이 기법을 사용하면 집계 가능한 모든 값이 동일한 기준 통화로 표시되므로 합산하여 총 집계 구매 가치(요약 구매 가치)를 생성할 수 있습니다.

목표를 키로 변환

측정 목표와 측정항목을 바탕으로 주요 전략을 위한 다양한 옵션을 선택할 수 있습니다. 이러한 전략 중 두 가지에 집중해 보겠습니다.

• 전략 A: 하나의 세분화된 키 구조
• 전략 B: 두 개의 대략적인 키 구조

전략 A: 하나의 깊은 트리 (하나의 세분화된 키 구조)

전략 A에서는 필요한 모든 측정기준을 포함하는 세분화된 키 구조 하나를 사용합니다.

모든 키가 이 구조를 사용합니다.

측정 목표를 두 개 지원하기 위해 이 키 구조를 두 가지 키 유형으로 분할합니다.

• 키 유형 0: 측정 목표 유형 = 0이며, 구매 수로 정의하기로 결정합니다.
• 키 유형 1: 측정 목표 유형 = 1이며 구매 가치로 정의하기로 결정합니다.

요약 보고서는 다음과 같습니다.

전략 A를 '하나의 깊은 트리' 전략이라고 생각할 수 있습니다.

• 요약 보고서의 각 요약 값은 추적 중인 모든 측정기준과 연결됩니다.
• 이러한 각 측정기준과 함께 이러한 요약 값을 롤업할 수 있으므로 이러한 롤업은 측정기준 수만큼 깊어질 수 있습니다.

전략 A를 사용하면 다음과 같이 질문에 답할 수 있습니다.

전략 A를 사용하면 세 번째 질문에도 직접 답변할 수 있습니다.

'각 지역의 각 캠페인에서 각 제품에 대해 발생한 수익은 얼마야?'

요약 값이 노이즈가 많더라도 각 캠페인 간에 측정된 값의 차이가 노이즈로만 인한 것이 아닌 시점을 확인할 수 있습니다. 노이즈 이해하기에서 방법을 알아보세요.

전략 B: 얕은 트리 2개 (대략적인 키 구조 2개)

전략 B에서는 필요한 측정기준의 하위 집합을 각각 포함하는 두 개의 대략적인 키 구조를 사용합니다.

두 가지 측정 목표를 지원하기 위해 이러한 각 주요 구조를 두 가지 주요 유형으로 분할합니다.

• 측정 목표 유형 = 0이며, 이를 구매 수로 정의하기로 결정합니다.
• 측정 목표 유형 = 1이며, 이를 구매 가치로 정의하기로 결정합니다.

결과적으로 다음과 같은 네 가지 주요 유형이 있습니다.

• 키 유형 I-0: 키 구조 I, 구매 수입니다.
• 주요 유형 I-1: 주요 구조 I, 구매 가치
• 키 유형 II-0: 키 구조 II, 구매 횟수입니다.
• 키 유형 II-1: 키 구조 II, 구매 가치

요약 보고서는 다음과 같습니다.

전략 B를 '얕은 트리 두 개' 전략이라고 생각할 수 있습니다.

• 요약 보고서의 요약 값은 두 개의 작은 측정기준 집합 중 하나에 매핑됩니다.
• 이러한 요약 값을 이러한 집합의 각 측정기준과 함께 롤업할 수 있습니다. 즉, 롤업할 측정기준이 적기 때문에 이러한 롤업은 옵션 A만큼 깊지 않습니다.

전략 B를 사용하면 다음과 같이 질문에 답할 수 있습니다.

결정: 전략 A

전략 A는 더 간단합니다. 모든 데이터가 동일한 키 구조를 따르므로 유지관리해야 하는 키 구조가 하나뿐입니다.

하지만 전략 A를 사용하면 요약 보고서에서 수신한 요약 값을 합산하여 일부 질문에 답변해야 합니다. 이러한 요약 값은 모두 노이즈가 있습니다. 이 데이터를 합산하면 노이즈도 합산됩니다.

전략 B의 경우 요약 보고서에 노출된 요약 값이 이미 필요한 정보를 제공하므로 이 경우에 해당하지 않습니다. 즉, 전략 B는 전략 A보다 노이즈의 영향을 덜 받을 가능성이 높습니다.

어떤 전략을 사용해야 하는지 어떻게 결정해야 할까요? 기존 광고주 또는 캠페인의 경우 과거 데이터를 활용하여 전환수가 전략 A 또는 전략 B에 더 적합한지 판단할 수 있습니다. 하지만 신규 광고주 또는 캠페인의 경우 다음을 결정할 수 있습니다.

• 세부 키를 사용하여 한 달 동안의 데이터를 수집합니다 (전략 A). 데이터 수집 기간을 연장하면 요약 값이 높아지고 노이즈가 상대적으로 낮아집니다.
• 주간 전환수와 구매 가치를 합리적인 정확도로 평가합니다.

이 예에서는 주간 구매 수와 구매 금액이 충분히 높아 전략 A를 사용하면 사용 사례에 적합하다고 간주되는 노이즈 비율이 발생한다고 가정합니다.

전략 A가 더 간단하고 의사결정 능력에 영향을 미치지 않는 노이즈 영향을 미치므로 전략 A를 선택합니다.

해싱 알고리즘 선택

키를 생성하기 위해 해시 기반 접근 방식을 채택하기로 결정합니다. 이렇게 하려면 이 접근 방식을 지원하는 해싱 알고리즘을 선택해야 합니다.

SHA-256을 선택했다고 가정해 보겠습니다. MD5와 같이 보안이 약한 간단한 알고리즘을 사용할 수도 있습니다.

브라우저에서 키 및 값 설정

이제 키 구조와 해싱 알고리즘을 결정했으므로 사용자가 광고를 클릭하거나 보고 나중에 전환할 때 키와 값을 등록할 수 있습니다.

다음은 브라우저에 키와 값을 등록하기 위해 설정할 헤더의 개요입니다.

소스 측 키 설정

사용자가 광고를 클릭하거나 조회하면 Attribution-Reporting-Register-Aggregatable-Source 헤더에 집계 키를 설정합니다. 이 단계에서는 각 키에 대해 광고 게재 시점에 알려진 키 부분, 즉 키 조각만 설정할 수 있습니다.

다음과 같이 주요 부분을 생성해 보겠습니다.

이제 주요 부분을 설정해 보겠습니다.

// Upon receiving the request from the publisher site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Source",
  JSON.stringify([
    {
      "id": "key_purchaseCount",
      "key_piece": "0x3cf867903fbb73ec0000000000000000"
    },
    {
      "id": "key_purchaseValue",
      "key_piece": "0x245265f432f16e730000000000000000"
    }
  ])
);

키 ID는 최종 보고서에 표시되지 않습니다. 소스 측 및 트리거 측 키 조각이 서로 매핑되고 전체 키로 결합될 수 있도록 브라우저에서 키를 설정할 때만 사용됩니다.

선택사항: 이벤트 수준 보고서

집계 가능한 보고서와 함께 이벤트 수준 보고서를 사용해야 하는 경우 특정 소스에 대해 이벤트 수준 데이터 (소스 이벤트 ID 및 트리거 데이터)와 집계 키가 일치하는지 확인합니다.

예를 들어 이벤트 수준 보고서를 사용하여 구매 수가 가장 많은 광고 유형에 대한 모델을 실행하려는 경우 두 보고서를 모두 사용할 수 있습니다.

사용자가 전환됨

사용자가 전환하면 일반적으로 픽셀 요청이 광고 기술 서버로 전송됩니다. 이 요청을 받으면 다음 단계를 따르세요.

• 전환 측 (트리거 측) 키 조각을 설정하여 키를 완료합니다. 헤더 Attribution-Reporting-Register-Aggregatable-Trigger-Data를 사용하여 이러한 주요 부분을 설정합니다.
• Attribution-Reporting-Register-Aggregatable-Values 헤더를 사용하여 해당 전환의 집계 가능한 값을 설정합니다.

트리거 측 키 조각을 설정하여 키를 완료합니다.

다음과 같이 주요 부분을 생성해 보겠습니다.

이제 주요 부분을 설정해 보겠습니다.

// Upon receiving the pixel request from the advertiser site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Trigger-Data",
  JSON.stringify([
    // Each dictionary independently adds pieces to multiple source keys
    {
      "key_piece": "0x0000000000000000f9e491fe37e55a0c",
      "source_keys": ["key_purchaseCount", "key_purchaseValue"]
    },
  ])
);

source_keys에 여러 키 ID를 나열하여 동일한 키 부분을 여러 키에 추가하는 방법을 참고하세요. 키 부분이 두 키에 모두 추가됩니다.

집계 가능한 값 설정

집계 가능한 값을 설정하기 전에 노이즈를 줄이기 위해 값을 스케일업해야 합니다.

제품 유형 25에 대해 52달러로 한 번 구매했다고 가정해 보겠습니다.

이러한 값은 집계 가능한 값으로 직접 설정할 수 없습니다.

• key_purchaseCount: 전환 1개
• key_purchaseValue: 52달러

대신 이러한 집계 가능한 값을 등록하기 전에 노이즈를 최소화하기 위해 값을 조정해야 합니다.

기여 예산을 지출할 목표가 두 개이므로 기여 예산을 두 개로 분할할 수 있습니다.

이 경우 각 목표에 최대 CONTRIBUTION_BUDGET/2(=65,536/2=32,768)이 할당됩니다.

사이트의 모든 사용자의 구매 내역을 기반으로 단일 사용자의 최대 구매 금액이 1,500달러라고 가정해 보겠습니다. 예를 들어 해당 금액 이상을 지출한 사용자가 매우 적은 이상치가 있을 수 있지만 이러한 이상치를 무시할 수 있습니다.

구매 가치의 배율은 다음과 같아야 합니다.

((CONTRIBUTION_BUDGET/2) / 1,500) = 32,768/1,500 = 21.8 ≈ 22

광고 클릭 또는 조회 (소스 이벤트)당 최대 1건의 구매를 추적하기로 결정했으므로 구매 수의 확장 계수는 32,768/1 = 32,768입니다.

이제 다음 값을 설정할 수 있습니다.

• key_purchaseCount: 1 × 32,768 = 32,768
• key_purchaseValue: 52 × 22 = 1,144

실제로 전용 헤더 Attribution-Reporting-Register-Aggregatable-Values를 사용하여 다음과 같이 설정합니다.

// Instruct the browser to schedule-send a report
res.set(
  "Attribution-Reporting-Register-Aggregatable-Values",
  JSON.stringify({
    "key_purchaseCount": 32768,
    "key_purchaseValue": 1144,
  })
);

집계 가능한 보고서가 생성됩니다.

브라우저가 전환을 이전 조회 또는 클릭과 일치시키고 집계 가능한 보고서를 생성합니다. 이 보고서에는 보고서 메타데이터 옆에 암호화된 페이로드가 포함됩니다.

다음은 집계 가능한 보고서의 페이로드 내에서 찾을 수 있는 데이터의 예시입니다(일반 텍스트로 읽을 수 있는 경우).

[
  {
    key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece OR conversion-side key piece for the key key_purchaseCount
    value: 32768 // the scaled value for 1 conversion, in the context of [CONTRIBUTION_BUDGET/2]
  },
  {
    key: 0x245265f432f16e73f9e491fe37e55a0c, // source-side key piece OR conversion-side key piece for the key key_purchaseValue
    value: 1144 // the scaled value for $52, in the context of [CONTRIBUTION_BUDGET/2]
  },
]

여기에서는 하나의 집계 가능한 보고서 내에 두 개의 별도 기여가 표시됩니다.

요약 보고서 요청

• 집계 가능한 보고서를 일괄 처리합니다. 일괄 처리에 제공된 조언을 따르세요.
• 데이터를 확인할 키를 생성합니다. 예를 들어 캠페인 ID 12 × 지역 ID 7 × 제품 카테고리 25의 COUNT (총 구매 수) 및 VALUE (총 구매 가치)에 대한 요약 데이터를 보려면 다음을 실행합니다.
  • 브라우저에서 설정할 때와 마찬가지로 소스 측 키 부분을 생성합니다.
  • 브라우저에서 설정할 때와 마찬가지로 트리거 측 키 부분을 생성합니다.

• 이러한 키에 대한 집계 서비스에 요약 데이터를 요청합니다.

요약 보고서 처리

결과적으로 다음과 같은 요약 보고서가 표시됩니다.

[
  {"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
    "value": "2558500"},
  {"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
    "value": "687060"},
  …
]

첫 번째 버킷은 바이너리의 COUNT 키입니다. 두 번째 버킷은 바이너리의 VALUE 키입니다. 키는 이질적 (COUNT 대 VALUE)이지만 동일한 보고서에 포함됩니다.

값 축소

• 2,558,500은 이 키의 구매 수를 이전에 계산된 확장 요인으로 확장한 값을 나타냅니다. 구매 수의 배율은 32,768이었습니다. 2,558,500을 목표의 기여도 예산으로 나눕니다.2,558,500/32,768 = 156.15건의 구매
• 687,060 → 687,060/22 = 총 구매 가치 31,230달러

따라서 요약 보고서는 다음과 같은 유용한 정보를 제공합니다.

- Within the reporting time period, campaign #12
  run in Europe drove about 156 purchases (± noise)
  for the product category #25
  ```

  ```text
- Within the reporting time period, campaign #12
  run in Europe drove $31,230 of purchases (± noise)
  for the product category #25.