Protected Audience API를 사용한 맞춤 잠재고객 타겟팅 지원

참고: 이 도움말은 Android의 현재 설계 제안서에 관한 개인 정보 보호 샌드박스를 반영하며 추가로 변경될 수 있습니다. 이러한 노력에 도움이 되도록 의견과 댓글을 보내주세요.

의견 보내기

최신 업데이트

• 맞춤 잠재고객 업데이트 예약에 대한 정보를 추가했습니다.
• Protected Audience와 기여 분석 보고 통합이 추가되었습니다.
• Protected Audience 기능의 일정을 게시했습니다.
• FLEDGE의 이름이 Protected Audience API로 변경되었습니다.
• 맞춤 잠재고객 위임에 관한 제안이 추가되었습니다.
• 일일 업데이트 URL의 k-익명성 요구사항을 삭제했습니다.

Protected Audience는 베타 버전이며 공개 기기에서 테스트에 사용할 수 있습니다.

Protected Audience를 사용하면 다음 작업을 할 수 있습니다.

• 이전 사용자 작업을 기반으로 맞춤 잠재고객 관리
• 단일 판매자 또는 폭포식 구조 미디에이션을 지원하는 기기 내 입찰 시작
• 광고 선택 후 노출 보고 실행

시작하려면 Protected Audience 개발자 가이드를 참고하세요. 보내주신 의견은 지속적인 Protected Audience 개발에 도움이 됩니다.

타임라인

향후 몇 달 내에 새로운 기능을 출시할 예정입니다. 정확한 출시일은 기능에 따라 다르며 이 표는 문서가 제공될 때 문서 링크로 업데이트됩니다.

기능	개발자 프리뷰에서 사용 가능	베타 버전에서 사용 가능
이벤트 수준 보고	2023년 1분기	2023년 3분기
폭포식 구조 미디에이션	2023년 1분기	2023년 4분기
앱 설치 광고 필터링	2023년 2분기	2023년 3분기
최대 게재빈도 필터링	2023년 2분기	2023년 3분기
필터링을 위해 광고 선택 워크플로에 문맥 광고 전달	2023년 2분기	2023년 3분기
상호작용 보고	2023년 2분기	2023년 3분기
맞춤 잠재고객 위임에 참여	2023년 3분기	2023년 4분기
CPM이 아닌 청구	2023년 3분기	2023년 4분기
입찰 서비스 통합	2023년 3분기	2023년 4분기
디버그 보고	2023년 3분기	2023년 4분기
기여 분석 보고 통합	N/A	2023년 4분기
공개 입찰 미디에이션	2023년 4분기	2023년 4분기
통화 관리	2024년 1분기	2024년 2분기
K-anon 통합	N/A	2024년 2분기
집계 보고 통합	2024년 3분기	2024년 4분기

개요

모바일 광고에서 광고주는 일반적으로 사용자가 과거에 광고주의 앱에서 참여했던 방식을 기반으로 잠재적 관심이 있는 사용자에게 광고를 게재하려고 합니다. 예를 들어 SportingGoodsApp 개발자는 장바구니에 상품이 남아 있는 사용자에게 광고를 게재하여 구매 절차를 완료하라는 메시지를 표시할 수 있습니다. 업계에서는 일반적으로 '리마케팅', '맞춤 잠재고객 타겟팅'과 같은 용어로 이러한 일반적인 개념을 설명합니다.

오늘날 이러한 사용 사례는 일반적으로 광고가 표시되는 방식에 관한 문맥 정보(예: 앱 이름)와 개인 정보(예: 잠재고객 목록)를 광고 기술 플랫폼과 공유하여 구현됩니다. 이 정보를 사용하여 광고주는 서버에서 관련성 높은 광고를 선택할 수 있습니다.

Android의 Protected Audience API(이전의 FLEDGE)는 광고 기술 플랫폼과 광고주를 위한 다음 API를 포함하여 앱 간 식별자와 사용자의 앱 상호작용 정보를 서드 파티와 공유하는 것을 제한하는 방식으로 일반적인 상호작용 기반 사용 사례를 지원합니다.

1. Custom Audience API: 공통의 의도가 있는 광고주 지정 잠재고객을 나타내는 '맞춤 잠재고객' 추상화를 중심으로 합니다. 잠재고객 정보는 기기에 저장되며 잠재고객을 위한 관련 조합 광고 및 입찰 신호와 같은 임의의 메타데이터와 연결될 수 있습니다. 이 정보는 광고주 입찰, 광고 필터링, 렌더링에 영향을 미치는 데 사용될 수 있습니다.
2. Ad Selection API: 기기 내 신호를 활용하여 '낙찰된' 광고를 결정하는 광고 기술 플랫폼의 워크플로를 조정하는 프레임워크를 제공합니다. 이 프레임워크는 로컬에 저장된 조합 광고를 고려하고 광고 기술 플랫폼이 기기에 반환하는 조합 광고에서 추가 처리를 실행합니다.

Android의 개인 정보 보호 샌드박스에서 맞춤 잠재고객 관리 및 광고 선택 워크플로를 보여주는 플로 차트

참고: 이 설계 제안서는 앱 간 사용자 상호작용 기반 광고 사용 사례에 중점을 둡니다. 이러한 경우 앱은 다른 앱에서 광고를 표시하기 위해 고려할 수 있는 맞춤 잠재고객을 등록할 수 있습니다. 다른 사용 사례에 관한 자세한 내용은 예를 들어 사용자가 WebView를 사용하여 웹 앱에서 상호작용하고 브라우저가 생각해 보세요.

상위 수준에서 통합은 다음과 같이 작동합니다.

1. SportingGoodsApp에서는 사용자가 2일 이내에 구매를 완료하지 않은 경우 장바구니에 남은 상품을 구매하라고 사용자에게 알려주려고 합니다. 또한 Custom Audience API를 통해 '장바구니에 있는 제품' 잠재고객 목록에 사용자를 추가합니다. 플랫폼은 이 잠재고객 목록을 기기에서 관리하고 저장하여 서드 파티와의 공유를 제한합니다. SportingGoodsApp에서는 잠재고객 목록의 사용자에게 광고를 표시하기 위해 광고 기술 플랫폼과 파트너 관계를 맺습니다. 광고 기술 플랫폼은 잠재고객 목록의 메타데이터를 관리하고 조합 광고를 제공하여 광고 선택 워크플로에서 고려할 수 있도록 합니다. 백그라운드에서 업데이트된 잠재고객 기반 광고를 정기적으로 가져오도록 플랫폼을 구성할 수 있습니다. 이렇게 하면 잠재고객 기반 조합 광고 목록을 최신 상태로 유지하고, 광고 기회 동안 서드 파티 광고 서버에 전송된 요청(즉, 문맥 광고 요청)과 해당 목록의 상관관계가 없도록 할 수 있습니다.

