이 페이지는 Cloud Translation API를 통해 번역되었습니다.

관련성 높은 앱 설치 광고를 지원하기 위한 보호된 앱 신호

이 제안서에는 개인 정보 보호 샌드박스 등록 프로세스 및 증명이 적용됩니다. 증명에 관한 자세한 내용은 제공된 증명 링크를 참고하세요. 이 제안서의 향후 업데이트에서는 이 시스템에 액세스하기 위한 요구사항을 설명할 예정입니다.

사용자 획득 광고라고도 하는 모바일 앱 설치 광고는 사용자의 모바일 앱 다운로드를 유도하기 위해 만들어진 모바일 광고 유형입니다. 이러한 광고는 일반적으로 관심분야와 인구통계를 기반으로 사용자에게 게재되며 게임, 소셜 미디어, 뉴스 앱과 같은 다른 모바일 앱에도 자주 게재됩니다. 사용자가 앱 설치 광고를 클릭하면 앱을 다운로드할 수 있는 앱 스토어로 바로 연결됩니다.

예를 들어 미국에서 새로운 모바일 음식 배달 앱의 신규 설치를 유도하려는 광고주는 미국에 거주하며 이전에 다른 음식 배달 앱을 이용한 적이 있는 사용자를 광고 타겟으로 정할 수 있습니다.

이러한 타겟팅은 일반적으로 광고 기술 간의 문맥, 퍼스트 파티, 서드 파티 신호를 포함하여 광고 ID를 기반으로 한 사용자 프로필을 생성함으로써 이뤄집니다. 광고 기술 머신러닝 모델은 이 정보를 입력으로 사용하여 사용자와 관련이 있고 전환 발생 확률이 가장 높은 광고를 선택합니다.

다음 API는 교차 파티 사용자 식별자에 대한 의존을 제거하여 사용자 개인 정보 보호를 개선하는 효과적인 앱 설치 광고를 지원하기 위해 제안됩니다.

Protected App Signals API: 사용자의 잠재적 관심분야를 나타내는 광고 기술 엔지니어링 기능을 저장하고 만드는 데 중점을 둡니다. 광고 기술은 앱 설치, 첫 실행, 사용자 작업 (인게임 레벨링, 업적), 구매 활동, 앱 내 시간과 같은 자체 정의된 앱별 이벤트 신호를 저장합니다. 신호는 데이터 유출을 방지하기 위해 기기에 작성 및 저장되며, 보안 환경에서 실행되는 보호된 입찰 중에 특정 신호를 저장한 광고 기술 로직에만 사용할 수 있습니다.
Ad Selection API: 신뢰할 수 있는 실행 환경 (TEE)에서 실행되는 보호된 입찰을 구성 및 실행하는 API를 제공합니다. 광고 기술은 광고 조합을 검색하고, 추론을 실행하고, 입찰가를 계산하며, 보호된 앱 신호와 게시자가 제공한 실시간 문맥 정보를 모두 사용하여 '낙찰된' 광고를 선택하기 위해 점수를 계산합니다.

보호된 신호를 사용하는 앱 설치 흐름을 보여주는 다이어그램 — Android의 개인 정보 보호 샌드박스에서 보호된 앱 신호 및 광고 선택 워크플로를 보여주는 플로 차트

다음은 Protected App Signals가 관련 앱 설치 광고를 지원하는 방식을 개략적으로 보여줍니다. 이 문서의 다음 섹션에서는 이러한 각 단계를 자세히 설명합니다.

신호 선별: 사용자가 모바일 앱을 사용할 때 광고 기술은 Protected App Signals API를 사용하여 관련성 있는 광고를 게재하기 위해 광고 기술로 정의된 앱 이벤트를 저장하여 신호를 선별합니다. 이러한 이벤트는 맞춤 잠재고객과 마찬가지로 보호되는 기기 내 저장소에 저장되며 기기 밖으로 전송되기 전에 암호화됩니다. 따라서 적절한 보안 및 개인 정보 보호 설정을 갖춘 신뢰할 수 있는 실행 환경 내에서 실행되는 입찰 서비스만 입찰 및 점수 광고를 위해 이를 복호화할 수 있습니다.
신호 인코딩: 신호는 맞춤 광고 기술 로직에 의해 예약된 주기에 따라 준비됩니다. Android 백그라운드 작업은 이 로직을 실행하여 기기 내 인코딩을 실행하여 나중에 보호된 입찰 중에 광고 선택에 실시간으로 사용할 수 있는 보호된 앱 신호의 페이로드를 생성합니다. 페이로드는 입찰을 위해 전송될 때까지 기기에 안전하게 저장됩니다.
광고 선택: 사용자와 관련된 광고를 선택하기 위해 판매자 SDK는 보호된 앱 신호의 암호화된 페이로드를 전송하고 보호된 입찰을 구성합니다. 입찰에서 구매자 맞춤 로직은 게시자가 제공한 문맥 데이터(일반적으로 Open-RTB 광고 요청에서 공유되는 데이터)와 함께 보호된 앱 신호를 준비하여 광고 선택(광고 검색, 추론, 입찰 생성)을 위한 기능(광고 검색, 추론, 입찰 생성)을 엔지니어링합니다. Protected Audience와 마찬가지로 구매자는 Protected 입찰에서 최종 점수를 받기 위해 판매자에게 광고를 제출합니다.
- 광고 검색: 구매자는 보호된 앱 신호와 게시자가 제공한 문맥 데이터를 사용하여 사용자의 관심분야와 관련된 기능을 추출합니다. 이러한 기능은 타겟팅 기준을 충족하는 광고를 찾는 데 사용됩니다. 예산 범위 내에 있지 않은 광고는 필터링됩니다. 그러면 상위 k개의 광고가 입찰에 선정됩니다.
- 입찰: 구매자의 맞춤 입찰 로직이 게시자 제공 문맥 데이터와 Protected App Signals를 준비하여 신뢰할 수 있는 개인 정보 보호 경계 내에서 조합 광고에 관한 추론 및 입찰을 위해 구매자 머신러닝 모델의 입력으로 사용되는 기능을 설계합니다. 그런 다음 구매자는 선택한 광고를 판매자에게 반환합니다.
- 판매자 점수: 판매자의 맞춤 점수 로직은 참여 구매자가 제출한 광고에 점수를 매기고 낙찰된 광고를 선택하여 렌더링을 위해 앱으로 다시 전송합니다.
보고: 입찰 참여자는 관련 낙찰 보고서와 낙찰 실패 보고서를 받습니다. Google에서는 낙찰 보고서에 모델 학습용 데이터를 포함하기 위한 개인 정보 보호 메커니즘을 모색하고 있습니다.

