Protected Audience API 입찰 지연 시간 개선

Protected Audience API가 효율적으로 작동하도록 하는 것이 모든 사용자에게 이롭습니다.

  • 웹을 탐색하는 사용자는 사이트가 빠르게 로드되기를 원합니다. 즉, 개발자는 사이트와 삽입된 광고를 로드하는 데 필요한 컴퓨팅 또는 네트워크 리소스와 같은 제한된 기기 리소스를 과도하게 사용하지 않도록 Protected Audience API로 효율적으로 빌드해야 합니다.
  • 게시자는 사이트가 빠르게 로드되어 사용자에게 효율적이고 반응이 빠른 환경을 제공하기를 원합니다. 게시자는 수익을 극대화하기 위해 효과적인 광고도 원합니다.
  • 광고주와 광고 기술은 광고가 최대한 유용하게 게재되도록 빠르게 표시되기를 원합니다.

이 문서에서는 사이트가 최대의 효율로 작동하도록 하기 위한 Protected Audience API 구현을 위한 몇 가지 권장사항을 설명합니다.

구매자 (입찰자) 권장사항

Protected Audience API 입찰 효율성을 최적화하려면 다음 권장사항을 따르세요.

관심분야 그룹 소유자 수 감소

브라우저가 사이트 격리를 사용하여 웹의 여러 출처를 보호하는 것과 동일한 방식으로 Protected Audience API 입찰자를 보호하기 위해 브라우저는 운영체제 프로세스와 같은 값비싼 리소스를 사용하여 개별 관심분야 그룹 소유자를 보호합니다.

이러한 매우 비싼 리소스의 지출을 최소화하려면 관심분야 그룹 소유자의 수를 최소화하는 것이 중요합니다. 여러 하위 도메인이 서로 다른 관심분야 그룹을 소유하지 않도록 합니다. 예를 들어 adtech.examplecats.adtech.exampledogs.adtech.example가 소유한 관심분야 그룹이 있는 경우 브라우저는 두 개의 별도 프로세스를 사용하여 입찰 스크립트를 실행할 수 있습니다.

입찰하는 관심분야 그룹이 적음

브라우저는 새롭고 깨끗한 JavaScript 실행 환경을 설정하고 generateBid() 코드를 파싱 및 로드하는 등 구매자의 generateBid() 스크립트를 호출하기 전에 상당한 설정과 준비를 해야 합니다.

  • 운영 중인 광고 캠페인의 현재 타겟이 아닌 사용자를 나타내는 관심분야 그룹의 광고 소재 목록은 비어 있어야 합니다. 이렇게 하면 Protected Audience API가 관련성 있는 광고가 없는 관심분야 그룹에 대해 generateBid()를 실행하지 못합니다.
  • 유사한 관심분야 그룹을 결합하면 generateBid()를 실행해야 하는 횟수가 줄어듭니다. 관심분야 그룹의 userBiddingSignals 속성을 사용하여 사용자에 관한 추가 메타데이터를 저장할 수 있으므로 관심분야 그룹이 적다고 해서 타겟팅 효과가 떨어지는 것은 아닙니다.
  • Protected Audience API는 판매자가 지정한 관심분야 그룹 수 제한과 구매자가 관심분야 그룹의 상대적 우선순위를 지정할 수 있는 API를 지원합니다. 이러한 제한을 사용하면 실행할 입찰 스크립트 수를 크게 줄일 수 있습니다.

키/값 서비스의 입찰에서 관심분야 그룹 제외

구매자가 실시간 신뢰할 수 있는 입찰 신호 서버에서 특정 관심분야 그룹이 입찰해서는 안 된다고 판단할 수 있는 경우 (예: 캠페인이 사용 중지되거나 일시중지되었거나 예산이 부족하거나 이 특정 게시자에 입찰해서는 안 됨) 신뢰할 수 있는 입찰 신호 가져오기에 대한 priorityVector 응답을 사용하여 브라우저에 이를 표시할 수 있습니다. priorityVectorprioritySignals의 결과로 나온 희소 내적값이 음수인 경우 브라우저는 이 관심분야 그룹에 대한 generateBid() 호출을 건너뜁니다. 이 메커니즘에 관한 자세한 내용은 설명서의 '관심분야 그룹 필터링 및 우선순위 지정' 섹션을 참고하세요.

JavaScript 실행 환경 재사용

브라우저가 generateBid()를 실행하려면 먼저 새 JavaScript 실행 환경을 초기화해야 합니다. 최소 generateBid() 자체가 실행되는 데 걸리는 시간과 비슷한 상당한 시간이 걸릴 수 있습니다. 이 시간을 절약하려면 출처별 그룹화 또는 동결된 컨텍스트 실행 모드를 사용하면 됩니다.

