입찰 서비스

초기 Protected Audience 제안서에서는 리마케팅 광고 수요에 대한 입찰이 기기에서 로컬로 실행됩니다. 이 요구사항은 처리 성능이 제한적인 기기에서 실행하기에 비효율적이거나, 네트워크 지연 시간으로 인해 광고를 선택하거나 렌더링하기에 너무 느릴 수 있는 계산 요건을 요구할 수 있습니다.

입찰 서비스(B&A) 제안서에서는 Protected Audience 계산을 사용자의 기기에서 로컬로 실행하지 않고 신뢰할 수 있는 실행 환경(TEE)의 클라우드 서버에서 실행할 수 있는 방법을 설명합니다. B&A 제안서는 문맥 및 리마케팅 광고 수요를 고려하기 위한 통합 흐름을 지원하는 것을 목표로 합니다. 계산을 서버로 이동하면 기기의 계산 주기와 네트워크 대역폭을 확보하여 Protected Audience 입찰을 최적화하는 데 도움이 될 수 있습니다.

Google에서 B&A의 구성요소를 제공하고 이러한 구성요소는 오픈소스로 제공됩니다. 관심 있는 광고 기술은 지원되는 퍼블릭 클라우드 제공업체를 통해 자체 인스턴스를 호스팅할 수 있습니다. B&A 제안서에 관한 자세한 내용은 GitHub를 참고하세요. 해당 문서에 표시된 날짜는 Chrome 구현을 반영하며 향후 Android와의 통합에 관한 자세한 정보를 게시할 예정입니다. 이 문서는 B&A와 B&A와 상호작용하기 위해 Android에서 제공하는 새로운 API를 소개합니다. 향후 업데이트에서 이러한 새 API를 사용하는 방법에 관한 자세한 기술 정보를 게시할 예정입니다.

B&A 서비스가 적합한 곳

B&A는 Google에서 제공하는 오픈소스 바이너리를 실행하는 신뢰할 수 있는 광고 기술 소유 서버 내에서 입찰을 실행하는 추가 옵션을 제공합니다. 사용자 데이터는 여전히 기기에 있으며, Google은 이 데이터를 TEE로 안전하게 이동하는 API를 제공합니다. 아래에서 암호화 전략을 자세히 알아보세요.

즉, 입찰 프로세스의 일부는 기기에서 발생하고 일부는 클라우드에서 이루어집니다. DSP의 관점에서 볼 때, 맞춤 잠재고객(리마케팅 캠페인을 위한 조합 광고 포함)은 기기에서 입찰이 실행될 때와 동일한 맞춤 잠재고객 관리 API를 사용하여 여전히 기기에서 관리됩니다. SSP의 관점에서 요청은 여전히 기기에서 트리거되며 이 문서에서는 사용할 새로운 API를 설명합니다. 모든 당사자의 경우 입찰 결과 보고는 여전히 B&A 호출이 완료된 후 기기에서 시작됩니다.

주요 차이점은 입찰, 점수 산정, 보고 URL 생성 로직이 실행되는 위치에 있습니다. 입찰, 보고 로직을 기기에서 실행하는 대신 generateBid(), scoreAd(), reportResult(), reportWin() 로직은 TEE에서 실행됩니다. 구매자의 입찰 로직과 판매자의 점수 로직은 Protected Audience 입찰 흐름 중에 자체 B&A 환경 내에서 실행됩니다.

<ph type="x-smartling-placeholder">
</ph> Protected Audience 입찰 흐름 및 입찰이 적합한 위치를 보여주는 그림
Protected Audience 입찰 흐름

데이터 암호화

B&A를 사용하면 맞춤 잠재고객 및 입찰 금액과 같은 Protected Audience 정보가 판매자 광고 기술 서버를 통해 기기에서 구매자 광고 기술 서버로 그리고 다시 기기로 흐릅니다. 따라서 플랫폼은 Protected Audience 서비스로 이동하는 데이터를 암호화하며, 증명된 서비스에서만 복호화할 수 있습니다. GitHub에서 암호화 전략에 관해 자세히 알아보세요.

아키텍처 및 입찰 흐름

이 제안서에는 기기에서 B&A로의 데이터 흐름을 포함하여 GitHub에 자세히 설명된 여러 새 구성요소의 필요성이 포함되어 있습니다.

<ph type="x-smartling-placeholder">
</ph> 다음에 설명된 통합 문맥 및 Protected Audience 입찰 흐름을 보여주는 그림
통합 문맥 및 입찰 서비스가 포함된 Protected Audience 입찰 흐름