타임라인

	개발자 프리뷰			베타
특성	2023년 4분기	2024년 1분기	2024년 2분기	2024년 3분기
Signal Curation API	기기 내 저장소 API	기기 내 저장용량 할당량 로직 기기 내 맞춤 로직 일일 업데이트	해당 사항 없음	1% T 이상의 기기에 사용 가능
TEE의 광고 검색 서버	MVP	GCP에서 사용 가능 Top K 지원 UDF 프로덕션화	AWS에서 사용 가능 동의한 디버깅, 측정항목, 모니터링
TEE의 추론 서비스 ML 모델 실행 및 TEE에서 입찰에 사용하는 기능 지원	개발 중	GCP에서 사용 가능 Tensorflow 및 PyTorch를 사용하여 정적 ML 모델을 배포하고 프로토타입을 제작할 수 있는 기능	AWS에서 사용 가능 Tensorflow 및 PyTorch 모델을 위한 프로덕션화된 모델 배포 원격 분석, 동의 디버깅, 모니터링
TEE에서 입찰 지원	GCP에서 사용 가능	PAS-B&A 및 TEE 광고 검색 통합(gRPC 및 TEE<>TEE 암호화 사용) 문맥 경로를 통한 광고 검색 지원(TEE의 B&A<>K/V 지원 포함)	AWS에서 사용 가능 디버그 보고 동의한 디버깅, 측정항목, 모니터링

Protected App Signals 선별

신호는 광고 기술이 관련성 있는 광고를 게재하는 데 유용하다고 판단한 앱의 다양한 사용자 상호작용을 표현한 것입니다. 앱 또는 통합 SDK는 앱 열기, 업적, 구매 활동 또는 앱 내 시간과 같은 사용자 활동을 기반으로 광고 기술에 의해 정의된 보호된 앱 신호를 저장하거나 삭제할 수 있습니다. 보호된 앱 신호는 기기 내에 안전하게 저장되며 기기 외부로 전송되기 전에 암호화되므로 적절한 보안 및 개인 정보 보호 설정을 갖춘 신뢰할 수 있는 실행 환경 내에서 실행되는 입찰 서비스만 입찰 및 입찰 광고를 복호화할 수 있습니다. Custom Audience API와 마찬가지로 기기에 저장된 신호는 앱이나 SDK에서 읽거나 검사할 수 없습니다. 신호 값을 읽는 API는 없으며 API는 신호의 유출을 방지하도록 설계되었습니다. 광고 기술 맞춤 로직은 선별된 신호에 대한 액세스를 보호하여 Protected Auction에서 광고 선택의 기반으로 사용되는 기능을 설계합니다.

Protected App Signals API

Protected App Signals API는 맞춤 잠재고객에 사용되는 것과 유사한 위임 메커니즘을 사용하여 신호 관리를 지원합니다. Protected App Signals API를 사용하면 단일 스칼라 값 형식 또는 시계열로 신호를 저장할 수 있습니다. 시계열 신호는 사용자 세션 시간 등을 저장하는 데 사용할 수 있습니다. 시계열 신호는 선입 선출 규칙을 사용하여 지정된 길이를 적용하는 유틸리티를 제공합니다. 스칼라 신호 또는 시계열 신호의 각 요소의 데이터 유형은 바이트 배열입니다. 각 값은 신호를 저장한 애플리케이션의 패키지 이름과 저장 신호 API 호출의 생성 타임스탬프로 보강됩니다. 이 추가 정보는 신호 인코딩 JavaScript에서 확인할 수 있습니다. 이 예는 특정 광고 기술에서 소유한 신호의 구조를 보여줍니다.

이 예는 adtech1.com과 연결된 스칼라 신호와 시계열 신호를 보여줍니다.

base64 값 키가 'A1c'이고 값이 'c12Z'인 스칼라 신호입니다. 신호 저장소는 2023년 6월 1일에 com.google.android.game_app에 의해 트리거되었습니다.
두 개의 서로 다른 애플리케이션에서 생성한 키가 'dDE'인 신호의 목록입니다.

광고 기술에는 기기에 신호를 저장하기 위해 일정한 공간이 할당됩니다. 신호에는 최대 TTL이 있으며 이는 나중에 결정됩니다.

생성되는 애플리케이션이 제거되거나, Protected App Signals API 사용이 차단되거나, 사용자가 앱 데이터를 삭제하는 경우 Protected App Signals가 저장소에서 삭제됩니다.

Protected App Signals API는 다음과 같은 부분으로 구성됩니다.

신호를 추가, 업데이트 또는 삭제하는 Java 및 JavaScript API
신뢰할 수 있는 실행 환경 (TEE)에서 실행되는 보호 입찰 중에 실시간으로 추가 기능 엔지니어링을 준비할 수 있도록 지속된 신호를 처리하는 JavaScript API.

신호 추가, 업데이트 또는 삭제

광고 기술은 fetchSignalUpdates() API를 사용하여 신호를 추가, 업데이트 또는 삭제할 수 있습니다. 이 API는 Protected Audience 맞춤 잠재고객 위임과 유사한 위임을 지원합니다.

신호를 추가하려면 앱에 SDK가 없는 구매자 광고 기술은 모바일 측정 파트너(MMP)나 공급측 플랫폼(SSP)과 같이 기기 내 존재하는 광고 기술과 공동작업해야 합니다. Protected App Signals API는 기기 내 호출자가 구매자를 대신하여 Protected App Signal 생성을 호출할 수 있도록 함으로써 Protected App Signal 관리를 위한 유연한 솔루션을 제공하여 이러한 광고 기술을 지원하는 것을 목표로 합니다. 이 프로세스를 위임이라고 하며 fetchSignalUpdates() API를 활용합니다. fetchSignalUpdates()는 URI를 사용하여 신호 업데이트 목록을 검색합니다. 예를 들어 fetchSignalUpdates()는 지정된 URI에 GET 요청을 실행하여 로컬 신호 저장소에 적용할 업데이트 목록을 검색합니다. 구매자가 소유한 URL 엔드포인트가 JSON 명령어 목록으로 응답합니다.

