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

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

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

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

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

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

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

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

를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">

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

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

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

타임라인

	개발자 프리뷰			베타
기능	2023년 4분기	2024년 1분기	2024년 2분기	2024년 3분기
Signal Curation API	기기 내 저장소 API	기기 내 저장용량 할당량 로직 기기 내 맞춤 로직 일일 업데이트	N/A	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는 광고 기술에서 정의한 Protected App Signals를 저장하거나 삭제할 수 있습니다. 사용자의 활동(예: 앱 열기, 업적, 구매 활동)이나 앱 사용 시간 Protected App Signals는 기기에 안전하게 저장되며 기기 외부로 전송되기 전에 암호화되어 신뢰할 수 있는 실행 환경 내에서 적절한 보안이 적용된 상태로 실행되는 서비스 개인 정보 보호 설정이 광고 입찰 및 점수 산정을 위해 이를 복호화할 수 있습니다 유사한 Custom Audience API를 통해 기기에 저장된 신호를 읽거나 검사할 수 없음 앱 또는 SDK별 신호 값을 읽는 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
지속된 신호를 처리하여 이에 준비할 수 있는 JavaScript API Protected Auction이 실행되는 동안 실시간으로 추가 특성 추출을 수행합니다. (TEE(신뢰할 수 있는 실행 환경)에서 실행되어야 함).

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