개략적으로 데이터 흐름은 다음과 같습니다.

  1. 기기에서 판매자는 getAdSelectionData API를 사용하여 Protected Audience에서 정보를 수집합니다.
  2. 기기 내 SDK가 판매자 광고 서비스에 요청을 보냅니다. 이 요청에는 문맥 페이로드와 암호화된 ProtectedAudienceInput이 포함됩니다.
  3. 판매자 광고 서비스는 TEE 외부에서 실행되는 구매자의 실시간 입찰(RTB) 서비스에 요청을 보내 조합 문맥 광고를 획득한 다음 낙찰 문맥 광고를 평가하고 선택합니다.
  4. 판매자 광고 서비스가 TEE에서 실행되는 SellerFrontEnd 서비스에 요청을 보냅니다.
  5. SellerFrontEnd 서비스는 BuyerFrontEnd 서비스에 구매자 관련 데이터가 포함된 요청을 보냅니다.
  6. 구매자는 자체 키/값 서비스 및 입찰 서비스를 사용하여 리마케팅 대상으로 고려되는 모든 맞춤 잠재고객을 위해 기기에서 제공된 광고 조합에 대한 입찰가를 생성합니다.
  7. SellerFrontEnd 서비스는 키/값 서비스에서 읽고 조합 광고에 점수를 매깁니다. 결과는 암호화되어 판매자 광고 서비스로 반환됩니다.
  8. 판매자 광고 서비스는 암호화된 낙찰 결과 및 문맥 결과(선택사항)를 기기 내 SDK에 반환합니다.
  9. 기기에서 판매자는 processAdSelectionResult API를 사용하여 낙찰 광고를 검색합니다. 이 API는 판매자 광고 서비스의 응답을 복호화합니다.

각 단계와 데이터 암호화 방법에 관한 자세한 설명은 GitHub에서 확인할 수 있습니다. 이러한 구성요소의 코드는 오픈소스를 통해 제공됩니다. 제공된 코드는 SellerFrontEnd 서비스에서 BuyerFrontEnd 서비스로의 요청 통합을 처리합니다.

클라우드 배포

광고 기술은 지원되는 퍼블릭 클라우드 플랫폼에 B&A 서비스를 배포합니다. 이러한 배포는 가용성 서비스 수준 목표를 정의하는 광고 기술로 관리됩니다.

입찰 실행

B&A 입찰을 실행하는 첫 번째 단계는 기기 내 맞춤 잠재고객에서 데이터를 수집하고 이를 암호화하여 서버 측 입찰로 전송하는 것입니다. 이렇게 하려면 getAdSelectionData API를 사용합니다.

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

getAdSelectionData 메서드는 BuyerInput 및 ProtectedAudienceInput과 같은 B&A 구성요소에 필요한 입력을 생성하고 데이터를 암호화한 후 호출자에게 결과를 제공합니다. 여러 앱에서 데이터가 유출되는 것을 방지하기 위해 이 데이터에는 기기에 있는 모든 구매자의 정보가 포함됩니다. 이 결정에 관한 자세한 내용은 개인 정보 보호 고려사항 섹션을 참고하세요.

이 API는 AdSelectionData 객체를 반환합니다.

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

이 AdSelectionData를 사용하면 기기 내 SDK가 POST 또는 PUT 요청에 데이터를 포함하여 판매자 광고 서비스에 요청을 보낼 수 있습니다.

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

기기 내 SDK는 이 데이터를 인코딩해야 합니다. 판매자 광고 서비스에 요청을 보내는 것과 같은 공간 효율적인 솔루션을 multipart/form-data로 사용하는 것이 좋습니다.

요청이 시작되면 판매자 광고 서비스는 TEE에서 실행되는 SellerFrontEnd 서비스로 요청을 전달합니다. SellerFrontEnd 서비스를 구성할 때 판매자는 판매자가 파트너십을 맺은 구매자가 운영하는 BuyerFrontEnd 서비스에 해당하는 도메인 주소 목록을 제공합니다. 구매자가 선택된 광고 조합의 입찰을 생성할 수 있도록 판매자가 제공한 다양한 BuyerFrontEnd 서비스에 요청이 통합됩니다. 특정 구매자의 경우 B&A는 구매자가 소유한 맞춤 잠재고객에 관한 정보만 전송하므로 구매자 간에 데이터가 교차 유출되지 않습니다. 입찰을 생성한 후 조합 광고 목록이 낙찰자가 선택된 SellerFrontEnd 서비스로 다시 돌아갑니다. 마지막으로 SellerFrontEnd 서비스는 암호화된 낙찰 광고를 기기에 반환합니다.

판매자 광고 서비스에 대한 요청의 응답이 기기에 다시 있으면 플랫폼은 두 번째 새 API를 제공하여 결과를 복호화하고, 현재 기기 내 입찰에서 반환되는 동일한 객체인 AdSelectionOutcome을 제공합니다.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

보고