group-by-origin 모드는 관심분야 그룹이 동일한 출처에서 조인된 경우 실행 환경을 재사용할 수 있으며 입찰 스크립트를 변경하지 않아도 될 수 있습니다. 자세한 내용은 설명서의 group-by-origin 설명을 참고하세요. 동결된 컨텍스트 모드는 잠재적으로 모든 실행 환경을 재사용할 수 있지만 입찰 스크립트를 변경해야 할 수도 있습니다. 자세한 내용은 설명의 frozen-context 설명을 참고하세요.

입찰 스크립트 재사용

가능하면 관심분야 그룹에 동일한 입찰 스크립트를 사용합니다. 이렇게 하면 브라우저에서 여러 스크립트를 다운로드, 파싱, 컴파일할 필요가 없으므로 추가 네트워크 요청이 발생하지 않습니다. 입찰자는 동일한 스크립트를 사용하는 동안 관심분야 그룹 정보 (예: name 또는 userBiddingSignals)를 기반으로 입찰을 차별화할 수 있습니다.

HTTP 캐시 관리 헤더가 없으면 입찰 스크립트가 캐시되지 않습니다. 스크립트가 불필요하게 가져오지 않도록 적절한 헤더를 지정합니다. 페이지에서 여러 입찰이 동시에 실행되는 경우 동일한 입찰자의 입찰 스크립트가 이미 메모리에 있으면 캐싱 시맨틱스를 무시하고 재사용됩니다. 입찰이 순차적으로 실행되면 브라우저는 HTTP 캐싱 메커니즘을 준수합니다.

브라우저는 입찰 시간 (generateBid()의 경우)과 보고 시간 (reportWin()의 경우)에 입찰 스크립트를 로드합니다. 캐시 제어 헤더가 설정되지 않으면 브라우저는 각 기간에 한 번씩 동일한 스크립트를 두 번 가져옵니다.

따라서 모든 스크립트에 캐시 제어 헤더를 설정하는 것이 좋습니다.

trustedBiddingSignalsUrls 재사용

네트워크 지연 시간과 리소스 사용량이 상당할 수 있습니다. 신뢰할 수 있는 실시간 입찰 신호 가져오기를 줄이면 이러한 지연 시간을 줄일 수 있습니다.

trustedBiddingSignalsUrl가 여러 관심분야 그룹 간에 재사용되면 신뢰할 수 있는 입찰 신호 가져오기를 결합할 수 있습니다. 가능하면 모든 관심분야 그룹에 동일한 trustedBiddingSignalsUrl를 사용하세요.

적절한 HTTP 캐시 제어 헤더를 지정하여 신뢰할 수 있는 입찰 신호 가져오기가 특정 웹페이지의 광고 슬롯 전체에 캐시되도록 합니다. 요청된 URL이 다르므로 슬롯 크기가 다를 때 광고 슬롯 전체에서 캐싱이 방지되므로 trustedBiddingSignalsSlotSizeModeslot-size로 설정하지 마세요.

더 적은 수의 신뢰할 수 있는 실시간 입찰 신호 가져오기

네트워크 지연 시간은 매우 클 수 있으며 이는 실시간 신뢰할 수 있는 입찰 신호 가져오기 중에 전송되는 데이터의 양에 직접적인 영향을 받습니다.

실시간 신뢰할 수 있는 입찰 신호 서비스가 아닌 관심분야 그룹에 광고별 또는 관심분야 그룹별 데이터를 저장하는 것이 좋습니다. 캠페인 예산 또는 종료 스위치와 같이 실제로 실시간인 신호에 대해서만 실시간 신뢰할 수 있는 입찰 신호 데이터를 예약합니다.

매일 또는 그 이상 업데이트할 수 있는 신호는 관심분야 그룹에 저장하고 일일 업데이트를 사용하여 업데이트해야 합니다.

'키-값 서비스에서 입찰에서 관심분야 그룹 제외' 섹션에 설명된 대로 제외된 관심분야 그룹에 대해 신뢰할 수 있는 입찰 신호를 반환하지 마세요.

관심분야 그룹 우선순위 지정

판매자는 제한 시간을 사용하여 게시자 페이지에서 브라우저 리소스가 사용되는 방식을 제한합니다. perBuyerCumulativeTimeouts를 사용하여 구매자가 신뢰할 수 있는 입찰 신호를 가져오고 입찰 스크립트를 실행하는 데 걸리는 시간을 제한하는 경우 구매자는 입찰에서 낙찰될 가능성이 가장 높은 관심분야 그룹을 먼저 실행할 수 있도록 우선순위를 지정해야 합니다. 예를 들어 perBuyerCumulativeTimeouts가 100ms로 설정되어 있고 입찰자의 신뢰할 수 있는 입찰 신호 가져오기에 50ms가 소요되며 각 generateBid() 호출에 10ms가 소요되고 기기에 10개의 관심분야 그룹이 있는 경우 관심분야 그룹의 절반만 입찰가를 계산할 수 있습니다. 이 예에서 구매자는 낙찰 가능성이 가장 높은 순서부터 낙찰 가능성이 가장 낮은 순서로 관심분야 그룹의 우선순위를 지정해야 합니다.

