집계 키의 정의, Attribution Reporting API에서의 사용 방법, 목표를 키로 변환하는 방법을 알아봅니다.
다양한 제품 카테고리에 대해 여러 위치에서 캠페인을 운영하는 광고 기술 회사는 광고주가 다음 질문에 답변할 수 있도록 지원하고자 합니다.
- 각 지역의 각 캠페인에서 각 제품 카테고리의 구매 수는 얼마인가요?
- 각 지역의 각 캠페인에서 제품 카테고리별로 발생한 수익은 얼마인가요?
많은 광고 기술 회사에서는 광고주가 다양한 전환 유형을 구성하도록 권장하지만, 구매와 같이 가장 중요한 전환에 집중하면 이러한 중요한 이벤트에 대한 요약 결과를 자세하고 정확하게 얻을 수 있습니다.
이를 위해서는 데이터가 수집되기 전에 어떤 질문에 답변할지 생각해봐야 합니다.
측정기준, 키, 값
이러한 질문에 답변하려면 측정기준, 키, 값을 살펴보겠습니다.
측정기준
캠페인에서 수익이 창출되는 방식을 파악하려면 여기에 설명된 대로 다음 측정기준을 추적해야 합니다.
- 광고 캠페인 ID: 특정 캠페인의 식별자입니다.
- 지역 ID: 광고가 게재된 지역입니다.
- 제품 카테고리: 판매자가 정의한 제품 유형입니다.
캠페인 ID 및 지역 ID 측정기준은 광고가 게재될 때 (광고 게재 시간) 알 수 있지만 제품 카테고리는 사용자가 전환을 완료할 때 (전환 시간) 트리거 이벤트에서 알 수 있습니다.
이 예시에서 추적하려는 측정기준은 다음 이미지와 같습니다.

집계 키 (버킷)란 무엇인가요?
집계 키와 버킷은 같은 것을 의미합니다. 집계 키는 보고서를 구성하는 데 사용되는 브라우저 API에서 사용됩니다. 버킷이라는 용어는 집계 가능 보고서 및 요약 보고서와 집계 서비스 API에서 사용됩니다.
집계 키 (줄여서 키)는 추적 중인 측정기준의 값을 나타내는 데이터입니다. 나중에 각 집계 키를 기준으로 데이터가 집계됩니다.
예를 들어 제품 카테고리, 지역 ID, 캠페인 ID 측정기준을 추적한다고 가정해 보겠습니다.
지역 ID 7에 있는 사용자가 캠페인 ID 12의 광고를 본 후 나중에 제품 카테고리 25의 제품을 구매하여 전환하는 경우 다음 이미지와 같은 집계 키를 설정할 수 있습니다.

실제로는 집계 키가 이와 정확히 일치하지 않음을 나중에 확인할 수 있지만 지금은 키에 포함된 정보에 집중하겠습니다.
집계 가능한 값이란 무엇인가요?
설명한 측정기준에 관해 궁금한 점을 파악하려면 다음 사항을 알아야 합니다.
- 구매 횟수입니다. 집계되어 요약 보고서에 제공되면 총 구매 건수 (요약 값)가 됩니다.
- 각 구매의 수익 (구매 가치)입니다. 집계되어 요약 보고서에 제공되면 총수익 (요약 값)이 됩니다.
전환당 구매 횟수와 전환당 구매 가치는 각각 집계 가능한 값입니다. 집계 가능한 값은 측정 목표의 값이라고 생각할 수 있습니다.
질문 | 집계 가능한 값 = 측정 목표 |
---|---|
구매 횟수… | 구매 수 |
수익은 얼마인가요? | 구매 가치 |
지역 ID 7에 있는 사용자가 캠페인 ID 12의 광고를 본 후 나중에 제품 카테고리 25의 제품을 120달러에 구매하여 전환하는 경우 (통화가 USD라고 가정) 다음과 같은 집계 키와 집계 가능한 값을 설정할 수 있습니다.

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

집계 가능한 값을 합산하여 측정 목표에 대한 집계된 통계를 생성합니다.
이 다이어그램에서는 복호화를 생략하고 노이즈가 적용되지 않은 단순화된 예시를 보여줍니다. 다음 섹션에서는 노이즈를 사용하여 이 예시를 간략히 설명합니다.
키 및 값에서 보고서로
이제 집계 가능한 키와 값이 보고서와 어떤 관련이 있는지 알아보겠습니다.
집계 가능한 보고서
사용자가 광고를 클릭하거나 조회한 후 나중에 전환하면 브라우저에 {집계 키, 집계 가능한 값} 쌍을 저장하도록 지시합니다.
이 예시에서 사용자가 광고를 클릭하거나 조회한 후 나중에 전환하면 측정 목표당 하나씩 두 개의 기여도를 생성하도록 브라우저에 지시합니다.