지원되는 JSON 명령어는 다음과 같습니다.

put: 지정된 키의 스칼라 값을 삽입하거나 재정의합니다.
put_if_not_present: 아직 저장된 값이 없는 경우 지정된 키의 스칼라 값을 삽입합니다. 이 옵션은 지정된 사용자에 대해 실험 ID를 설정하고 다른 애플리케이션에서 이미 설정한 경우 이 ID를 재정의하지 않으려는 경우에 유용할 수 있습니다.
append: 지정된 키와 연결된 시계열에 요소를 추가합니다. maxSignals 매개변수는 시계열의 최대 신호 수를 지정합니다. 크기가 초과되면 이전 요소가 삭제됩니다. 키에 스칼라 값이 포함된 경우 자동으로 시계열로 변환됩니다.
remove: 지정된 키와 연결된 콘텐츠를 삭제합니다.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

모든 키와 값은 Base64로 표현됩니다.

위에 나열된 명령어는 스칼라 신호의 삽입, 덮어쓰기, 삭제 시맨틱스와 시계열 신호의 삽입, 추가, 전체 계열 덮어쓰기를 제공하기 위한 것입니다. 시계열 신호의 특정 요소에 관한 삭제 및 덮어쓰기 시맨틱스는 인코딩 및 압축 프로세스 중에 관리되어야 합니다. 예를 들어 인코딩 중에 최신 값으로 대체되거나 수정되는 시계열의 값이 무시되고 압축 프로세스 중에 이러한 값이 삭제됩니다.

저장된 신호는 가져오기 요청을 실행하는 애플리케이션 및 요청의 응답자 (등록된 광고 기술의 '사이트' 또는 '원본')와 요청 생성 시간을 자동으로 연결합니다. 모든 신호는 개인 정보 보호 샌드박스 등록 광고 기술을 대신하여 저장될 수 있으며, URI '사이트'/'원본'은 등록된 광고 기술의 데이터와 일치해야 합니다. 요청하는 광고 기술이 등록되어 있지 않으면 요청이 거부됩니다.

저장소 한도 및 제거

각 광고 기술은 사용자 기기에서 신호를 저장할 공간이 제한되어 있습니다. 이 한도는 광고 기술별로 정의되므로 다양한 앱에서 선별된 신호가 한도를 공유합니다. 한도가 초과되면 시스템은 선입 선출 방식으로 이전의 신호 값을 삭제하여 공간을 정리합니다. 제거가 너무 자주 실행되는 것을 방지하기 위해 시스템은 제한된 양의 한도 초과를 허용하고 제거 로직이 트리거된 후 일부 추가 공간을 정리하는 일괄 처리 로직을 구현합니다.

데이터 전송을 위한 기기 내 인코딩

광고 선택을 위한 신호를 준비하기 위해 구매자별 맞춤 로직은 저장된 앱별 신호 및 이벤트에 대한 액세스를 보호합니다. Android 시스템 백그라운드 작업은 기기에 다운로드되는 구매자별 맞춤 인코딩 로직을 실행하기 위해 매시간 실행됩니다. 구매자별 맞춤 인코딩 로직은 앱별 신호를 인코딩한 후 앱별 신호를 구매자별 할당량을 준수하는 페이로드로 압축합니다. 페이로드는 보호된 기기 저장소의 경계 내에서 암호화된 후 입찰 서비스로 전송됩니다.

광고 기술은 자체 맞춤 로직으로 처리되는 신호 처리 수준을 정의합니다. 예를 들어 솔루션을 계측하여 초기 신호를 삭제하고 다른 애플리케이션의 유사하거나 강화하는 신호를 공간을 더 적게 사용하는 새 신호로 집계할 수 있습니다.

구매자가 신호 인코더를 등록하지 않았다면 신호가 준비되지 않고 기기 내 선별된 신호가 입찰 서비스에 전송되지 않습니다.

저장소, 페이로드, 요청 할당량에 관한 자세한 내용은 향후 업데이트에서 제공됩니다. 또한 맞춤 함수를 제공하는 방법에 관한 추가 정보도 제공됩니다.

광고 선택 워크플로

이 제안서를 통해 광고 기술 맞춤 코드는 TEE에서 실행되는 Protected Auction(Ad Selection API) 내의 Protected App Signals에만 액세스할 수 있습니다. 앱 설치 사용 사례의 요구사항을 더 잘 지원하기 위해 Protected Auction 중에 실시간으로 조합 광고를 가져옵니다. 이는 입찰 전에 조합 광고를 알 수 있는 리마케팅 사용 사례와 대조됩니다.

이 제안서에서는 앱 설치 사용 사례를 지원하기 위한 업데이트와 함께 Protected Audience 제안서와 유사한 광고 선택 워크플로를 사용합니다. 기능 설계 및 실시간 광고 선택을 위한 컴퓨팅 요구사항을 지원하기 위해 TEE에서 실행되는 입찰 서비스에서 앱 설치 광고를 위한 입찰을 실행해야 합니다. Protected Auction 중에 Protected App Signals에 액세스하는 것은 기기 내 입찰에서 지원되지 않습니다.

광고 선택 워크플로 이미지 — Android의 개인 정보 보호 샌드박스의 광고 선택 워크플로

광고 선택 워크플로는 다음과 같습니다.

판매자의 SDK가 Protected App 신호의 기기 내 암호화된 페이로드를 전송합니다.
판매자의 서버는 입찰 구성을 만들고 암호화된 페이로드와 함께 판매자의 신뢰할 수 있는 입찰 서비스에 이를 전송하여 광고 선택 워크플로를 시작합니다.
판매자의 입찰 서비스는 신뢰할 수 있는 참여 구매자 프런트엔드 서버에 페이로드를 전달합니다.
구매자의 입찰 서비스가 구매 측 광고 선택 로직을 실행합니다.
1. 구매 측 광고 검색 로직 실행
2. 구매 측 입찰 로직 실행
판매 측 점수 로직이 실행됩니다.
광고가 렌더링되고 보고가 시작됩니다.