2. 사용자가 같은 기기에서 FrisbeeGame을 플레이할 때 SportingGoodsApp의 장바구니에 남은 상품 구매를 완료하라고 알려주는 광고가 표시될 수 있습니다. FrisbeeGame(통합 광고 SDK 포함)이 Ad Selection API를 호출하여 사용자가 포함되어 있을 수 있는 잠재고객 목록(이 예에서는 SportingGoodsApp이 만든 '장바구니에 있는 제품' 맞춤 잠재고객)에 따라 사용자를 위한 낙찰된 광고를 선택하면 됩니다. 광고 선택 워크플로는 광고 기술 플랫폼의 서버에서 가져온 광고와 맞춤 잠재고객과 연결된 기기 내 광고, 기타 기기 내 신호를 고려하도록 설정할 수 있습니다. 워크플로는 맞춤 입찰 및 점수 로직을 통해 광고 기술 플랫폼 및 광고 SDK에서 맞춤설정하여 적절한 광고 목표를 달성할 수도 있습니다. 이 접근 방식을 통해 사용자의 관심분야 또는 앱 상호작용 데이터가 광고 선택에 영향을 미치도록 하면서 이 데이터가 서드 파티와 공유되는 것을 제한할 수 있습니다.

3. 광고 게재 앱 또는 광고 기술 플랫폼의 SDK가 선택된 광고를 렌더링합니다.

4. 플랫폼에서는 노출수 및 광고 선택 결과 보고를 지원합니다. 이 보고 기능은 Attribution Reporting API를 보완합니다. 광고 기술 플랫폼은 보고 요구사항에 따라 맞춤설정할 수 있습니다.

Android의 Protected Audience API에 액세스

광고 기술 플랫폼은 Protected Audience API에 액세스하려면 등록해야 합니다. 자세한 내용은 개인 정보 보호 샌드박스 계정 등록을 참고하세요.

맞춤 잠재고객 관리

맞춤 잠재고객

맞춤 잠재고객은 광고주가 공통의 의도나 관심분야를 가진 것으로 판단한 사용자 그룹을 나타냅니다. 앱 또는 SDK는 맞춤 잠재고객을 사용하여 '장바구니에 상품이 남아 있는' 사용자나 게임의 '초급 레벨을 완료한' 사용자와 같은 특정 잠재고객을 나타낼 수 있습니다. 플랫폼은 잠재고객 정보를 기기에 로컬로 유지하고 저장하며 사용자가 어느 맞춤 잠재고객에 속해 있는지 노출하지 않습니다. 맞춤 잠재고객은 Chrome의 Protected Audience 관심분야 그룹과 다르며 웹 및 앱 간에 공유되지 않습니다. 이렇게 하면 사용자 정보의 공유를 제한할 수 있습니다.

광고주 앱 또는 통합 SDK는 앱에서의 사용자 참여 등을 기반으로 맞춤 잠재고객에 참여하거나 이를 종료할 수 있습니다.

맞춤 잠재고객 메타데이터

각 맞춤 잠재고객에는 다음과 같은 메타데이터가 포함됩니다.

• 소유자: 소유자 앱의 패키지 이름입니다. 암시적으로 호출자 앱의 패키지 이름으로 설정됩니다.
• 구매자: 이 맞춤 잠재고객의 광고를 관리하는 구매자 광고 네트워크입니다. 또한 구매자는 맞춤 잠재고객에 액세스하여 관련 광고 정보를 가져올 수 있는 당사자를 나타냅니다. 구매자는 eTLD+1 형식에 따라 지정됩니다.
• 이름: 맞춤 잠재고객의 임의 이름 또는 식별자(예: '장바구니 이탈자'가 있는 사용자)입니다. 이 속성은 예를 들어 광고주의 광고 캠페인의 타겟팅 기준 중 하나 또는 입찰 코드를 가져오기 위한 URL의 쿼리 문자열로 사용할 수 있습니다.
• 활성화 시간 및 만료 시간: 이 필드는 이 맞춤 잠재고객이 적용되는 기간을 정의합니다. 플랫폼은 이 정보를 사용하여 맞춤 잠재고객의 멤버십을 철회합니다. 만료 시간은 맞춤 잠재고객의 기간을 제한하도록 최대 기간을 초과할 수 없습니다.
• 일일 업데이트 URL: 플랫폼이 '사용자 입찰 신호' 및 '신뢰할 수 있는 입찰 신호'에 정의된 조합 광고 및 기타 메타데이터를 반복적으로 가져오는 데 사용하는 URL입니다. 자세한 내용은 맞춤 잠재고객을 위해 조합 광고를 가져오는 방법 섹션을 참고하세요.
• 사용자 입찰 신호: 리마케팅 광고 입찰을 위한 광고 기술 플랫폼별 신호입니다. 신호의 예로는 사용자의 대략적인 위치, 선호 언어 등이 있습니다.
• 신뢰할 수 있는 입찰 데이터: 광고 기술 플랫폼은 실시간 데이터를 사용하여 광고 검색 및 점수에 영향을 미칩니다. 예를 들어 어떤 광고는 예산이 소진될 수 있어 즉시 게재를 중지해야 합니다. 광고 기술은 이 실시간 데이터를 가져올 수 있는 URL 엔드포인트와 실시간 조회를 실행해야 하는 키 집합을 정의할 수 있습니다. 이 요청을 처리하는 서버는 광고 기술 플랫폼에서 관리하는 신뢰할 수 있는 서버입니다.
• 입찰 로직 URL: 수요측 플랫폼에서 입찰 코드를 가져오기 위해 플랫폼이 사용하는 URL입니다. 플랫폼은 광고 입찰이 시작되면 이 단계를 실행합니다.
• 광고: 맞춤 잠재고객의 조합 광고 목록입니다. 여기에는 광고 기술 플랫폼별 광고 메타데이터와 광고를 렌더링하는 URL이 포함됩니다. 맞춤 잠재고객을 위한 입찰이 시작되면 이 광고 메타데이터 목록이 고려됩니다. 이 광고 목록은 가능한 경우 일일 업데이트 URL 엔드포인트를 사용하여 새로고침됩니다. 휴대기기의 리소스 제약 조건으로 인해 맞춤 잠재고객에 저장할 수 있는 광고 수에는 제한이 있습니다.

맞춤 잠재고객 위임

기존 맞춤 잠재고객 정의 및 구성은 일반적으로 대행사 및 광고주 클라이언트와 파트너 간의 제휴로 광고 기술을 통해 서버 측 기술 및 통합에 의존합니다. Protected Audience API는 사용자 개인 정보를 보호하면서 맞춤 잠재고객 정의와 구성을 지원합니다. 맞춤 잠재고객에 참여하려면 앱에 SDK가 없는 구매자 광고 기술은 모바일 측정 파트너(MMP)나 공급측 플랫폼(SSP)과 같이 기기 내 존재하는 광고 기술과 공동작업해야 합니다. Protected Audience API의 목표는 온디바이스 호출자가 구매자 대신 맞춤 잠재고객 생성을 호출할 수 있도록 함으로써 맞춤 잠재고객 관리를 위한 유연한 솔루션을 제공하여 이러한 SDK를 지원하는 것입니다. 이 과정을 맞춤 잠재고객 위임이라고 합니다. 다음 단계에 따라 맞춤 잠재고객 위임을 구성하세요.

