Android의 개인 정보 보호 샌드박스 개발자 프리뷰 1이 출시되었습니다. 시작하는 방법을 알아보고 의견을 제공해 주세요.

FLEDGE를 사용한 맞춤 잠재고객 타겟팅 지원

의견 보내기

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

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

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

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

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

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

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

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

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

맞춤 잠재고객 관리

맞춤 잠재고객

맞춤 잠재고객은 공통의 의도 또는 관심분야를 가진 사용자 그룹을 나타냅니다. 앱 또는 SDK는 맞춤 잠재고객을 사용하여 '장바구니에 상품이 남아 있는' 사용자나 게임의 '초급 레벨을 완료한' 사용자와 같은 특정 잠재고객을 나타낼 수 있습니다. 플랫폼은 잠재고객 정보를 기기에 로컬로 유지하고 저장합니다. 이렇게 하면 사용자 정보의 공유를 제한할 수 있습니다.

광고주 앱 또는 통합 SDK는 예를 들어 앱에서의 사용자 참여를 기반으로 맞춤 잠재고객에 참여하거나 탈퇴할 수 있습니다.

맞춤 잠재고객 메타데이터

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

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

맞춤 잠재고객에 참여

앱은 다음 예시 코드 스니펫과 같이 JoinCustomAudience()를 호출하여 맞춤 잠재고객에 참여하도록 요청할 수 있습니다.

CustomAudience audience = new CustomAudience(
    "com.sporting-goods.app",      // Owner. Defaults to the calling app's
                                   // package name.
    "com.example-dsp",             // Reader.
    "running-shoes",               // A logical name for the custom audience.
    currentTime,                   // Creation time.
    expirationTime,                // Expiration time.
    Uri.parse("https://..."),      // Daily update URL.
    biddingData,                   // Trusted Bidding Data key/value pairs.
    candidateAdsList,              // List of candidate ads related to
                                   // this custom audience.
    biddingLogicUrl
);

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

JoinCustomAudience()를 호출하는 앱이 맞춤 잠재고객의 소유자입니다. 이 메서드를 호출할 때 앱은 다음 정보를 지정해야 합니다.

리더: 맞춤 잠재고객에 액세스하여 관련 광고 정보를 가져올 수 있는 당사자를 나타냅니다.

이름: 이 맞춤 잠재고객의 이름입니다.

일일 업데이트 URL: 조합 광고 목록의 URL입니다.

조합 광고: 맞춤 잠재고객 소유자가 맞춤 잠재고객에 참여하면 구매측 플랫폼에서 조합 광고를 가져올 수 있습니다. 광고를 정기적으로 가져오도록 구성할 수도 있습니다.

맞춤 잠재고객 탈퇴

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

// Define a custom audience populated with key fields.
CustomAudience audience = new CustomAudience(
    "com.sporting-goods.app",     // Owner. Defaults to
                                  // the calling app's package name.
    "com.example-dsp",            // Reader.
    "running-shoes"               // A logical name for the custom audience.
    ...
);

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

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

사용자 제어

  • 제안서의 목적은 연결된 맞춤 잠재고객이 하나 이상 있는 설치된 앱의 목록을 사용자에게 보여주는 것입니다.
  • 사용자는 이 목록에서 앱을 삭제할 수 있습니다. 삭제하면 앱과 연결된 모든 맞춤 잠재고객이 삭제되고 앱은 새 맞춤 잠재고객에 참여하지 못합니다.

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

광고 기술 플랫폼 권한 및 제어

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

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

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

맞춤 잠재고객을 위한 조합 광고 가져오기