광고 선택 워크플로 시작

애플리케이션이 광고를 표시할 준비가 되면 광고 기술 SDK (일반적으로 SSP)는 게시자로부터 관련 문맥 데이터와 구매자별 암호화된 페이로드를 전송하여 getAdSelectionData 호출을 사용하여 보호된 입찰에 전송할 요청에 포함할 광고 선택 워크플로를 시작합니다. 이 API는 리마케팅 워크플로에 사용되는 것과 동일한 API이며 Android용 입찰 및 입찰 통합 제안서에 설명되어 있습니다.

광고 선택을 시작하기 위해 판매자는 참여 구매자 목록과 기기 내 Protected App Signals의 암호화된 페이로드를 전달합니다. 이 정보를 바탕으로 판매 측 광고 서버는 신뢰할 수 있는 SellerFrontEnd 서비스를 위한 SelectAdRequest를 준비합니다.

판매자는 다음을 설정합니다.

Protected App Signals가 포함된 getAdSelectionData에서 수신된 페이로드
다음을 사용하는 문맥 시그널
- auction_config.auction_signals (입찰 정보용)
- auction_config.seller_signals (판매자의 신호용)
- auction_config.per_buyer_config["buyer"].buyer_signals (구매자 신호용)
buyer_list 필드를 사용하여 입찰에 포함된 구매자 목록

구매 측 광고 선택 로직 실행

대략적으로 구매자의 맞춤 로직은 게시자 및 Protected App Signals에서 제공하는 문맥 데이터를 사용하여 광고 요청의 관련성 있는 광고를 선택하고 입찰가를 적용합니다. 이 플랫폼을 사용하면 구매자가 사용 가능한 큰 광고 풀에서 가장 관련성 높은 광고(상위 k개)로 범위를 좁힐 수 있습니다. 이러한 광고는 최종 선택을 위해 판매자에게 반환되기 전에 입찰가가 계산됩니다.

구매 측 광고 선택 실행 로직을 보여주는 그림 — Android의 개인 정보 보호 샌드박스의 구매 측 광고 선택 실행 로직

구매자는 입찰 전에 방대한 광고 풀로 시작합니다. 각 광고의 입찰가를 계산하는 것은 너무 느리기 때문에 구매자는 먼저 대규모 풀에서 상위 k개의 후보를 선택해야 합니다. 다음으로 구매자는 이러한 상위 k개 후보의 입찰가를 각각 계산해야 합니다. 그런 다음 최종 선택을 위해 해당 광고와 입찰가가 판매자에게 반환됩니다.

BuyerFrontEnd 서비스가 광고 요청을 받습니다.
BuyerFrontEnd 서비스가 구매자의 입찰 서비스에 요청을 보냅니다. 구매자의 입찰 서비스는 광고 검색 서비스에서 상위 k개 후보를 가져오기 위한 요청을 빌드하는 prepareDataForAdRetrieval()라는 UDF를 실행합니다. 입찰 서비스는 이 요청을 구성된 검색 서버 엔드포인트로 전송합니다.
광고 검색 서비스는 getCandidateAds() UDF를 실행하여 구매자의 입찰 서비스로 전송되는 상위 k개 조합 광고 집합을 필터링합니다.
구매자의 입찰 서비스는 최적의 후보를 선택하고 입찰가를 계산한 후 BuyerFrontEnd 서비스에 반환하는 generateBid() UDF를 실행합니다.
BuyerFrontEnd 서비스는 판매자에게 광고와 입찰가를 반환합니다.

이 흐름에는 특히 각 항목이 서로 통신하는 방법과 상위 k개 광고를 검색하고 그 입찰가를 계산하는 머신러닝 예측 기능 등의 기능을 플랫폼이 제공하는 방법과 관련하여 여러 중요한 세부정보가 있습니다.

이 부분을 자세히 살펴보기 전에 위 다이어그램의 TEE에 관한 몇 가지 중요한 아키텍처 참고사항이 있습니다.

구매자의 입찰 서비스에는 내부적으로 추론 서비스가 포함되어 있습니다. 광고 기술은 머신러닝 모델을 구매자의 입찰 서비스에 업로드할 수 있습니다. Google에서는 광고 기술이 구매자의 입찰 서비스에서 실행되는 UDF 내에서 이러한 모델을 예측하거나 임베딩을 생성할 수 있도록 JavaScript API를 제공합니다. 광고 검색 서비스와 달리 구매자의 입찰 서비스에는 광고 메타데이터를 저장하는 키-값 서비스가 없습니다.

광고 검색 서비스는 내부적으로 키-값 서비스를 포함합니다. 광고 기술은 개인 정보 보호 경계 외부의 자체 서버에서 키-값 쌍을 이 서비스로 구체화할 수 있습니다. 광고 기술이 광고 검색 서비스에서 실행되는 UDF 내 이 키-값 서비스에서 읽을 수 있도록 JavaScript API를 제공합니다. 구매자의 입찰 서비스와 달리 광고 검색 서비스에는 추론 서비스가 포함되어 있지 않습니다.

이 설계에서 다루는 주요 질문 중 하나는 검색 시간 및 입찰 시간을 예측하는 방법입니다. 모델 분해라는 솔루션을 사용하면 이 두 가지 문제를 모두 해결할 수 있습니다.

모델 분해

모델 분해는 단일 모델을 여러 부분으로 나눈 다음 이러한 부분을 예측으로 결합할 수 있는 기법입니다. 앱 설치 사용 사례에서 모델은 종종 사용자 데이터, 문맥 데이터, 광고 데이터라는 세 가지 종류의 데이터를 사용합니다.

분해되지 않은 경우 단일 모델은 세 가지 종류의 데이터 모두에 관해 학습됩니다. 분해된 사례에서는 모델을 여러 부분으로 나눕니다. 사용자 데이터가 포함되는 부분만 민감합니다. 즉, 사용자 부분이 있는 모델만 구매자 입찰 서비스의 추론 서비스에서 신뢰 경계 내에서 실행되어야 합니다.