나중에 {집계 키, 집계 가능 값} 집계 가능 보고서가 이와 정확히 일치하지 않는 것을 알 수 있습니다. 하지만 지금은 보고서에 포함된 정보에 집중하겠습니다.
브라우저에 두 가지 기여도를 생성하도록 지시하면 브라우저는 전환을 이전 조회 또는 클릭과 일치시킬 수 있는 경우 집계 가능한 보고서를 생성합니다.
집계 가능한 보고서에는 다음이 포함됩니다.
- 구성한 참여 항목
- 클릭 또는 조회 이벤트 및 전환 이벤트에 관한 메타데이터(전환이 발생한 사이트 등) 집계 가능한 보고서의 모든 필드 보기

집계 가능한 보고서는 JSON 형식이며 최종 요약 보고서의 데이터 입력으로 사용되는 페이로드 필드가 포함됩니다.
페이로드에는 각 항목이 {집계 키, 집계 가능한 값} 쌍인 기여 목록이 포함됩니다.
bucket
: 바이트 문자열로 인코딩된 집계 키입니다.value
: 해당 측정 목표의 집계 가능한 값으로, 바이트 문자열로 인코딩됩니다.
예를 들면 다음과 같습니다.
{
"data": [
{
"bucket": "111001001",
"value": "11111010000",
}
],
"operation": "histogram"
}
실제로는 집계 가능한 보고서는 버킷과 값이 이전 예와 다르게 보이도록 인코딩됩니다 (즉, 버킷이 \u0000\u0000\x80\u0000
처럼 보일 수 있음). 버킷과 값은 모두 바이트 문자열입니다.
요약 보고서
집계 가능한 보고서는 다음과 같이 여러 브라우저 및 기기 (사용자)에서 집계됩니다.
- 광고 기술은 특정 키 집합에 대한 요약 보고서와 여러 브라우저 (사용자)에서 가져온 집계 가능한 보고서 집합을 요청합니다.
- 집계 가능한 보고서는 집계 서비스에서 복호화합니다.
- 각 키에 대해 집계 가능한 보고서의 집계 가능한 값이 합산됩니다.
- 요약 값에 노이즈가 추가됩니다.

결과는 {집계 키, 요약 값} 쌍의 집합이 포함된 요약 보고서입니다.
요약 보고서에는 JSON 사전 스타일의 키-값 쌍 집합이 포함됩니다. 각 쌍에는 다음이 포함됩니다.
bucket
: 바이트 문자열로 인코딩된 집계 키입니다.value
: 사용 가능한 모든 집계 가능한 보고서에서 합산된 특정 측정 목표의 요약 값(소수점 이하 자릿수 포함)으로, 노이즈 수준이 추가됩니다.
예:
[
{"bucket": "111001001", "value": "2558500"},
{"bucket": "111101001", "value": "3256211"},
{...}
]
실제로는 요약 보고서가 버킷과 값이 예시와 다르게 보이도록 인코딩됩니다 (즉, 버킷이 \u0000\u0000\x80\u0000
처럼 보일 수 있음). 버킷과 값은 모두 바이트 문자열입니다.
집계 키의 실제 사용
집계 키 (버킷)는 광고 기술 회사에서 정의하며, 일반적으로 광고가 클릭되거나 조회될 때와 사용자가 전환할 때 두 단계로 정의됩니다.
키 구조
키에 인코딩된 측정기준 집합을 지정하는 데 키 구조라는 용어를 사용합니다.
예를 들어 캠페인 ID × GeoID × 제품 카테고리가 핵심 구조입니다.

키 유형
집계 가능한 값은 여러 사용자/브라우저에서 지정된 키에 대해 합산됩니다. 하지만 집계 가능한 값은 구매 가치나 구매 횟수와 같은 다양한 측정 목표를 추적할 수 있습니다. 집계 서비스가 동일한 유형의 집계 가능한 값을 합산하도록 하려면 어떻게 해야 하나요?
이렇게 하려면 각 키 내에 요약 값이 나타내는 내용(이 키가 참조하는 측정 목표)을 나타내는 데이터를 인코딩합니다. 측정 목표 유형을 나타내는 측정기준을 키에 추가하는 방법이 있습니다.
위의 예를 사용하면 이 측정 목표 유형에는 두 가지 값이 있을 수 있습니다.
- 구매 건수는 첫 번째 유형의 측정 목표입니다.
- 구매 가치는 두 번째 유형의 측정 목표입니다.

