Attribution Reporting의 집계 키 이해

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

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

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

많은 광고 기술 회사에서는 광고주가 다양한 전환 유형을 구성하도록 권장하지만, 구매와 같은 가장 중요한 전환에 초점을 맞추는 것이 이러한 중요한 이벤트에 대한 요약 결과를 자세하고 정확하게 확인할 수 있는 좋은 방법입니다.

이를 위해서는 데이터가 수집되기 전에 어떤 질문에 답변할지 생각해봐야 합니다.

크기, 키, 값

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

측정기준

여기에 설명된 대로 캠페인에서 수익이 발생하는 방식을 이해하려면 다음 측정기준을 추적하는 것이 좋습니다.

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

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

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

캠페인 ID, 지역 ID, 제품 카테고리
추적할 측정기준

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

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

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

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

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

전환의 집계 키입니다.

나중에 집계 키가 실제로 이와 똑같지 않다는 것을 알게 되지만 지금은 키에 포함된 정보에 집중해 보겠습니다.

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

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

  • 구매 횟수입니다. 집계되어 요약 보고서에 제공되면 이 값이 총 구매 건수 (요약 값)가 됩니다.
  • 각 구매의 수익(구매 가치)입니다. 집계되어 요약 보고서에 제공되면 이 금액이 총 수익 (요약 값)이 됩니다.

전환당 구매 횟수와 전환당 구매 가치는 각각 집계 가능한 값입니다. 집계 가능한 값을 측정 목표의 가치로 생각하면 됩니다.

질문 집계 가능한 값 = 측정 목표
구매 건수... 구매 수
수익 구매 가치

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

집계 키 및 값.
집계 키 및 집계 가능한 값입니다. 집계 가능한 값은 파란색 배경에 굵게 표시됩니다.

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

집계된 통계를 생성하는 중입니다.

집계 가능한 값을 합산하여 측정 목표에 대한 집계된 통계를 생성합니다.

이 다이어그램에서는 복호화를 생략하고 노이즈가 적용되지 않은 단순화된 예시를 보여줍니다. 다음 섹션에서는 이 예를 노이즈와 함께 간략하게 살펴보겠습니다.

키와 값에서 보고서로

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

집계 가능한 보고서

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

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

참여 2건을 생성하고 있습니다.

나중에 {집계 키, 집계 가능 값} 집계 가능 보고서가 이와 정확히 일치하지 않는 것을 확인할 수 있습니다. 하지만 지금은 보고서에 포함된 정보에 집중하겠습니다.

브라우저에 두 가지 기여도를 생성하도록 지시하면 브라우저는 전환을 이전 조회 또는 클릭과 일치시킬 수 있는 경우 집계 가능한 보고서를 생성합니다.

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

그 결과로 생성되는 집계 가능한 보고서입니다.

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

페이로드에는 {집계 키, 집계 가능한 값} 쌍인 기여 목록이 포함됩니다.

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

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

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

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

요약 보고서

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

  • 광고 기술은 지정된 키 모음에 관한 요약 보고서와 다양한 브라우저 (사용자)에서 가져오는 집계 가능한 특정 보고서 집합을 요청합니다.
  • 집계 가능한 보고서는 집계 서비스를 통해 복호화됩니다.
  • 키마다 집계 가능한 보고서의 집계 가능한 값이 합산됩니다.
  • 노이즈가 요약 값에 추가됩니다.
집계 가능한 보고서와 집계, 복호화, 노이즈 결과를 결합하면 요약 보고서가 생성됩니다.

결과로 {집계 키, 요약 값} 쌍 집합이 포함된 요약 보고서가 생성됩니다.

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

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

예:

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

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

집계 키의 실제 사용

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

키 구조

키에 인코딩된 측정기준 집합을 지정할 때 키 구조라는 용어를 사용합니다.

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

키 구조

키 유형