이를 통해 다음과 같은 설계가 가능합니다.

모델을 비공개 부분(사용자 데이터)과 하나 이상의 비공개가 아닌 부분(문맥 및 광고 데이터)으로 나눕니다.
원하는 경우 예측을 실행해야 하는 UDF에 비공개가 아닌 부분의 일부 또는 전부를 인수로 전달합니다. 예를 들어 컨텍스트 임베딩은 per_buyer_signals의 UDF로 전달됩니다.
원하는 경우 광고 기술은 비공개가 아닌 부분의 모델을 만든 다음 이러한 모델의 임베딩을 광고 검색 서비스의 키-값 저장소로 구체화할 수 있습니다. 광고 검색 서비스의 UDF는 런타임 시 이러한 임베딩을 가져올 수 있습니다.
UDF 중에 예측하려면 추론 서비스의 비공개 임베딩을 UDF 함수 인수의 비공개가 아닌 임베딩과 결합하거나 내적과 같은 연산을 통해 키-값 저장소와 결합합니다. 이것이 최종 예측입니다.

이를 통해 각 UDF를 자세히 살펴볼 수 있습니다. 이러한 UDF의 기능과 통합 방법, 상위 k개 광고를 선택하고 그 입찰가를 계산하는 데 필요한 예측 실행 방법을 설명합니다.

`prepareDataForAdRetrieval()` UDF

구매자의 입찰 서비스에서 실행되는 prepareDataForAdRetrieval()은 상위 k개의 조합 광고를 가져오기 위해 광고 검색 서비스로 전송될 요청 페이로드를 만듭니다.

prepareDataForAdRetrieval()은 다음 정보를 사용합니다.

getAdSelectionData에서 수신된 구매자별 페이로드. 이 페이로드에는 Protected App Signals가 포함되어 있습니다.
문맥 신호의 auction_signals(입찰 정보용) 및 buyer_signals (구매자 신호 필드용)입니다.

prepareDataForAdRetrieval()은 다음 두 가지 작업을 합니다.

기능화: 검색 시간 추론이 필요한 경우 들어오는 신호를 추론 서비스를 호출하는 동안 사용할 기능으로 변환하여 검색을 위한 비공개 임베딩을 가져옵니다.
검색을 위한 비공개 임베딩 계산: 검색 예측이 필요한 경우 위의 특성을 사용하여 추론 서비스를 호출하고 검색 시간 예측을 위한 비공개 임베딩을 가져옵니다.

prepareDataForAdRetrieval()는 다음을 반환합니다.

Protected App Signals: 광고 기술에서 선별한 신호 페이로드입니다.
입찰별 신호: 플랫폼별 판매 측 신호와 SelectAdRequest의 auction_signals 및 per_buyer_signals(문맥 임베딩 포함)와 같은 문맥 정보입니다. 이는 Protected Audiences와 유사합니다.
추가 신호: 추론 서비스에서 가져온 비공개 임베딩과 같은 추가 정보입니다.

이 요청은 후보 일치를 실행한 후 getCandidateAds() UDF를 실행하는 광고 검색 서비스로 전송됩니다.

`getCandidateAds()` UDF

getCandidateAds()는 광고 검색 서비스에서 실행됩니다. 구매자의 입찰 서비스에서 prepareDataForAdRetrieval()로 만든 요청을 수신합니다. 이 서비스는 요청을 일련의 설정된 쿼리, 데이터 가져오기로 변환하고 맞춤 비즈니스 로직 및 기타 맞춤 검색 로직을 실행하여 입찰에 사용할 상위 k개의 후보를 가져오는 getCandidateAds()를 실행합니다.

getCandidateAds()는 다음 정보를 사용합니다.

Protected App Signals: 광고 기술에서 선별한 신호 페이로드입니다.
입찰별 신호: 플랫폼별 판매 측 신호와 SelectAdRequest의 auction_signals 및 per_buyer_signals(문맥 임베딩 포함)와 같은 문맥 정보입니다. 이는 Protected Audiences와 유사합니다.
추가 신호: 추론 서비스에서 가져온 비공개 임베딩과 같은 추가 정보입니다.

getCandidateAds()는 다음을 실행합니다.

광고 조합의 초기 집합 가져오기: 언어, 지역, 광고 유형, 광고 크기 또는 예산과 같은 타겟팅 기준을 사용하여 가져와서 광고 조합을 필터링합니다.
검색 임베딩 가져오기: 키-값 서비스의 임베딩이 상위 k개 선택을 위한 검색 시간 예측을 실행하는 데 필요한 경우 키-값 서비스에서 가져와야 합니다.
상위 k개 조합 선택: 키-값 저장소에서 가져온 광고 메타데이터와 구매자의 입찰 서비스에서 전송된 정보에 기반하여 필터링된 광고 조합 세트의 간단한 점수를 계산하고 이 점수에 따라 상위 k개 조합을 선택합니다. 예를 들어 광고를 통해 앱을 설치할 확률이 점수가 될 수 있습니다.
입찰 임베딩 가져오기: 입찰 시간 예측을 위해 입찰 코드에 의해 키-값 서비스의 임베딩이 필요한 경우 키-값 서비스에서 임베딩을 가져올 수 있습니다.

광고의 점수는 예측 모델의 결과일 수 있습니다. 예측 모델은 예를 들어 사용자가 앱을 설치할 확률을 예측합니다. 이러한 유형의 점수 생성에는 일종의 모델 분해가 포함됩니다. getCandidateAds()는 광고 검색 서비스에서 실행되고 광고 검색 서비스에는 추론 서비스가 없으므로 다음을 결합하여 예측이 생성될 수 있습니다.

입찰별 신호 입력을 사용하여 전달된 문맥 임베딩입니다.
추가 신호 입력을 사용하여 전달된 비공개 임베딩
모든 비공개 임베딩 광고 기술은 서버에서 광고 검색 서비스의 키-값 서비스로 구체화되었습니다.

