Protected Audience: 통합 가이드

Android의 Protected Audience(이전의 FLEDGE) 구현에는 일반적으로 광고주 앱과 게시자 앱, 판매자, 구매자 간의 통합이 포함됩니다. 이 가이드는 구매자와 판매자로 모두 운영되는 광고 기술 네트워크를 비롯하여, 맞춤 잠재고객을 관리하고 입찰을 실행하려는 파트너를 위해 작성되었습니다. 광고 캠페인마다 목표가 다를 수 있으며 모든 Protected Audience 기능이 모든 사용 사례에 사용되는 것은 아닙니다. 이 가이드에서는 가능하면 더 전문적인 사례를 지원하는 데 필요한 단계를 알아봅니다.

Protected Audience의 대규모 프로덕션 배포를 준비하기 위해 파트너는 다른 당사자와의 통합 지점을 모의 처리하여 테스트를 시작할 수 있습니다. 통합 계획에 도움이 되도록 이 가이드에서는 Android 앱과 Protected Audience를 통합하는 방법을 포괄적으로 설명합니다. 여기에는 Android의 개인 정보 보호 샌드박스 개발자 프리뷰의 현재 단계에서 아직 구현되지 않은 기능이 포함될 수 있습니다. 이러한 경우에는 일정 안내가 제공됩니다.

Protected Audience 통합 워크플로는 다양한 유형의 광고 기술 파트너가 주도하는 4가지 주요 단계로 구성됩니다.

1. 구매자가 맞춤 잠재고객을 생성합니다.
2. 광고 선택 프로세스에서 낙찰된 광고를 선택합니다.
   1. 판매자의 앱에서 광고 선택을 시작합니다.
   2. 광고 서비스에서 구매 측 필터링 및 입찰 코드를 실행합니다.
   3. 광고 서비스에서 판매 측 결정 코드를 실행합니다.
3. 낙찰된 광고가 판매자의 앱에서 렌더링됩니다.
4. 광고 노출 보고서가 구매자와 판매자에게 모두 제공됩니다.

다음 다이어그램에서는 이러한 단계를 보여줍니다.

Protected Audience 맞춤 잠재고객 관리 및 광고 선택 워크플로

용어

• 광고주: 광고 인벤토리를 구매하는 수단을 통해 사용자를 참여시키는 회사입니다.
• 게시자: 콘텐츠와 함께 제공되는 광고 인벤토리를 판매하는 회사입니다.
• 구매자: 광고주가 광고 인벤토리를 구매하도록 돕는 광고 기술 회사입니다.
• 판매자: 게시자가 광고 인벤토리를 판매하도록 돕는 광고 기술 회사입니다.
• 네트워크: 구매자와 판매자 역할을 모두 실행하는 광고 기술 회사입니다.
• 소유 및 운영: 게시자와 판매자, 구매자 역할을 하는 회사입니다.
• 통합 파트너: 위에 언급된 회사 중 Protected Audience와 성공적으로 통합하기 위해 협력해야 하는 모든 회사입니다.

기본 요건, 통합 파트너 참여, 설정

이 섹션에서는 Protected Audience의 작동 방식, Protected Audience 통합을 시작하는 방법, Protected Audience 구현 시 통합 파트너와 협력하는 방법을 이해할 수 있도록 일련의 초기 활동을 간략히 설명합니다. 이러한 활동은 동시에 발생할 수 있습니다.

Protected Audience 기능 출시 가이드

Protected Audience 숙지

첫 번째 단계는 Protected Audience API 및 서비스에 익숙해지는 것입니다.

1. 먼저 설계 제안서를 읽고 Protected Audience API와 그 기능을 익힙니다.
2. 사용 사례에 필요한 코드와 API 호출을 통합하는 방법과 Protected Audience와 통합하는 데 필요한 서비스는 개발자 가이드를 참고합니다.
3. Protected Audience API, 서비스, 문서의 설계와 구현에 관한 의견을 제출합니다.
4. 개인 정보 보호 샌드박스의 최신 기능에 관한 정보를 놓치지 않으려면 가입하여 최신 소식을 받아 봅니다.

샘플 앱 설정 및 테스트

앞에서 설명한 대로 Protected Audience 기본사항에 익숙해졌다면 샘플 앱을 설정하고 테스트해야 합니다.

