Attribution Reporting API: 통합 가이드

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

안내가 다를 수 있으므로 Android의 개인 정보 보호 샌드박스 문서를 읽으면서 개발자 프리뷰 또는 베타 버튼을 사용하여 작업 중인 프로그램 버전을 선택하세요.


Attribution Reporting API는 당사자 간 사용자 식별자에 의존하지 않고 앱과 웹 전반에서 기여 분석 및 전환 측정을 위한 주요 사용 사례를 지원하도록 설계되었습니다. 현재 일반적인 설계와 비교할 때 Attribution Reporting API 구현자는 몇 가지 중요한 상위 수준 고려사항을 포함해야 합니다.

  • 이벤트 수준 보고서에는 낮은 충실도의 전환 데이터가 포함됩니다. 적은 수의 전환 가치가 효과적입니다.
  • 집계 가능한 보고서에는 충실도 높은 전환 데이터가 포함됩니다. 솔루션은 비즈니스 요구사항과 128비트 한도를 기준으로 집계 키를 설계해야 합니다.
  • 솔루션의 데이터 모델과 처리에는 사용 가능한 트리거의 비율 제한, 트리거 이벤트 전송에 걸리는 시간 지연, API에서 적용한 노이즈가 고려되어야 합니다.

통합 계획에 도움이 되도록 이 가이드에서는 포괄적 뷰를 제공하며, 여기에는 Android의 개인 정보 보호 샌드박스 개발자 프리뷰의 현재 단계에서 아직 구현되지 않은 기능이 포함될 수 있습니다. 이러한 경우에는 일정 안내가 제공됩니다.

이 문서에서는 소스를 사용하여 클릭 또는 조회를 나타내고 트리거를 사용하여 전환을 나타냅니다.

아래 차트에는 기여 분석 통합을 위한 여러 워크플로 옵션이 나와 있습니다. 같은 열에 나열된 섹션(초록색 원으로 표시됨)은 동시에 작업할 수 있습니다. 예를 들어 파트너 참여는 앱 간 이벤트 수준 기여 분석과 동시에 실행할 수 있습니다.

기여 분석 통합 워크플로 다이어그램

그림 1: 기여 분석 통합 워크플로

기본 요건 및 설정

Attribution Reporting API를 더 잘 이해하려면 이 섹션의 단계를 완료하세요. 이러한 단계를 통해, 광고 기술 생태계에서 이 API를 사용할 때 의미 있는 결과를 수집할 수 있습니다.

API 숙지

  1. Attribution Reporting API와 그 기능을 알아보려면 디자인 제안서를 참고하세요.
  2. 사용 사례에 필요할 코드와 API 호출을 통합하는 방법은 개발자 가이드를 참고하세요.
  3. 문서에 관한, 특히 미해결된 질문에 관한 의견을 제출하세요.
  4. 가입하여 Attribution Reporting API에 관한 업데이트를 받으세요. 이렇게 하면 향후 버전에서 도입되는 새로운 기능을 계속 확인할 수 있습니다.

샘플 앱 설정 및 테스트

  1. 통합을 시작할 준비가 되면 Android 스튜디오에서 최신 개발자 프리뷰를 사용합니다.
  2. 이벤트 등록 및 보고서 전송을 위한 모의 서버 엔드포인트를 설정합니다. 온라인에서 제공되는 도구와 함께 사용할 수 있는 모의 버전이 제공되었습니다.
  3. 소스 및 트리거 등록에 익숙해지도록 샘플 앱에서 코드를 다운로드하고 실행합니다.
    1. 보고서 전송 기간을 설정합니다. API는 2일이나 7일, 2~30일의 맞춤 기간을 지원합니다.
    2. 샘플 앱을 실행하고 사용하여 소스와 트리거를 등록하고 설정된 기간이 지나고 나면 이벤트 수준 보고서 및 암호화된 집계 가능한 보고서를 받았는지 확인합니다. 보고서를 디버그해야 하는 경우 보고 작업을 강제 실행하여 더 빠르게 보고서를 생성할 수 있습니다.
    3. 앱 간 기여 분석 결과를 검토합니다. 이러한 결과의 데이터가 마지막 터치 및 설치 후 사례에 대하여 모두 예상한 바와 같은지 확인합니다.

  4. 클라이언트 API와 서버가 함께 작동하는 방식을 파악한 후에는 샘플 앱을 예로 사용하여 자체 통합을 안내합니다. 자체 프로덕션 서버를 설정하고 앱에 이벤트 등록 호출을 추가합니다.