측정 목표가 n개 있는 경우 측정 목표 유형에는 n개의 서로 다른 유형의 값이 있습니다.
키의 측정기준은 측정항목이라고 생각할 수 있습니다. 예를 들어 '지역별 캠페인당 특정 제품의 구매 수'입니다.
키 크기, 측정기준 크기
최대 키 크기는 비트 단위로 정의됩니다. 비트 단위는 전체 키를 만드는 데 필요한 0과 1의 개수입니다. 이 API는 키 길이가 128비트가 될 수 있습니다.
이 크기를 사용하면 매우 세분화된 키를 사용할 수 있지만, 키가 더 세분화될수록 노이즈가 더 많은 값이 발생할 가능성이 높습니다. 노이즈 이해하기에서 노이즈에 관해 자세히 알아보세요.
앞에서 설명한 대로 측정기준은 집계 키에 인코딩됩니다. 각 측정기준에는 특정 카디널리티(측정기준이 가질 수 있는 고유한 값의 수)가 있습니다. 카디널리티에 따라 각 측정기준은 특정 비트 수로 표시되어야 합니다. n 비트로 2n개의 고유한 옵션을 표현할 수 있습니다.
예를 들어 전 세계에 약 200개의 국가가 있으므로 국가 측정기준의 카디널리티는 200일 수 있습니다. 이 측정기준을 인코딩하는 데 필요한 비트 수는 얼마인가요?
7비트는 27 = 128개의 고유한 옵션만 저장할 수 있으므로 필요한 200개보다 적습니다.
8비트는 28 = 256개의 고유한 옵션을 저장할 수 있으므로 필요한 200개보다 많습니다. 따라서 n=8비트를 사용하여 이 측정기준을 인코딩할 수 있습니다.
키 인코딩
브라우저에서 키를 설정할 때는 16진수로 인코딩해야 합니다. 요약 보고서에는 키가 바이너리로 표시되며 버킷 이름이 지정됩니다.
전체 키의 두 키 조각 설정
키를 사용하여 다음 측정기준을 추적한다고 가정해 보겠습니다.
- 캠페인 ID
- 지역 ID
- 제품 카테고리
캠페인 ID 및 지역 ID 측정기준은 광고가 게재될 때 (광고 게재 시간) 알 수 있지만 제품 카테고리는 사용자가 전환을 완료할 때 (전환 시간) 트리거 이벤트에서 알 수 있습니다.
실제로는 다음 두 단계로 키를 설정합니다.
- 클릭 또는 조회 시 키의 일부인 캠페인 ID × 지역 ID를 설정합니다.
- 키의 두 번째 부분인 제품 카테고리는 전환 시 설정합니다.
키의 이러한 여러 부분을 키 조각이라고 합니다.
키는 키 조각의 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비트 (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)입니다.
이 예에서 이러한 키의 키 구조 맵은 다음과 같습니다.