1. 통합을 시작할 준비가 되면 최신 개인 정보 보호 샌드박스 개발자 프리뷰로 개발 환경을 설정합니다.
2. 필수 서버 엔드포인트를 설정합니다. 원하는 API 테스트 솔루션과 함께 모의 샘플을 사용하여 이 프로세스를 부트스트랩합니다.
3. 샘플 앱에서 코드를 포크하고 실행하여 맞춤 잠재고객 관리, 광고 선택 워크플로, 노출 보고서에 익숙해집니다.

통합 파트너 참여

통합 파트너와의 논의 일정을 예약하여 당사자 간에 전달되는 신호의 형태를 포함하여 Android에서 Protected Audience를 테스트하고 채택할 방법을 논의합니다. 구매자의 경우 논의에는 맞춤 잠재고객을 만들고 맞춤 잠재고객에 참여하는 전략이 포함되어야 하며, 여기에는 잠재고객 정의 방식에 관한 논의가 포함될 수 있습니다. 통합 파트너와 협력하여 초기 테스트부터 채택까지의 통합 일정과 각 당사자가 설계에서 담당하는 영역을 정의합니다.

베타 설정(4분기에 제공)

Android의 개인 정보 보호 샌드박스에 조직을 등록합니다. 등록은 광고 기술 개발자가 개인 정보 보호 샌드박스 정책 내에서 운영하도록 하는 데 필요하며, 등록을 통해 광고 기술 개발자는 여러 SDK 및 도메인에서 ID를 정의할 수 있습니다.

아키텍처 고려사항

구매자와 판매자 모두를 위해 Protected Audience에는 기기에서 광고 입찰을 실행하는 기능이 도입되었습니다. 개발자와 통합 파트너는 설계에서 다음과 같은 몇 가지 중요한 사항을 고려해야 합니다.

기기에 저장되는 잠재고객 및 리마케팅 광고

오늘날 광고를 완전히 서버에 저장하는 것과 달리 잠재고객 정보와 리마케팅 광고는 기기에 저장됩니다. 타겟팅을 위해 기기 내 데이터를 사용하지 않는 문맥 광고는 계속해서 서버에 남아 있게 됩니다. 광고 기술 플랫폼은 서버와 기기 사이에 분산된 광고 수요를 고려하기 위해 확장해야 합니다.

기기에서 이루어지는 입찰 프로세스

서버에서 입찰을 실행하는 것 외에도 광고 기술 플랫폼은 이제 기기에 저장된 광고 수요의 가격을 책정하고 순위를 지정할 수 있습니다.

일반적인 접근 방식은 광고 기술이 오늘날 실행하는 것과 같이 문맥 광고 입찰을 실행하는 것입니다. 입찰을 완료한 후 판매자는 기기에서 입찰을 실행하여 기기에 저장된 리마케팅 수요를 평가할 수 있습니다. 이제 이러한 프로세스가 기기에서 실행되는 점을 감안하면 여러 통합 파트너가 설계한 대로 다양한 리마케팅 사용 사례에서 입찰이 처음부터 끝까지 실행되도록 기존 제한을 기억해야 합니다.

데이터 전략

광고 기술 플랫폼은 입찰에 사용되는 데이터 유형을 고려해야 합니다. 오늘날 이 정보는 다양한 소스에서 수집된 후 서버에서 중앙 집중화됩니다. Protected Audience 입찰에서는 이러한 데이터를 전달할 여러 경로를 제공합니다. 예를 들어 잔여 예산과 같은 실시간 신호는 키-값 서비스에서 신뢰할 수 있는 신호로 제공되고 시간과 같은 문맥 신호는 입찰을 실행할 때 판매자로부터 전송됩니다. 이러한 신호에 관한 자세한 내용은 이 가이드의 관련 섹션을 참고하세요.

솔루션 빌드

Protected Audience에서 입찰을 실행하는 주요 단계는 다음과 같습니다. 구매자는 잠재고객을 구축하고, 입찰 데이터를 제공하고, 잠재고객에게 광고를 타겟팅하고, 입찰을 설정해야 합니다. 판매자는 입찰을 구성 및 트리거하고, 조합 광고를 채점하고, 낙찰자를 선택해야 합니다. 일부 단계에서는 입찰이 올바르게 실행될 수 있도록 양측의 협력이 필요합니다. 아래 섹션에서는 각 단계를 자세히 설명하고 구현을 담당하는 당사자를 명시적으로 설명합니다.

구매자: 잠재고객 구축