사전 통합

Android의 개인 정보 보호 샌드박스에 조직을 등록합니다. 이 등록은 광고 기술 플랫폼의 불필요한 중복을 방지하기 위해 설계되었으며, 이를 통해 사용자 활동에 필요한 것보다 더 많은 정보에 액세스할 수 있습니다.

파트너 참여

광고 기술 파트너(MMP/SSP/DSP)는 통합 기여 분석 솔루션을 만드는 경우가 많습니다. 이 섹션의 단계는 광고 기술 파트너와의 성공적인 소통을 준비하는 데 도움이 됩니다.

  1. 주요 측정 파트너와의 논의 일정을 예약하여 Attribution Reporting API의 테스트와 채택에 관해 논의합니다. 측정 파트너에는 광고 기술 네트워크, SSP, DSP, 광고주 또는 현재 협력 중이거나 협력하려는 기타 파트너가 포함될 수 있습니다.
  2. 측정 파트너와 협력하여 초기 테스트부터 채택까지 통합 일정을 정의합니다.
  3. 각각이 기여 분석 설계에 포함할 영역을 측정 파트너와 함께 명확히 합니다.
  4. 측정 파트너 간의 커뮤니케이션 채널을 설정하여 일정과 엔드 투 엔드 테스트를 동기화합니다.
  5. 측정 파트너 간에 대략적인 데이터 흐름을 설계합니다. 주요 고려사항은 다음과 같습니다.
    • 측정 파트너는 Attribution Reporting API에 기여 분석 소스를 어떻게 등록하나요?
    • 광고 기술 네트워크는 Attribution Reporting API에 트리거를 어떻게 등록하나요?
    • 각 광고 기술은 어떻게 API 요청을 검증하고 완전한 소스와 트리거 등록에 응답을 반환하나요?
    • Attribution Reporting API 외부의 파트너 간에 공유해야 하는 보고서가 있나요?
    • 파트너 간에 필요한 다른 통합 지점이나 조정이 있나요? 예를 들어 파트너와 전환 중복 삭제 작업을 해야 하나요? 아니면 집계 키를 조정해야 하나요?
  6. 앱과 웹 간 기여 분석이 적용되는 경우 웹에 관한 측정 파트너와의 논의 일정을 예약하여 Attribution Reporting API의 설계, 테스트, 채택을 논의합니다. 웹 파트너와의 대화를 시작할 때 이전 단계의 질문을 참고하세요.

앱 간 이벤트 수준 기여 분석 프로토타입 제작