맞춤 잠재고객에 참여

맞춤 잠재고객에 참여하는 방법은 두 가지입니다.

joinCustomAudience()

앱이나 SDK에서 예상 매개변수로 CustomAudience 객체를 인스턴스화한 후 joinCustomAudience()를 호출하여 맞춤 잠재고객에 참여하도록 요청할 수 있습니다. 다음은 코드 스니펫 예입니다.

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

앱이나 SDK에서 다음 예와 같이 예상 매개변수로 fetchAndJoinCustomAudience()를 호출하여 기기 내 존재하지 않는 광고 기술을 대신하여 맞춤 잠재고객에 참여하도록 요청할 수 있습니다.

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

구매자가 소유한 URL 엔드포인트는 응답 본문에서 CustomAudience JSON 객체로 다시 응답합니다. 맞춤 잠재고객의 구매자 및 소유자 필드는 무시됩니다(API로 자동 완성됨). 또한 API는 일일 업데이트 URL이 구매자의 eTLD+1과도 일치하도록 합니다.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

fetchAndJoinCustomAudience() API는 fetchUri의 eTLD+1에서 구매자 ID를 확인합니다. CustomAudience 구매자 ID는 joinCustomAudience()에 의해 실행된 동일한 등록 및 앱 승인 검사를 실행하는 데 사용되며 가져오기 응답에서 변경할 수 없습니다. CustomAudience 소유자는 호출하는 애플리케이션의 패키지 이름입니다. eTLD+1 검사 외에 fetchUri의 다른 검사는 없으며 특히 k-anon 검사가 없습니다. fetchAndJoinCustomAudience() API는 fetchUri에 HTTP GET 요청을 실행하고 맞춤 잠재고객을 나타내는 JSON 객체를 기대합니다. 맞춤 잠재고객 객체 필드의 필수, 선택적 제약 조건 및 기본값이 응답에 동일하게 적용됩니다. 개발자 가이드의 현재 요구사항 및 제한사항을 알아보세요.

구매자의 HTTP 오류 응답이 발생하면 fetchAndJoinCustomAudience가 실패합니다. 특히 HTTP 상태 응답 429(너무 많은 요청)는 정의될 기간 동안 현재 애플리케이션의 요청을 차단합니다. 또한 구매자의 응답 형식이 잘못된 경우에도 API 호출이 실패합니다. 일시적인 실패(예: 서버가 응답하지 않음)인 경우 재시도하거나 연속적인 실패(예: 데이터 검증 실패 또는 서버와의 통신에서 일시적이지 않은 실패)를 처리할 책임이 있는 API 호출자에게 실패가 보고됩니다.

CustomAudienceFetchRequest 객체를 사용하면 API 호출자는 위의 예에 표시된 선택적 속성을 사용하여 맞춤 잠재고객에 관한 몇 가지 정보를 정의할 수 있습니다. 요청에 설정된 경우 플랫폼에서 수신한 구매자 응답으로 이 값을 덮어쓸 수 없습니다. Protected Audience API는 응답의 필드를 무시합니다. 요청에 설정되어 있지 않으면 맞춤 잠재고객을 만드는 데 이 필드가 필요하므로 응답에서 설정해야 합니다. API 호출자가 부분적으로 정의한 CustomAudience 콘텐츠의 JSON 표현은 특수 헤더 X-CUSTOM-AUDIENCE-DATA의 fetchUri에 대한 GET 요청에 포함됩니다. 맞춤 잠재고객에 지정된 데이터의 직렬화된 형식 크기는 8KB로 제한됩니다. 크기가 제한을 초과하면 fetchAndJoinCustomAudience API 호출이 실패합니다.

k-anon 검사가 이루어지지 않으면 구매자 인증에 fetchUri를 사용할 수 있고 구매자와 SDK 간에 정보를 공유할 수 있습니다. 맞춤 잠재고객 확인을 용이하게 하기 위해 구매자는 확인 토큰을 제공할 수 있습니다. 기기 내 SDK는 구매자가 호스팅한 엔드포인트에서 맞춤 잠재고객의 콘텐츠를 가져오고 확인 토큰을 사용하여 fetchAndJoinCustomAudience() 작업이 구매자에 대응하고 신뢰할 수 있는 기기 내 파트너에서 발생한 것인지 확인할 수 있도록 이 토큰을 fetchUri에 포함해야 합니다. 정보를 공유하기 위해 구매자는 기기 내 호출자와 동의하여 맞춤 잠재고객을 생성하는 데 사용되는 일부 정보를 fetchUri에 쿼리 매개변수로 추가할 수 있습니다. 이를 통해 구매자는 호출을 감사하고 악성 광고 기술에서 인증 토큰을 사용하여 여러 맞춤 잠재고객을 만들었는지 감지할 수 있습니다.

확인 토큰 정의 및 저장에 관한 참고사항

• 확인 토큰은 어떠한 목적으로도 Protected Audience API에서 사용하지 않으며 선택사항입니다.

  • 확인 토큰은 구매자가 생성 중인 잠재고객이 판매자를 대신해 실행되고 있는지 확인하는 데 사용할 수 있습니다.
  • Protected Audience API 제안은 확인 토큰의 형식이나 구매자가 확인 토큰을 호출자에게 전송하는 방법을 지정하지 않습니다. 예를 들어 확인 토큰은 소유자의 SDK 또는 백엔드에 미리 로드되거나 소유자의 SDK가 구매자의 서버에서 실시간으로 가져올 수 있습니다.

맞춤 잠재고객 탈퇴

맞춤 잠재고객의 소유자는 다음 코드 스니펫 예와 같이 leaveCustomAudience()를 호출하여 탈퇴할 수 있습니다.

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

참고: 이 API에는 앱이 이 메서드를 사용하여 사용자의 맞춤 잠재고객 멤버십을 추론하는 것을 방지하는 반환 값이 없습니다.

저장소 및 기타 기기 리소스의 사용량을 절약하기 위해 맞춤 잠재고객은 미리 결정된 기간이 지나면 만료되고 기기 내 저장소에서 삭제됩니다. 기본값은 추후 결정됩니다. 소유자는 이 기본값을 재정의할 수 있습니다.

사용자 제어

• 제안서의 목적은 맞춤 잠재고객을 하나 이상 만든, 설치된 앱의 목록을 사용자에게 보여주는 것입니다.
• 사용자는 이 목록에서 앱을 삭제할 수 있습니다. 삭제하면 앱과 연결된 모든 맞춤 잠재고객이 삭제되고 앱은 새 맞춤 잠재고객에 참여하지 못합니다.
• 사용자는 Protected Audience API를 완전히 재설정할 수 있습니다. 이 경우 기기의 기존 맞춤 잠재고객이 모두 삭제됩니다.
• 사용자는 Protected Audience API가 포함된 Android의 개인 정보 보호 샌드박스를 완전히 거부할 수 있습니다. 사용자가 개인 정보 보호 샌드박스를 거부한 경우 Protected Audience API가 자동으로 실패합니다.