집계 가능한 값은 여러 사용자/브라우저에서 특정 키에 대해 합산됩니다. 하지만 집계 가능한 가치로 구매 가치, 구매 횟수 등 다양한 측정 목표를 추적할 수 있습니다. 집계 서비스가 동일한 유형의 집계 가능한 값을 합산하도록 하려면 어떻게 해야 하나요?

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

위의 예를 사용하면 이 측정 목표 유형에는 두 가지 값이 있을 수 있습니다.

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

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

키의 측정기준은 측정항목이라고 생각할 수 있습니다. 예: '지역별 캠페인별 특정 제품 구매 횟수'

키 크기, 측정기준 크기

최대 키 크기는 비트 단위로 정의됩니다. 비트 단위는 전체 키를 만드는 데 필요한 0과 1의 개수입니다. API는 키 길이가 128비트가 될 수 있도록 허용합니다.

이 크기로 인해 매우 세분화된 키가 허용되지만, 키가 더 세분화되면 노이즈가 더 많은 값으로 이어질 가능성이 높습니다. 노이즈 이해하기에서 노이즈에 관해 자세히 알아보세요.

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

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

7비트는 필요한 200개보다 적은 27 = 128개의 고유 옵션만 저장합니다.

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

키 인코딩

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

전체 키를 위한 키 2개 설정하기

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

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

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

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

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

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

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

핵심 요소를 OR로 변환합니다.

예:

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

주요 부분 정렬

신중하게 배치된 64비트 필러/오프셋 (16개 0)을 사용하여 128비트로 확장된 두 개의 64비트 키 조각을 OR-ing하는 것은 이를 연결하는 것과 같으므로 다음과 같이 추론하고 확인하기가 더 쉽습니다.

  • 소스 측 키 조각 = 0xa7e297e7c8c8d0540000000000000000
  • 트리거 측 키 조각 = 0x0000000000000000674fbe308a597271
  • 키 = 0xa7e297e7c8c8d0540000000000000000 v 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)입니다.

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

키 구조 맵

키 내 측정기준의 순서는 사용자가 결정합니다.

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

각 측정기준 내에서 최상위 비트(숫자 값이 가장 큰 비트)는 맨 왼쪽 비트입니다. 최소 자릿수(가장 작은 숫자 값을 전달하는 자릿수)는 가장 오른쪽 자릿수입니다.

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

0b1100100111100을 임의의 예시 키로 사용하고, 이 키가 이전 그림의 키 구조 맵을 따른다는 것을 알 수 있는 방법이 있다고 가정해 보겠습니다.

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

`11001 0 011 1100`

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

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

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

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

  1. 해싱 알고리즘을 선택합니다.
  2. 광고 게재 시 추적하려는 모든 측정기준과 그 값을 포함하는 문자열을 생성합니다. 소스 측 키 조각을 생성하려면 이 문자열을 해시하고 64비트 서픽스로 0을 추가하여 트리거 측 키 조각에 맞춰 정렬하고 OR을 더 쉽게 추론할 수 있습니다.
    • 소스 측 키 조각
      = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
    • COUNT는 키 구조 맵 접근 방식에서 measurementGoalType=0와 동일한 것을 인코딩합니다. COUNT은 약간 더 가볍고 더 명확합니다.
  3. 전환 시 추적하려는 모든 측정기준과 그 값을 포함하는 문자열을 생성합니다. 트리거 측 키 부분을 생성하려면 이 문자열을 해싱하고 64비트 0 접두사를 추가합니다.
    • 트리거 측 키 조각 = <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"))
    • 브라우저와 마찬가지로 또는 이러한 키 조각을 사용하여 브라우저가 이전에 생성한 것과 동일한 키를 생성합니다.
      • 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가지 제품 카테고리

측정 항목

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

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

구매 건수와 구매 금액을 모두 측정하고 총 구매 금액, 지역별 분류와 같은 다양한 중요한 집계 통계에 액세스할 수 있습니다. 이렇게 하면 노이즈가 적절하게 유지되고 기여도 예산을 간편하게 확장할 수 있습니다.

