집계 키의 정의, Attribution Reporting API에서 집계 키가 사용되는 방식, 목표를 키로 변환하는 방법
다양한 제품 카테고리에 대한 여러 위치에서 캠페인을 운영하는 광고 기술 회사로서 광고주가 다음 질문에 답할 수 있도록 지원하려고 합니다.
- 각 지역의 각 캠페인에서 제품 카테고리별 구매가 몇 건 발생했나요?
- 각 지역의 각 캠페인에서 발생한 제품 카테고리별 수익은 얼마인가요?
많은 광고 기술 회사에서는 광고주에게 다양한 전환 유형을 구성하도록 권장하지만, 구매와 같은 가장 중요한 전환에 초점을 맞추는 것이 이러한 중요한 이벤트에 대한 요약 결과를 자세하고 정확하게 확인할 수 있는 좋은 방법입니다.
그러기 위해서는 데이터를 수집하기 전에 어떤 질문에 답하고 싶은지 생각해야 합니다.
크기, 키, 값
이러한 질문에 답하기 위해 측정기준, 키, 값을 살펴보겠습니다.
크기
여기에 설명된 대로 캠페인에서 수익이 발생하는 방식을 이해하려면 다음 측정기준을 추적하는 것이 좋습니다.
- 광고 캠페인 ID: 특정 캠페인의 식별자입니다.
- 지역 ID: 광고가 게재된 지역
- 제품 카테고리: 정의한 제품 유형입니다.
캠페인 ID 및 지역 ID 측정기준은 광고가 게재될 때 (광고 게재 시간) 알려져 있지만 제품 카테고리는 사용자가 전환을 완료할 때 (전환 시간) 트리거 이벤트를 통해 알 수 있습니다.
이 예에서 추적하려는 측정기준은 다음 이미지에 나와 있습니다.
![캠페인 ID, 지역 ID, 제품 카테고리입니다.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/campaign-id-geography-id-223ed5327b057.png?authuser=7&hl=ko)
집계 키 (버킷)란 무엇인가요?
집계 키와 버킷은 같은 것을 의미합니다. 집계 키는 보고서를 구성하는 데 사용되는 브라우저 API에서 사용됩니다. 버킷이라는 용어는 집계 가능한 보고서 및 요약 보고서와 집계 서비스 API에서 사용됩니다.
집계 키 (줄여서 키)는 추적 중인 측정기준의 값을 나타내는 데이터입니다. 나중에 각 집계 키에 따라 데이터가 집계됩니다.
예를 들어 제품 카테고리, 지역 ID, 캠페인 ID 측정기준을 추적한다고 가정해 보겠습니다.
지역 ID 7의 사용자가 캠페인 ID 12의 광고를 본 후 나중에 제품 카테고리 25의 제품을 구매하여 전환하는 경우 다음 이미지와 같은 집계 키를 설정할 수 있습니다.
![전환의 집계 키입니다.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/aggregation-key-a-conver-0cd37e4079fee.png?authuser=7&hl=ko)
나중에 집계 키가 실제로 이와 똑같지 않다는 것을 알게 되지만 지금은 키에 포함된 정보에 집중해 보겠습니다.
집계 가능한 값이란 무엇인가요?
지금까지 설명한 측정기준에 대한 질문에 답하려면 다음을 확인하세요.
- 구매 횟수 (구매 수)입니다. 집계되어 요약 보고서에 제공되면 이 값이 총 구매 건수 (요약 값)가 됩니다.
- 각 구매의 수익 (구매 가치)입니다. 집계되어 요약 보고서에 제공되면 이 금액이 총 수익 (요약 값)이 됩니다.
이러한 각 요소(전환 1회의 구매 횟수 및 1회 전환의 구매 가치)는 집계 가능한 가치입니다. 집계 가능한 값을 측정 목표의 가치로 생각하면 됩니다.
문제 | 집계 가능한 값 = 측정 목표 |
---|---|
구매 건수... | 구매 수 |
수익은 얼마인가요? | 구매 가치 |
지역 ID 7에 있는 사용자가 캠페인 ID 12의 광고를 본 다음 나중에 제품 카테고리 25의 제품을 120달러에 구매하여 전환하는 경우 (통화가 미국 달러라고 가정) 다음과 같이 집계 키와 집계 가능한 값을 설정할 수 있습니다.
![집계 키 및 값.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/aggregation-keys-values-912b4f69661bd.png?authuser=7&hl=ko)
집계 가능한 값은 여러 사용자의 키별로 합산되어 요약 보고서의 요약 값 형태로 집계된 통계를 생성합니다.
![집계된 통계를 생성하는 중입니다.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/generating-aggregated-ins-e7ef89ea0a238.png?authuser=7&hl=ko)
집계 가능한 값을 합산하여 측정 목표에 대한 집계된 통계를 생성합니다.
이 다이어그램은 복호화를 생략하고 노이즈를 적용하지 않은 간소화된 예를 나타냅니다. 다음 섹션에서는 이 예를 노이즈와 함께 간략하게 살펴보겠습니다.
키와 값에서 보고서로
이제 집계 가능한 키와 값이 보고서와 어떤 관련이 있는지 알아보겠습니다.
집계 가능한 보고서
사용자가 광고를 클릭하거나 본 후에 나중에 전환하는 경우 {집계 키, 집계 가능한 값} 쌍을 저장하도록 브라우저에 지시합니다.
이 예에서는 사용자가 광고를 클릭하거나 본 후 나중에 전환하는 경우 브라우저에 2회의 기여 (측정 목표당 1회)를 생성하도록 지시합니다.
![참여 2건을 생성하고 있습니다.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/generating-contributions-fa8bc97295bc7.png?authuser=7&hl=ko)
나중에 {집계 키, 집계 가능한 값} 집계 가능한 보고서가 이와 똑같아 보이지는 않을 것입니다. 하지만 지금은 보고서에 포함된 정보를 중점적으로 살펴보겠습니다.
브라우저에 2회의 기여도를 생성하도록 지시하면 브라우저는 집계 가능한 보고서를 생성합니다 (전환을 이전 조회 또는 클릭과 일치시킬 수 있는 경우).
집계 가능한 보고서에는 다음이 포함됩니다.
- 구성한 참여입니다.
- 클릭 또는 조회 이벤트 및 전환 이벤트(전환이 발생한 사이트 등)에 대한 메타데이터입니다. 집계 가능한 보고서의 모든 필드 보기
![집계 가능한 결과 보고서입니다.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/the-resulting-aggregatabl-3df86364f7725.png?authuser=7&hl=ko)
집계 가능한 보고서는 JSON 형식이며 최종 요약 보고서의 데이터 입력으로 사용되는 페이로드 필드를 포함합니다.
페이로드에는 {집계 키, 집계 가능한 값} 쌍인 기여 목록이 포함됩니다.
bucket
: 바이트 문자열로 인코딩된 집계 키입니다.value
: 해당 측정 목표의 집계 가능한 값이며 바이트 문자열로 인코딩됩니다.
예를 들면 다음과 같습니다.
{
"data": [
{
"bucket": "111001001",
"value": "11111010000",
}
],
"operation": "histogram"
}
실제로 집계 가능한 보고서는 버킷과 값이 이전 예와 다르게 표시되도록 인코딩됩니다 (즉, 버킷이 \u0000\u0000\x80\u0000
처럼 보일 수 있음). Bucket과 value는 모두 바이트 문자열입니다.
요약 보고서
집계 가능한 보고서는 다음과 같이 여러 브라우저 및 기기 (사용자)를 대상으로 집계됩니다.
- 광고 기술은 지정된 키 세트에 관한 요약 보고서와 여러 다양한 브라우저 (사용자)에서 제공되는 집계 가능한 특정 보고서 세트를 요청합니다.
- 집계 가능한 보고서는 집계 서비스를 통해 복호화됩니다.
- 키마다 집계 가능한 보고서의 집계 가능한 값이 합산됩니다.
- 노이즈가 요약 값에 추가됩니다.
![집계 가능한 보고서와 집계, 복호화, 노이즈 결과를 포함하는 요약 보고서](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/aggregatable-reports-plus-9bd26966f76f7.png?authuser=7&hl=ko)
결과로 {집계 키, 요약 값} 쌍 집합이 포함된 요약 보고서가 생성됩니다.
요약 보고서에는 JSON 사전 스타일의 키-값 쌍 집합이 포함됩니다. 각 쌍에는 다음이 포함됩니다.
bucket
: 바이트 문자열로 인코딩된 집계 키입니다.value
: 추가된 노이즈 수준을 포함하여, 사용 가능한 모든 집계 가능한 보고서에서 합산된 특정 측정 목표의 십진수 요약 값입니다.
예:
[
{"bucket": "111001001", "value": "2558500"},
{"bucket": "111101001", "value": "3256211"},
{...}
]
실제로 요약 보고서는 버킷과 값이 예시와 다르게 표시되도록 인코딩됩니다 (즉, 버킷이 \u0000\u0000\x80\u0000
처럼 보일 수 있음). Bucket과 value는 모두 바이트 문자열입니다.
집계 키의 실제 사용 사례
집계 키 (버킷)는 광고 기술 회사가 일반적으로 광고를 클릭하거나 조회할 때와 사용자가 전환할 때의 두 단계로 정의합니다.
키 구조
키에 인코딩된 측정기준 집합을 지정할 때 키 구조라는 용어를 사용합니다.
예를 들어 캠페인 ID × GeoID × 제품 카테고리는 키 구조입니다.
![키 구조](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/key-structure-17b99e9ad0974.png?authuser=7&hl=ko)
키 유형
집계 가능한 값은 여러 사용자/브라우저에서 특정 키에 대해 합산됩니다. 하지만 집계 가능한 가치로 구매 가치, 구매 횟수 등 다양한 측정 목표를 추적할 수 있습니다. 집계 서비스에서 동일한 유형의 집계 가능한 값을 합산하도록 하려고 합니다.
이렇게 하려면 각 키 내에서 요약 값이 나타내는 내용, 즉 이 키가 참조하는 측정 목표를 알려주는 데이터 조각을 인코딩합니다. 이를 위한 한 가지 방법은 측정 목표 유형을 나타내는 키에 대한 추가 측정기준을 만드는 것입니다.
앞서 살펴본 예의 경우 이 측정 목표 유형은 다음과 같은 2개의 값을 가질 수 있습니다.
- 구매 횟수는 첫 번째 측정 목표 유형입니다.
- 구매 가치는 두 번째 측정 목표 유형입니다.
![측정 목표 및 측정 목표 유형](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/measurement-goals-measur-6f6f8b6468ec3.png?authuser=7&hl=ko)
n개의 측정 목표가 있다면 측정 목표 유형에는 n개의 서로 다른 값 유형이 포함됩니다.
키의 측정기준은 측정항목으로 생각할 수 있습니다. 예: '지역별 캠페인별 특정 제품 구매 횟수'
키 크기, 크기 크기
최대 키 크기는 전체 키를 생성하기 위한 0과 1의 수(2진수)인 비트로 정의됩니다. 이 API는 128비트의 키 길이를 허용합니다.
이 크기로 인해 매우 세분화된 키가 허용되지만, 키가 더 세분화되면 노이즈가 더 많은 값으로 이어질 가능성이 높습니다. 노이즈 이해하기에서 노이즈에 관해 자세히 알아보세요.
앞서 소개한 것처럼 측정기준은 집계 키로 인코딩됩니다. 각 측정기준에는 특정 카디널리티, 즉 측정기준에 사용할 수 있는 고유한 값의 수가 있습니다. 카디널리티에 따라 각 차원은 특정 비트 수로 표현되어야 합니다. n 비트를 사용하여 2n 개의 개별 옵션을 표현할 수 있습니다.
예를 들어 전 세계에는 약 200개의 국가가 있으므로 국가 측정기준의 카디널리티가 200일 수 있습니다. 이 차원을 인코딩하려면 몇 비트가 필요할까요?
7비트는 필요한 200개보다 적은 27 = 128개의 고유 옵션만 저장합니다.
8비트는 필요한 200개보다 많은 28 = 256개의 고유 옵션을 저장하므로 n=8비트를 사용하여 이 차원을 인코딩할 수 있습니다.
키 인코딩
브라우저에서 키를 설정할 때 16진수로 인코딩해야 합니다. 요약 보고서에서 키는 바이너리로 표시되며 이름이 지정된 버킷으로 표시됩니다.
전체 키를 위한 키 2개 설정하기
키를 사용하여 다음 측정기준을 추적한다고 가정해 보겠습니다.
- 캠페인 ID
- 지역 ID
- 제품 카테고리
캠페인 ID 및 지역 ID 측정기준은 광고가 게재될 때 (광고 게재 시간) 알려져 있지만 제품 카테고리는 사용자가 전환을 완료할 때 (전환 시간) 트리거 이벤트를 통해 알 수 있습니다.
실제로 이는 다음 두 단계로 키를 설정한다는 의미입니다.
- 클릭 또는 조회 시 키의 한 부분(캠페인 ID × 지역 ID)을 설정합니다.
- 전환 시 키의 두 번째 부분인 제품 카테고리를 설정합니다.
키의 이러한 서로 다른 부분을 키 조각이라고 합니다.
키는 키 조각의 XOR (^
)을 취하여 계산됩니다.
![XOR 처리 핵심 요소.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/xoring-key-pieces-6c7b39f58a41f.png?authuser=7&hl=ko)
예:
- 소스 측 키 조각 =
0x159
- 트리거 측 키 피스 =
0x400
- 키 =
0x159 ^ 0x400 = 0x559
핵심 요소 정렬
신중하게 배치된 64비트 필러/오프셋 (16개의 0)을 사용하여 2개의 64비트 키 조각이 128비트로 확장된 경우, XOR-ing 키 조각은 이를 연결하는 것과 같으며, 다음과 같이 추론하고 확인하기가 더 쉽습니다.
- 소스 측 키 조각 =
0xa7e297e7c8c8d0540000000000000000
- 트리거 측 키 피스 =
0x0000000000000000674fbe308a597271
- 키 =
0xa7e297e7c8c8d0540000000000000000 ^ 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271
광고 클릭 또는 조회당 여러 개의 키 사용
실제로는 기여 분석 소스 이벤트 (광고 클릭 또는 조회)당 여러 개의 키를 설정할 수 있습니다. 예를 들어 다음을 설정할 수 있습니다.
- 지역 ID × 캠페인 ID를 추적하는 키입니다.
- 광고 소재 유형 × 캠페인 ID를 추적하는 또 다른 키입니다.
다른 예로 전략 B를 살펴보겠습니다.
측정기준을 키로 인코딩
요약 보고서를 요청할 때 특정 집계 키 세트에 대한 요약 보고서를 요청하여 액세스하려는 측정항목을 집계 서비스에 알려야 합니다.
요약 보고서에는 원시 {key, summary value} 쌍이 포함되며 키에 대한 추가 정보는 없습니다. 이는 다음을 의미합니다.
- 사용자가 광고를 보거나 클릭한 후 나중에 전환할 때 키를 설정할 때는 키가 나타내는 측정기준의 값에 따라 키를 안정적으로 설정해야 합니다.
- 요약 보고서를 요청할 키를 정의할 때는 집계 데이터를 확인하려는 측정기준의 값에 따라 사용자가 광고를 보거나 클릭하고 전환할 때 설정한 키와 동일한 키를 즉석에서 안정적으로 생성하거나 액세스할 수 있어야 합니다.
키 구조 맵을 사용하여 측정기준 인코딩
측정기준을 키로 인코딩하려면 키를 정의할 때 (광고 게재 시간 전에) 미리 키 구조 맵을 만들고 유지하면 됩니다.
키 구조 맵은 각 측정기준과 키에서의 위치를 나타냅니다.
실제로 키 구조 맵을 만들고 유지관리한다는 것은 디코더 로직을 구현하고 유지관리해야 한다는 것을 의미합니다. 이렇게 할 필요가 없는 방법을 찾는 경우 대신 해시 기반 접근 방식을 사용하는 것이 좋습니다.
예를 들면 다음과 같습니다.
특정 캠페인, 지역, 제품에 대한 구매 및 구매 가치를 모두 추적하려는 경우를 가정해 보겠습니다.
제품 카테고리, 지역 ID, 캠페인 ID는 키의 측정기준이어야 합니다. 또한 서로 다른 두 가지 측정 목표인 구매 횟수와 구매 가치를 추적하려면 키 내에 키 유형을 추적하는 측정기준을 하나 추가해야 합니다. 이렇게 하면 요약 보고서에서 {키, 집계 가능한 값} 쌍을 수신할 때 집계 가능한 값이 실제로 무엇을 나타내는지 정의할 수 있습니다.
이러한 측정 목표를 사용하면 키에 다음과 같은 측정기준이 포함됩니다.
- 제품 카테고리
- 측정 목표 유형
- 지역 ID
- 캠페인 ID
각 측정기준을 살펴보면서 사용 사례에서 다음을 추적해야 한다고 가정해 보겠습니다.
- 29가지 제품 카테고리
- 8개 지역: 북미, 중앙 아메리카, 남미, 유럽, 아프리카, 아시아, 카리브해, 오세아니아
- 16개의 서로 다른 캠페인
다음은 키에서 각 차원을 인코딩하는 데 필요한 비트 수입니다.
- 제품 카테고리: 5비트 (25 = 32 > 29).
- 측정 목표 유형: 1비트 측정 목표는 구매 횟수 또는 구매 가치이므로 서로 다른 두 가지 가능성을 의미합니다. 따라서 1비트이면 충분합니다.
지리 ID: 3비트 (23 = 8) 또한 각 바이너리 값이 나타내는 지역을 파악하기 위해 지역 ID의 측정기준 맵을 정의합니다. 지역 ID 측정기준에 대한 측정기준 맵은 다음과 같이 표시될 수 있습니다.
키의 바이너리 값 지역 000 북미 001 중미 010 남아메리카 011 유럽 100 아프리카 101 아시아 110 카리브해 111 오세아니아 캠페인 ID: 4비트 (24 = 16)
이 구조를 따르는 키의 길이는 13비트 (5 + 1 + 3 + 4)입니다.
이 예에서 이러한 키의 키 구조 맵은 다음과 같습니다.
![키 구조 맵](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/key-structure-map-4664a0905c7de.png?authuser=7&hl=ko)
키 내 측정기준의 순서는 사용자가 결정합니다.
측정기준이 키 구조를 구성하는 방식을 설명하기 위해 이진 표현을 사용하겠습니다. 따라서 캠페인 ID (첫 번째 비트)가 맨 오른쪽이고 제품 카테고리 (마지막 비트)가 가장 왼쪽에 위치합니다.
각 차원 내에서 최상위 비트(가장 큰 숫자 값을 지닌 비트)는 맨 왼쪽 비트입니다. 최하위 비트(가장 작은 숫자 값을 전달하는 비트)는 맨 오른쪽 비트입니다.
키 구조 맵을 사용하여 키를 디코딩하는 방법을 살펴보겠습니다.
0b1100100111100을 임의의 예시 키로 사용하고, 이 키가 이전 그림의 키 구조 맵을 따른다는 것을 알 수 있는 방법이 있다고 가정해 보겠습니다.
키 구조 맵에 따라 이 키는 11001 0 011 1100
로 디코딩됩니다.
따라서 키 0b1100100111100은 유럽에서 출시된 캠페인 ID 12에 대해 제품 카테고리 25의 구매 수를 나타냅니다.
해시 함수를 사용하여 차원 인코딩
키 구조 맵을 사용하는 대신 해싱 함수를 사용하여 일관되고 신뢰할 수 있는 방식으로 키를 동적으로 생성할 수 있습니다.
이는 다음과 같이 작동합니다.
- 해싱 알고리즘을 선택합니다.
- 광고 게재 시 추적하려는 모든 측정기준과 그 값을 포함하는 문자열을 생성합니다. 소스 측 키 조각을 생성하려면 이 문자열을 해시하고 64비트 접미사로 0을 추가하여 트리거 측 키 조각에 맞춰 정렬하고 XOR를 더 쉽게 추론할 수 있습니다.
- 소스 측 키 조각
=<64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
COUNT
는 키 구조 맵 접근 방식에서measurementGoalType=0
와 동일한 것을 인코딩합니다.COUNT
은 약간 더 가볍고 더 명확합니다.
- 소스 측 키 조각
- 전환 시 추적하려는 모든 측정기준과 그 값을 포함하는 문자열을 생성합니다. 트리거 측 키 조각을 생성하려면 이 문자열을 해시하고 64비트 접두사 0을 추가합니다.
- 트리거 측 키 조각
=
<64-bit 00000000…><64-bit hex hash("productCategory=25")>
- 트리거 측 키 조각
=
- 브라우저는 이러한 키 조각을 XOR 처리하여 키를 생성합니다.
- 128비트 집계 키
=<64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
- 128비트 집계 키
- 나중에 이 키의 요약 보고서를 요청할 준비가 되면 즉시 생성합니다.
- 관심 있는 측정기준에 따라 앞서 한 것처럼 소스 측 및 트리거 측 키 조각을 생성합니다.
- 소스 측 키 조각
=<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"))
- 소스 측 키 조각
- 브라우저와 마찬가지로 이러한 키 조각을 XOR 처리하여 브라우저가 이전에 생성한 것과 동일한 키를 생성합니다.
- 128비트 집계 키
=<64-bit source-side key piece hash><64-bit source-side key piece hash>
- 128비트 집계 키
- 관심 있는 측정기준에 따라 앞서 한 것처럼 소스 측 및 트리거 측 키 조각을 생성합니다.
이 해시 기반 접근 방식을 사용하는 경우 몇 가지 실용적인 팁은 다음과 같습니다.
- 항상 동일한 측정기준 순서를 사용하세요. 이렇게 하면 해시를 안정적으로 재생성할 수 있습니다. (
"COUNT, CampaignID=12, GeoID=7"
는"COUNT, GeoID=7, CampaignID=12"
와 동일한 해시를 생성하지 않습니다.) 이를 수행하는 한 가지 간단한 방법은 측정기준을 영숫자로 정렬하는 것입니다. 예시에서는 항상COUNT
또는VALUE
을 측정기준의 첫 번째 항목으로 만듭니다. 단,COUNT
또는VALUE
는 다른 모든 차원과 개념적으로 약간 다른 정보를 인코딩하므로 가독성을 위해 이 옵션을 선택합니다. - 키에서 사용 중인 측정기준 세트를 추적합니다. 한 번도 사용하지 않은 측정기준 집합을 기반으로 키가 생성되지 않도록 해야 합니다.
- 적절한 해시 함수를 사용하면 해시 충돌은 거의 발생하지 않지만 이전에 사용된 해시 (집계 서비스의 결과를 해석하기 위해 저장해야 함)를 확인하면 이전 키와 충돌하는 새로운 키가 유입되지 않도록 할 수 있습니다.
클릭당 1회의 전환 또는 보기의 예시에서 해시 기반 키를 실제로 사용하는 방법을 알아보세요.
집계 가능한 값의 실제 사례
광고 기술 회사는 사용자가 전환할 때 집계 가능한 값을 설정합니다.
사용자 개인 정보 보호를 위해 각 사용자의 기여에는 상한이 있습니다. 단일 소스 (광고 클릭 또는 조회)와 연결된 집계 가능한 모든 값에서 어떤 값도 특정 기여도 한도를 초과할 수 없습니다.
이 한도를 CONTRIBUTION_BUDGET
라고 합니다. 설명서에서는 이 한도를 L1 예산이라고 하지만 CONTRIBUTION_BUDGET
와 동일합니다.
참여 예산에 대한 자세한 내용은 요약 보고서의 참여 예산을 참고하세요.
예: 클릭 또는 조회당 1회의 전환
이 예에서는 다음 질문에 답변하려고 한다고 가정해 보겠습니다.
- 각 지역에서 가장 가치가 높은 제품 카테고리는 무엇인가요?
- 각 지역에서 어떤 캠페인 전략이 가장 효과적인가요?
또한 사용 사례의 경우 주별 통계가 필요하다고 가정해 보겠습니다.
또한 다음 항목도 추적해야 합니다.
- 16개의 서로 다른 캠페인
- 8개 지역: 북미, 중앙 아메리카, 남미, 유럽, 아프리카, 아시아, 카리브해, 오세아니아
- 29가지 제품 카테고리
측정 항목
많은 광고 기술 회사에서는 광고주에게 다양한 전환 유형을 구성하도록 권장하지만, 구매와 같이 가장 중요한 전환에 집중하는 것이 이러한 중요한 전환 이벤트에 대한 집계 결과를 자세하고 정확하게 확인할 수 있는 좋은 방법입니다. 실제로 측정하는 측정항목이 많을수록 측정항목당 참여 예산이 줄어들기 때문에 각 값의 노이즈가 더 많아질 수 있습니다. 따라서 측정할 항목을 신중하게 선택해야 합니다.
이 예에서는 클릭 또는 조회당 하나의 전환, 즉 구매 1회만 측정하는 캠페인 설정을 중점적으로 살펴보겠습니다.
이전과 마찬가지로 구매 횟수와 구매 가치를 모두 측정하고 총 구매 가치 및 지역 분석과 같은 중요한 집계 통계에 액세스할 수 있습니다. 이렇게 하면 노이즈를 적절히 유지하고 기여 예산에 간단한 확장 방식을 적용할 수 있습니다.
통화는 어떤가요?
여러 지역에서 캠페인을 운영한다는 것은 통화를 고려해야 한다는 것을 의미합니다. 다음과 같은 방법을 사용할 수 있습니다.
- 집계 키에서 통화를 전용 측정기준으로 설정합니다.
- 또는 캠페인 ID에서 통화를 추론하고 모든 통화를 참조 통화로 변환합니다.
이 예에서는 캠페인 ID에서 통화를 추론할 수 있다고 가정합니다. 이렇게 하면 특정 구매 가치를 사용자의 현지 통화에서 선택한 참조 통화로 변환할 수 있습니다. 사용자가 항목을 구매할 때 바로 변환을 실행할 수도 있습니다.
이 기법을 사용하면 집계 가능한 모든 값이 동일한 참조 통화이므로 합산하여 총 집계 구매 가치(요약 구매 가치)를 생성할 수 있습니다.
목표를 키로 변환
측정 목표 및 측정항목을 통해 주요 전략을 위한 여러 가지 옵션을 사용할 수 있습니다. 이러한 전략 중 두 가지를 집중적으로 살펴보겠습니다.
- 전략 A: 하나의 세분화된 키 구조
- 전략 B: 2개의 대략적인 키 구조
전략 A: 하나의 딥 트리 (하나의 세분화된 키 구조)
전략 A에서는 필요한 모든 측정기준이 포함된 하나의 세분화된 키 구조를 사용합니다.
![하나의 세분화된 키 구조](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/one-granular-key-structur-85e0f0ef579b3.png?authuser=7&hl=ko)
모든 키에서 이 구조를 사용합니다.
두 가지 측정 목표를 지원하기 위해 이 키 구조를 두 가지 키 유형으로 분할합니다.
- 키 유형 0: 측정 목표 유형 = 0, 이를 구매 횟수로 정의함
- 키 유형 1: 측정 목표 유형 = 1, 이를 구매 가치로 정의하기로 결정합니다.
요약 보고서는 다음과 같습니다.
![전략 A 요약 보고서](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/strategy-summary-report-c13d51d0ef5b.png?authuser=7&hl=ko)
전략 A는 '단일 딥 트리' 전략으로 생각할 수 있습니다.
- 요약 보고서의 각 요약 값은 추적하는 모든 측정기준과 연결됩니다.
- 각 측정기준과 함께 요약 값을 롤업하여 보유한 측정기준의 수만큼 집계할 수 있습니다.
전략 A를 사용하면 다음과 같이 질문에 답할 수 있습니다.
문제 | 정답 |
---|---|
각 지역에서 가장 가치가 높은 제품 카테고리는 무엇인가요? | 모든 캠페인의 요약 보고서에 있는 요약 구매 건수와 값을 합산합니다. 이렇게 하면 지역 ID × 제품 카테고리당 구매 횟수와 가치를 알 수 있습니다. 지역별로 구매 가치와 여러 제품 카테고리 수를 비교합니다. |
각 지역에서 어떤 캠페인 전략이 가장 효과적인가요? | 모든 제품 카테고리의 요약 보고서에 있는 요약 구매 건수와 값을 합산합니다. 이렇게 하면 캠페인 ID × 지역 ID당 구매 횟수와 가치를 확인할 수 있습니다. 지역별로 여러 캠페인의 구매 가치와 개수를 비교합니다. |
전략 A를 사용하면 다음 세 번째 질문에 직접 답변할 수 있습니다.
'각 지역의 각 캠페인에서 창출한 제품별 수익은 얼마인가요?'
요약 값에 노이즈가 있더라도 각 캠페인 간에 측정된 값의 차이가 노이즈만으로 인한 것이 아닌 경우 이를 확인할 수 있습니다. 노이즈 이해에서 이 작업을 수행하는 방법을 알아보세요.
전략 B: 2개의 얕은 트리 (두 개의 대략적인 키 구조)
전략 B에서는 각각 필요한 측정기준의 하위 집합을 포함하는 대략적인 키 구조 두 개를 사용합니다.
![키 구조 1과 키 구조 2](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/key-structure-1-key-stru-f5313e8766cd6.png?authuser=7&hl=ko)
이러한 각 키 구조를 두 가지 키 유형으로 분할하여 두 가지 측정 목표를 지원합니다.
- 측정 목표 유형 = 0, 이를 구매 횟수로 정의하기로 결정합니다.
- 측정 목표 유형 = 1, 구매 가치로 정의하기로 결정합니다.
4가지 키 유형이 생성됩니다.
- 키 유형 I-0: 키 구조 I, 구매 횟수
- 키 유형 I-1: 키 구조 I, 구매 가치
- 키 유형 II-0: 키 구조 II, 구매 횟수
- 키 유형 II-1: 키 구조 II, 구매 가치
요약 보고서는 다음과 같습니다.
![요약 보고서 전략 B.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/summary-report-strategy-b-a402cebbf58ca.png?authuser=7&hl=ko)
전략 B는 '두 개의 얕은 나무' 전략으로 생각할 수 있습니다.
- 요약 보고서의 요약 값은 두 개의 작은 측정기준 집합 중 하나에 매핑됩니다.
- 이러한 집합의 각 측정기준과 함께 이러한 요약 값을 롤업할 수 있습니다. 즉, 롤업할 측정기준이 더 적기 때문에 이러한 롤업은 옵션 A만큼 깊지 않습니다.
전략 B를 사용하면 다음과 같이 질문에 답할 수 있습니다.
문제 | 정답 |
---|---|
각 지역에서 가장 가치가 높은 제품 카테고리는 무엇인가요? | 요약 보고서에 있는 요약 구매 건수 및 값에 직접 액세스합니다. |
각 지역에서 어떤 캠페인 전략이 가장 효과적인가요? | 요약 보고서에 있는 요약 구매 건수 및 값에 직접 액세스합니다. |
결정: 전략 A
전략 A는 더 간단합니다. 모든 데이터는 동일한 키 구조를 따르므로 유지관리할 키 구조가 하나만 있습니다.
하지만 전략 A에서는 몇 가지 질문에 답하기 위해 요약 보고서에 수신된 요약 값을 합산해야 합니다. 이러한 각 요약 값에는 노이즈가 포함됩니다 이 데이터를 요약하면 노이즈도 합산합니다.
요약 보고서에 노출된 요약 값이 이미 필요한 정보를 제공하는 전략 B는 그렇지 않습니다. 즉, 전략 B는 전략 A보다 노이즈로 인한 영향이 적을 가능성이 높습니다.
어떤 전략을 사용해야 할지 어떻게 결정해야 할까요? 기존 광고주 또는 캠페인의 경우 이전 데이터를 사용하여 전환수가 전략 A 또는 전략 B에 더 적합한지 확인할 수 있습니다. 그러나 신규 광고주나 캠페인의 경우 다음과 같이 할 수 있습니다.
- 세분화된 키로 한 달 치의 데이터를 수집합니다 (전략 A). 데이터 수집 기간을 연장하므로 요약 값이 증가하고 노이즈가 비교적 줄어듭니다.
- 주간 전환수와 구매 가치를 합리적인 정확도로 평가합니다.
이 예시에서는 전략 A로 인해 사용 사례에 허용 가능한 노이즈 비율로 이어질 만큼 주간 구매 수와 구매 가치가 충분히 높다고 가정해 보겠습니다.
전략 A는 더 간단하고 노이즈에 영향을 미치므로 의사 결정 능력에 영향을 미치지 않으므로 전략 A를 사용하기로 결정합니다.
해싱 알고리즘 선택
키를 생성하기 위해 해시 기반 접근 방식을 채택하기로 결정합니다. 이렇게 하려면 이 접근 방식을 지원하는 해싱 알고리즘을 선택해야 합니다.
SHA-256을 선택했다고 가정해 보겠습니다. MD5와 같이 더 간단하고 보안 수준이 낮은 알고리즘을 사용할 수도 있습니다.
브라우저에서: 키 및 값 설정
키 구조와 해싱 알고리즘을 결정했으므로 사용자가 광고를 클릭하거나 본 후 전환할 때 키와 값을 등록할 수 있습니다.
다음은 브라우저에서 키와 값을 등록하기 위해 설정하는 헤더의 개요입니다.
![조회 또는 클릭에 대한 키와 값을 등록합니다.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/register-keys-values-a-59763f86a1f19.png?authuser=7&hl=ko)
![전환을 위한 키와 값을 등록합니다.](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/register-keys-values-a-155f081dc7bca.png?authuser=7&hl=ko)
소스 측 키 조각 설정
사용자가 광고를 클릭하거나 볼 때 Attribution-Reporting-Register-Aggregatable-Source
헤더에 집계 키를 설정합니다.
이 단계에서는 각 키에 대해 광고 게재 시 알려진 키의 일부 또는
키 조각만 설정할 수 있습니다.
핵심 요소를 생성해 보겠습니다.
키 ID의 소스 측 키 조각... | 설정하려는 측정기준 값이 포함된 문자열 | 16진수로 표시된 이 문자열의 해시로, 첫 64비트로 자릅니다 (64/4 = 16자1). | 0이 추가된 16진수 해시는 XOR 처리를 간소화 합니다. 이는 소스 측 키 조각입니다. |
---|---|---|---|
key_purchaseCount |
COUNT, CampaignID=12, GeoID=7 |
0x3cf867903fbb73ec | 0x3cf867903fbb73ec0000000000000000 |
key_purchaseValue |
VALUE, CampaignID=12, GeoID=7 |
0x245265f432f16e73 | 0x245265f432f16e7300000000000000000x245265f432f16e730000000000000000 |
이제 주요 요소를 설정해 보겠습니다.
// 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
헤더를 통해 해당 전환의 집계 가능한 가치를 설정합니다.
트리거 측 키 조각을 설정하여 키 완성
핵심 요소를 생성해 보겠습니다.
키 ID의 트리거 측 키 조각... | 설정하려는 측정기준 값이 포함된 문자열 | 16진수로 표시된 이 문자열의 해시로, 첫 64비트로 자릅니다 (64/4 = 16자1). | XOR 처리를 simplify하기 위해 0이 추가된 16진수 해시. 이것이 소스 측 키 조각입니다. |
---|---|---|---|
key_purchaseCount |
ProductCategory=25 |
0x1c7ce88c4904bbe2 | 0x0000000000000000f9e491fe37e55a0c |
key_purchaseValue |
(동일) | (동일) | (동일) |
이제 주요 요소를 설정해 보겠습니다.
// 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,000원에 제품 유형 25를 한 번 구매했다고 가정해 보겠습니다.
이러한 값은 집계 가능한 값으로 직접 설정하지 않습니다.
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
구매 수의 배율은 32,768/1 = 32,768입니다. 광고 클릭 또는 조회당 최대 1개의 구매를 추적하기로 결정했기 때문입니다 (소스 이벤트).
이제 다음 값을 설정할 수 있습니다.
key_purchaseCount
: 1 × 32,768 = 32,768key_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 XOR 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 XOR 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
(총 구매 가치)에 관한 요약 데이터를 보려면 다음을 실행합니다.
요청하려는 측정항목1 | 소스 측 키 조각 | 트리거 측 키 피스 | 집계 서비스에 요청하는 키2 |
---|---|---|---|
총 구매 횟수 (COUNT ) |
0x3cf867903fbb73ec 0000000000000000 |
0x00000000000000 00f9e491fe37e55a0c |
0x3cf867903fbb73 ecf9e491fe37e55a0c |
총 구매 가치 (VALUE ) |
0x245265f432f16e73 0000000000000000 |
0x0000000000000000 f9e491fe37e55a0c |
0x245265f432f16e73 f9e491fe37e55a0c |
- 이러한 키의 집계 서비스에 요약 데이터를 요청합니다.
요약 보고서 처리
최종적으로 다음과 같은 요약 보고서를 받게 됩니다.
[
{"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.
따라서 요약 보고서는 다음과 같은 정보를 제공합니다.
- 보고서 기간 동안 유럽에서 실행된 캠페인 #12에서 제품 카테고리 25에 대해 약 156건의 구매 (± 노이즈)가 발생했습니다.
- 보고서 기간 동안 유럽에서 실행된 캠페인 #12는 제품 카테고리 #25에 대해 $31,230의 구매 (± 노이즈)를 유도했습니다.