이 기능의 설계는 진행 중인 작업이며 세부정보는 이후 업데이트에 포함됩니다.

예약된 업데이트

앞서 설명한 솔루션을 사용하려면 앱 또는 광고 기술 SDK가 API가 포그라운드 상태일 때 API를 사용하고 맞춤 잠재고객을 직접 또는 위임을 통해 사용할 수 있습니다. 하지만 광고주와 광고 기술 제공업체는 사용자가 광고를 볼 잠재고객을 실시간으로 속하게 될 수 있습니다.

이를 용이하게 하기 위해 광고 기술은 scheduleCustomAudienceUpdate() API를 사용합니다. 이 API를 사용하면 호출자가 API 호출이 수행되어야 하는 시점이 지연되므로 추가 시간이 제공됩니다. 응답하는 광고 기술이 앱 수준 이벤트를 처리하고 사용자가 참여하거나 삭제해야 하는 Protected Audience입니다.

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest에는 플랫폼에서 실행할 지연된 작업을 등록하는 데 필요한 정보가 포함됩니다. 지정된 지연 시간이 지나면 백그라운드 작업이 주기적으로 실행되고 요청을 보냅니다. ScheduleCustomAudienceUpdateRequest에는 다음 정보가 포함될 수 있습니다.

• UpdateUri: 업데이트를 가져오기 위해 GET 호출을 전송하는 URI 엔드포인트입니다. 구매자 ID는 eTLD+1에서 본질적으로 추론되며 명시적으로 제공되고 업데이트 응답에 의해 변경될 수 없습니다. GET 요청에는 다음과 같은 customAudience 객체 목록이 포함된 JSON 객체가 필요합니다. 반환합니다.
• DelayTime: scheduleCustomAudienceUpdate() API를 호출하여 업데이트를 예약합니다.

참고: 임의의 노이즈 양이 지연 및 제한에 추가됩니다. 지연의 최솟값 및 최댓값에 배치됩니다.

• PartialCustomAudience: 이 API를 사용하면 기기 내 SDK가 목록을 전송할 수도 있습니다. 부분적으로 구성된 맞춤 잠재고객의 그룹입니다. 이렇게 하면 인앱 SDK가 맞춤 잠재고객 관리를 완료에서 부분적으로 제어할 수 있는 이중 역할 광고 수익을 창출할 수 있습니다.

  • 또한 이 API는 유사한 정보 공유를 허용하는 fetchAndJoinCustomAudience() API와 호환됩니다.

• ShouldReplacePendingUpdates: 대기 중인 작업이 있는지 확인하는 불리언 해당 업데이트를 취소하고 현재 ScheduleCustomAudienceUpdateRequest입니다. 이 값을 false로 설정하고 이전에 요청한 업데이트가 같은 앱, 다음 코드로 scheduleCustomAudienceUpdate 호출 ScheduleCustomAudienceUpdateRequest는 실패합니다. 기본값은 false입니다.

앱 권한 및 제어

이 제안서의 목적은 앱에서 맞춤 잠재고객을 제어할 수 있도록 하는 것입니다.

• 앱은 맞춤 잠재고객과의 연결을 관리할 수 있습니다.
• 앱은 서드 파티 광고 기술 플랫폼에 앱을 대신하여 맞춤 잠재고객을 관리하는 권한을 부여할 수 있습니다.

이 기능의 설계는 진행 중인 작업이며 세부정보는 이후 업데이트에 포함됩니다.

광고 기술 플랫폼 제어

이 제안서는 광고 기술이 맞춤 잠재고객을 제어하는 방법을 설명합니다.

• 광고 기술은 개인 정보 보호 샌드박스에 등록하고 맞춤 잠재고객의 모든 URL과 일치하는 eTLD+1 도메인을 제공합니다.
• 광고 기술은 앱 또는 SDK와 협력하여 맞춤 잠재고객 생성을 확인하는 데 사용되는 확인 토큰을 제공할 수 있습니다. 이 절차가 파트너에게 위임되면 확인을 요구하도록 광고 기술에서 맞춤 잠재고객 생성을 구성할 수 있습니다.
• 광고 기술은 앱이나 SDK를 대신하여 joinCustomAudience 호출을 비활성화하도록 선택하고 fetchAndJoinCustomAudience API만 맞춤 잠재고객을 호출하도록 사용 설정할 수 있습니다. 개인 정보 보호 샌드박스 등록 중에 제어 방식을 업데이트할 수 있습니다. 이 제어 방식은 모든 광고 기술을 허용하거나 허용하지 않습니다. 플랫폼 제한으로 인해 위임 권한은 광고 기술별로 존재할 수 없습니다.

조합 광고 및 메타데이터 응답

구매측 플랫폼에서 반환된 조합 광고 및 메타데이터에는 다음 필드가 포함되어야 합니다.

• 메타데이터: 구매측 광고 기술별 광고 메타데이터입니다. 예를 들어 여기에는 광고 캠페인에 관한 정보와 타겟팅 기준(예: 위치, 언어)이 포함될 수 있습니다.
• 렌더링 URL: 광고 소재를 렌더링하기 위한 엔드포인트입니다.
• 필터: Protected Audience API에서 기기 내 데이터를 기반으로 광고를 필터링하는 데 필요한 선택적 정보입니다. 자세한 내용은 구매측 필터링 로직 섹션을 참고하세요.

광고 선택 워크플로

이 제안서의 목표는 광고 기술 플랫폼의 입찰 실행을 조정하는 Ad Selection API를 도입하여 개인 정보 보호를 개선하는 것입니다.

오늘날의 광고 기술 플랫폼은 일반적으로 서버에서만 입찰과 광고 선택을 실행합니다. 이 제안서에서는 맞춤 잠재고객과 기타 민감한 사용자 신호(예: 사용 가능한 설치된 패키지 정보)에 Ad Selection API를 통해서만 액세스할 수 있습니다. 또한 리마케팅 사용 사례의 경우 조합 광고는 대역 외(즉, 광고가 표시될 문맥이 아님)에서 가져옵니다. 광고 기술 플랫폼은 현재 입찰 및 광고 선택 로직의 일부를 기기에 배포하고 실행할 수 있도록 준비해야 합니다. 광고 기술 플랫폼은 광고 선택 워크플로의 다음 변경사항을 고려할 수 있습니다.

• 서버에서 사용할 수 있는 설치된 패키지 정보가 없는 경우, 광고 기술 플랫폼에서는 관련 광고를 표시할 기회를 극대화하기 위해 여러 문맥 광고를 기기에 다시 전송하고 광고 선택 워크플로를 호출하여 앱 설치 기반 필터링을 사용 설정하는 것이 좋습니다.
• 리마케팅 광고는 대역 외로 가져오므로 현재 입찰 모델을 업데이트해야 할 수 있습니다. 광고 기술 플랫폼에서 입찰 하위 모델을 만들 수 있습니다. (구현은 2개 타워 모델) 광고 기능과 문맥 시그널에 대해 개별적으로 작동하고 하위 모델 출력을 사용하여 입찰가를 예측합니다. 이렇게 하면 서버 측 입찰과 특정 광고 기회 입찰의 이점을 모두 누릴 수 있습니다.