이 섹션에서는 앱 또는 SDK의 이벤트 수준 보고서를 사용하여 기본 앱 간 기여 분석을 설정하는 방법을 설명합니다. 집계 서버 기여 분석 프로토타입 제작을 시작하려면 먼저 이 섹션을 완료해야 합니다.

  1. 이벤트 기록의 컬렉션 서버를 설정합니다. 제공된 사양을 사용하여 모의 서버를 생성하거나 [샘플 서버 코드][39]{:.external}로 자체 서버를 설정하면 됩니다.
  2. 광고가 표시될 때 SDK 또는 앱에 [소스 등록 이벤트 호출][22]을 추가합니다.
    • 중요한 고려사항은 다음과 같습니다.
      • 소스 이벤트 ID가 제공되고 소스 등록 API 호출에 올바르게 전달되는지 확인합니다.
      • `InputEvent`도 전달하여 클릭 소스를 등록할 수 있는지 확인합니다.
      • 다양한 이벤트 유형의 [소스 우선순위를 구성][23]하는 방법을 결정합니다. 예를 들어 조회보다 우선순위가 높은 클릭과 같이 가치가 높은 것으로 간주되는 이벤트에 높은 우선순위를 할당합니다.
      • 테스트용 만료의 기본값은 OK입니다. 또는 서로 다른 [만료 기간을 구성할 수 있습니다][24].
      • 필터 및 기여 산정 기간은 테스트를 위해 기본값으로 둘 수 있습니다.
    • 고려사항은 다음과 같습니다(선택사항).
      • 집계 키를 사용할 준비가 되면 설계합니다.
      • 다른 측정 파트너와 협력하는 방식을 설정할 때 리디렉션 전략을 고려합니다.
  3. SDK 또는 앱에 [트리거 등록 이벤트][25]를 추가하여 전환 이벤트를 기록합니다.
    • 중요한 고려사항은 다음과 같습니다.
      • [제한된 충실도 반환][26]을 고려하여 트리거 데이터 정의: 클릭에 사용할 수 있는 3비트와 조회에 사용할 수 있는 1비트에 관해 광고주에게 필요한 전환 유형 수를 어떻게 줄일 계획인가요?
      • [이벤트 보고서에서 사용 가능한 트리거 제한][3]: 이벤트 보고서에서 받을 수 있는 소스당 총 전환수를 어떻게 줄일 계획인가요?
    • 고려사항은 다음과 같습니다(선택사항).
      • 정확성 테스트를 할 때까지 중복 삭제 키 생성을 건너뜁니다.
      • [시뮬레이션 테스트 지원][7]이 준비될 때까지 집계 키와 값 생성을 건너뜁니다.
      • 다른 측정 파트너와 협력하는 방법을 설정할 때까지 리디렉션을 건너뜁니다.
      • 테스트의 경우 트리거 우선순위는 필수가 아닙니다.
      • 필터는 초기 테스트에서 무시될 수 있습니다.
  4. 광고의 소스 이벤트가 생성되고 트리거가 이벤트 보고서 생성을 유도하고 있는지 테스트합니다.

시뮬레이션 테스트

이 섹션에서는 현재 전환을 이벤트 및 집계 가능한 보고서로 이동함으로써 보고 및 최적화 시스템이 받는 영향을 테스트하는 방법을 설명합니다. 이를 통해 통합을 완료하기 전에 영향 테스트를 시작할 수 있습니다.

테스트는 보유하고 있는 이전 전환 기록을 기반으로 이벤트 및 집계 가능한 보고서 생성을 시뮬레이션한 다음, 시뮬레이션된 집계 서버에서 집계된 결과를 가져오는 방식으로 실행됩니다. 이러한 결과를 이전 전환수와 비교하여 보고 정확성이 어떻게 달라지는지 확인할 수 있습니다.