키 내 측정기준의 순서는 개발자가 결정합니다.
측정기준이 키 구조를 구성하는 방식을 설명하기 위해 바이너리 표현을 사용합니다. 따라서 캠페인 ID (첫 번째 비트)가 가장 오른쪽에 있고 제품 카테고리 (마지막 비트)가 가장 왼쪽에 있습니다.
각 측정기준 내에서 최상위 비트(숫자 값이 가장 큰 비트)는 맨 왼쪽 비트입니다. 최솟값 비트(가장 작은 숫자 값을 전달하는 비트)는 가장 오른쪽 비트입니다.
키 구조 맵을 사용하여 키를 디코딩하는 방법을 살펴보겠습니다.
0b1100100111100을 임의의 키 예시로 들고 이 키가 이전 그림의 키 구조 맵을 따른다는 것을 알 수 있는 방법이 있다고 가정해 보겠습니다.
키 구조 맵에 따라 이 키는 다음과 같이 디코딩됩니다.
`11001 0 011 1100`
따라서 키 0b1100100111100은 유럽에서 시작된 캠페인 ID 12의 제품 카테고리 25 구매 수를 나타냅니다.
해시 함수를 사용하여 측정기준 인코딩
키 구조 맵을 사용하는 대신 해싱 함수를 사용하여 일관되고 안정적인 방식으로 키를 동적으로 생성할 수 있습니다.
작동 방식은 다음과 같습니다.
- 해싱 알고리즘을 선택합니다.
- 광고 게재 시 추적하려는 모든 측정기준과 해당 측정기준의 값을 포함하는 문자열을 생성합니다. 소스 측 키 조각을 생성하려면 이 문자열을 해싱하고 0으로 된 64비트 접미사를 추가하여 트리거 측 키 조각과 정렬하고 OR를 더 쉽게 추론할 수 있도록 합니다.
- 소스 측 키 조각
=<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")>
- 트리거 측 키 조각
=
- 브라우저는 이러한 키 조각을 OR 연산하여 키를 생성합니다.
- 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"))
- 소스 측 키 조각
- 브라우저와 마찬가지로 이러한 키 조각을 사용하여 브라우저에서 이전에 생성한 것과 동일한 키를 생성합니다.
- 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
는 다른 모든 측정기준과 개념적으로 약간 다른 정보를 인코딩하기 때문입니다. - 키에서 사용 중인 측정기준 집합을 추적합니다. 사용한 적이 없는 측정기준 세트를 기반으로 키를 생성하지 않으려고 합니다.
- 적절한 해시 함수를 사용하는 경우 해시 충돌은 드물지만 이전에 사용된 해시 (집계 서비스의 결과를 해석하기 위해 저장해야 함)를 확인하면 이전 키와 충돌하는 새 키를 도입하지 않을 수 있습니다.
클릭 또는 조회당 전환 하나 예시에서 해시 기반 키를 실제로 사용하는 방법을 참고하세요.
실제로 집계 가능한 값
광고 기술 회사는 사용자가 전환할 때 집계 가능한 값을 설정합니다.
사용자 개인 정보를 보호하기 위해 각 사용자의 참여도에 상한선이 있습니다. 단일 소스 (광고 클릭 또는 조회)와 연결된 집계 가능한 모든 값 중 특정 기여도 한도를 초과하는 값은 없습니다.
이 제한을 CONTRIBUTION_BUDGET
라고 합니다. 설명에서는 이 한도를 L1 예산이라고 하지만 CONTRIBUTION_BUDGET
과 동일합니다.
기여 예산에 대한 자세한 내용은 요약 보고서의 기여 예산을 참고하세요.
예: 클릭 또는 조회당 전환 1회
이 예에서는 다음 질문에 답변하려고 한다고 가정해 보겠습니다.
- 각 지역에서 가장 가치 있는 제품 카테고리는 무엇인가요?
- 각 지역에서 가장 효과적인 캠페인 전략은 무엇인가요?
또한 사용 사례에 주간 통계가 필요하다고 가정해 보겠습니다.
다음 사항도 추적해야 합니다.
- 16개의 서로 다른 캠페인
- 8개의 지리적 지역: 북미, 중앙아메리카, 남미, 유럽, 아프리카, 아시아, 카리브해, 오세아니아
- 29개의 다양한 제품 카테고리
측정 항목
많은 광고 기술 회사에서는 광고주가 다양한 전환 유형을 구성하도록 권장하지만, 구매와 같이 가장 중요한 전환에 집중하면 이러한 중요한 전환 이벤트에 대한 집계 결과를 자세하고 정확하게 얻을 수 있습니다. 실제로 측정하는 측정항목이 많을수록 측정항목당 기여도 예산이 작아지므로 각 값의 노이즈가 더 클 수 있습니다. 따라서 측정할 항목을 신중하게 선택해야 합니다.
이 예에서는 클릭 또는 조회당 하나의 전환(구매)만 측정하는 캠페인 설정에 중점을 둘 것입니다.
구매 건수와 구매 금액을 모두 측정하고 총 구매 금액, 지역별 분류 등 다양한 중요한 집계 통계에 액세스할 수 있습니다. 이렇게 하면 노이즈가 적절하게 유지되고 기여도 예산을 간편하게 확장할 수 있습니다.
통화는 어떻게 되나요?
여러 지역에서 캠페인을 운영하려면 통화를 고려해야 합니다. 다음과 같은 방법을 사용할 수 있습니다.
- 집계 키에서 통화를 전용 측정기준으로 만듭니다.
- 또는 캠페인 ID에서 통화를 추론하고 모든 통화를 참조 통화로 변환합니다.
이 예에서는 캠페인 ID에서 통화를 추론할 수 있다고 가정합니다. 이렇게 하면 지정된 구매 금액을 사용자의 현지 통화에서 원하는 참조 통화로 변환할 수 있습니다. 사용자가 상품을 구매할 때 즉시 전환을 실행할 수도 있습니다.
이 기법을 사용하면 집계 가능한 모든 값이 동일한 참조 통화를 사용하므로 합산하여 총 집계된 구매 가치(요약 구매 가치)를 생성할 수 있습니다.
목표를 키로 변환
측정 목표와 측정항목을 사용하면 주요 전략에 다양한 옵션을 적용할 수 있습니다. 다음 두 가지 전략에 중점을 두겠습니다.
- 전략 A: 세분화된 키 구조 하나
- 전략 B: 두 개의 대략적인 키 구조
전략 A: 하나의 깊은 트리 (하나의 세분화된 키 구조)
전략 A에서는 필요한 모든 측정기준이 포함된 세분화된 키 구조를 하나 사용합니다.