이 접근 방식을 사용하면 사용자의 앱 상호작용 데이터가 광고 선택에 영향을 미치는 동시에 이 데이터가 서드 파티와 공유되는 것을 제한할 수 있습니다.

광고 선택 워크플로의 시작을 보여주는 플로 차트

이 광고 선택 워크플로는 다음 순서를 기반으로 광고 기술 제공 JavaScript 코드의 기기 내 실행을 조정합니다.

1. 구매측 입찰 로직 실행
2. 구매측 광고 필터링 및 처리
3. 판매측 결정 로직 실행

맞춤 잠재고객이 포함된 광고 선택의 경우 플랫폼은 맞춤 잠재고객의 '입찰 로직 URL' 메타데이터로 정의된 공개 URL 엔드포인트를 기반으로 구매 측 제공 JavaScript 코드를 가져옵니다. 판매 측 결정 코드의 URL 엔드포인트도 광고 선택 워크플로를 시작하는 입력으로 전달됩니다.

맞춤 잠재고객이 포함되지 않는 광고 선택 설계는 현재 진행 중입니다.

광고 선택 워크플로 시작

앱에서 광고를 표시해야 하는 경우 광고 기술 플랫폼 SDK는 예상 매개변수로 AdSelectionConfig 객체를 인스턴스화한 후 selectAds() 메서드를 호출하여 광고 선택 워크플로를 시작할 수 있습니다.

• 판매자: eTLD+1 형식을 따르는 판매 측 광고 플랫폼의 식별자입니다.
• 결정 로직 URL: 광고 입찰이 시작되면 플랫폼은 이 URL을 사용하여 판매 측 플랫폼에서 JavaScript 코드를 가져와 낙찰된 광고에 점수를 매깁니다.
• 맞춤 잠재고객 구매자: 이 입찰의 맞춤 잠재고객 기반 수요가 있는 구매측 플랫폼의 목록으로, eTLD+1 형식을 따릅니다.
• 광고 선택 신호: 입찰 정보(광고 크기, 광고 형식 등)입니다.
• 판매자 신호: 공급측 플랫폼(SSP) 관련 신호입니다.
• 신뢰할 수 있는 점수 신호 URL: 광고 소재별 실시간 정보를 가져올 수 있는, 신뢰할 수 있는 판매 측 신호의 URL 엔드포인트입니다.
• 구매자별 신호: 참여하는 수요 측은 이 매개변수를 사용하여 입찰을 위한 입력을 제공할 수 있습니다. 예를 들어 이 매개변수에는 입찰가 결정에 유용한 포괄적인 문맥 정보가 포함될 수 있습니다.

다음 코드 스니펫 예는 먼저 AdSelectionConfig를 정의하고 selectAds을 호출하여 낙찰된 광고를 가져오는 방식으로 광고 선택 워크플로를 시작하는 광고 기술 플랫폼 SDK를 보여줍니다.

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

구매측 입찰 로직

입찰 로직은 일반적으로 구매측 플랫폼에서 제공합니다. 이 코드의 목적은 조합 광고의 입찰가를 결정하는 데 있습니다. 추가 비즈니스 로직을 적용하여 결과를 결정할 수도 있습니다.

플랫폼은 맞춤 잠재고객의 '입찰 로직 URL' 메타데이터를 사용하여 아래 함수 서명을 포함해야 하는 JavaScript 코드를 가져옵니다.

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

generateBid() 메서드는 계산된 입찰가를 반환합니다. 플랫폼은 모든 광고(문맥 또는 리마케팅)에 순차적으로 이 함수를 호출합니다. 입찰 로직 제공자가 여러 개 있다면 시스템은 여러 제공자 간의 실행 순서를 보장하지 않습니다.

이 함수에는 다음과 같은 매개변수가 필요합니다.

• 광고: 구매측 입찰 코드에서 고려 중인 광고입니다. 요건을 충족하는 맞춤 잠재고객의 광고입니다.
• 입찰 신호: 판매측 플랫폼별 신호입니다.
• 구매자별 신호: 참여하는 수요 측은 이 매개변수를 사용하여 입찰을 위한 입력을 제공할 수 있습니다. 예를 들어 이 매개변수에는 입찰가 결정에 유용한 포괄적인 문맥 정보가 포함될 수 있습니다.
• 신뢰할 수 있는 입찰 신호: 광고 기술 플랫폼은 실시간 데이터를 사용하여 광고 검색 및 점수에 영향을 미칩니다. 예를 들어 광고 캠페인은 예산이 소진될 수 있으므로 즉시 게재를 중지해야 합니다. 광고 기술은 이 실시간 데이터를 가져올 수 있는 URL 엔드포인트와 실시간 조회를 실행해야 하는 키 집합을 정의할 수 있습니다. 이 요청을 처리하는 광고 기술 플랫폼의 관리형 서버가 광고 기술 플랫폼에서 관리하는 신뢰할 수 있는 서버가 됩니다.
• 문맥 신호: 여기에는 대략적인 타임스탬프 또는 대략적인 위치 정보나 광고 클릭당비용이 포함될 수 있습니다.
• 사용자 신호: 여기에는 사용 가능한 설치된 패키지 정보 등의 정보가 포함될 수 있습니다.

광고 비용

입찰가 외에도 구매 측 플랫폼은 generateBid()의 일부로 클릭당비용을 반환할 수 있습니다. 예를 들면 다음과 같습니다.

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

이 광고가 낙찰되면 adCost는 개인 정보 보호를 위해 8비트로 확률적으로 반올림됩니다. 그런 다음 반올림된 adCost 값은 노출 보고 중에 reportWin의 contextual_signals 매개변수로 전달됩니다.

구매 측 필터링 로직

구매 측 플랫폼은 광고 선택 단계 중에 제공되는 추가적인 기기 내 신호를 기반으로 광고를 필터링할 수 있습니다. 예를 들어 광고 기술 플랫폼은 여기에서 최대 게재빈도 설정 기능을 구현할 수 있습니다. 필터링 제공자가 여러 개 있다면 시스템은 여러 제공자 간의 실행 순서를 보장하지 않습니다.

구매 측 필터링 로직은 특정 광고의 입찰가 0을 반환하여 입찰 로직의 일부로 구현할 수 있습니다.

또한 구매측 플랫폼은 특정 광고가 Protected Audience에 제공되는 기기 내 추가 신호를 기반으로 필터링되어야 하고 기기를 벗어나지 않는다는 신호를 보낼 수 있습니다. 추가 필터링 로직의 설계를 확고히 함에 따라 구매측 플랫폼은 필터링이 발생해야 한다는 신호를 보내려고 이와 동일한 구조를 따릅니다.

판매측 점수 로직