예상 전환율 계산 등의 최적화 모델을 이러한 보고서에서 학습시켜 이러한 모델의 정확성을 현재 데이터에 기반한 모델과 비교할 수 있습니다. 또한 다양한 집계 키 구조와 이러한 구조가 결과에 미치는 영향을 실험해 볼 수 있습니다.

  1. 로컬 시스템에서 측정 시뮬레이션 라이브러리를 설정합니다.
  2. 시뮬레이션된 보고서 생성기와 호환되도록 전환 데이터의 형식을 지정하는 방법에 관한 사양을 읽어봅니다.
  3. 비즈니스 요구사항에 따라 집계 키를 설계합니다.
    • 중요한 고려사항은 다음과 같습니다.
      • 클라이언트 또는 파트너가 집계해야 하는 중요한 측정기준을 고려하고 이러한 기준에 평가의 초점을 맞춥니다.
      • 요구사항에 필요한 집계 측정기준 및 카디널리티의 최소 개수를 결정합니다.
      • 소스 측 및 트리거 측 키 조각이 128비트를 초과하지 않는지 확인합니다.
      • 솔루션이 트리거 이벤트당 여러 값에 기여하는 경우 최대 기여 예산 L1에 따라 값을 조정해야 합니다. 이렇게 하면 노이즈의 영향을 최소화할 수 있습니다.
      • 다음 예를 통해 캠페인 수준에서 집계 전환수를 수집하는 키와 지역 수준에서 집계 구매 가치를 수집하는 키를 설정하는 방법을 자세히 알아볼 수 있습니다.
  4. 보고서 생성기를 실행하여 이벤트 및 집계 가능한 보고서를 생성합니다.
  5. 시뮬레이션된 집계 서버를 통해 집계 가능한 보고서를 실행하여 요약 보고서를 가져옵니다.
  6. 유틸리티 실험을 실행합니다.
    • 이벤트 수준 및 요약 보고서의 전환 총계를 이전 전환 데이터와 비교하여 전환 보고의 정확성을 판단합니다. 최상의 결과를 얻으려면 광고주 기반의 광범위하고 대표적인 부분에서 보고 테스트와 비교를 실행하세요.
    • 이벤트 수준 보고서 데이터와 잠재적인 요약 보고서 데이터를 기반으로 모델을 다시 학습시킵니다. 이전 학습 데이터를 기반으로 한 모델과 정확성을 비교합니다.
    • 다양한 배치 전략을 시도해 보고 결과에 어떤 영향을 미치는지 확인합니다.
      • 중요한 고려사항은 다음과 같습니다.
      • 입찰가 조정을 위한 요약 보고서의 적시성
      • 기기에서 발생한 기여 이벤트의 평균 빈도. 예를 들어 이전 구매 이벤트 데이터를 기반으로 재방문하는 중단한 사용자가 있습니다.
      • 노이즈 수준. 배치가 클수록 집계가 작고, 집계가 작을수록 노이즈가 더 많이 적용됩니다.

프로토타입 집계 서버 기여 분석: 설정

(3분기 후반에 제공) 이러한 단계를 통해 소스 및 트리거 이벤트에 관한 집계 가능한 보고서를 수신할 수 있습니다.

  1. 집계 서버를 설정합니다.
    • AWS 계정을 설정합니다.
    • 코디네이터를 통해 집계 서비스에 등록합니다.
    • 제공된 바이너리에서 AWS의 집계 서버를 설정합니다. (4분기 초에 제공)
  2. 비즈니스 요구사항에 따라 집계 키를 설계합니다. 앱 간 이벤트 수준 섹션에서 이 작업을 이미 완료했다면 이 단계를 건너뛰어도 됩니다.
  3. 집계 가능한 보고서의 컬렉션 서버를 설정합니다. 앱 간 이벤트 수준 섹션에서 이미 생성한 경우 이를 재사용해도 됩니다.

프로토타입 집계 서버 기여 분석: 통합

(3분기 후반에 제공): 이 지점 이후 계속 진행하려면 프로토타입 집계 서버 기여 분석: 설정 섹션 또는 프로토타입 앱 간 이벤트 수준 기여 분석 섹션을 완료해야 합니다.

  1. 소스 및 트리거 이벤트에 집계 키 데이터를 추가합니다. 이렇게 하려면 광고 이벤트에 관한 더 많은 데이터(예: 캠페인 ID)를 SDK 또는 앱에 전달하여 집계 키에 포함해야 할 수 있습니다.
  2. 집계 키 데이터로 등록한 소스 및 트리거 이벤트에서 앱 간 집계 가능한 보고서를 수집합니다.
  3. 집계 서버를 통해 이러한 집계 가능한 보고서를 실행할 때 다양한 배치 전략을 테스트하여 결과에 어떤 영향을 미치는지 확인합니다.