일반적으로 구매자는 맞춤 잠재고객을 관리합니다. 맞춤 잠재고객은 기기에서 관리되므로 맞춤 잠재고객을 관리하는 API는 기기에서 호출되도록 설계되었습니다.

광고주 앱에 자체 SDK가 있는 경우 joinCustomAudience()를 통해 이 코드를 직접 구현할 수 있습니다.

기기에 자체 SDK 코드가 없다면 SDK 제공업체이기도 한 기존 통합 파트너와 협력하는 것을 고려할 수 있습니다. 이러한 파트너를 찾아 협력하여 맞춤 잠재고객을 정의하고 관리하기 위한 계약과 흐름을 정의합니다. 이 가이드에서는 사용되는 접근 방식과 관계없이 '구매자'라는 용어를 사용합니다. 다음은 몇 가지 접근 방식의 예입니다.

• 구매자는 광고주가 잠재고객을 정의하도록 합니다. 기기의 통합 파트너 SDK는 구매자에게 앱 이벤트를 전송할 수 있습니다. 사전 정의된 기준이 충족되면 구매자는 SDK에 메시지를 전송하여 구매자를 대신하여 클라이언트에서 맞춤 잠재고객에 참여하도록 합니다.
• SDK는 잠재고객을 직접 소유할 수 있습니다. 광고주는 SDK 제공업체와 협력하여 잠재고객을 정의합니다. SDK는 앱 이벤트를 모니터링하고 적절한 때에 잠재고객에 참여하며 구매자에게 사용자가 잠재고객에 가입되었음을 알립니다.

프로토타입 리마케팅 캠페인: 맞춤 잠재고객 설계

맞춤 잠재고객은 개인 맞춤 광고를 게재할 수 있는 유사한 관심분야를 가진 사용자 그룹입니다. 구매자는 광고주가 사용자 활동을 기반으로 앱에 맞춤 잠재고객을 구축하도록 지원할 수 있습니다.

Protected Audience는 광고주가 정의한 특정 맞춤 사용자 참여에 매핑되는 맞춤 잠재고객을 위한 컨테이너를 설정합니다. 여기에는 해당 잠재고객에게 표시할 수 있는 조합 광고 컬렉션 및 입찰 중에 광고를 필터링하고 가격을 책정하는 데 사용할 수 있는 맞춤 입찰 로직 및 데이터 컬렉션이 포함됩니다.

설정 및 프로토타입

• 맞춤 잠재고객 API를 사용하여 나중에 입찰에서 사용할 수 있는 잠재고객을 만들고 기기에 저장합니다.
• 구현 및 API 사용 세부정보는 개발자 가이드를 참고하세요.

설계 고려사항

구매자는 맞춤 잠재고객을 구성하여 다양한 사용 사례를 지원할 수 있습니다. 여기에는 이 잠재고객을 타겟팅하는 광고 또는 캠페인 유형에 관한 입찰 로직 정의와 조합 광고 목록 정의, 이와 유사한 고려사항이 포함됩니다. 이 섹션에는 맞춤 잠재고객의 일부 주요 필드를 채우고 사용하기 위한 설계 고려사항이 포함되어 있습니다.

입찰 로직 URL

입찰은 기기에서 실행되므로 구매자는 입찰 로직을 자바스크립트로 반환할 수 있는 엔드포인트를 배포해야 합니다. 개발자 가이드에서는 필요한 메서드 서명을 설명합니다. 입찰 로직은 다음 몇 가지 섹션에서 설명하는 것처럼 입찰 중에 사용자에 관한 특정 신호에 액세스할 수 있습니다. 입찰 로직과 사용자 신호 설정은 이 문서의 후반부에서 설명합니다.

사용자 입찰 신호

구매자는 UserBiddingSignals를 사용하여 광고주 또는 구매자 자체에서 사용자에 관해 보유한 정보를 기기의 향후 입찰에 전달할 수 있습니다. 여기에는 다음과 같은 정보가 포함될 수 있습니다.

• 사용자가 추가된 다른 잠재고객
• 광고주가 사용자에 관해 보유하고 있는 퍼스트 파티 통계

이러한 신호는 입찰 중에 사용할 수 있으므로 구매자는 입찰 중에 다음과 같은 맞춤 입찰 작업을 실행할 수 있습니다.

• 입찰 신호에 따라 입찰가를 조정합니다.
• 입찰에서 특정 광고를 필터링합니다.

