입찰 서비스 통합 및 최적화

Android용 입찰 서비스 설계 제안서에서는 신뢰할 수 있는 입찰 서버를 사용하여 Android에서 입찰을 실행하는 실행 및 데이터 흐름을 자세히 설명합니다. 전송 중 데이터가 개인 정보 보호 API와 신뢰할 수 있는 서버에서만 처리되도록 하기 위해 양방향 하이브리드 공개 키 암호화를 사용하여 클라이언트와 서버 간에 데이터를 암호화합니다.

Protected Audience 입찰 흐름

앞에서 설명한 대로 입찰을 실행하려면 기기의 판매자 광고 기술이 다음 단계를 실행해야 합니다.

1. 서버 입찰을 위한 데이터 수집 및 암호화
2. 신뢰할 수 없는 판매자 서비스에 요청 전송
3. 신뢰할 수 없는 판매자 서비스로부터 응답 수신
4. Protected Audience 입찰 응답 복호화 및 입찰 결과 가져오기

Protected Audience는 서버 입찰 실행을 지원하기 위해 두 가지 새로운 API를 도입합니다.

1. getAdSelectionData API는 서버 입찰을 위한 데이터를 수집하고 입찰 데이터를 포함하는 암호화된 페이로드를 생성합니다. 입찰 서버는 이 페이로드를 사용하여 입찰을 실행하고 입찰 결과를 생성하며 입찰 결과를 반환합니다.
2. 기기 내 광고 기술 클라이언트는 persistAdSelectionResult API를 호출하여 서버 입찰에서 생성된 결과를 복호화하고 낙찰된 광고 렌더링 URL을 가져올 수 있습니다.

기기의 판매자 광고 기술은 입찰을 실행하려면 다음을 통합하고 빌드해야 합니다.

1. 서버 입찰 판매자를 위한 데이터 수집 및 암호화: 광고 기술은 getAdSelectionData API를 호출하여 암호화된 페이로드를 가져와야 합니다.
2. 신뢰할 수 없는 판매자 서비스에 요청 전송: getAdSelectionData API에서 생성된 암호화된 페이로드를 포함하는 HTTP POST 또는 PUT 요청을 신뢰할 수 없는 판매자 서비스에 보내고 신뢰할 수 없는 판매자 서비스에 필요한 데이터를 보내 문맥 결과를 생성합니다.
3. 신뢰할 수 없는 판매자 서비스로부터 응답 수신: 신뢰할 수 없는 판매자 서비스의 응답에는 암호화된 Protected Audience 입찰 결과 및 문맥 입찰 결과가 포함됩니다.
4. Protected Audience 입찰 응답 복호화 및 입찰 결과 가져오기: Protected Audience 입찰 결과를 복호화하려면 판매자 광고 기술이 persistAdSelectionResult API를 호출해야 합니다. persistAdSelectionResult에 의해 생성된 결과는 광고 기술이 문맥 광고 또는 Protected Audience 광고가 입찰에서 낙찰되었는지 여부와 낙찰된 Protected Audience 광고의 URI(해당하는 경우)를 결정하는 데 도움이 됩니다.

서버 입찰에서 지원되는 기능

Google은 현재 기기 내 입찰에 사용할 수 있는 모든 기능을 지원하는 것을 목표로 합니다. 서버 입찰에서 이러한 기능을 지원하는 타임라인은 다음과 같습니다.

	기기 내 입찰		서버 입찰
	개발자 프리뷰	베타	개발자 프리뷰	베타
이벤트 수준 낙찰 보고	2023년 1분기	2023년 3분기	N/A	2023년 4분기
폭포식 구조 미디에이션	2023년 1분기	2023년 4분기	N/A	2024년 1분기
최대 게재빈도 필터링	2023년 2분기	2023년 3분기	N/A	2023년 4분기
필터링을 위해 광고 선택 워크플로에 문맥 광고 전달	2023년 2분기	2024년 1분기	N/A	N/A
상호작용 보고	2023년 2분기	2023년 3분기	N/A	2023년 4분기
맞춤 잠재고객 위임에 참여	2023년 3분기	2023년 4분기	N/A	2023년 4분기
CPM이 아닌 청구	2023년 3분기	2023년 4분기
디버그 보고	2023년 3분기	2023년 4분기	2023년 3분기	2023년 4분기
공개 입찰 미디에이션	N/A	N/A	N/A	2024년 1분기
앱 설치 광고 필터링	2023년 2분기	2024년 1분기	N/A	2024년 1분기
통화 관리	N/A	N/A	N/A	2024년 1분기
K-anon 통합	N/A	2024년 1분기	N/A	2024년 1분기
비공개 집계 통합	N/A	N/A	N/A	2024년 3분기