모든 키는 이 구조를 사용합니다.
두 가지 측정 목표를 지원하기 위해 이 키 구조를 두 가지 키 유형으로 분할합니다.
- 키 유형 0: 측정 목표 유형 = 0으로, 구매 건수로 정의합니다.
- 키 유형 1: 측정 목표 유형 = 1(구매 가치로 정의)
요약 보고서는 다음과 같습니다.

전략 A는 '하나의 깊은 트리' 전략이라고 생각할 수 있습니다.
- 요약 보고서의 각 요약 값은 추적 중인 모든 측정기준과 연결됩니다.
- 이러한 요약 값을 각 측정기준과 함께 롤업할 수 있으므로 이러한 롤업은 측정기준의 수만큼 세부적으로 진행할 수 있습니다.
전략 A를 사용하면 다음과 같이 질문에 답변할 수 있습니다.
질문 | 답변 |
---|---|
각 지역에서 가장 가치 있는 제품 카테고리는 무엇인가요? | 모든 캠페인에서 요약 보고서에 있는 요약 구매 건수와 값의 합계를 구합니다. 이렇게 하면 지역 ID × 제품 카테고리별 구매 수 및 가치를 확인할 수 있습니다. 각 지역에서 여러 제품 카테고리의 구매 금액과 수를 비교합니다. |
각 지역에서 가장 효과적인 캠페인 전략은 무엇인가요? | 모든 제품 카테고리의 요약 보고서에 있는 요약 구매 건수와 값을 합산합니다. 이렇게 하면 캠페인 ID × 지역 ID별 구매 수 및 가치를 확인할 수 있습니다. 각 지역에서 여러 캠페인의 구매 금액과 수를 비교합니다. |
전략 A를 사용하면 다음 세 번째 질문에 직접 답변할 수도 있습니다.
"각 지역의 각 캠페인에서 제품별로 발생한 수익은 얼마인가요?"
요약 값에는 노이즈가 있더라도 각 캠페인 간에 측정된 값의 차이가 노이즈로 인한 것이 아닌 경우를 파악할 수 있습니다. 노이즈 이해하기에서 이를 실행하는 방법을 알아보세요.
전략 B: 얕은 트리 2개 (대략적인 키 구조 2개)
전략 B에서는 각각 필요한 측정기준의 하위 집합을 포함하는 두 가지 대략적인 키 구조를 사용합니다.

두 가지 측정 목표를 지원하기 위해 이러한 각 키 구조를 두 가지 키 유형으로 분할합니다.
- 측정 목표 유형 = 0으로, 구매 건수로 정의합니다.
- 측정 목표 유형 = 1(구매 가치로 정의)
4가지 주요 유형이 생성됩니다.
- 키 유형 I-0: 키 구조 I, 구매 횟수입니다.
- 키 유형 I-1: 키 구조 I, 구매 가치
- 키 유형 II-0: 키 구조 II, 구매 횟수입니다.
- 키 유형 II-1: 키 구조 II, 구매 가치
요약 보고서는 다음과 같습니다.