신뢰할 수 있는 입찰 데이터

Protected Audience 구현의 일환으로 구매자는 입찰 중에 키-값 서비스에서 실시간 정보에 액세스할 수 있습니다. 임시 메커니즘으로 구매자와 판매자는 자체적으로 운영되는 서비스를 비롯하여 모든 서비스에서 이러한 입찰 신호를 가져올 수 있습니다. 가장 일반적인 예는 광고의 남은 예산을 조회하는 것입니다. 개발 중에는 이 서비스를 모의 처리할 수 있으며 이 모의 엔드포인트에 대해 개발할 수 있습니다. 설정 안내는 GitHub의 샘플 앱 저장소에서 FledgeServerSpec 디렉터리를 참고하세요.

TrustedBiddingData 필드는 URL과 키 모음으로 구성됩니다. 사용할 키 구조의 종류를 설계할 때 고려할 사항은 다음과 같습니다.

• 간단한 접근 방식은 생성 중인 잠재고객에 1:1 매핑하는 키를 포함하는 것입니다. 그러면 키-값 서비스에는 잠재고객과 연결된 모든 관련 정보가 포함될 수 있습니다.
• 예산과 광고 상태는 실시간으로 고려해야 하는 중요한 요소입니다.
• 입찰에서 광고 가격을 책정하는 데 사용할 수 있는 최대 입찰 금액 또는 기타 신호입니다. 이 정보를 광고와 함께 AdData 목록에 포함할 수 있지만 이를 키-값 서비스에 저장하면 필요에 따라 더 쉽게 업데이트할 수 있습니다.

AdData 목록

리마케팅 캠페인을 만들 때 광고주는 일반적으로 잠재고객의 사용자에게 표시할 다양한 유형의 광고를 고려합니다. 사용자의 이전 앱 참여에 따라 여러 할인을 광고하는 것을 예로 들 수 있습니다. 맞춤 잠재고객에는 조합 광고를 포함하는 AdData 목록이 포함됩니다.

각 광고에 포함할 정보의 양은 구매자가 결정합니다. 이때 다음과 같은 사항을 고려해 보시기 바랍니다.

• AdData 목록은 다음 두 가지 방법으로 업데이트할 수 있습니다.
  • 포그라운드에 표시되는 활동이 있는 앱은 사용자를 맞춤 잠재고객에 연결할 때 목록을 시작할 수 있습니다.
  • 일일 업데이트 중에 백그라운드에서 가져오기가 시작되었습니다. 기기는 joinCustomAudience 호출에 포함된 daily_update_url에 요청을 전송하고 업데이트된 AdData 목록을 포함한 응답을 예상합니다.
• 광고에 관한 추가 정보는 입찰 시점에 요청할 수 있습니다. 입찰 전에 기기는 joinCustomAudience의 trustedBiddingData 필드에 제공된 구매자의 키-값 서비스에 요청을 전송합니다. 키-값 서비스는 새로운 서비스로, 구매자의 Protected Audience 구현의 일부입니다. 이 서비스에 관한 자세한 내용은 이 문서의 뒷부분을 참고하세요.
• 광고에 광고 소재 ID를 포함하면 특정 광고 소재에 관해 특정 조치를 취할 수 있습니다. 예를 들어 광고주는 특정 광고 소재를 일시중할 수 있고 개발자는 이러한 광고 소재 ID를 실시간 키-값 서비스에서 가져온 다음 AdData 목록의 광고와 일치시키려고 합니다.

AdData에는 render_url이 포함되어야 합니다. 낙찰된 리마케팅 광고의 렌더링 URL은 광고를 렌더링하는 데 사용됩니다. 다음은 몇 가지 고려사항입니다.

• 렌더링 URL에는 k-익명성 기준점이 있으므로 좁은 매개변수는 포함하지 않아야 합니다. 이 k-익명성 기준점에 관한 자세한 내용은 나중에 게시됩니다.
• 이 URL에는 광고를 렌더링하는 데 필요한 모든 정보가 포함되어야 합니다. 예를 들어 특정 제품을 표시하려면 제품 ID를 매개변수로 URL에 삽입합니다.

프로토타입을 제작하는 동안 유일한 필수 필드는 광고의 렌더링 애셋을 가리키는 renderUri입니다. AdData의 메타데이터 필드는 솔루션을 만드는 동안 무시해도 됩니다. 솔루션을 프로덕션 단계로 전환할 때 관련 있는 메타데이터를 고려해야 합니다. 입찰 생성 중에 입찰가를 조정하는 데 사용할 수 있기 때문입니다.