점수 로직은 일반적으로 판매측 플랫폼(SSP)에서 제공합니다. 코드의 목적은 입찰 로직 출력에 따라 낙찰된 광고를 결정하는 것입니다. 추가 비즈니스 로직을 적용하여 결과를 결정할 수도 있습니다. 결정 로직 제공자가 여러 개 있는 경우 시스템은 여러 제공자 간의 실행 순서를 보장하지 않습니다. 플랫폼은 selectAds() API의 '결정 로직 URL' 입력 매개변수를 사용하여 아래 함수 서명을 포함해야 하는 JavaScript 코드를 가져옵니다.

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

이 함수에는 다음과 같은 매개변수가 필요합니다.

• 광고: 평가될 광고입니다. generateBid() 함수에서 출력됩니다.
• 입찰가: generateBid() 함수의 입찰가 출력입니다.
• 입찰 구성: selectAds() 메서드에 관한 입력 매개변수입니다.
• 신뢰할 수 있는 점수 신호: 광고 기술 플랫폼은 실시간 데이터를 사용하여 광고 필터링 및 점수에 영향을 미칩니다. 예를 들어 앱 게시자는 광고 캠페인이 앱에 광고를 표시하지 못하도록 할 수 있습니다. 이 데이터는 입찰 구성의 신뢰할 수 있는 점수 신호 URL 매개변수에서 가져옵니다. 이 요청을 처리하는 서버는 광고 기술로 관리되는 신뢰할 수 있는 서버여야 합니다.
• 문맥 신호: 여기에는 대략적인 타임스탬프 또는 대략적인 위치 정보가 포함될 수 있습니다.
• 사용자 신호: 여기에는 앱 설치를 시작한 앱 스토어와 같은 정보가 포함될 수 있습니다.
• 맞춤 잠재고객 신호: 채점되는 광고가 기기 내 맞춤 잠재고객에서 제공된 경우 여기에는 리더 및 맞춤 잠재고객 이름과 같은 정보가 포함됩니다.

광고 선택 코드 런타임

제안서에서 시스템은 구성 가능한 URL 엔드포인트에서 광고 기술 플랫폼 제공 입찰 코드를 가져와 기기에서 실행합니다. 휴대기기의 리소스 제약 조건을 감안할 때 입찰 코드는 다음 가이드라인을 준수해야 합니다.

• 코드는 사전 정의된 시간 내에 실행을 마쳐야 합니다. 이 제한은 모든 구매자 광고 네트워크에 균일하게 적용됩니다. 이 제한에 관한 자세한 내용은 이후 업데이트에서 공유됩니다.
• 코드는 독립적이어야 하며 외부 종속 항목이 없어야 합니다.

입찰 로직과 같은 입찰 코드는 앱 설치 소스와 같은 비공개 사용자 데이터에 액세스해야 할 수 있으므로 런타임에 네트워크 또는 저장소 액세스 권한이 제공되지 않습니다.

프로그래밍 언어

광고 기술 플랫폼 제공 입찰 코드는 JavaScript로 작성해야 합니다. 이렇게 하면 광고 기술 플랫폼이 개인 정보 보호 샌드박스를 지원하는 플랫폼 간에 입찰 코드를 공유하는 등의 작업을 실행할 수 있습니다.

낙찰된 광고 렌더링

점수가 가장 높은 광고가 입찰에서 낙찰된 것으로 간주됩니다. 이 초기 제안서에서는 낙찰된 광고가 렌더링을 위해 SDK에 전달됩니다.

사용자의 맞춤 잠재고객 멤버십 또는 앱 참여 기록에 관한 정보가 낙찰된 광고 정보를 통해 앱이나 SDK에서 결정할 수 없도록 솔루션을 개선할 계획입니다(Chrome의 분리 프레임 제안서와 유사).

노출 및 이벤트 보고

참고: 기기 내 입찰과 입찰 서비스를 사용하여 실행되는 입찰 간에는 JS 보고 API에서 약간의 차이가 있습니다. B&A 보고에 관한 자세한 내용은 B&A 문서를 참고하세요.

광고가 렌더링되고 나면 낙찰된 노출이 참여하는 구매 측 플랫폼과 판매 측 플랫폼에 보고될 수 있습니다. 이렇게 하면 구매자와 판매자가 입찰가 또는 맞춤 잠재고객 이름과 같은 입찰의 정보를 낙찰된 노출 보고서와 함께 포함할 수 있습니다. 또한 판매 측 및 낙찰된 구매 측 플랫폼은 낙찰된 광고에 관한 추가적인 이벤트 수준 보고를 받을 수 있습니다. 이를 통해 클릭, 조회, 기타 광고 이벤트와 함께 입찰 정보(입찰가, 맞춤 잠재고객 이름 등)를 포함할 수 있습니다. 플랫폼은 다음 순서로 보고 로직을 호출합니다.

1. 판매 측 보고
2. 구매 측 보고

이를 통해 구매 측 및 판매 측 플랫폼은 중요한 기기 내 정보를 서버로 다시 전송하여 실시간 예산 책정, 입찰 모델 업데이트, 정확한 결제 워크플로와 같은 기능을 사용 설정할 수 있습니다. 이 노출 보고 지원은 Attribution Reporting API를 보완합니다.

이벤트 보고를 지원하는 데는 두 가지 단계가 필요합니다. 판매 측 및 구매 측 JavaScript는 이벤트 보고서를 수신해야 하는 이벤트를 등록해야 하고 판매 측은 이벤트 수준 정보를 보고해야 합니다.

Protected Audience는 비콘을 등록하여, 낙찰된 입찰과 관련된 향후 이벤트를 구독하는 메커니즘을 제공합니다. 판매자의 reportResult() JavaScript 함수에서 판매 측 플랫폼은 플랫폼의 registerAdBeacon() 함수를 사용하여 비콘을 등록할 수 있습니다. 마찬가지로 구매 측 플랫폼은 reportWin() JavaScript 함수에서 registerAdBeacon() 메서드를 호출할 수 있습니다.

registerAdBeacon(beacons)

입력:

• event_key: 등록할 상호작용 유형을 나타내는 문자열입니다. 입찰 결과를 보고하는 동안 플랫폼이 핑하는 엔드포인트를 조회하는 키로 사용됩니다.
• reporting_url: 이벤트를 처리하기 위해 광고 기술 플랫폼에서 소유한 URL입니다.

이벤트 키는 입찰 결과 보고를 담당하는 판매 측 SDK가 소유한 문자열 식별자입니다. 콜백을 실행하기 위해 광고 기술은 이벤트를 보고할 때 판매 측이 사용하는 키와 일치하는 키로 비콘을 등록합니다. 이는 k-익명일 필요는 없지만 특정 맞춤 잠재고객에 등록할 수 있는 키의 수량과 길이에는 제한이 있습니다. reportEvent()이 호출되면 입찰을 실행한 판매 측 플랫폼은 항상 이러한 이벤트 보고서를 수신할 수 있습니다. 낙찰된 구매 측 플랫폼만 이러한 보고서를 수신할 수 있습니다.