전략 B는 '얕은 트리 2개' 전략이라고 생각할 수 있습니다.
- 요약 보고서의 요약 값은 두 가지 작은 측정기준 세트 중 하나에 매핑됩니다.
- 이러한 요약 값을 이러한 세트의 각 측정기준과 함께 롤업할 수 있습니다. 즉, 롤업할 측정기준이 적으므로 옵션 A만큼 깊이 있는 롤업이 아닙니다.
전략 B를 사용하면 다음과 같이 질문에 답변할 수 있습니다.
질문 | 답변 |
---|---|
각 지역에서 가장 가치 있는 제품 카테고리는 무엇인가요? | 요약 보고서에 있는 요약 구매 수 및 값에 직접 액세스할 수 있습니다. |
각 지역에서 가장 효과적인 캠페인 전략은 무엇인가요? | 요약 보고서에 있는 요약 구매 수 및 값에 직접 액세스할 수 있습니다. |
결정: 전략 A
전략 A가 더 간단합니다. 모든 데이터가 동일한 키 구조를 따르므로 유지해야 할 키 구조가 하나뿐입니다.
하지만 전략 A를 사용하면 일부 질문에 답변하기 위해 요약 보고서에서 수신한 요약 값을 합산해야 합니다. 이러한 요약 값은 각각 노이즈가 있습니다. 이 데이터를 합산하면 노이즈도 합산됩니다.
전략 B의 경우는 다릅니다. 요약 보고서에 노출된 요약 값에서 이미 필요한 정보를 얻을 수 있습니다. 즉, 전략 B는 전략 A보다 노이즈의 영향을 덜 받을 가능성이 높습니다.
어떤 전략을 사용해야 할지 어떻게 결정해야 하나요? 기존 광고주 또는 캠페인의 경우 과거 데이터를 토대로 전환수가 전략 A에 더 적합한지 아니면 전략 B에 더 적합한지 판단할 수 있습니다. 하지만 신규 광고주 또는 캠페인의 경우 다음과 같이 할 수 있습니다.
- 세분화된 키로 한 달 분량의 데이터를 수집합니다 (전략 A). 데이터 수집 기간을 연장하면 요약 값이 더 높아지고 노이즈는 상대적으로 줄어듭니다.
- 주간 전환수 및 구매 가치를 합리적으로 정확하게 평가합니다.
이 예에서는 전략 A를 사용하면 사용 사례에 적합하다고 생각되는 노이즈 비율이 발생할 만큼 주별 구매 횟수와 구매 금액이 충분히 높다고 가정해 보겠습니다.
전략 A가 더 간단하고 의사결정 능력에 영향을 미치지 않는 노이즈 영향을 미치므로 전략 A를 사용하기로 결정합니다.
해싱 알고리즘 선택
해시 기반 접근 방식을 사용하여 키를 생성하기로 결정합니다. 이렇게 하려면 이 접근 방식을 지원하는 해싱 알고리즘을 선택해야 합니다.
SHA-256을 선택했다고 가정해 보겠습니다. MD5와 같이 더 간단하고 안전하지 않은 알고리즘을 사용할 수도 있습니다.
브라우저에서 키 및 값 설정
이제 키 구조와 해싱 알고리즘을 결정했으므로 사용자가 광고를 클릭하거나 조회한 후 전환할 때 키와 값을 등록할 수 있습니다.
다음은 브라우저에 키와 값을 등록하기 위해 설정할 헤더에 관한 개요입니다.


소스 측 키 조각 설정
사용자가 광고를 클릭하거나 조회하면 Attribution-Reporting-Register-Aggregatable-Source
헤더에 집계 키를 설정합니다.
이 단계에서는 각 키에 대해 광고 게재 시 알려진 키의 일부 또는 키 조각만 설정할 수 있습니다.
주요 부분을 생성해 보겠습니다.
키 ID의 소스 측 키 조각… | 설정하려는 측정기준 값이 포함된 문자열 | 이 문자열의 해시(16진수)로, 처음 64비트(64/4 = 16자1)로 잘립니다. | OR 연산을 간소화 하기 위해 0이 추가된 16진수 해시입니다. 소스 측 핵심 요소입니다. |
---|---|---|---|
key_purchaseCount |
COUNT, CampaignID=12, GeoID=7 |
0x3cf867903fbb73ec | 0x3cf867903fbb73ec0000000000000000 |
key_purchaseValue |
VALUE, CampaignID=12, GeoID=7 |
0x245265f432f16e73 | 0x245265f432f16e730000000000000000 |
이제 주요 부분을 설정해 보겠습니다.
// 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)로 잘립니다. | OR 연산을 간소화하기 위해 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를 52달러에 1회 구매했다고 가정해 보겠습니다.
다음은 집계 가능한 값으로 직접 설정하지 않습니다.
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,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 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
(총 구매 금액)에 대한 요약 데이터를 보려면 다음 단계를 따르세요.
요청할 측정항목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달러
따라서 요약 보고서를 통해 다음과 같은 유용한 정보를 얻을 수 있습니다.
- 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.