활성화 시간 및 만료 시간

활성화 및 만료 시간 필드를 사용하여 맞춤 잠재고객이 사전 정의된 시간 내에서만 입찰해야 하는 사용 사례를 지원할 수 있습니다. 활성화 시간이 지연될 수 있는 시간과 활성화 및 만료 시간 사이의 델타에는 특정 제한이 있습니다. 사용 사례의 예는 다음과 같습니다.

• 사용 중단한 사용자 (예: 지난 7일 동안 광고주의 앱을 사용하지 않은 사용자)
  • 사용자가 앱을 열 때마다 구매자는 joinCustomAudience를 호출하고 activation_time을 향후 7일의 타임스탬프가 되도록 구성할 수 있습니다.
  • 잠재고객은 사용자가 앱을 마지막으로 연 후 7일이 지나면 입찰에 참여할 수 있습니다.
• 시즌 잠재고객(조만간 특정 기간 동안만 유효한 잠재고객)
  • 구매자는 향후 미리 정해진 기간 동안에만 입찰할 수 있는 맞춤 잠재고객을 미리 정의할 수 있습니다.
  • 예를 들어 광고주가 2022년 미국에서 여름 종료 캠페인을 한다면 구매자는 joinCustomAudience를 호출하고 activation_time을 2022년 8월 20일 토요일이 되도록 구성할 수 있습니다. 캠페인을 1주 동안만 진행하는 경우 구매자는 만료일을 2022년 8월 27일로 설정할 수 있습니다. 그 후에는 맞춤 잠재고객이 광고 선택 중에 플랫폼에서 필터링되고 결국 가비지 컬렉션됩니다.

구매자 및 판매자: 광고 선택

광고 선택에는 구매자와 판매자 간의 협력이 필요합니다. 이는 네 단계로 이루어진 프로세스로 볼 수 있습니다.

1. 판매자가 미디에이션 전략을 정의합니다.
2. 판매자가 입찰을 구성하고 광고 선택을 시작합니다.
3. 구매자는 판매자가 정의한 구성을 통해 입찰에 참여하도록 초대됩니다. 조합 광고 및 입찰을 선택하기 위해 구매자의 입찰 로직이 실행됩니다.
4. 조합 광고를 평가하고 낙찰된 광고를 선택하기 위해 판매자 결정 로직이 실행됩니다.

개발을 간소화하기 위해 입찰 및 점수 로직이 포함된 구매자와 판매자의 서비스 응답을 모의 처리할 수 있으므로 사용 사례와 관련된 항목을 개발하는 데 집중할 수 있습니다. 모의 엔드포인트 설정에 관한 안내는 GitHub의 FledgeServerSpec 디렉터리를 참고하고 원격 자바스크립트 가져오기 필요성을 재정의하는 방법에 관한 안내는 개발자 가이드를 참고하세요.

판매자: 미디에이션 전략 정의

Protected Audience는 폭포식 구조 미디에이션을 지원하는 것을 목표로 합니다. 이 영역은 개발 중이며 더 많은 정보가 제공될 예정입니다. 지금은 Protected Audience의 폭포식 구조 미디에이션에 관한 설계 제안서를 참고하세요.

판매자: 입찰 구성

판매자는 입찰을 구성하여 광고 선택 프로세스에 정보를 제공해야 합니다. 판매자는 모든 당사자 또는 선택한 당사자에게만 정보를 제공할지 선택할 수 있습니다. 여기에는 개발자가 보유한 정보 또는 구매자를 대신하여 개발자가 포함하는 정보가 포함될 수 있습니다.

설정 및 프로토타입

• 판매자는 AdSelectionConfig 객체를 설정하고 AdSelection API를 사용하여 입찰을 구성하고 시작할 수 있습니다. selectAds()를 호출하여 입찰을 트리거합니다.
• 구현 및 API 사용 세부정보는 개발자 가이드를 참고하세요.

설계 고려사항

이 섹션에는 광고 선택 구성의 주요 필드를 채우고 사용하기 위한 설계 고려사항이 포함되어 있습니다.

• 비공개 실행 환경에는 기기의 맞춤 잠재고객 광고만 포함되므로 문맥 광고 요청을 미리 실행하면 추가 수요를 고려할 수 있습니다.