참고: 이 제안서에는 이벤트 수준 보고를 사용해야 합니다. 설계는 향후 집계 보고 메커니즘으로 발전할 예정입니다.

판매 측 보고

플랫폼은 selectAds() API의 판매자 결정 로직 URL 매개변수에서 다운로드한 공급 측 제공 코드에서 reportResult() JavaScript 함수를 호출합니다.

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

출력: 다음을 포함하는 JSON 객체입니다.

• 상태: 성공한 경우 0, 실패한 경우 기타 모든 값입니다.
• 보고 URL: 플랫폼은 함수에서 반환된 이 URL을 호출합니다.
• 구매자용 신호: 구매자의 reportWin 함수에 전달할 JSON 객체입니다.

공급 측은 보고 URL에서 관련 신호를 인코딩하여 입찰 및 낙찰된 광고에 관한 유용한 추가 정보를 얻을 수 있습니다. 예를 들어 아래의 신호가 포함될 수 있습니다.

• 광고 렌더링 URL
• 낙찰가
• 앱 이름
• 쿼리 식별자
• 구매자용 신호: 공급 측과 수요 측 간의 데이터 공유를 지원하기 위해 플랫폼은 이 반환 값을 수요 측 보고 코드에 입력 매개변수로 전달합니다.

구매 측 보고

플랫폼은 입찰과 연결된 맞춤 잠재고객의 입찰 로직 URL 메타데이터에서 다운로드한 수요측 제공 코드에서 reportWin() JavaScript 함수를 호출합니다.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

입력:

• AuctionConfig에서 auction_signals 및 per_buyer_signals를 가져옵니다. 구매측 플랫폼이 보고 URL에 전달해야 하는 모든 정보는 이 데이터에서 가져올 수 있습니다.
• signals_for_buyer는 판매측 reportResult의 출력입니다. 이를 통해 판매측 플랫폼은 보고 목적으로 구매측 플랫폼과 데이터를 공유할 수 있습니다.
• contextual_signals에는 앱 이름과 같은 정보가 포함되며 custom_audience_signals에는 맞춤 잠재고객 정보가 포함됩니다. 향후 다른 정보가 추가될 수 있습니다.

출력:

• 상태: 성공한 경우 0, 실패한 경우 기타 모든 값입니다.
• 보고 URL: 플랫폼은 함수에서 반환된 이 URL을 호출합니다.

이벤트 보고

이벤트 보고는 입찰의 노출 보고가 완료된 후에만 가능합니다. 판매 측 SDK는 모든 이벤트를 보고해야 합니다. 플랫폼은 최근 실행된 입찰, 보고된 이벤트 키, 이 키와 연결된 데이터, 보고서를 구매자로 전송해야 하는지 판매자로 전송해야 하는지(또는 둘 다로), 광고 이벤트의 선택적 입력 이벤트를 지정하는 ReportEventRequest를 사용하는 API를 노출합니다. 클라이언트는 보고할 이벤트 키와 데이터 컬렉션을 정의합니다.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

입력:

• ad_selection_id는 AdSelectionOutcome에서 가져온 최근에 실행된 입찰의 AdSelectionId여야 합니다.
• event_key는 상호작용 이벤트를 설명하는 판매 측 정의 문자열입니다.
• event_data는 event_key와 연결된 데이터를 나타내는 문자열입니다.
• reporting_destinations는 플랫폼에서 제공하는 플래그를 사용하는 비트 마스크 집합입니다. FLAG_REPORTING_DESTINATION_SELLER 또는 FLAG_REPORTING_DESTINATION_BUYER 중 하나이거나 둘 다일 수 있습니다.
• input_event(선택사항)는 Attribution Reporting API와 통합하는 데 사용됩니다. InputEvent 객체(클릭 이벤트의 경우) 또는 null(조회 이벤트의 경우)입니다. 이 매개변수에 관한 자세한 내용은 Attribution Reporting API 통합을 참고하세요.

판매 측 SDK가 reportEvent를 호출한 후 reporting_destinations 플래그에 따라 플랫폼은 reportWin 및 reportResult JavaScript 함수에서 구매자와 판매자가 등록한 키와 event_key를 일치시키려고 합니다. 일치하는 항목이 있으면 플랫폼은 연결된 reporting_url에 event_data를 게시합니다. 요청의 콘텐츠 유형은 일반 텍스트이고 event_data인 본문이 포함되어 있습니다. 이 요청은 최선의 방식으로 이루어지며 네트워크 오류 또는 서버 오류 응답이 발생하거나 일치하는 키가 발견되지 않으면 자동으로 실패합니다.

Attribution Reporting API 통합

Protected Audience 입찰에 참여하는 구매자를 지원하기 위해 Google에서는 Protected Audience 및 Attribution Reporting API(ARA) 전반에 교차 API 기능을 제공합니다. 이 기능을 사용하면 광고 기술이 다양한 리마케팅 전술에서 기여 분석 실적을 평가할 수 있으므로 가장 높은 ROI를 제공하는 잠재고객 유형을 파악할 수 있습니다.

이러한 교차 API 통합을 통해 광고 기술에서는 다음을 실행할 수 있습니다.

• 1) 광고 상호작용 보고 및 2) 소스 등록에 둘 다 사용할 수 있는 URI의 키-값 맵을 만듭니다.
• 집계 요약 보고의 소스 측 키 매핑에 Protected Audience 입찰의 입찰 데이터를 포함합니다(Attribution Reporting API 사용). 자세한 내용은 ARA 설계 제안서를 참고하세요.

사용자가 광고를 보거나 클릭할 때:

• Protected Audience를 사용하여 이러한 이벤트 상호작용을 보고하는 데 사용되는 URL은 Attribution Reporting API에 조회 또는 클릭을 적격 소스로 등록하는 데 사용되는 필수 데이터를 구매자에게 제공합니다.
• 광고 기술에서는 해당 URL을 사용하여 CustomAudience(또는 광고 게재위치 또는 시청 지속 시간과 같은 광고에 관한 기타 관련 문맥 정보)를 전달하도록 선택할 수 있습니다. 그러면 광고 기술에서 전체 캠페인 실적을 검토할 때 이 메타데이터를 요약 보고서로 전파할 수 있습니다.

소스 등록 사용 설정

reportEvent()는 새로운 선택적 매개변수인 InputEvent를 허용합니다. 광고 비콘을 등록하는 낙찰된 구매자는 Attribution Reporting API에 등록된 소스로 등록할 reportEvent 보고서를 선택할 수 있습니다. 요청 헤더 Attribution-Reporting-Eligible이 reportEvent()에서 전송된 모든 이벤트 보고 요청에 추가됩니다. 적절한 ARA 헤더가 있는 응답은 다른 일반 ARA 소스 등록 응답과 동일한 방식으로 파싱됩니다. 소스 URL을 등록하는 방법은 Attribution Reporting API 설명을 참고하세요.

Android의 ARA는 조회 및 클릭 이벤트를 지원하므로 InputEvents가 두 유형을 구분하는 데 사용됩니다. ARA 소스 등록과 마찬가지로 reportEvent() API는 플랫폼 인증 InputEvent를 클릭 이벤트로 해석합니다. InputEvent가 누락되거나 null이거나 유효하지 않으면 소스 등록이 조회로 간주됩니다.

