Protected Audience API가 효율적으로 작동하도록 하는 것이 모두에게 가장 좋습니다.
- 웹을 탐색하는 사용자는 사이트가 빠르게 로드되기를 원합니다. 즉, 개발자는 사이트와 삽입된 광고를 로드하는 데 필요한 컴퓨팅 또는 네트워크 리소스와 같은 제한된 기기 리소스를 과도하게 사용하지 않도록 Protected Audience API를 효율적으로 사용하여 빌드해야 합니다.
- 게시자는 사이트가 빠르게 로드되어 사용자에게 효율적이고 반응성이 뛰어난 환경을 제공하기를 원합니다. 게시자도 수익을 극대화하기 위해 효과적인 광고를 원합니다.
- 광고주와 광고 기술은 최대한의 유용성을 제공하기 위해 광고가 빠르게 표시되기를 원합니다.
이 문서에서는 사이트가 최대한 효율적으로 작동하도록 Protected Audience API 구현을 위한 몇 가지 권장사항을 설명합니다.
구매자 (입찰자) 권장사항
Protected Audience API 입찰 효율성을 최적화하려면 다음 권장사항을 따르세요.
관심분야 그룹 소유자 수 감소
브라우저가 사이트 격리를 사용하여 웹에서 다양한 출처를 보호하는 것과 동일한 방식으로 Protected Audience API 입찰자를 보호하기 위해 브라우저는 운영체제 프로세스와 같은 비용이 많이 드는 리소스를 사용하여 개별 관심분야 그룹 소유자를 보호합니다.
매우 비싼 이러한 리소스의 지출을 최소화하려면 관심분야 그룹 소유자 수를 최소화하는 것이 중요합니다. 다양한 하위 도메인이 소유한 관심분류가 서로 다르지 않도록 합니다. 예를 들어 adtech.example에 cats.adtech.example 및 dogs.adtech.example가 소유한 관심분야 그룹이 있는 경우 브라우저는 입찰 스크립트를 실행하기 위해 별도의 프로세스 두 개를 사용할 가능성이 높습니다.
입찰하는 관심분야 그룹이 적음
브라우저는 구매자의 generateBid() 스크립트를 호출하기 전에 새 클린 JavaScript 실행 환경을 설정하고 generateBid() 코드를 파싱하고 로드하는 등 상당한 설정과 준비를 해야 합니다.
- 활성 광고 캠페인의 현재 타겟이 아닌 사용자를 나타내는 관심분야 그룹에는 광고 소재 목록이 비어 있어야 합니다. 이렇게 하면 관련 광고가 없는 관심분야 그룹에 대해 Protected Audience API가
generateBid()를 실행하지 않습니다. - 유사한 관심분야 그룹을 결합하면
generateBid()를 실행해야 하는 횟수가 줄어듭니다. 관심분야 그룹의userBiddingSignals속성을 사용하여 사용자에 관한 추가 메타데이터를 저장할 수 있으므로 관심분야 그룹이 적다고 타겟팅 효과가 떨어지는 것은 아닙니다. - Protected Audience API는 판매자가 지정한 관심분야 그룹 수 제한과 구매자가 관심분야 그룹의 상대적 우선순위를 지정할 수 있는 API를 지원합니다. 이러한 한도를 사용하면 실행할 입찰 스크립트 수를 크게 줄일 수 있습니다.
키/값 서비스에서 입찰에서 관심분야 그룹 필터링
구매자가 실시간 신뢰할 수 있는 입찰 신호 서버에서 특정 관심분야 그룹이 입찰해서는 안 된다고 판단할 수 있는 경우 (예: 캠페인이 사용 중지되었거나, 일시중지되었거나, 예산이 부족하거나, 이 특정 게시자에게 입찰해서는 안 됨) 신뢰할 수 있는 입찰 신호 가져오기에 대한 priorityVector 응답을 사용하여 브라우저에 이를 표시할 수 있습니다. priorityVector와 prioritySignals의 결과 스파스 점곱이 음수이면 브라우저는 이 관심분야 그룹에 대해 generateBid() 호출을 건너뜁니다. 이 메커니즘에 관한 자세한 내용은 설명서의 '관심분야 그룹 필터링 및 우선순위 지정' 섹션을 참고하세요.
JavaScript 실행 환경 재사용
브라우저가 generateBid()를 실행하려면 먼저 새 JavaScript 실행 환경을 초기화해야 합니다. 이 작업은 최소한의 generateBid() 자체를 실행하는 데 걸리는 시간과 비슷한 상당한 시간이 걸릴 수 있습니다. group-by-origin 또는 frozen-context 실행 모드를 사용하면 이 시간을 절약할 수 있습니다.
group-by-origin 모드는 동일한 출처에서 관심분류가 가입된 경우 실행 환경을 재사용할 수 있으며 입찰 스크립트를 변경하지 않아도 될 수 있습니다. 자세한 내용은 설명서의 group-by-origin 설명을 참고하세요. 고정 컨텍스트 모드는 잠재적으로 모든 실행 환경을 재사용할 수 있지만 입찰 스크립트를 변경해야 할 수 있습니다. 자세한 내용은 설명의 frozen-context 설명을 참고하세요.
입찰 스크립트 재사용
가능하면 관심분야 그룹에 동일한 입찰 스크립트를 사용합니다. 이렇게 하면 브라우저가 여러 스크립트를 다운로드, 파싱, 컴파일하지 않아도 됩니다 (추가 네트워크 요청이 발생하지 않음). 입찰자는 동일한 스크립트를 사용하는 동안에도 관심분야 그룹 정보 (예: name 또는 userBiddingSignals)에 따라 입찰을 차별화할 수 있습니다.
HTTP 캐시 제어 헤더가 없으면 입찰 스크립트가 캐시되지 않습니다. 스크립트가 불필요하게 가져오지 않도록 적절한 헤더를 지정하세요. 페이지에서 여러 입찰이 동시에 실행되는 경우 동일한 입찰자의 입찰 스크립트가 이미 메모리에 있으면 캐싱 의미 체계를 무시하고 재사용됩니다. 경매가 순차적으로 실행되면 브라우저는 HTTP 캐싱 메커니즘을 준수합니다.
브라우저는 입찰 시간 (generateBid())과 보고 시간 (reportWin())에 입찰 스크립트를 로드합니다. 캐시 제어 헤더가 설정되지 않으면 브라우저가 각 기간에 대해 한 번씩 동일한 스크립트를 두 번 가져옵니다.
따라서 모든 스크립트에 캐시 제어 헤더를 설정하는 것이 좋습니다.
trustedBiddingSignalsUrls 재사용
네트워크 지연 시간과 리소스 사용량이 매우 클 수 있습니다. 실시간 신뢰할 수 있는 입찰 신호 가져오기 횟수를 줄이면 이 지연 시간을 줄일 수 있습니다.
trustedBiddingSignalsUrl이 여러 관심분야 그룹 간에 재사용되는 경우 신뢰할 수 있는 입찰 신호 가져오기를 결합할 수 있습니다.
가능하면 모든 관심분야 그룹에 동일한 trustedBiddingSignalsUrl를 사용하세요.
신뢰할 수 있는 입찰 신호 가져오기가 특정 웹페이지의 광고 슬롯 전반에 캐시되도록 적절한 HTTP 캐시 제어 헤더를 지정합니다. 요청된 URL이 다르기 때문에 슬롯 크기가 다를 때 광고 슬롯 간 캐싱이 방지되므로 trustedBiddingSignalsSlotSizeMode을 slot-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() 속도에 대해 의견을 제시하지 않으므로 (예: 빠르게 입찰하는 관심분류가 많고 느리게 입찰하는 관심분류가 적은 경우 모두 제한 시간 전에 완료될 수 있음) perBuyerTimeouts 및 perBuyerGroupLimits를 사용하는 것보다 perBuyerCumulativeTimeouts를 사용하는 것이 좋습니다.
신뢰할 수 있는 점수 매기기 신호 가져오기 및 scoreAd() 실행에 너무 많은 시간이 걸리는 경우 지나치게 긴 입찰을 방지하기 위해 입찰 구성 signal 필드를 사용하여 전체 입찰 시간 제한을 구현하는 것도 좋습니다.
다음 단계
Google은 누구나 사용할 수 있는 API를 빌드할 수 있도록 개발자 여러분과 대화를 나누고 싶습니다.
API에 관해 논의하기
다른 개인 정보 보호 샌드박스 API와 마찬가지로 이 API는 문서화되고 공개적으로 논의됩니다.
API 실험
Protected Audience API에 관한 대화에 실험하고 참여할 수 있습니다.