• 광고 선택 워크플로를 시작하기 전에 광고 요청을 실행하여 구매자로부터 정보를 수집합니다. 그런 다음 이 정보를 사용하여 광고 선택을 구성합니다.

• 많은 구매자가 기기에서 맞춤 잠재고객을 만들 수 있으므로 판매자는 맞춤 잠재고객 구매자 필드를 사용하여 프로세스에 포함할 특정 구매자를 나타내야 합니다. 이 목록을 구성하는 방법은 다양합니다. 다음은 몇 가지 예입니다.

  • 판매자가 항상 프로세스에 포함하려는 구매자의 정적 목록
  • 광고 응답에 참여하길 원하는 구매자 목록. 이 옵션은 판매자가 광고 거래소를 이용 중이고 모든 구매자에 관해 완전히 알지 못할 수 있는 경우 유용합니다.

• 판매자는 다음과 같은 여러 방법으로 정보를 프로세스에 전달할 수 있습니다.

  • 광고 선택 신호 필드는 모든 구매자와 비공개 런타임에 입찰에 참여하는 판매자에게 제공됩니다. 이를 사용하여 광고 크기 및 광고 형식과 같은 광고 기회에 관한 정보를 제공합니다.
  • 구매자별 신호 필드는 특정 구매자에게 제공되어 입찰 프로세스에 사용됩니다. 이 정보는 구매자가 제공하며 판매자는 광고 선택 시 사용할 기기의 이 정보를 가져오는 방법을 고려해야 합니다.
  • 판매자 신호 필드는 판매자가 프로세스에 정보를 전달할 수 있는 마지막 방법입니다. 판매자는 광고를 채점하고 필터링할 때(예: 브랜드 안전성 확인 사용 설정) 이러한 신호를 사용합니다.

구매자: 광고 슬롯 입찰

설정 및 프로토타입

• 구매자는 CustomAudience를 빌드할 때 설정된 biddingLogicUrl 매개변수에서 제공되는 generateBid() 자바스크립트 함수에 입찰 로직을 추가할 수 있습니다. 제공된 사양을 사용하여 모의 서비스를 설정하거나 실제 서버에서 이 엔드포인트를 구현할 수 있습니다.
• 구현 및 API 사용 세부정보는 개발자 가이드를 참고하세요.

설계 고려사항

• 입찰 로직은 기기에서 실행되며 입찰에서 사용되는 일부 신호는 실시간으로 쿼리됩니다. 제약 조건은 제한 목록을 참고하세요.
• 일부 광고 사용 사례의 경우 여러 광고 조합과 그 입찰이 기기에서 고려되도록 판매자와 협력해야 합니다.

입찰 로직 설계

구매자의 입찰 로직은 자바스크립트를 통해 구현해야 하며 기기에서 실행됩니다. 개발자 가이드에는 필수 서명에 관한 정보와 입찰 중에 전달된 다양한 매개변수에 관한 세부정보가 포함되어 있습니다. 기기의 입찰 로직은 추가 정보에 액세스할 수 있으며 이는 generateBid() 함수에 매개변수로 전달됩니다.

입찰 데이터 제공

키-값 서비스를 통한 실시간 입찰 신호

구매자는 입찰 중에 직접 소유한 키-값 서비스에서 실시간 신호를 가져올 수 있습니다. 이 서비스의 초기 구현은 공개 개인 정보 보호 샌드박스 저장소에서 확인할 수 있지만 자체 서비스를 만들 수도 있습니다. 이 서비스의 URL은 맞춤 잠재고객에서 trustedBiddingUrl로 지정되며 플랫폼은 데이터를 가져와 trusted_bidding_signals parameter를 사용하여 generateBid 함수에 제공하려고 시도합니다. 자체 키 구조를 설정해야 합니다.

문맥 및 사용자 신호

generateBid 함수는 기기에서 입찰을 실행할 때 추가 사용자 신호에 액세스할 수 있습니다. 이러한 신호는 contextual_signals 및 per_buyer_signals 필드를 사용하여 전달됩니다. 이러한 필드는 구매자와 판매자가 형식을 정의해야 하는 모든 JSON 객체입니다.

contextual_signals 필드에는 사용자와 관련이 있을 수 있는 정보가 포함됩니다. 이러한 신호를 보유하는 객체는 Protected Audience 자체에서 생성되고 입찰 로직으로 전달됩니다. 현재는 빈 객체로 전달됩니다. 사용자에 관한 문맥 신호가 사용 사례와 관련이 있다고 생각되면 검토를 위해 의견을 제출해 주세요.