구매측 플랫폼은 기기에 사용자 상호작용 기반 조합 광고가 저장되도록 할 수 있으므로 맞춤 잠재고객을 위한 입찰이 실행될 때 평가될 수 있습니다. 맞춤 잠재고객을 위한 조합 광고 및 관련 메타데이터는 두 가지 상호 보완적인 방식으로 가져올 수 있습니다.

  1. 시스템 일일 가져오기: 앱이 맞춤 잠재고객에 참여하면 플랫폼에서 매일 쿼리하는 일일 업데이트 URL을 지정할 수 있습니다. 광고 기술 플랫폼은 이 기능을 사용하여 광고 목록을 최신 상태로 유지하고 더 이상 활성 상태가 아니거나 남아 있는 예산이 없는 광고를 삭제할 수 있습니다. 플랫폼은 광고 가져오기 요청을 처리하기 전에 URL 엔드포인트가 k-익명성 개인 정보 보호 기준을 통과하는지 확인합니다.
  2. 맞춤 잠재고객 소유자 중심 가져오기: 소유자가 맞춤 잠재고객에 사용자를 추가하면 구매측 플랫폼에서 조합 광고를 가져올 수 있습니다. 반환된 광고 및 메타데이터는 맞춤 잠재고객의 '광고' 필드에 저장할 수 있습니다. 광고 기술 플랫폼은 이 사용자에게 광고 게재를 바로 시작하려는 경우 이 기능을 사용하는 것이 좋습니다.

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

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

  • 메타데이터: 구매측 광고 기술별 광고 메타데이터입니다. 예를 들어 여기에는 광고 캠페인에 관한 정보와 타겟팅 기준(예: 위치, 언어)이 포함될 수 있습니다.
  • 렌더링 URL: 광고 소재를 렌더링하기 위한 엔드포인트입니다.

광고 선택 워크플로

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

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

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

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

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

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

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

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

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

광고 선택 워크플로 시작

앱에서 광고를 표시해야 하는 경우 광고 기술 플랫폼 SDK가 runAdAuction() 메서드를 호출하여 광고 선택 워크플로를 시작할 수 있습니다.

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

판매자: 판매측 광고 플랫폼의 식별자입니다.

결정 로직 URL: 광고 입찰이 시작되면 플랫폼은 이 URL을 사용하여 판매측 플랫폼(SSP)에서 자바스크립트 코드를 가져와 낙찰된 광고에 점수를 매깁니다.

맞춤 잠재고객 구매자: 이 입찰의 맞춤 잠재고객 기반 수요가 있는 구매측 플랫폼의 목록입니다.

입찰 신호: 입찰 정보(광고 크기, 광고 형식 등)입니다.

판매자 신호: 공급측 플랫폼(SSP) 관련 신호입니다.

신뢰할 수 있는 점수 신호 URL: 광고 소재별 실시간 정보를 가져올 수 있는, 신뢰할 수 있는 판매측 신호의 URL 엔드포인트입니다.

구매자별 신호: 참여하는 수요측은 이 매개변수를 사용하여 입찰을 위한 입력을 제공할 수 있습니다. 예를 들어 이 매개변수에는 입찰가 결정에 유용한 포괄적인 문맥 정보가 포함될 수 있습니다.

다음 예시 코드 스니펫은 광고 선택 워크플로를 시작하는 광고 기술 플랫폼 SDK를 보여줍니다.

AuctionConfig myAuctionConfig = new AuctionConfig {
    "com.example.app",         // Package name for the calling app.
    Uri.parse("https://..."),  // Decision logic URL.
    customAudienceBuyerList,   // List of package names
                               // for custom audience buyers.
    auctionSignals,            // Auction signals
    sellerSignals,             // Seller signals
    perBuyerSignals,           // Per buyer signals
    ...
};

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

구매측 입찰 로직

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

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

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

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

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

광고: 구매측 입찰 코드에서 고려 중인 광고입니다. 맞춤 잠재고객의 광고 또는 문맥 응답에서 반환된 광고일 수 있습니다.

입찰 신호: 판매측 플랫폼별 신호입니다.

구매자별 신호: 참여하는 수요측은 이 매개변수를 사용하여 입찰을 위한 입력을 제공할 수 있습니다. 예를 들어 이 매개변수에는 입찰가 결정에 유용한 포괄적인 문맥 정보가 포함될 수 있습니다.

신뢰할 수 있는 입찰 신호: 광고 기술 플랫폼은 실시간 데이터를 사용하여 광고 검색 및 점수에 영향을 미칩니다. 예를 들어 광고 캠페인은 예산이 소진될 수 있으므로 즉시 게재를 중지해야 합니다. 광고 기술은 이 실시간 데이터를 가져올 수 있는 URL 엔드포인트와 실시간 조회를 실행해야 하는 키 집합을 정의할 수 있습니다. 이 요청을 처리하는 광고 기술 플랫폼의 관리형 서버가 광고 기술 플랫폼에서 관리하는 신뢰할 수 있는 서버가 됩니다.