구매자의 입찰 서비스에서 실행되는 generateBid() UDF도 자체 유형의 모델 분해를 적용하여 입찰을 예측할 수 있습니다. 이를 위해 키-값 서비스에서 임베딩이 필요한 경우 지금 가져와야 합니다.

getCandidateAds()는 다음을 반환합니다.

조합 광고: generateBid()에 전달할 상위 k개 광고입니다. 각 광고는 다음으로 구성됩니다.
- 렌더링 URL: 광고 소재를 렌더링하기 위한 엔드포인트입니다.
- 메타데이터: 구매 측 광고 기술별 광고 메타데이터입니다. 예를 들어 여기에는 광고 캠페인에 관한 정보와 타겟팅 기준(예: 위치, 언어)이 포함될 수 있습니다. 메타데이터는 입찰 중에 추론을 실행하기 위해 모델 분해가 필요할 때 사용되는 임베딩(선택사항)을 포함할 수 있습니다.
추가 신호: 선택적으로 광고 검색 서비스는 generateBid()에서 사용할 추가 임베딩 또는 스팸 신호와 같은 추가 정보를 포함할 수 있습니다.

Google에서는 SelectAdRequest 호출의 일부로 제공하는 등 점수를 매길 광고를 제공하는 다른 방법을 조사하고 있습니다. 이러한 광고는 RTB 입찰 요청을 사용하여 검색할 수 있습니다. 이러한 경우 Protected App Signals 없이 광고를 검색해야 합니다. 광고 기술은 응답 페이로드 크기, 지연 시간, 비용, 신호 가용성을 포함하여 최적의 옵션을 선택하기 전에 절충점을 평가할 것으로 예상됩니다.

`generateBid()` UDF

검색 중에 조합 광고 세트와 임베딩을 가져온 후에는 구매자의 입찰 서비스에서 실행되는 입찰을 진행할 수 있습니다. 이 서비스는 구매자 제공 generateBid() UDF를 실행하여 상위 k개에서 입찰할 광고를 선택한 후 입찰가와 함께 반환합니다.

generateBid()는 다음 정보를 사용합니다.

조합 광고: 광고 검색 서비스에서 반환된 상위 k개의 광고입니다.
입찰별 신호: 플랫폼별 판매 측 신호와 SelectAdRequest의 auction_signals 및 per_buyer_signals(문맥 임베딩 포함)와 같은 문맥 정보입니다.
추가 신호: 입찰 시 사용할 추가 정보입니다.

구매자의 generateBid() 구현은 다음 세 가지 작업을 실행합니다.

특화: 추론 중에 사용할 수 있도록 신호를 특성으로 변환합니다.
추론: 머신러닝 모델을 통해 예측을 생성하여 예상 클릭률 및 전환율과 같은 값을 계산합니다.
입찰: 추론된 값을 다른 입력과 결합하여 조합 광고의 입찰가를 계산합니다.

generateBid()는 다음을 반환합니다.

조합 광고
계산된 입찰가

앱 설치 광고에 사용되는 generateBid()와 리마케팅 광고에 사용되는 generateBid()는 다릅니다.

다음 섹션에서는 기능화, 추론, 입찰을 더 자세히 설명합니다.

기능화

generateBid()에서 입찰 신호를 기능으로 준비할 수 있습니다. 이러한 특성은 추론 중에 클릭률, 전환율 등을 예측하는 데 사용할 수 있습니다. 또한 모델 학습에 사용할 수 있도록 낙찰 보고서에서 일부를 전송하는 개인 정보 보호 메커니즘도 살펴보고 있습니다.

추론

입찰가를 계산할 때는 하나 이상의 머신러닝 모델에 대해 추론을 실행하는 것이 일반적입니다. 예를 들어 효과적인 eCPM을 계산할 때는 종종 모델을 사용하여 클릭률과 전환율을 예측합니다.

클라이언트는 generateBid() 구현과 함께 여러 머신러닝 모델을 제공할 수 있습니다. 또한 클라이언트가 런타임에 추론을 실행할 수 있도록 generateBid() 내에서 JavaScript API를 제공합니다.

추론은 구매자의 입찰 서비스에서 실행됩니다. 이는 추론 지연 시간과 비용에 영향을 미칠 수 있습니다. 특히 TEE에서 아직 가속기를 사용할 수 없기 때문입니다. 일부 클라이언트는 구매자의 입찰 서비스에서 실행되는 개별 모델로 요구사항을 충족할 수 있습니다. 예를 들어 매우 큰 모델을 사용하는 클라이언트는 입찰 시 추론 비용과 지연 시간을 최소화하기 위해 모델 분해와 같은 옵션을 고려할 수 있습니다.

지원되는 모델 형식 및 최대 크기와 같은 추론 기능에 관한 자세한 내용은 향후 업데이트에서 제공됩니다.

모델 분해 구현

앞에서 모델 분해를 설명했습니다. 입찰 시 구체적인 접근 방식은 다음과 같습니다.

단일 모델을 비공개 부분(사용자 데이터)과 하나 이상의 비공개가 아닌 부분(문맥 및 광고 데이터)으로 나눕니다.
비공개가 아닌 부분을 generateBid()에 전달합니다. 이는 per_buyer_signals에서 가져오거나 광고 기술이 외부에서 계산하여 검색 서비스의 키-값 저장소로 구체화하고 검색 시 가져와 추가 신호의 일부로 반환하는 임베딩에서 가져올 수 있습니다. 비공개 임베딩은 개인 정보 보호 경계 외부에서 가져올 수 없으므로 여기에 포함되지 않습니다.
generateBid()에서:
1. 모델에 대한 추론을 실행하여 비공개 사용자 임베딩을 얻습니다.
2. 내적과 같은 연산을 사용하여 비공개 사용자 임베딩을 per_buyer_signals의 문맥 임베딩과 결합하거나 검색 서비스의 비공개가 아닌 광고 및 문맥 임베딩과 결합합니다. 입찰가를 계산하는 데 사용할 수 있는 최종 예측입니다.

이 접근 방식을 사용하면 구매자의 입찰 서비스에서 실행하기에 너무 크거나 느린 모델에 대해 입찰 시 추론을 실행할 수 있습니다.

판매 측 점수 로직