per_buyer_signals 필드는 입찰 로직에 사용할 수 있습니다. 판매자는 입찰 구성을 만들 때 이러한 값을 설정합니다. 구매자와 판매자는 이 데이터가 기기에 있고 입찰 로직으로 전달되도록 협력해야 합니다. 이 필드의 사용 예는 다음과 같습니다.

• 브랜드 안전성을 위한 필터링. 판매자는 구매자가 광고를 요청하는 앱에 관한 분류 정보를 알 수 있도록 하고 구매자는 이 정보를 사용해 특정 광고를 필터링할 수 있습니다.
• 문맥 정보를 고려하는 ML 모델의 임베딩 전송

판매자: 낙찰된 광고의 채점 및 선택

설정 및 프로토타입

• 판매자는 AdSelectionConfig를 빌드할 때 설정된 scoringLogicUrl 매개변수에서 제공되는 scoreAd() 자바스크립트 함수에 점수 로직을 추가할 수 있습니다. 제공된 사양을 사용하여 모의 서비스를 설정하거나 실제 서버에서 이 엔드포인트를 구현할 수 있습니다.
• 구현 및 API 사용 세부정보는 개발자 가이드를 참고하세요.

점수 로직 설계

판매자는 자바스크립트로 점수 로직을 구현하며 이는 기기에서 실행됩니다. 개발자 가이드에는 필수 서명에 관한 정보와 입찰 중에 전달된 다양한 매개변수에 관한 세부정보가 포함되어 있습니다. 또한 기기의 점수 로직은 scoreAd 함수에 매개변수로 전달된 추가 정보에 액세스할 수 있습니다.

점수 데이터 제공

키-값 서비스를 통한 실시간 점수 신호

판매자는 입찰 중에 직접 소유한 키-값 서비스에서 실시간 신호를 가져올 수 있습니다. 이 서비스의 초기 구현은 공개 개인 정보 보호 샌드박스 저장소에서 확인할 수 있습니다. 이 서비스의 URL은 입찰 구성에서 trustedScoringUri로 지정되며 플랫폼은 데이터를 가져와 trusted_scoring_signals 매개변수를 통해 scoreAd 함수에 제공하려고 시도합니다. 자체 키 구조를 설정해야 합니다.

문맥 및 사용자 신호

scoreAd 함수는 기기에서 입찰을 실행할 때 추가 사용자 신호에 액세스할 수 있습니다. 이러한 신호는 contextual_signal 필드를 통해 점수 함수에 전달됩니다. 이 필드에는 구매자와 판매자가 형식을 정의한 JSON 객체가 포함됩니다.

contextual_signal 필드에는 사용자와 관련이 있을 수 있는 문맥 정보가 포함됩니다. 이러한 신호를 보유하는 객체는 Protected Audience 자체에서 생성되고 점수 로직으로 전달됩니다. 이것은 빈 객체로 전달됩니다. 사용자에 관한 신호가 사용 사례와 관련이 있다고 생각되면 검토를 위해 의견을 제출해 주세요.

판매자: 광고 렌더링

판매자는 낙찰된 광고를 렌더링해야 합니다. 낙찰된 광고를 렌더링하는 방법에 관한 자세한 내용은 설계 제안서를 참고하세요. 이 영역은 아직 설계 중입니다.

노출 결과 보고

설정 및 프로토타입

• 구매자와 판매자는 각각 biddingLogicUrl 또는 scoringLogicUrl 매개변수에서 제공되는 reportWin() 자바스크립트 함수에 보고 로직을 추가할 수 있습니다. 제공된 사양을 사용하여 모의 서비스를 설정하거나 실제 서버에서 이 엔드포인트를 구현할 수 있습니다.
• 구현 및 API 사용 세부정보는 개발자 가이드를 참고하세요.

설계 고려사항

구매자와 판매자는 구성된 엔드포인트에서 반환된 자바스크립트 코드에서 reportWin 함수를 구현해야 합니다. 이 방법을 통해 데이터를 서버로 다시 보낼 수 있습니다.

개인 정보 보호 샌드박스는 이벤트 수준 및 집계 보고서를 관리하는 Attribution Reporting API도 제공합니다. 자세한 내용은 통합 가이드를 참고하세요.