광고 기술은 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를 제공하고 이미 설정된 경우 재정의하지 않습니다. 다른 애플리케이션에서 설정합니다.
append: 지정된 키와 연결된 시계열에 요소를 추가합니다. maxSignals 매개변수는 시간의 최대 신호 수를 지정합니다. Google Cloud 시리즈를 확인해 보세요 크기가 초과되면 이전 요소가 삭제됩니다. 키가 시계열로 자동 변환됩니다.
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 호출을 사용하여 Protected Auction에 전송됩니다. 이것은 리마케팅 워크플로에 사용되는 것과 동일한 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 서비스는 구매자의 입찰 서비스에 요청을 보냅니다. 구매자의 입찰 서비스는 prepareDataForAdRetrieval()라는 UDF를 실행합니다. 이 명령어는 광고 검색에서 상위 k개의 후보를 가져오기 위한 요청을 작성합니다. 서비스. 입찰 서비스는 이 요청을 구성된 가져오기에 전송합니다. 지정할 수 있습니다
광고 검색 서비스는 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( 구매자의 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 보고와 동일한 Reporting API를 사용합니다. 제안서 (예: reportImpression()는 플랫폼이 판매자 및 구매자 보고서 전송).

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

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

단기적으로 노이즈가 있는 데이터를 generateBid() 이에 대한 초기 제안은 아래와 같으며 향후 개선될 예정입니다. (이전 버전과 호환되지 않을 수 있는 변경사항 포함) 의견을 보냅니다.

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

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

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

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

해당 JSON의 구조를 정의하는 CDDL 파일이 제공됩니다. 이 CDDL 파일에는 지원되는 기능 유형 집합 (예: (부울, 정수, 버킷 등) CDDL 파일과 버전이 지정됩니다

예를 들어 단일 불리언 특성으로 구성된 이그레스 페이로드 그 뒤에 크기가 2인 버킷 특성은 다음과 같은 형태가 됩니다.

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

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

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

특정 구매자의 모든 Protected App Signals는 generateBid() UDF : 사용자 정의 함수 기능이 활성화되면 광고 기술은 JSON 형식입니다. 이 이그레스 페이로드는 광고 기술 서버로 전송합니다.

이 설계에 대한 대안은 이그레스 벡터 계산이 generateBid() 대신 reportWin() 이 두 가지 옵션에는 업계의 의견을 수렴하여 최종 결정을 내리게 되었습니다.

이그레스 페이로드 유효성 검사

플랫폼은 광고 기술에서 생성된 모든 이그레스 페이로드의 유효성을 검사합니다. 확인 특성 값이 유형에 유효하고 크기 제약 조건이 충족되는지, 악의적인 행위자가 민감한 정보를 사용하여 개인 정보 보호 설정을 이그레스 페이로드에 추가 정보를 패킹합니다

이그레스 페이로드가 잘못된 경우 입력에서 자동으로 삭제됩니다. 낙찰 보고서로 전송됩니다. 이는 디버깅을 제공하고 싶지는 않기 때문입니다. 악의적인 행위자에게 공개하지 않습니다.

Google은 광고 기술이 이그레스 페이로드를 보장하기 위해 JavaScript API를 제공합니다. generateBid()의 create는 플랫폼 유효성 검사를 전달합니다.

validate(payload, schema)

이 JavaScript API는 전적으로 호출자가 특정 페이로드가 있는지 확인하기 위한 것입니다. 플랫폼 유효성 검사를 통과합니다 플랫폼에서 실제 검증이 이루어져야 함 악성 generateBid() UDF로부터 보호

이그레스 페이로드 노이즈 처리

플랫폼은 낙찰 보고서에 포함하기 전에 이그레스 페이로드의 노이즈를 제거합니다. 초기 노이즈 기준점은 1%이며 이 값은 시간이 지남에 따라 달라질 수 있습니다. 이 플랫폼에서 특정 이그레스 페이로드가 노이즈가 제거되었습니다.

노이즈 제거 메서드는 다음과 같습니다.

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

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

검증되고 노이즈가 적용된 이그레스 페이로드는 reportWin(), 개인 정보 보호 범위 외의 구매자 광고 기술 서버로 전송됩니다. 경계선에 위치합니다 이그레스 페이로드는 유선 형식입니다.

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

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

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

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

처음에는 generateBid()에서 2개의 이그레스 페이로드가 지원됩니다. <ph type="x-smartling-placeholder">
1. egressPayload: 지금까지 설명한 크기가 제한된 이그레스 페이로드 참조하세요. 처음에 이 이그레스 페이로드의 크기는 0비트입니다. 즉, 유효성 검사 중에 항상 삭제됩니다.
2. temporaryUnlimitedEgressPayload: 임시 크기 무제한 이그레스 크기 실험에 적합합니다 형식 지정, 생성 및 처리 이 이그레스 페이로드의 수는 egressPayload와 동일한 메커니즘을 사용합니다.
이러한 각 이그레스 페이로드에는 자체 스키마 JSON 파일이 있습니다. egress_payload_schema.json 및 temporary_egress_payload_schema.json
모델을 결정하는 실험 프로토콜과 측정항목 집합 제공 다양한 이그레스 페이로드 크기 (예: 5, 10, ... 비트)의 유틸리티입니다.
실험 결과에 따라 적절한 유틸리티 및 개인 정보 보호 장단점을 고려해야 합니다
egressPayload의 크기를 0비트에서 새 크기로 설정합니다.
정해진 이전 기간이 지나면 temporaryUnlimitedEgressPayload가 삭제됩니다. egressPayload만 새 크기로 남깁니다.

Google에서는 이 변경사항을 관리하기 위한 추가적인 기술적 안전장치를 조사하고 있습니다. 예를 들어 0비트에서 크기를 늘릴 때 egressPayload를 암호화합니다. 이러한 세부정보에는 실험 시기 및 temporaryUnlimitedEgressPayload -- 향후 업데이트에 포함됩니다.

다음으로는 설비의 규모를 결정하는 데 사용할 수 있는 실험 프로토콜에 대해 egressPayload 저희의 목표는 업계와 협력하여 언론사의 니즈와 유틸리티 및 데이터 수집 최소화 이러한 실험으로 생성되는 아티팩트는 그래프에서 x축은 비트 단위의 학습 페이로드 크기이고 y축은 해당 크기로 모델에서 생성된 수익의 비율 크기 제한이 없는 기준점까지 조정할 수 있습니다

여기서는 pInstall 모델을 학습한다고 가정하고 학습 데이터 소스를 temporaryUnlimitedegressPayload의 콘텐츠는 받을 수 있습니다. 광고 기술의 프로토콜에는 먼저 오프라인이 포함됩니다. 실험:

Protected App과 함께 사용할 모델의 아키텍처를 결정합니다. 신호. 예컨대, 디바이스에서 광고를 게재할지 여부를 모델 분해를 사용합니다.
모델 품질을 측정하기 위한 측정항목을 정의합니다. 추천 측정항목은 AUC 손실입니다. 로그 손실이 포함됩니다
모델 학습 중에 사용할 특성 세트를 정의합니다.
이 모델 아키텍처, 품질 측정항목, 학습 특성 세트를 사용하면 절제 연구를 실행하여 각 비트에 대해 비트당 기여한 유틸리티를 결정합니다. 선택합니다. 절제 연구에 권장되는 프로토콜 다음과 같습니다. <ph type="x-smartling-placeholder">
1. 모든 특성을 사용하여 모델을 학습시키고 유용성을 측정합니다. 이것이 바로 비교 기준이 있습니다
2. 기준을 생성하는 데 사용되는 각 특성에 대해 해당 기능을 제외한 모든 기능에 적용됩니다.
3. 결과로 도출되는 유용성을 측정합니다. 델타를 특성의 크기로 나눕니다. 비트 단위; 이는 해당 기능의 비트당 예상되는 유틸리티입니다.
실험에 관심이 있는 학습 페이로드 크기를 결정합니다. [5, 10, 15, ..., size_of_all_training_features_for_baseline] 추천 있습니다. 이러한 각 요소는 egressPayload의 가능한 크기를 나타냅니다. 지정합니다.
가능한 크기마다 그보다 작거나 같은 특성 세트를 선택하세요. 비트당 유용성을 극대화하는 크기여야 합니다.
가능한 한 각 크기에 맞게 모델을 학습시키고 모든 특성에 대해 학습된 기준 모델의 유용성 비율
x축이 학습의 크기인 그래프에 결과를 표시합니다. y축은 10비트 숫자에 대해 창출된 수익의 모델을 비교했습니다

다음으로, 광고 기술은 기능을 사용하여 실시간 트래픽 실험에서 5~8단계를 반복할 수 있습니다. temporaryUnlimitedEgressPayload을(를) 통해 전송되는 데이터입니다. 광고 기술은 개인 정보 보호 샌드박스를 사용한 오프라인 및 실시간 트래픽 실험의 결과 egressPayload의 크기에 대한 결정을 알립니다.

실험 일정 및 규모 설정 일정 egressPayload와(과)의 비교는 이 문서의 범위를 벗어납니다. 향후 업데이트에서 제공될 예정입니다.

데이터 보호 조치

이그레스된 데이터에 다음과 같은 여러 보호 조치를 적용할 예정입니다.

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

권한

사용자 제어

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

앱 권한 및 제어

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

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

광고 기술 플랫폼 제어

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

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