이 단계에서는 모든 참여 구매자로부터 받은 입찰이 포함된 광고에 점수가 매겨집니다. generateBid()의 출력이 판매자의 입찰 서비스에 전달되어 scoreAd()가 실행되고 scoreAd()는 한 번에 하나의 광고만 고려합니다. 이 점수에 따라 판매자는 렌더링을 위해 기기에 반환할 낙찰 광고를 선택합니다.

점수 로직은 Protected Audience 리마케팅 흐름에 사용되는 것과 동일하며 리마케팅 및 앱 설치 후보 중에서 낙찰자를 선택할 수 있습니다. 이 함수는 Protected Auction에서 제출된 각 조합 광고에 한 번씩 호출됩니다. 자세한 내용은 입찰 설명을 참고하세요.

광고 선택 코드 런타임

제안서에서 앱 설치를 위한 광고 선택 코드는 Protected Audience 리마케팅 흐름과 동일한 방식으로 지정됩니다. 자세한 내용은 입찰 및 입찰 구성을 참고하세요. 입찰 코드는 리마케팅에 사용된 것과 동일한 클라우드 스토리지 위치에서 사용할 수 있습니다.

보고

이 제안서는 Protected Audience 보고 제안서와 동일한 보고 API를 사용합니다 (예: 플랫폼이 판매자 및 구매자 보고서를 전송하도록 트리거하는 reportImpression()).

구매측 보고의 일반적인 사용 사례 중 하나는 광고 선택 중에 사용된 모델의 학습 데이터를 가져오는 것입니다. 기존 API 외에도 플랫폼에서는 이벤트 수준 데이터를 플랫폼에서 광고 기술 서버로 이그레스하기 위한 특정 메커니즘을 제공합니다. 이러한 이그레스 페이로드에는 특정 사용자 데이터가 포함될 수 있습니다.

장기적으로 이벤트 수준의 사용자 데이터를 TEE에서 실행되는 서비스 외부로 전송하지 않고 보호된 입찰에 사용된 데이터로 모델 학습을 해결하기 위해 개인 정보 보호 솔루션을 연구하고 있습니다. 향후 업데이트에서 추가 세부정보를 제공할 예정입니다.

단기적으로 generateBid()에서 노이즈가 적용된 데이터를 이그레스할 수 있는 임시 방법을 제공할 예정입니다. 이에 관한 초기 제안서는 아래와 같으며, 업계 의견에 따라 이전 버전과 호환되지 않을 수 있는 변경사항을 포함하여 개선할 예정입니다.

기술적으로 작동 방식은 다음과 같습니다.

광고 기술은 전송하려는 데이터의 스키마를 정의합니다.
generateBid()에서 원하는 이그레스 페이로드를 빌드합니다.
플랫폼은 스키마를 기준으로 이그레스 페이로드를 검증하고 크기 제한을 적용합니다.
플랫폼은 이그레스 페이로드에 노이즈를 추가합니다.
이그레스 페이로드는 와이어 형식으로 낙찰 보고서에 포함되며 광고 기술 서버에서 수신되고 디코딩되어 모델 학습에 사용됩니다.

이그레스 페이로드의 스키마 정의

플랫폼에서 변화하는 개인 정보 보호 요구사항을 적용하려면 이그레스 페이로드를 플랫폼이 이해할 수 있는 방식으로 구조화해야 합니다. 광고 기술은 스키마 JSON 파일을 제공하여 이그레스 페이로드의 구조를 정의합니다. 이 스키마는 플랫폼에서 처리되며 UDF 및 모델 등의 다른 광고 기술 리소스와 동일한 메커니즘을 사용하여 입찰 서비스에서 기밀로 유지됩니다.

Google에서는 해당 JSON의 구조를 정의하는 CDDL 파일을 제공합니다. CDDL 파일에는 지원되는 지형지물 유형 (예: 부울, 정수, 버킷 등의 특성)이 포함됩니다. CDDL 파일과 제공된 스키마 모두 버전이 지정됩니다.

예를 들어 단일 부울 특성 다음에 크기가 2인 버킷 특성으로 구성된 이그레스 페이로드는 다음과 같습니다.

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

지원되는 기능 유형에 관한 세부정보는 GitHub에서 확인할 수 있습니다.

`generateBid()`에서 이그레스 페이로드 빌드

지정된 구매자의 모든 보호된 앱 신호는 generateBid() UDF에서 사용할 수 있습니다. 기능이 구현되면 광고 기술이 JSON 형식으로 페이로드를 만듭니다. 이 이그레스 페이로드는 광고 기술 서버로의 전송을 위한 구매자의 성공 보고서에 포함됩니다.

이 설계의 대안은 이그레스 벡터 계산이 generateBid() 대신 reportWin()에서 발생하는 것입니다. 각 접근 방식에는 장단점이 있으며 업계 의견을 수렴하여 이 결정을 마무리할 예정입니다.

이그레스 페이로드 검증

플랫폼은 광고 기술에서 생성된 모든 이그레스 페이로드의 유효성을 검사합니다. 검증을 통해 특성 값이 유형에 유효하고, 크기 제약 조건을 충족하며, 악의적인 행위자가 이그레스 페이로드에 추가 정보를 패킹하여 개인 정보 보호 설정을 우회하려고 시도하지 않는지 확인할 수 있습니다.

이그레스 페이로드가 유효하지 않으면 성공 보고서에 전송된 입력에서 자동으로 삭제됩니다. 유효성 검사를 우회하려는 악의적인 행위자에게 디버깅 정보를 제공하지 않으려고 하기 때문입니다.

Google은 광고 기술이 generateBid()에서 만드는 이그레스 페이로드가 플랫폼 유효성 검사를 통과할 수 있도록 JavaScript API를 제공합니다.

validate(payload, schema)

이 JavaScript API는 전적으로 호출자가 특정 페이로드가 플랫폼 유효성 검사를 통과하는지 확인하기 위한 것입니다. 악의적인 generateBid() UDF를 방지하려면 플랫폼에서 실제 검증을 수행해야 합니다.

이그레스 페이로드 노이즈 제거