관심분야 그룹에는 priority 필드로 정의된 정적 우선순위가 포함될 수 있습니다. 관심분야 그룹은 신뢰할 수 있는 입찰 신호 서비스에서 계산되고 신뢰할 수 있는 입찰 신호 가져오기에 대한 priorityVector 응답과 함께 브라우저로 반환될 수 있는 동적 우선순위를 사용할 수도 있습니다.

브라우저가 관심분야 그룹을 우선순위가 높은 순서대로 실행하면 서로 다른 조인 출처의 관심분야 그룹이 섞여 group-by-origin 최적화가 실패할 수 있습니다.

판매자 권장사항

Protected Audience API 입찰 효율성을 모니터링하고 최적화해야 합니다.

입찰 병렬화

최신 네트워크 연결과 멀티코어 프로세서는 여러 활동을 동시에 실행하는 데 탁월합니다. 브라우저는 다른 활동과 동시에 Protected Audience 입찰을 실행할 수 있습니다. 이를 위해서는 최대한 빨리 runAdAuction()를 호출하는 것이 가장 좋습니다. runAdAuction()의 일부 입력(예: 문맥 응답에서 브라우저로 다시 전송되는 입력)은 초기에 사용할 수 없을 수 있음을 인식하여 브라우저는 이러한 입력을 사용할 수 있기 전에 runAdAution()를 호출하고 나중에 JavaScript Promise를 사용하여 이러한 입력을 제공할 수 있도록 허용합니다. 가능한 한 짧은 입찰 지연 시간을 달성하려면 interestGroupBuyers 입력이 알려진 후에 runAdAuction()를 호출해야 합니다. 이렇게 하면 입찰자의 실시간 입찰 신호 가져오기를 비롯하여 입찰의 여러 부분을 즉시 시작할 수 있습니다.

입찰 모니터링

입찰에 대한 측정항목을 수집합니다. 브라우저는 판매자의 입찰에서 시간이 어떻게 소비되는지에 대한 유용한 정보를 제공하는 per-buyer 지연 시간 측정항목을 판매자에게 보고할 수 있습니다. 판매자는 이러한 측정항목을 사용하여 가장 효과적으로 제한 시간을 설정하는 방법을 알리는 등 입찰을 최적화하는 방법을 모색할 수 있습니다. 판매자는 특정 구매자의 지연 시간 측정항목을 구매자와 공유하여 구매자가 추가로 최적화할 수 있도록 지원할 수 있습니다.

입찰자는 자신의 관심분야 그룹의 입찰 실적에 대한 통계를 확인할 수 있지만 이를 다른 입찰자와 비교할 수는 없습니다. 여러 입찰자의 상대적 낙찰률과 입찰 거부율을 비교하면 관심분야 그룹이 실행 가능한 입찰가를 생성하지 못하거나 승인되지 않은 광고 소재로 과도하게 입찰하여 입찰 컴퓨팅 리소스가 낭비된 사례를 파악하는 데 도움이 될 수 있습니다.

느린 입찰 스크립트로부터 보호

시간이 너무 오래 걸리는 입찰 스크립트는 관련된 모든 사용자의 Protected Audience API 입찰 속도를 저하시킬 수 있습니다. 제한 시간을 사용하면 입찰이 느려도 수익을 계속 회수하면서 느린 입찰을 방지할 수 있습니다.

판매자는 perBuyerCumulativeTimeouts를 사용하여 입찰 속도가 느려지지 않도록 하고 입찰이 느려져 제한 시간에 도달한 경우에도 입찰가를 계속 수락해야 합니다. perBuyerCumulativeTimeouts는 관심분야 그룹의 수나 generateBid()의 속도에 관해 선입견이 없으므로 perBuyerTimeoutsperBuyerGroupLimits를 사용하는 것보다 perBuyerCumulativeTimeouts를 사용하는 것이 좋습니다. 예를 들어 빠르게 입찰하는 관심분야 그룹이 많고 천천히 입찰하는 관심분야 그룹이 적더라도 모두 제한 시간 전에 완료될 수 있습니다.

입찰 구성 signal 필드를 사용하여 전체 입찰 시간 제한을 구현하는 것도 좋습니다. 신뢰할 수 있는 점수 매기기 신호 가져오기 및 scoreAd() 실행에 시간이 너무 오래 걸리는 경우 입찰이 너무 길어지는 것을 방지할 수 있습니다.

다음 단계

Google은 누구나 사용할 수 있는 API를 빌드할 수 있도록 개발자 여러분과 대화를 나누고 싶습니다.

API에 관해 논의하기

다른 개인 정보 보호 샌드박스 API와 마찬가지로 이 API는 문서화되고 공개적으로 논의됩니다.

API 실험

Protected Audience API에 관한 대화에 실험하고 참여할 수 있습니다.