보고 URL은 B&A 서비스에서 생성됩니다. 입찰의 노출 및 상호작용 보고를 위해 이러한 URL을 핑하는 작업은 여전히 기기에서 트리거되어야 합니다. 기기 내 SDK는 B&A 흐름 중에 생성된 AdSelectionId를 사용하여 reportImpression() 및 reportInteraction() API를 여전히 호출해야 합니다. 상호작용 보고를 위해 생성된 비콘과 관련 URL이 암호화된 응답에 포함되어 있으므로 응답을 복호화하는 동안 이벤트와 URL 매핑이 기기에 저장됩니다.

개인 정보 보호 고려사항

GitHub의 브라우저 입찰 API 제안서에서는 개인 정보 보호 고려사항이 고려된 방법을 설명합니다. 이 제안서는 Chrome의 명명법을 사용하지만 Android에도 동일하게 적용됩니다.

전송 중 데이터에는 PPAPI 및 신뢰할 수 있는 서버에서만 액세스할 수 있도록 adSelectionData가 암호화됩니다. adSelectionData 크기 변경으로 인한 데이터 유출 위험을 완화하기 위해 모든 getAdSelectionData API 호출에 동일한 adSelectionData를 생성할 계획입니다. 즉, 기기의 모든 CustomAudience가 adSelectionData를 만드는 데 사용됩니다. 또한 GetAdSelectionData 입력 매개변수가 생성된 adSelectionData에 미치는 영향을 제한할 계획입니다.

모든 기기 내 입찰 데이터를 사용하는 모든 광고 기술에 동일한 adSelectionData를 생성하면 광고 기술 서버를 호출할 때마다 전송해야 하는 더 높은 페이로드가 생겨날 수 있으며 동시에 악성 항목의 악용에 생태계가 노출될 수 있습니다. 이러한 문제는 아래 크기 고려사항 및 악용 방지 고려사항 섹션에서 다룹니다.

크기 고려사항

광고 기술 클라이언트 SDK는 adSelectionData의 암호화된 바이트를 판매자 서버에 대한 문맥 광고 호출에 패키징해야 합니다. 최적의 성능을 얻으려면 기능을 손상시키지 않고 adSelectionData의 크기를 최적화하는 것이 중요합니다. 페이로드 최적화 설명에 언급된 대로 최적화를 도입하여 adSelectionData 크기를 줄일 계획입니다. 이러한 최적화에는 다음이 포함됩니다.

  1. 광고 렌더링 URI 및 메타데이터를 사용하는 대신 adSelectionData를 사용하여 전송되도록 CustomAudience에 ad_render_id를 추가합니다. 광고 기술은 adSelectionData에서 광고 데이터를 전송하지 않음으로써 이를 추가로 최적화할 수 있습니다. 이 옵션은 향후 출시되는 CustomAudience API에서 지원될 예정입니다.
  2. user_bidding_signals가 adSelectionData에서 전송되지 않도록 합니다. 대신 광고 기술은 키/값 서버에서 user_bidding_signals를 가져올 수 있습니다.
  3. 구매자가 CustomAudience를 우선하도록 허용합니다.
  4. 구매자가 판매자 우선순위를 지정할 수 있습니다.
  5. 비트 유출을 제한하면서 페이로드 크기를 줄이도록 몇 개의 고정 버킷에서 adSelectionData를 생성합니다.

개인 정보 보호 고려사항에서 제기된 문제를 준수하면서 크기를 최적화합니다.

악용 방지 고려사항

개인 정보 보호 고려사항에서 언급했듯이 adSelectionData는 기기의 모든 구매자 데이터를 사용하여 생성됩니다.

이를 통해 성능을 저하시킬 수 있는 사기성 구매자 데이터를 추가하고, 비용 등의 증가를 위해 페이로드를 팽창시킬 수 있는 잠재적 악성 항목에 생태계가 노출됩니다.

adSelectionData의 악용을 방지하기 위해 다음과 같은 조치를 도입합니다.

  • CustomAudience가 승인된 판매자와 판매자 우선순위를 명시적으로 지정할 수 있습니다.
  • SSP가 생성된 페이로드에서 구매자, 구매자 우선순위, 구매자당 할당량을 명시적으로 지정할 수 있습니다.
  • SSP에서 호출당 최대 구매자 수 또는 구매자당 최대 크기를 정의할 수 있는 메커니즘을 제공합니다.

이러한 조치는 광고 기술이 협력하는 다른 광고 기술을 정의하고 처리해야 하는 adSelectionData 페이로드에 허용 가능한 제한을 설정할 수 있도록 설계되었습니다. 판매자가 별도의 호출에서 이 구매자 목록과 우선순위를 지정할 수 있도록 하는 것이 좋습니다. 이 사양은 반복 호출을 통해 사용자에 관한 추가 데이터가 노출되지 않도록 시간 간격 전반에서 일정하게 유지됩니다.

위에서 설명한 완화 조치는 논의 중이며 시간이 지남에 따라 달라질 수 있습니다. 앞서 언급했듯이 악용 방지 및 크기 제한에 관해 도입된 모든 완화 조치는 개인 정보 보호 고려사항을 준수해야 합니다.