FLEDGE는 이제 Protected Audience입니다. 자세히 알아보기

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

의견 보내기

최신 업데이트

  • 맞춤 잠재고객 위임에 관한 제안이 추가되었습니다.
  • 일일 업데이트 URL의 k-익명성 요구사항을 삭제했습니다.

개요

모바일 광고에서 광고주는 일반적으로 사용자가 과거에 광고주의 앱에서 참여했던 방식을 기반으로 잠재적 관심이 있는 사용자에게 광고를 게재하려고 합니다. 예를 들어 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를 보완합니다. 광고 기술 플랫폼은 보고 요구사항에 따라 맞춤설정할 수 있습니다.

Android용 FLEDGE API에 액세스

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

맞춤 잠재고객 관리

맞춤 잠재고객

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

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

맞춤 잠재고객 메타데이터

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

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

맞춤 잠재고객 위임

기존 맞춤 잠재고객 정의 및 구성은 일반적으로 대행사 및 광고주 클라이언트와 파트너 간의 제휴로 광고 기술을 통해 서버 측 기술 및 통합에 의존합니다. FLEDGE를 사용하면 개인 정보를 보호하는 방식으로 맞춤 잠재고객을 정의하고 구성할 수 있습니다. 맞춤 잠재고객에 참여하려면 앱에 SDK가 없는 구매자 광고 기술은 모바일 측정 파트너(MMP)나 공급측 플랫폼(SSP)과 같이 기기 내 존재하는 광고 기술과 공동작업해야 합니다. FLEDGE 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);

fetchCustomAudience()

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

CustomAudienceFetchRequest fetchRequest = new CustomAudienceFetchRequest(
    // 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("{...}")
);

fetchCustomAudience(fetchRequest);

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

{
 "name": "running-shoes",
 "activation_time": 1680603133,
 "expiration_time": 1680803133,
 "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/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": "key1",
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": "key2",
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

fetchCustomAudience() API는 fetchUri의 eTLD+1에서 구매자 ID를 확인합니다. CustomAudience 구매자 ID는 joinCustomAudience()에 의해 실행된 동일한 등록 및 앱 승인 검사를 실행하는 데 사용되며 가져오기 응답에서 변경할 수 없습니다. CustomAudience 소유자는 호출하는 애플리케이션의 패키지 이름입니다. eTLD+1 검사 외에 fetchUri의 다른 검사는 없으며 특히 k-anon 검사가 없습니다. fetchCustomAudience() API는 fetchUri에 HTTP GET 요청을 실행하고 맞춤 잠재고객을 나타내는 JSON 객체를 기대합니다. 맞춤 잠재고객 객체 필드의 필수, 선택적 제약 조건 및 기본값이 응답에 동일하게 적용됩니다. 개발자 가이드의 현재 요구사항 및 제한사항을 알아보세요. 구매자의 HTTP 오류 응답이 발생하면 CustomAudience가 실패합니다. 특히 HTTP 상태 응답 429(너무 많은 요청)는 정의될 기간 동안 현재 애플리케이션의 요청을 차단합니다. 일시적인 실패(예: 서버가 응답하지 않거나 시간 초과됨)인 경우 재시도하거나 연속적인 실패(예: 데이터 검증 실패 또는 서버와의 통신에서 일시적이지 않은 실패)를 처리할 책임이 있는 API 호출자에게 실패가 보고됩니다.

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

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

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

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

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

맞춤 잠재고객 탈퇴

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

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

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

사용자 제어

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

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

앱 권한 및 제어

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

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

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

광고 기술 플랫폼 제어

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

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

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

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

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

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

광고 선택 워크플로

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

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

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

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

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

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

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

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

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

광고 선택 워크플로 시작

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

  • 판매자: eTLD+1 형식을 따르는 판매 측 광고 플랫폼의 식별자입니다.
  • 결정 로직 URL: 광고 입찰이 시작되면 플랫폼은 이 URL을 사용하여 판매 측 플랫폼에서 자바스크립트 코드를 가져와 낙찰된 광고에 점수를 매깁니다.
  • 맞춤 잠재고객 구매자: 이 입찰의 맞춤 잠재고객 기반 수요가 있는 구매측 플랫폼의 목록으로, 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' 메타데이터를 사용하여 아래 함수 서명을 포함해야 하는 자바스크립트 코드를 가져옵니다.

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

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

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

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

구매측 필터링 로직

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

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

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

판매 측 점수 로직

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

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 엔드포인트에서 광고 기술 플랫폼 제공 입찰 코드를 가져와 기기에서 실행합니다. 휴대기기의 리소스 제약 조건을 감안할 때 입찰 코드는 다음 가이드라인을 준수해야 합니다.

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

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

프로그래밍 언어

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

낙찰된 광고 렌더링

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

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

노출 보고

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

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

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

판매측 보고

플랫폼은 selectAds() 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_signals 및 per_buyer_signals는 AuctionConfig에서 가져옵니다. 구매측 플랫폼이 보고 URL에 전달해야 하는 모든 정보는 이 데이터에서 가져올 수 있습니다.
  • signals_for_buyer는 판매측 reportResult의 출력입니다. 이를 통해 판매 측 플랫폼은 보고 목적으로 구매 측 플랫폼과 데이터를 공유할 수 있습니다.
  • 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 및 웹의 개인 정보 보호 샌드박스와 호환되는 플랫폼에 신뢰할 수 있는 일반적인 키-값 유형 서버를 사용할 수 있습니다.