선택적 기능으로 설계 반복

다음은 측정 솔루션에 포함할 수 있는 추가 기능입니다.

  1. 디버그 키를 설정하면 Attribution Reporting API에서 생성된 보고서와 함께 소스 또는 트리거 이벤트의 변경되지 않은 보고서를 수신할 수 있습니다. 디버그 키를 사용하여 보고서를 비교하고 통합 중에 버그를 찾을 수 있습니다.

기여 분석 동작 맞춤설정

  1. 설치 후 트리거 기여 분석
    • 이 기능은 더 최근에 발생한 다른 적합한 기여 분석 소스가 있더라도 설치를 유도한 동일한 기여 분석 소스로 인해 설치 후 트리거가 발생해야 하는 경우에 사용할 수 있습니다.
    • 예를 들어 사용자가 설치를 유도하는 광고를 클릭하는 경우가 있을 수 있습니다. 설치된 후에는 사용자가 다른 광고를 클릭하고 구매합니다. 이 경우 광고 기술 회사는 재참여 클릭이 아닌 첫 번째 클릭에 구매 기여도를 부여할 수 있습니다.
  2. 필터를 사용하여 이벤트 수준 보고서의 데이터 미세 조정
    • 전환 필터는 선택된 트리거를 무시하고 이벤트 보고서에서 이를 제외하도록 설정할 수 있습니다. 기여 분석 소스당 트리거 수에 제한이 있으므로 필터를 사용하면 이벤트 보고서에 가장 유용한 정보를 제공하는 트리거만 포함할 수 있습니다.
    • 필터를 사용하여 일부 트리거를 선택적으로 필터링하여 사실상 무시할 수도 있습니다. 예를 들어 앱 설치를 타겟팅하는 캠페인이 있는 경우 설치 후 트리거가 해당 캠페인의 소스로 인해 발생하지 않도록 필터링할 수 있습니다.
    • 필터는 소스 데이터를 기반으로 트리거 데이터를 맞춤설정하는 데도 사용할 수 있습니다. 예를 들어 소스는 "product" : ["1234"]를 지정할 수 있습니다. 여기서 product는 필터 키이고 1234는 값입니다. 필터 키가 'product'이고 값이 '1234'가 아닌 트리거는 무시됩니다.
  3. 맞춤설정된 소스 및 트리거 우선순위
    • 여러 기여 분석 소스가 트리거와 연결될 수 있거나 여러 트리거가 소스에 기인할 수 있는 경우 서명된 64비트 정수를 사용하여 특정 소스/트리거 기여 분석을 다른 것보다 우선할 수 있습니다.

MMP 등과 협력

  1. 소스 및 트리거 이벤트를 위해 다른 서드 파티로 리디렉션
    • 여러 광고 기술 플랫폼에서 요청을 등록할 수 있도록 리디렉션 URL을 설정할 수 있습니다. 이는 기여 분석에서 교차 네트워크 중복 삭제를 사용 설정하는 데 사용할 수 있습니다.
  2. 중복 삭제 키
    • 광고주가 여러 광고 기술 플랫폼을 사용하여 동일한 트리거 이벤트를 등록하는 경우 이러한 반복된 보고서를 구별하는 데 중복 삭제 키를 사용할 수 있습니다. 중복 삭제 키가 제공되지 않으면 각 광고 기술 플랫폼에 중복 트리거가 고유한 것으로 보고될 수 있습니다.

크로스 플랫폼 측정 사용

  1. 교차 앱 및 웹 기여 분석(4분기 말에 제공)
    • 사용자가 앱에서 광고를 본 후 모바일 또는 앱 브라우저에서 전환하는 사용 사례를 지원합니다. 그 반대의 경우도 마찬가지입니다.