플랫폼은 성공 보고서에 포함하기 전에 이그레스 페이로드에 노이즈를 추가합니다. 초기 노이즈 기준점은 1%이며 이 값은 시간이 지남에 따라 달라질 수 있습니다. 플랫폼은 특정 이그레스 페이로드에 노이즈가 있는지 여부를 표시하지 않습니다.

노이즈 제거 방법은 다음과 같습니다.

플랫폼은 이그레스 페이로드의 스키마 정의를 로드합니다.
이그레스 페이로드의 1% 가 노이즈에 대해 선택됩니다.
이그레스 페이로드를 선택하지 않으면 전체 원래 값이 유지됩니다.
이그레스 페이로드가 선택되면 각 특성의 값은 해당 특성 유형에 유효한 임의의 값으로 대체됩니다 (예: 불리언 특성의 경우 0 또는 1).

모델 학습을 위한 이그레스 페이로드 전송, 수신, 디코딩

검증되고 노이즈가 있는 이그레스 페이로드는 reportWin()의 인수에 포함되며 모델 학습을 위한 개인 정보 보호 경계 외부의 구매자 광고 기술 서버로 전송됩니다. 이그레스 페이로드는 와이어 형식입니다.

모든 기능 유형 및 이그레스 페이로드 자체의 와이어 형식에 대한 세부정보는 GitHub에서 제공됩니다.

이그레스 페이로드의 크기 결정

비트 단위의 이그레스 페이로드 크기는 유틸리티와 데이터 수집 최소화의 균형을 이룹니다. Google은 업계와 협력하여 실험을 통해 적절한 크기를 결정합니다. 이러한 실험을 실행하는 동안 일시적으로 비트 크기 제한 없이 데이터를 이그레스합니다. 비트 크기 제한이 없는 추가 이그레스 데이터는 실험이 완료되면 삭제됩니다.

크기를 결정하는 방법은 다음과 같습니다.

처음에는 generateBid()에서 이그레스 페이로드 두 개가 지원됩니다.
1. egressPayload: 이 문서에서 지금까지 설명한 크기 제한된 이그레스 페이로드 처음에는 이 이그레스 페이로드의 크기는 0비트입니다(즉, 검증 중에 항상 삭제됨).
2. temporaryUnlimitedEgressPayload: 크기 실험을 위한 임시 크기 무제한 이그레스 페이로드입니다. 이 이그레스 페이로드의 형식 지정, 생성, 처리에는 egressPayload와 동일한 메커니즘이 사용됩니다.
이러한 각 이그레스 페이로드에는 자체 스키마 JSON 파일(egress_payload_schema.json 및 temporary_egress_payload_schema.json)이 있습니다.
Google에서는 다양한 이그레스 페이로드 크기 (예: 5, 10, ... 비트)에서 모델 유틸리티를 결정하기 위한 실험 프로토콜과 측정항목 집합을 제공합니다.
실험 결과에 따라 적절한 유틸리티와 개인 정보 보호 절충점을 사용하여 이그레스 페이로드 크기를 결정합니다.
egressPayload의 크기를 0비트에서 새 크기로 설정합니다.
설정된 이전 기간이 지나면 temporaryUnlimitedEgressPayload가 삭제되고 새 크기의 egressPayload만 남습니다.

Google에서는 이 변경사항을 관리하기 위한 추가적인 기술적 안전장치(예: 크기를 0비트에서 늘릴 때 egressPayload 암호화)를 조사하고 있습니다. 이러한 세부정보는 실험 프로토콜, 실험 시기, temporaryUnlimitedEgressPayload 삭제 시기와 같은 추가 정보와 함께 향후 업데이트에 포함됩니다.

데이터 보호 조치

Google은 이그레스되는 데이터에 다음과 같은 여러 보호 조치를 적용합니다.

egressPayload 및 temporaryUnlimitedEgressPayload에서 모두 노이즈가 발생합니다.
데이터 수집 최소화 및 보호를 위해 temporaryUnlimitedEgressPayload는 크기 실험 기간에만 사용할 수 있으며, 이 실험에서 egressPayload의 올바른 크기가 결정됩니다.

권한

사용자 제어

이 제안서의 목적은 Protected App Signal 또는 맞춤 잠재고객을 하나 이상 저장한 설치된 앱의 목록을 사용자에게 보여주는 것입니다.
사용자는 이 목록에서 앱을 차단하거나 삭제할 수 있습니다. 차단하거나 삭제하면 다음이 실행됩니다.
- 앱과 연결된 보호된 앱 신호 및 맞춤 잠재고객을 모두 삭제합니다.
- 앱이 새로운 Protected App Signals 및 맞춤 잠재고객을 저장하지 못하도록 합니다.
사용자는 Protected App Signals 및 Protected Audience API를 완전히 재설정할 수 있습니다. 이 경우 기기의 기존 보호된 앱 신호 및 맞춤 잠재고객이 모두 삭제됩니다.
사용자는 Protected App Signals API와 Protected Audience API가 포함된 Android의 개인 정보 보호 샌드박스를 완전히 선택 해제할 수 있습니다. 이 경우 Protected Audience 및 Protected App Signals API는 표준 예외 메시지(SECURITY_EXCEPTION)를 반환합니다.

앱 권한 및 제어

이 제안서의 목적은 앱이 Protected App Signals를 제어할 수 있도록 하는 것입니다.

앱은 Protected App Signals와의 연결을 관리할 수 있습니다.
앱은 서드 파티 광고 기술 플랫폼에 앱을 대신하여 보호된 앱 신호를 관리하는 권한을 부여할 수 있습니다.

광고 기술 플랫폼 제어

이 제안서는 광고 기술이 Protected App Signals를 제어하는 방법을 설명합니다.

모든 광고 기술은 개인 정보 보호 샌드박스에 등록하고 Protected App Signals의 모든 URL과 일치하는 '사이트' 또는 '원본' 도메인을 제공해야 합니다.
광고 기술은 앱 또는 SDK와 협력하여 보호된 앱 신호 생성을 확인하는 데 사용되는 확인 토큰을 제공할 수 있습니다. 이 프로세스가 파트너에게 위임되면 광고 기술의 확인을 요구하도록 Protected App Signals 생성을 구성할 수 있습니다.