통화는 어떤가요?

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

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

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

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

목표를 키로 변환

측정 목표와 측정항목을 사용하면 다양한 주요 전략 옵션을 사용할 수 있습니다. 이러한 전략 중 두 가지를 집중적으로 살펴보겠습니다.

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

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

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

하나의 세분화된 키 구조

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

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

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

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

전략 A 요약 보고서

전략 A는 '단일 딥 트리' 전략으로 생각할 수 있습니다.

  • 요약 보고서의 각 요약 값은 추적하는 모든 측정기준과 연결됩니다.
  • 각 측정기준과 함께 요약 값을 롤업하여 보유한 측정기준의 수만큼 집계할 수 있습니다.

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

질문 답변
각 지역에서 가장 가치가 높은 제품 카테고리는 무엇인가요? 모든 캠페인에서 요약 보고서에 있는 요약 구매 건수 및 값의 합계를 구합니다.
이렇게 하면 지역 ID × 제품 카테고리별 구매 수 및 가치를 확인할 수 있습니다.
각 지역에서 여러 제품 카테고리의 구매 금액과 수를 비교합니다.
각 지역에서 어떤 캠페인 전략이 가장 효과적인가요? 모든 제품 카테고리의 요약 보고서에 있는 요약 구매 건수와 값을 합산합니다.
이렇게 하면 캠페인 ID × 지역 ID별 구매 수 및 가치를 확인할 수 있습니다.
각 지역에서 여러 캠페인의 구매 금액과 수를 비교합니다.

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

"각 지역의 각 캠페인에서 제품별로 얼마의 수익이 창출되었나요?"

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

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

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

키 구조 1과 키 구조 2

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

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

4가지 키 유형이 생성됩니다.

  • 키 유형 I-0: 키 구조 I, 구매 횟수
  • 키 유형 I-1: 키 구조 I, 구매 가치
  • 키 유형 II-0: 키 구조 II, 구매 횟수
  • 키 유형 II-1: 키 구조 II, 구매 가치

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

요약 보고서 전략 B

전략 B는 '두 개의 얕은 나무' 전략으로 생각할 수 있습니다.

  • 요약 보고서의 요약 값은 두 가지 작은 측정기준 집합 중 하나에 매핑됩니다.
  • 이러한 요약 값을 이러한 세트의 각 측정기준과 함께 롤업할 수 있습니다. 즉, 롤업할 측정기준이 적으므로 옵션 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 0x245265f432f16e7300000000000000000x245265f432f16e730000000000000000
1각 16진수는 4비트 (2진수)를 나타냅니다.

이제 핵심 요소를 설정해 보겠습니다.

// 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 (동일) (동일) (동일)
1각 16진수는 4비트(2진수)를 나타냅니다.

이제 주요 요소를 설정해 보겠습니다.

// 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

광고 클릭 또는 조회(소스 이벤트)당 최대 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 (총 구매 가치)의 요약 데이터를 보려면 다음을 실행합니다.
요청할 측정항목1 소스 측 키 조각 트리거 측 키 조각 집계 서비스에 요청하는 키2
총 구매 건수(COUNT) 0x3cf867903fbb73ec
0000000000000000
0x00000000000000
00f9e491fe37e55a0c
0x3cf867903fbb73
ecf9e491fe37e55a0c
총 구매 금액(VALUE) 0x245265f432f16e73
0000000000000000
0x0000000000000000
f9e491fe37e55a0c
0x245265f432f16e73
f9e491fe37e55a0c
1요청하려는 측정항목 (캠페인 ID 12 × 지역 ID 7 × 제품 카테고리 25) 2집계 서비스에 요청할 키 = 소스 측 키 조각 또는 트리거 측 키 조각
  • 집계 서비스에 이러한 키의 요약 데이터를 요청합니다.

요약 보고서 처리

최종적으로 다음과 같은 요약 보고서를 받게 됩니다.

[
  {"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.