문맥 신호: 여기에는 조잡해진 타임스탬프 또는 대략적인 위치 정보가 포함될 수 있습니다.

사용자 신호: 여기에는 사용 가능한 설치된 패키지 정보 등의 정보가 포함될 수 있습니다.

구매측 필터링 로직

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

구매측 필터링 로직은 입찰 로직 다음에 실행됩니다.

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

filterAd(ad, per_buyer_signals, trusted_bidding_signals, contextual_signals,
        user_signals) {
    // ...
    return is_filtered;
}

이 자바스크립트 함수에는 입찰 로직 함수의 입력 매개변수와 유사한 입력 매개변수가 필요합니다.

판매측 결정 로직

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

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

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

광고: 평가되는 광고입니다. generateBid() 및 filterAd() 함수의 출력입니다.

입찰가: generateBid() 함수의 입찰가 출력입니다.

입찰 구성: runAdAuction() 메서드에 관한 입력 매개변수입니다.

신뢰할 수 있는 점수 신호: 광고 기술 플랫폼은 실시간 데이터를 사용하여 광고 필터링 및 점수에 영향을 미칩니다. 예를 들어 앱 게시자는 광고 캠페인이 앱에 광고를 표시하지 못하도록 할 수 있습니다. 이 데이터는 입찰 구성의 신뢰할 수 있는 점수 신호 URL 매개변수에서 가져옵니다. 이 요청을 처리하는 서버는 광고 기술로 관리되는 신뢰할 수 있는 서버여야 합니다.

문맥 신호: 여기에는 조잡해진 타임스탬프 또는 대략적인 위치 정보가 포함될 수 있습니다.

사용자 신호: 여기에는 앱 설치를 시작한 앱 스토어와 같은 정보가 포함될 수 있습니다.

맞춤 잠재고객 신호: 채점되는 광고가 기기 내 맞춤 잠재고객에서 제공된 경우 여기에는 리더 및 맞춤 잠재고객 이름과 같은 정보가 포함됩니다.

광고 선택 코드 런타임

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

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

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

프로그래밍 언어

광고 기술 플랫폼 제공 입찰 코드는 자바스크립트로 작성해야 합니다. 이렇게 하면 광고 기술 플랫폼이 예를 들어 개인 정보 보호 샌드박스를 지원하는 플랫폼 간에 입찰 코드를 공유할 수 있습니다.

낙찰된 광고 렌더링

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

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

노출 보고

광고가 렌더링되고 나면 낙찰된 노출이 참여하는 구매측 플랫폼과 판매측 플랫폼(SSP)에 보고될 수 있습니다. 플랫폼은 다음 순서대로 보고 로직을 호출합니다.

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

따라서 구매측 플랫폼과 판매측 플랫폼(SSP)에서 입찰 정보, 맞춤 잠재고객 이름 등의 중요한 기기 내 정보를 서버로 다시 보내 실시간 예산 책정, 입찰 모델 업데이트, 정확한 결제 워크플로와 같은 기능을 사용 설정할 수 있습니다. 이 노출 보고 지원은 Attribution Reporting API를 보완합니다.

판매측 보고

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

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    return reporting_url, signals_for_buyer;
}

출력:

  • 보고 URL: 플랫폼은 함수에서 반환된 이 URL을 호출합니다.

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

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

구매측 보고

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

reportResult(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    return reporting_url;
}

입력:

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

출력:

  • 보고 URL: 플랫폼은 함수에서 반환된 이 URL을 호출합니다.

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

오늘날 광고 선택 로직에는 광고 조합이 입찰에 선택되어야 하는지 결정하기 위해 예산 소진 상태와 같은 실시간 정보가 필요합니다. 구매측 플랫폼과 판매측 플랫폼(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 및 웹의 개인 정보 보호 샌드박스와 호환되는 플랫폼에 신뢰할 수 있는 일반적인 키-값 유형 서버를 사용할 수 있습니다.