Protected Audience API를 사용하여 서버 입찰 실행

개발자 프리뷰 트랙에서 AdSelectionManager는 새로운 두 API인 getAdSelectionData 및 persistAdSelectionResult를 노출합니다. 이러한 API를 사용하면 광고 기술 SDK가 입찰 서버와 통합할 수 있습니다.

서버 입찰을 위한 데이터 수집 및 암호화

getAdSelectionData API는 BuyerInput 및 ProtectedAudienceInput과 같은 입찰 구성요소에 필요한 입력을 생성하고 데이터를 암호화한 후 결과를 호출자에게 제공합니다. 여러 앱에서 데이터가 유출되는 것을 방지하기 위해 이 데이터에는 기기에 있는 모든 구매자의 정보가 포함됩니다. 개인 정보 보호 고려사항 섹션에서 이 결정에 관해 자세히 알아보고 크기 고려사항 섹션에서 이를 최적화하는 전략을 알아보세요.

API에 액세스하려면 Protected Audience API에 대한 액세스를 사용 설정해야 하며 ACCESS_ADSERVICES_CUSTOM_AUDIENCE 권한을 호출자의 매니페스트에서 정의해야 합니다.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

호출자는 요청에서 seller 필드를 설정해야 합니다. 요청을 처리하기 전에 등록 확인을 실행하는 데 사용되기 때문입니다.

public class GetAdSelectionDataRequest {
  Public setSeller(AdTechIdentifier seller);
}

요청이 검증되면 기기 내 구매자 데이터가 BuyerInput 및 ProtectedAudienceInput으로 구성됩니다. 그러면 최종 페이로드 객체가 양방향 하이브리드 공개 키 암호화를 사용하여 암호화됩니다.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome은 getAdSelectionData API의 결과로 생성됩니다. 여기에는 다음이 포함되어 있습니다.

1. adSelectionId: 이 getAdSelectionData 호출을 식별하는 불투명 정수입니다. 광고 기술 클라이언트는 이 adSelectionId 값을 유지해야 합니다. getAdSelectionData 호출을 가리키는 포인터 역할을 하기 때문입니다. 이 식별자는 입찰 서버에서 입찰 결과를 복호화하기 위해 persistAdSelectionResult API에 필요하며, reportImpression 및 reportEvent API에도 필요합니다.
2. adSelectionData: 입찰 서버에서 입찰을 실행하는 데 필요한 암호화된 입찰 데이터입니다. 이 메서드에는 다음이 포함됩니다.
   1. 최대 게재빈도 설정, 앱 설치 필터, 맞춤 잠재고객의 서버 입찰 요구사항을 기반으로 필터링된 맞춤 잠재고객 데이터
   2. 향후 버전에는 앱 설치 데이터가 포함될 예정입니다.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

오류, 예외, 실패 처리

잘못된 인수나 시간 제한, 과도한 리소스 사용과 같은 이유로 광고 선택 데이터 생성을 성공적으로 완료할 수 없는 경우 OutcomeReceiver.onError() 콜백은 다음 동작과 함께 AdServicesException을 제공합니다.