입찰 후 eventData에는 민감한 정보가 포함될 수 있으므로 플랫폼은 리디렉션된 소스 등록 요청에서 eventData를 삭제합니다.

참여 및 전환 보고의 예

이 예에서는 입찰, 렌더링된 광고, 전환 앱의 데이터를 서로 연결하는 데 관심이 있는 구매자의 관점에서 살펴보겠습니다.

이 워크플로에서 구매자는 판매자와 협력하여 입찰에 고유 ID를 전송합니다. 입찰 중에 구매자는 이 고유 ID를 입찰 데이터와 함께 보냅니다. 렌더링 및 전환 시간 동안 렌더링된 광고의 데이터도 동일한 고유 ID로 전송됩니다. 나중에 이 고유 ID를 사용해 이러한 보고서를 연결할 수 있습니다.

워크플로: 입찰이 시작되기 전에 구매자는 프로그래매틱 실시간 입찰('RTB') 입찰 응답의 일부로 고유 ID를 판매자에게 전송합니다. 이 ID는 auctionId와 같은 변수로 설정할 수 있습니다. ID는 auctionConfig에서 perBuyerSignals로 전달되며 구매자의 입찰 로직에서 사용할 수 있게 됩니다.

1. reportWin을 실행하는 동안 구매자는 광고 렌더링 시간 동안 특정 상호작용 이벤트(registerAdBeacon())에 대해 트리거될 광고 비콘을 등록할 수 있습니다. 광고 이벤트의 입찰 신호를 연결하려면 비콘 URL의 쿼리 매개변수로 auctionId를 설정하세요.
2. 광고 렌더링 시간 동안 입찰 시간에 등록한 비콘은 이벤트 수준 데이터로 트리거되거나 개선될 수 있습니다. 판매자는 reportEvent()를 트리거하고 이벤트 수준 데이터를 전달해야 합니다. 플랫폼은 트리거된 reportEvent()와 상관관계가 있는 구매자의 등록된 광고 비콘 URL을 핑합니다.
3. 구매자는 Attribution-Reporting-Register-Source 헤더로 광고 비콘 요청에 응답하여 Attribution Reporting API에 광고를 등록합니다. 전환 이벤트의 입찰 신호를 연결하려면 소스 URL 등록에서 auctionId를 설정합니다.

위의 프로세스 후에 구매자는 서로 연결하는 데 사용할 수 있는 고유 ID를 사용하여 상호 연결할 수 있는 입찰 보고서, 상호작용 보고서, 전환 보고서를 갖게 됩니다.

기여 분석 데이터에 액세스해야 하는 판매자에게도 유사한 워크플로가 적용되며, 판매자도 고유 ID를 사용하여 registerAdBeacon()과 함께 전송할 수 있습니다. reportEvent() 호출에는 구매자와 판매자 모두에게 보고서를 보내는 데 사용할 수 있는 대상 속성이 포함됩니다.

광고 기술 플랫폼 신뢰할 수 있는 관리형 서버

오늘날 광고 선택 로직에는 광고 조합이 입찰에 선택되어야 하는지 결정하기 위해 예산 소진 상태와 같은 실시간 정보가 필요합니다. 구매 측 플랫폼과 판매 측 플랫폼(SSP)은 모두 운영하는 서버에서 이 정보를 얻을 수 있습니다. 이러한 서버를 통한 민감한 정보 유출을 최소화하기 위해 제안서에서는 다음 제한사항을 요구합니다.

• 이 섹션의 뒷부분에서 설명하는 이러한 서버의 동작이 사용자 정보를 유출하지 않습니다.
• 서버는 표시되는 데이터를 기반으로 가명 프로필을 만들지 않습니다. 즉, 서버를 '신뢰할 수 있어야' 합니다.

구매 측: 구매 측이 구매 측 입찰 로직을 시작하면 플랫폼은 신뢰할 수 있는 서버에서 신뢰할 수 있는 입찰 데이터의 HTTP 가져오기를 실행합니다. URL은 처리 중인 맞춤 잠재고객의 신뢰할 수 있는 입찰 신호 메타데이터에 있는 URL과 키를 추가하여 구성됩니다. 이 가져오기는 기기 내 맞춤 잠재고객의 광고를 처리할 때만 실행됩니다. 이 단계에서 구매측은 예산을 적용하고 캠페인 일시중지/일시중지 해제 상태를 확인하며 타겟팅을 실행하는 등의 작업을 할 수 있습니다.

다음은 맞춤 잠재고객의 신뢰할 수 있는 입찰 신호 메타데이터를 기반으로 신뢰할 수 있는 입찰 데이터를 가져오는 샘플 URL입니다.

https://www.kv-server.example/getvalues?keys=key1,key2

서버의 응답은 키가 key1, key2 등이고 구매자의 입찰 함수에서 값을 사용할 수 있는 JSON 객체여야 합니다.

판매 측: 위의 구매 측 흐름과 마찬가지로 판매 측도 입찰에서 고려된 광고 소재에 관한 정보를 가져오려고 할 수 있습니다. 예를 들어 게시자는 특정 광고 소재가 브랜드 안전성 문제에 따라 앱에 표시되지 않도록 할 수 있습니다. 이 정보를 가져와서 판매측 입찰 로직에 제공할 수 있습니다. 구매 측 신뢰할 수 있는 서버 조회와 마찬가지로 판매 측 신뢰할 수 있는 서버 조회도 HTTP 가져오기를 통해 발생합니다. 이 URL은 데이터를 가져와야 하는 광고 소재의 렌더링 URL과 함께 신뢰할 수 있는 점수 신호 URL을 추가하여 구성됩니다.

다음은 광고 소재 렌더링 URL을 기반으로 입찰에서 고려되는 광고 소재에 관한 정보를 가져오는 샘플 URL입니다.

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

서버의 응답은 키가 요청에서 전송된 렌더링 URL인 JSON 객체여야 합니다.

이러한 서버는 신뢰할 수 있는 방식으로 운영되어 다음과 같은 여러 보안 및 개인 정보 보호 이점을 제공합니다.

• 각 키에 관한 서버의 반환 값은 그 키에만 기반할 것으로 신뢰할 수 있습니다.
• 서버가 이벤트 수준 로깅을 실행하지 않습니다.
• 이 서버에는 이러한 요청에 기반한 다른 부수 효과가 없습니다.

임시 메커니즘으로 구매자와 판매자는 자체적으로 운영되는 서버를 비롯하여 모든 서버에서 이러한 입찰 신호를 가져올 수 있습니다. 하지만 이 출시 버전에서는 신뢰할 수 있는 키-값 유형 서버로만 요청이 전송됩니다.

구매자와 판매자는 Android 및 웹의 개인 정보 보호 샌드박스와 호환되는 플랫폼에 신뢰할 수 있는 일반적인 키-값 유형 서버를 사용할 수 있습니다.