1. getAdSelectionData가 잘못된 인수로 시작된 경우 AdServicesException`은 원인으로 IllegalArgumentException을 표시합니다.
2. 그 외 모든 오류에서는 원인으로 IllegalStateException이 표시된 AdServicesException을 수신하게 됩니다.

신뢰할 수 없는 판매자 서비스에 요청 전송

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

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

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

신뢰할 수 없는 판매자 서비스로부터 응답 수신

입찰 서버 설명에 설명된 대로 신뢰할 수 없는 판매자 서비스가 요청을 수신하면 문맥 광고를 위해 파트너 구매자를 호출합니다.

신뢰할 수 없는 판매자 서비스는 암호화된 adSelectionData 및 AuctionConfig를 TEE에서 실행되는 입찰 서버의 SellerFrontEnd 서비스에 전달합니다.

Protected Audience 입찰이 완료되면 SellerFrontEnd 서비스는 입찰 결과를 암호화하여 신뢰할 수 없는 판매자 서비스에 대한 응답으로 반환합니다.

신뢰할 수 없는 판매자 서비스는 문맥 광고 또는 암호화된 Protected Audience 입찰 결과가 포함된 기기에 응답을 전송합니다.

응답을 수신하면 기기의 판매자 광고 기술 코드는 응답에서 문맥 광고만 사용하도록 선택하거나, Protected Audience 결과를 가져오는 데 증분 값이 있다고 판단하는 경우 PersistAdSelectionResult API를 호출하여 Protected Audience 결과를 복호화하도록 선택할 수 있습니다.

PersistAdSelectionResult API

Protected Audience 결과를 복호화하기 위해 판매자 광고 기술은 두 번째 Protected Audience API persistAdSelectionResult를 호출할 수 있습니다. API는 결과를 복호화하고 오늘 기기 내 입찰에서 반환된 것과 동일한 객체인 AdSelectionOutcome을 반환합니다.

API에 액세스하려면 호출자가 Protected Audience API에 대한 액세스 권한을 사용 설정하고 매니페스트에서 ACCESS_ADSERVICES_CUSTOM_AUDIENCE 권한을 정의해야 합니다.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

호출자는 요청에서 다음을 설정해야 합니다.

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: 호출자가 결과를 복호화하려는 getAdSelectionData 호출로 생성된 불투명 식별자입니다.
2. seller: 판매자 광고 기술 식별자를 요청에서 설정하여 요청을 처리하기 전에 등록 확인을 실행해야 합니다.
3. adSelectionResult: 호출자가 복호화하려는 입찰 서버에서 생성한 암호화된 입찰 결과입니다.

AdSelectionOutcome 응답

Protected Audience 낙찰자가 있는 경우 AdSelectionOutcome은 낙찰된 광고 렌더링 URI를 반환합니다. adSelectionResult가 복호화되면 보고 데이터가 내부적으로 유지됩니다. OutcomeReceiver.onResult() 콜백은 다음을 포함하는 AdSelectionOutcome을 반환합니다.

• URI: 낙찰된 Protected Audience 광고가 있는 경우 낙찰된 광고의 광고 렌더링 URL이 반환됩니다. Protected Audience 낙찰자가 없는 경우 'Uri.EMPTY'가 반환됩니다.
• adSelectionId: 이 서버 입찰 실행과 연결된 adSelectionId입니다.

오류, 예외, 실패 처리

잘못된 인수나 시간 제한, 과도한 리소스 사용과 같은 이유로 광고 선택 데이터 생성을 성공적으로 완료할 수 없는 경우 OutcomeReceiver.onError() 콜백은 다음 동작과 함께 AdServicesException을 제공합니다.

1. getAdSelectionData가 잘못된 인수로 시작된 경우 AdServicesException은 원인으로 IllegalArgumentException을 표시합니다.
2. 그 외 모든 오류에서는 원인으로 IllegalStateException이 표시된 AdServicesException을 수신하게 됩니다.

개인 정보 보호 고려사항

전송 중 데이터에는 PPAPI 및 신뢰할 수 있는 서버에서만 액세스할 수 있도록 adSelectionData가 암호화됩니다.

암호화에도 불구하고 adSelectionData 크기로 인해 데이터 유출이 발생할 수 있습니다. adSelectionData 크기는 다음과 같은 이유로 달라질 수 있습니다.

1. 기기에 있는 CustomAudience 데이터 변경사항
2. CustomAudience 필터링 로직 변경사항
3. getAdSelectionData 호출의 입력 변경사항

1비트 유출 설명에 언급된 것처럼 adSelectionData 크기의 변경을 통해 교차 앱 식별자를 생성할 수 있습니다. 1비트 유출에 적용되는 여러 완화 조치도 여기에 적용할 수 있습니다.

이러한 유출을 관리하기 위해 모든 getAdSelectionData API 호출에 동일한 adSelectionData를 생성할 계획입니다. 초기 출시에서는 기기의 모든 CustomAudiences가 adSelectionData 생성에 사용되며 암호화된 페이로드는 마스크 크기 변형에 맞게 패딩됩니다. 또한 GetAdSelectionData 입력 매개변수가 생성된 adSelectionData에 미치는 영향을 제한합니다.

그러나 모든 기기 내 입찰 데이터를 사용하는 모든 광고 기술에 동일한 adSelectionData를 생성하면 이제 광고 기술 서버를 호출할 때마다 전송해야 하는 대용량 페이로드가 생성됩니다. 또한 모든 기기 내 맞춤 잠재고객을 사용하여 입찰 페이로드를 생성하면 생태계가 악의적인 행위자로부터 악용될 수 있습니다. 이러한 문제는 아래 크기 최적화 및 악용 완화 섹션에서 설명했습니다.

크기 최적화

광고 기술 클라이언트 SDK는 adSelectionData의 암호화된 바이트를 광고 기술 서버에 대한 HTTP PUT/POST 문맥 호출에 패키징해야 합니다. 왕복 지연 시간과 비용을 줄이려면 유틸리티에 영향을 주지 않으면서 adSelectionData 크기를 최대한 줄여야 합니다.

adSelectionData 크기를 줄이기 위해 향후 버전에서 다음 최적화를 살펴보고 잠재적으로 도입할 계획입니다.

1. 패딩이 있는 고정된 버킷 크기 세트에서 생성된 페이로드: 크기 변화로 인한 유출을 최소화하면서 더 적은 페이로드를 허용하려면 생성된 페이로드에 고정된 크기 버케팅을 사용하는 것이 좋습니다. 버킷 수를 적게 유지하세요. 예를 들어 7이라면 getAdSelectionData 호출당 3비트 미만의 유출 엔트로피가 발생합니다.

   기기 내 데이터가 최대 버킷 크기를 초과하면 우선순위 값과 같이 아래에 언급된 전략을 사용하여 삭제할 데이터를 결정합니다.

2. 구매자 구성: 구매자가 구매자당 페이로드 구성을 설정하도록 할 수 있는지 평가하고 있습니다. 이 구성은 구매자가 참여하고자 하는 입찰을 식별하는 데 유용합니다. 가능하다면 등록 중에 구매자 광고 기술은 Protected Audience가 매일 정기적으로 페이로드 구성을 가져오는 엔드포인트를 등록할 수 있습니다. 또는 개인 정보 보호 API가 구매자 광고 기술이 이 엔드포인트를 등록하도록 허용하는 API를 노출합니다.

   그러면 이 구성은 각 getAdSelectionData 요청에 관해 생성된 adSelectionData에 대한 구매자의 기여도를 평가하는 데 사용됩니다.

   구매자 페이로드 구성에서는 구매자가 다음을 지정할 수 있습니다.

   1. 허용된 판매자 목록: 구매자 CustomAudiences는 허용 목록에 있는 판매자가 getAdSelectionData 호출을 시작한 경우에만 페이로드에 추가됩니다. 허용 목록을 최신 상태로 유지하기 위해 매일 페이로드 구성을 가져옵니다.
   2. 판매자별 크기 제한: 구매자는 특정 판매자가 입찰을 시작할 때 페이로드에서 전송할 데이터 크기를 결정하기 위해 판매자별 크기 제한을 지정할 수 있습니다. 이는 구매자가 특정 판매자의 입찰 데이터를 처리하는 데 더 많은 리소스를 사용하려는 경우 유용합니다. SellerFrontendService는 구매자별 데이터만 각 BuyerFrontendService에 전달합니다. 따라서 판매자별 크기 제한을 정의함으로써 구매자는 판매자가 실행하는 입찰을 위해 입찰 서버의 BuyerFrontendService에서 수집 및 처리한 데이터의 양을 명시적으로 제어할 수 있습니다.

3. 판매자 구성: Google에서는 판매자가 입찰 매개변수를 정의하여 페이로드 크기와 입찰 참여자를 제어할 수 있는 판매자별 입찰 구성의 실현 가능성을 평가하고 있습니다. 가능하다면 등록 중에 판매자 광고 기술은 Protected Audience가 판매자별 입찰 구성을 정기적으로 가져올 수 있는 엔드포인트를 지정할 수 있습니다. 그러면 이 구성은 각 getAdSelectionData 요청에 관해 생성된 adSelectionData의 컴포지션 및 제한을 결정하는 데 사용됩니다.

   구매자 구성과 마찬가지로 판매자별 구성을 통해 판매자는 입찰에서 볼 것으로 예상되는 구매자 집합을 지정하고 페이로드 크기에 대한 구매자별 기여도에 관한 제한을 지정할 수 있습니다.

   판매자 입찰 구성에서 판매자는 다음을 지정할 수 있습니다.

   1. 허용된 구매자 목록: 지정된 판매자가 시작한 입찰의 경우 허용 목록에 있는 구매자만 입찰의 CustomAudiences를 제공할 수 있습니다. 허용 목록을 서버 측 구매자 허용 목록과 함께 최신 상태로 유지하려면 입찰 구성을 매일 업데이트해야 합니다.
   2. 구매자별 크기 제한: 판매자는 구매자별 제한을 지정하여 각 구매자가 SellerFrontendService로 전송되는 페이로드에 업로드하는 데이터 크기를 규제할 수 있습니다. 구매자가 구매자별 크기 제한을 초과하면 구매자 페이로드 구성에 설정된 CustomAudience 우선순위를 사용하여 예상 제한에서 데이터를 가져옵니다.
   3. 구매자별 우선순위: 판매자가 구매자별 우선순위를 설정할 수 있습니다. 페이로드 크기가 페이로드 크기 제한을 초과하는 경우 구매자 우선순위를 사용하여 페이로드에 유지해야 하는 구매자 데이터를 식별합니다.
   4. 페이로드의 최대 크기 제한: 판매자에 따라 리소스 할당이 다를 수 있으며 요청별 입찰 페이로드에 최대 크기 제한을 설정하고자 할 수 있습니다. 최대 크기 제한은 Protected Audience API에서 설정한 고정 크기 버킷을 따릅니다.

4. 맞춤 잠재고객 변경사항

   1. 맞춤 잠재고객 우선순위 지정: 구매자가 맞춤 잠재고객에서 우선순위 값을 지정할 수 있습니다. priority 필드는 구매자 맞춤 잠재고객 집합이 판매자별 또는 구매자별 크기 제한을 초과하는 경우 입찰에 포함해야 하는 맞춤 잠재고객을 식별하는 데 사용됩니다. 맞춤 잠재고객의 지정되지 않은 우선순위 값은 기본적으로 0.0으로 설정됩니다.

5. 페이로드 데이터 변경사항

   1. 페이로드에서 전송되는 데이터 줄이기: 입찰 서비스 페이로드 최적화에 자세히 설명된 대로 더 높은 페이로드는 맞춤 잠재고객 ads 데이터와 사용자 입찰 신호, Android 신호로 구동됩니다. 높은 페이로드는 다음과 같은 방식으로 낮아질 수 있습니다.
      1. 클라이언트가 페이로드에서 광고 객체 대신 광고 렌더링 ID를 전송하도록 합니다.
      2. 클라이언트가 페이로드에서 광고 데이터를 보내지 않도록 합니다.
      3. 클라이언트 페이로드에서 사용자 입찰 신호를 전송하지 않습니다.

위에서 언급한 전략을 사용하면 광고 기술이 adSelectionData 페이로드 컴포지션 및 제한을 관리하도록 구성을 정의할 수 있지만, 구성 매개변수를 변경하여 adSelectionData 크기를 조정하는 요소가 될 수도 있습니다. 이를 방지하기 위해 구성된 엔드포인트에서 Protected Audience가 매일 구성을 가져옵니다.

지연 시간 최적화

서버 입찰이 바람직한 수준의 유틸리티를 보유하려면 getAdSelectionData API와 persistAdSelectionResult API의 호출당 지연 시간이 짧아야 합니다. 2023년에 API의 기능 지원을 제공하는 것을 목표로 하고 있지만 후속 출시에서는 API의 지연 시간 벤치마크와 최적화에 중점을 둘 예정입니다.

Google에서는 지연 시간을 허용 가능한 제한 내로 유지하기 위해 다음 전략을 모색하고 있습니다.

1. 판매자별 Protected Audience 데이터 사전 생성: 판매자 입찰 구성과 구매자 페이로드 구성은 상당한 기간(매일) 동안 안정적이므로 플랫폼은 요건을 충족하는 Protected Audience 데이터를 사전 계산하여 저장할 수 있습니다.

   이를 위해서는 플랫폼에서 맞춤 잠재고객 업데이트를 모니터링하고 사전 생성된 Protected Audience 데이터를 업데이트에 따라 수정하는 메커니즘을 빌드해야 합니다. 또한 플랫폼은 맞춤 잠재고객 업데이트와 서버 입찰을 위해 생성된 adSelectionData의 변경사항을 확인하는 사이에 광고 기술이 예상할 수 있는 경합 지연에 관해 SLO를 선언해야 합니다.

   기기는 프로세스 우선순위가 다양한 제한된 리소스 계산 모델을 제공하므로 이 사전 생성 기능을 제공하면 높은 안정성과 SLO가 보장되어야 한다는 점을 알고 있습니다.

   그러면 Protected Audience 데이터는 다음 사항에 따라 사전 생성됩니다.

   1. Protected Audience 데이터를 사전 생성하도록 선택한 판매자
   2. 특정 판매자가 시작한 입찰에 참여할 수 있는 구매자
   3. 다음을 기준으로 페이로드에 포함될 구매자별 맞춤 잠재고객 식별
      1. 판매자 구성에서 정의된 구매자별 크기 제한, 구매자별 우선순위, 최대 크기 제한
      2. 구매자 구성에서 정의된 판매자별 크기 제한, 맞춤 잠재고객 우선순위

2. 제외 필터링 적극 적용: 판매자가 원하는 경우 플랫폼은 Protected Audience 데이터를 사전 생성하고 중요한 getAdSelectionData 호출에서 제외 필터링을 적용하여 adSelectionData를 미리 계산할 수 있습니다. 이렇게 하면 판매자가 제외 필터링의 비활성을 허용하면서 지연 시간을 줄이는 균형을 유지할 수 있습니다.

   플랫폼은 비활성 제한이 있는 판매자 구성의 기본 옵션과 필요한 경우 최신 계산을 허용하는 getAdSelectionData의 재정의 옵션을 제공하여 이 지원을 제공할 수 있습니다. 또는 플랫폼에서 입찰을 준비하기 위해 getAdSelectionData 전에 호출할 추가 초기화 API를 제공할 수도 있습니다.

3. 여러 입찰의 페이로드 계산: 특정 시나리오에서는 데이터 비활성이 증가하더라도 지연 시간 성능이 우수한 API를 사용하는 것이 좋을 수 있습니다. 이를 제공하기 위해 플랫폼은 초기화 API를 도입하여 전체 페이로드를 계산하고 계산된 페이로드 참조를 호출자에게 제공할 수 있습니다.

   후속 getAdSelectionData 호출의 경우 호출자는 adSelectionData 생성에 사용할 미리 계산된 페이로드 참조를 제공할 수 있습니다.

위에 언급된 세 가지 전략은 모두 초기 탐색 단계에 있으며 지연 시간최적화를 위해 플랫폼이 취할 수 있는 방향을 설명하기 위한 것입니다. API 및 광고 기술 요구사항에 관한 보다 자세한 지연 시간 프로필을 검토하면서 계속하여 추가 전략을 제안할 예정입니다.

악용 완화 및 식별

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

그러나 기기의 모든 구매자 데이터가 adSelectionData 출력을 생성하는 데 사용되면 악의적인 행위자가 구매자로 가장하고 허위 구매자 데이터를 만들어 Android 성능을 저하시키고 페이로드를 팽창시켜 광고 기술이 입찰을 실행하거나 입찰을 실행하는 등의 비용을 증가시킬 수 있습니다.

완화

허용 목록에 있는 판매자가 포함된 구매자 페이로드 구성 및 허용 목록에 있는 구매자가 포함된 판매자 입찰 구성과 같이 크기 고려사항 섹션에 언급된 일부 조치는 페이로드에서 예기치 않은 데이터를 제외하는 데 도움이 됩니다.

SSP가 구매자 우선순위를 지정할 수 있도록 허용하고, 생성된 페이로드에 구매자별 할당량을 배치하고, 입찰 페이로드당 최대 크기를 설정하는 등 다른 크기 고려사항 조치도 악성 페이로드 팽창의 영향을 완화하는 데 도움이 될 수 있습니다. 이러한 조치는 광고 기술이 협력하는 광고 기술을 정의하고 처리해야 하는 페이로드에 허용 가능한 제한을 설정할 수 있도록 설계되었습니다.

앞서 언급했듯이 악용 방지 및 크기 제한에 관해 도입된 모든 완화 조치는 개인 정보 보호 고려사항을 준수해야 합니다.

악의적인 행위자 식별

위에서 설명된 완화 조치는 서버 입찰의 adSelectionData 생성을 보호하지만 악의적인 행위자를 식별하거나, 구매자로부터 전례 없는 수의 맞춤 잠재고객을 생성하는 등의 악용으로부터 플랫폼을 보호하는 데 도움이 되지 않습니다.

플랫폼 안정성과 상태를 보장하려면 악의적인 행위자를 식별하고 악용 벡터를 식별하고 특정 공격의 동기를 식별하는 메커니즘을 찾아야 합니다. 향후 출시에서는 잠재적 악용 벡터와 이를 방지하는 보호 조치를 자세히 다루는 설명을 도입할 예정입니다.