의견 보고서 - 2025년 2분기

개인 정보 보호 샌드박스 제안에 관해 접수된 생태계 의견과 Chrome의 대응을 요약한 2025년 2분기 보고서입니다.

Google은 12항, 17(c)(ii)항, 32(a)항에 따라 경쟁시장청('CMA')에 대한 약속의 일환으로 이 분기별 보고서를 준비했습니다. 이 보고서에는 개인 정보 보호 샌드박스 제안에 대한 Google의 진행 상황, 업데이트된 일정 기대치, Google이 서드 파티의 의견을 고려한 방식에 관한 실질적인 설명, CMA의 의견 및 의견을 해결하기 위한 Google의 접근 방식을 포함한 Google과 CMA 간의 상호작용 요약이 포함되어 있습니다.

Google은 약속의 17(b)항에 따라 예정된 정기 상태 회의에서 개인 정보 보호 샌드박스 제안의 진행 상황을 CMA에 업데이트해 왔습니다. 또한 이 팀은 핵심 비공개 광고 기능과 쿠키 변경사항의 개요, API 구현, 상태 정보를 제공하는 개발자 문서를 관리합니다. 주요 업데이트는 개발자 블로그에 공유되며, 개별 개발자 메일링 리스트에는 타겟팅된 업데이트가 공유됩니다.

서드 파티의 의견 고려

약어 용어집

ARA
Attribution Reporting API
CHIPS
Cookies Having Independent Partitioned State
DSP
수요측 플랫폼
FedCM
Federated Credential Management
IAB
인터넷광고협회
IDP
ID 공급업체
IETF : 인터넷 엔지니어링 태스크포스
인터넷 엔지니어링 태스크 포스
IP
인터넷 프로토콜 주소
openRTB
실시간 입찰
연장전
오리진 트라이얼
PA API
Protected Audience API (이전 명칭: FLEDGE)
PatCG
비공개 광고 기술 커뮤니티 그룹
RP
신뢰 당사자
RWS
관련 웹사이트 세트 (이전 퍼스트 파티 세트)
SSP
공급측 플랫폼
UA
사용자 에이전트 문자열
UA-CH
User-Agent Client Hints
W3C
World Wide Web Consortium
WIPB
고의적인 IP 무시

일반적인 의견, 특정 API/기술 없음

의견 테마 요약 Chrome 응답
개인 정보 보호 샌드박스의 미래 서드 파티 쿠키에 대한 사용자 선택 메커니즘을 도입하지 않기로 한 발표에 따라 서드 파티 쿠키가 있는 경우 일부 API는 다른 API보다 유용하며 다른 API는 유용하려면 발전해야 합니다. 개인 정보 보호 샌드박스 API 외에도 Chrome에 투자할 수 있는 추가 영역이 있습니다. 의견을 보내 주셔서 감사합니다. Google은 Chrome에서 사용자에게 3PC 선택권을 제공하는 현재 접근 방식을 유지한다는 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할 수 있는지 평가하고 향후 투자할 새로운 분야를 모색하기 위해 이해관계자와 계속 소통하고 있습니다.
개인 정보 보호 샌드박스 일부 생태계 참여자는 서드 파티 쿠키에 대한 사용자 선택 메커니즘 도입을 진행하지 않는다는 발표에 실망했지만, 달성한 작업에 자부심을 느끼고 개인 정보 보호 샌드박스 내의 기술적 문제를 이해하며 Chrome과의 협력적 업무 관계의 가치와 시장 테스트 보조금의 유용성을 강조했습니다. 의견을 보내 주셔서 감사합니다. Chrome은 개발자와 협력하여 광고 지원 인터넷을 유지하면서 온라인 개인 정보 보호를 개선하는 기술을 만들 수 있으며 그렇게 해야 한다는 데 동의합니다.
브라우저 데이터 공유 브라우저 매개 데이터 공유는 시장 비효율성과 신뢰 문제를 해결할 수 있는 잠재력이 있는 매력적인 기술입니다. 브라우저는 공동작업을 위한 서드 파티 실행 컨텍스트로서 가치를 지닙니다. 의견을 보내 주셔서 감사합니다. Chrome은 협업하는 개발자와 사용자 간의 신뢰를 강화하는 기술을 개발하는 데 개발자를 지원하는 역할을 할 수 있으며 또 해야 한다고 생각합니다.
Chrome 트래픽 Chrome에서 쿠키 없는 트래픽의 점유율과 시크릿 모드의 트래픽 점유율은 어느 정도인가요? CMA가 '약속 발표 의향 통지'에서 언급한 바와 같이 시크릿 모드는 매우 적은 비율의 탐색 활동에만 영향을 미칩니다. 영국과 EEA에서 Chrome 시크릿 모드는 Android 운영체제에서 실행되는 기기의 탐색 중 10% 미만, Windows 운영체제에서 실행되는 기기의 탐색 중 10% 미만을 차지합니다. 이러한 측정항목은 영국 및 EEA의 Chromium 기반 Chrome에서의 탐색만 나타냅니다.
Google은 서드 파티 쿠키를 차단하는 브라우저에 관한 데이터를 공유하지 않습니다.
개발자는 스토리지 액세스 헤더를 사용하여 쿠키가 파티셔닝되는 시점을 결정하고 제공되는 완화 조치를 적절히 사용할 수 있습니다.
Chrome 테스트 라벨 2024년에 테스트를 위해 사용 설정된 1% 의 쿠키 없는 트래픽에 대한 Chrome의 계획은 무엇인가요? 현재로서는 공유할 계획이 없지만, 준비가 되는 대로 공개적으로 공유할 예정입니다.
Chrome 테스트 현재 테스트 라벨 설정에는 서드 파티 쿠키와 개인 정보 보호 샌드박스 API가 모두 사용 가능한 시나리오를 위한 처리가 포함되어 있나요? 현재 테스트 라벨 설정에는 모드 A 형식의 서드 파티 쿠키와 개인 정보 보호 샌드박스 API 모두에 대한 처리가 포함됩니다.
개인 정보 보호 샌드박스 일부 광고주는 개인 정보 보호 샌드박스 API가 복잡하다고 생각하고 이전 준비 연습으로 인해 무관심을 보이며, 초기 채택자의 이점을 정량화하는 방법을 궁금해하고, 재타겟팅, 신규 고객 발굴, 측정의 효과에 관한 교육을 찾고 있습니다. 의견을 보내주셔서 감사합니다. 기술적 복잡성과 준비 운동에 대한 의견을 잘 알고 있습니다.
현재 개인 정보 보호 샌드박스 기술의 실적을 파악하는 것과 관련하여 테스트 결과에 따르면 생태계 참여는 개인 정보 보호 샌드박스 솔루션의 실적을 파악하는 데 중요한 요소입니다. 소량으로 테스트하면 마켓 역학 관계와 대규모로 기술을 사용할 때의 인센티브를 재현할 수 없습니다.

등록 및 증명

이번 분기에 받은 의견이 없습니다.

관련성 높은 콘텐츠 및 광고 표시

주제

의견 테마 요약 Chrome 응답
개선사항이 적용된 Topics API의 성능 및 유틸리티 관심도 구매 측 이해관계자의 의견에 따르면 Topics API는 유용한 신호이며 광고주 캠페인의 경우 3PC 잠재고객의 CPM과 경쟁력 있는 노출당 비용 데이터 (CPM)를 제공합니다. 일부 게시자는 Topics API의 신호가 표준 개방형 웹 신호보다 품질이 더 높다고 생각합니다. Topics API의 유용성에 관한 이러한 의견을 바탕으로 이해관계자들은 분류 충실도와 일관성을 개선하고 게시자 관리 기능을 확대하여 더 광범위한 채택을 유도하는 등 개선사항을 요청하고 있습니다. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
다양한 유형의 이해관계자를 위한 유용성

현재 Topics 분류자는 페이지 호스트 이름만 사용하여 해당 주제를 정의하므로 콘텐츠가 다양한 대규모 사이트는 일반적인 주제를 제공하는 반면 소규모 사이트는 광고 가치가 더 높은 틈새 주제를 제공합니다. Google의 대답은 이전 분기와 유사합니다.
서드 파티 쿠키와 마찬가지로 사이트마다 기여하는 정보의 가치가 다릅니다. 틈새 시장 관심분야 사이트는 가치 기여도가 일관되지 않습니다. 모든 틈새 시장 관심분야 사이트에 상업적으로 가치 있는 콘텐츠가 있는 것은 아니므로 가치 기여도가 낮습니다. Topics API의 이점을 누릴 수 있는 사이트입니다. 사이트 수준이 아닌 페이지 수준 분류의 가능성도 고려했지만 이러한 분류에는 여러 가지 심각한 개인 정보 보호 및 보안 문제가 있습니다.
주제 분류가 세분화되지 않음 Topics API는 단일 도메인 내에 다양한 콘텐츠 섹션이 있는 뉴스 게시자에게 충분한 세부사항을 제공하지 않아 광고 타겟팅을 위한 API의 유용성이 제한될 수 있습니다. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
분류기 개선 게시자가 페이지 콘텐츠 (예: 헤드, 본문)를 기반으로 주제를 분류할 수 있는 권한을 Chrome에 부여하도록 허용 이 요청을 검토 중이며 여기에서 추가 의견을 보내주시면 감사하겠습니다.
정책 Topics API를 3PC 정보와 함께 사용하는 것과 관련된 가이드라인에 대한 설명 요청 Topics API는 3PC의 기능 중 일부를 제공하므로 Topics API와 3PC를 모두 사용하는 데는 문제가 없습니다.
Observe-Browse-Topics 헤더 Observe-Browse-Topics 헤더 구현에 관한 설명 요청, 특히 헤더를 지속적으로 반환하면 문제가 발생하는지 여부 Observe-Browse-Topics: ?1 헤더를 계속 반환해도 기술적인 문제가 발생하지는 않습니다.
브라우저는 이 신호를 효율적으로 처리하여 중복이나 오류를 일으키지 않고 페이지 방문이 주제 계산에 적합하다고 간단히 기록합니다. 모든 페이지에서 필수인 것은 아니지만 모든 최상위 문서에서 표준 헤더로 전송하는 것은 유효하고 간단한 전략입니다.
분류 카테고리 최신 주제 분류를 새 주제로 업데이트하도록 요청 Google에서는 이 요청을 고려하고 있으며 생태계의 추가 의견을 여기에서 기다리고 있습니다.
Null 값 Topics API의 성능을 개선하고 필터링이나 민감도와 같은 null 응답의 이유를 이해하는 데 도움이 되는 안내를 요청합니다. 명확히 말하자면 Topics API의 null 또는 빈 응답은 오류가 아니라 예상되는 개인 정보 보호 기능입니다.
null 응답은 다음과 같은 이유로 발생할 수 있습니다.
• 개인 정보 보호 규칙: 5% 의 무작위 null 확률 또는 스크립트가 해당 주제와 관련된 사이트에서 사용자를 '관찰'하지 않았기 때문입니다.
• 사용자 상태: 방문 기록이 충분하지 않거나, 시크릿 모드를 사용하거나, 사용자가 Chrome의 광고 개인 정보 보호 설정에서 선택 해제했습니다.
• 기술적 오류: 게시자 사이트는 Observe-Browse-Topics: ?1 헤더를 전송해야 하며 호출 iframe에는 allow="Browse-topics" 권한이 필요합니다.
조사하려면 chrome://topics-internals 디버깅 페이지를 사용하여 브라우저에서 계산한 주제와 이유를 확인하세요.
개인 정보 보호 기능으로 인해 100% 게재율을 달성할 수는 없지만 다음과 같은 방법으로 실적을 개선할 수 있습니다.
• 게시자와 협력: 파트너가 사이트에서 Observe-Browse-Topics: ?1 헤더를 올바르게 전송하는지 확인합니다.
• 코드 확인: iframe을 사용하는 경우 allow="Browse-topics" 정책이 적용되어 있는지 확인합니다.

Protected Audience API

의견 테마 요약 Chrome 응답
비용과 복잡성으로 인해 PA API 채택이 저해됨 도입자들은 운영 비용, 광고주 수요 부족, 거래소의 인벤토리 볼륨 부족을 이유로 Protected Audience API(PA API) 통합의 우선순위를 낮추거나 롤백하고 있습니다.
일부 의견에는 높은 일치율로 인해 지속 가능한 잠재고객과 우수한 도달범위를 제공하는 기능과 같은 PA API의 잠재적 이점이 포함되었습니다.
Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
크로스 플랫폼 기능 교차 플랫폼 기능은 플랫폼 전반에서 PA API를 활용하여 더 나은 재타겟팅 및 잠재고객 타겟팅 기능을 지원해야 합니다. Google은 Chrome에 등록된 관심분야 그룹 (IG)이 네이티브 환경 또는 웹뷰 내에서 광고를 게재할 때 액세스할 수 있도록 해야 하며, Android에 등록된 관심분야 그룹은 Chrome 입찰에서 사용할 수 있어야 합니다. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
directFromSellerSignals 컨텍스트 광고 입찰에서 사용할 수 있는 정보의 양을 제한하면 입찰 참여자는 항상 Google의 광고 서버를 통해 라우팅됩니다. 게시자는 먼저 모든 거래소 파트너를 호출한 다음 Google Ad Manager (GAM)를 두 번째로 호출하여 컨텍스트 입찰을 실행하고 마지막으로 GAM이 IG 입찰을 호출하도록 허용해야 합니다. 경쟁업체는 실시간으로 컨텍스트 광고의 결과를 알지 못하므로 공정하게 최상위 결정을 내릴 수 없습니다.

PA API의 directFromSellerSignals 기능은 경매 정보에 관한 투명성이 부족하여 필요한 데이터에 액세스하는 데 방해가 될 수 있습니다. Google은 directFromSellerSignals를 삭제하거나 광고 서버의 입찰 낙찰가를 숨기는 데 사용할 수 없도록 업데이트해야 합니다. 예를 들어 모든 입찰 참여자 (및 게시자)가 액세스하고 확인할 수 있는 투명하고 변경 불가능하며 서명된 필드를 통해 Chrome을 통해 컨텍스트 가격을 전달할 수 있습니다.
이전 분기와 마찬가지로 다음과 같이 답변합니다.
Chrome 답변:
판매자가 자체 iframe에서 runAdAuction()을 호출하지 않는 한 runAdAuction()에 전달된 정보가 판매자로부터 제공된 것인지 알 수 없습니다. 다중 판매자 입찰에서는 모든 판매자가 runAdAuction()을 호출하는 프레임을 만들 수 없습니다. directFromSellerSignals는 판매자의 출처에서 로드된 하위 리소스 번들에서 콘텐츠를 로드하여 이 문제를 해결했습니다. 이렇게 하면 판매자-입찰 구성에서 입찰에 전달된 정보의 진위성과 무결성이 조작될 수 없습니다. 게시자가 PA API를 사용하여 기술 제공업체가 PA 입찰에 전달하는 정보를 파악하려면 해당 기술 제공업체에 이 기능을 요청하면 됩니다.
Google Ad Manager 응답:
Google은 수년 동안 입찰 공정성에 중점을 두어 왔습니다. 여기에는 게시자의 미보장 광고 소스(미보장 광고 항목 가격 포함)의 가격이 입찰 전에 다른 구매자와 공유되지 않는다는 약속이 포함됩니다. 이 약속은 이후 프랑스 경쟁 당국에 대한 약속에서 재확인되었습니다.
Protected Audience 입찰의 경우 directFromSellerSignals를 활용하여 약속을 지키고 여러 판매자 입찰에서 입찰이 완료되기 전에 다른 입찰 참여자와 입찰 참여자의 입찰가를 공유하지 않을 예정입니다. 이 업데이트에 설명된 대로 Google은 자체 구성요소 입찰과 컨텍스트 입찰의 가격을 공유하지 않습니다.
보고 중앙 집중식 보고를 사용 설정하기 위해 분석/보고 항목을 추가하도록 요청합니다. 이 요청에 관해 여기에서 논의하고 있으며 추가 의견을 환영합니다.
buyerReportingId의 k-익명성 잠재고객 선별 및 서드 파티 데이터 제공업체와의 보고 의무를 용이하게 하기 위해 'buyerReportingId'의 k-익명성을 기반으로 입찰을 삭제할 수 있습니다. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
generateBid 스크립트의 디버깅 개선 프로세스가 실패하는 generateBid 스크립트 내의 특정 단계 또는 '중단점'을 신속하게 식별하는 메커니즘을 요청합니다. Google은 실시간 측정을 기기 내 경매의 중단점 설정 메커니즘으로 사용하려는 요구를 알고 있습니다. Google에서 Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식을 유지하겠다고 2025년 4월에 발표한 점을 고려하여 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
runAdAuction 상태 모니터링을 위한 이벤트 리스너 광고 입찰 수명 주기 모니터링을 개선하기 위해 PA API의 navigator.runAdAuction 함수에 이벤트 리스너 지원을 추가하자는 제안입니다. Google에서는 이 요청을 평가하고 있으며 생태계의 추가 의견을 여기에서 환영합니다.
API 사용량 특히 3PC를 선택 해제했지만 개인 정보 보호 샌드박스 API는 선택 해제하지 않은 사용자와 쿠키 동기화가 실패한 시나리오 및 WebView의 경우 PA API와 Attribution Reporting API (ARA)가 3PC가 없는 웹 광고 사용 사례를 어떻게 지원할 수 있는지 설명해 주세요. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
지연 시간 지연 시간이 너무 높으면 게시자가 PA API를 사용 중지할 수 있으므로 PA API와 관련된 지연 시간으로 인해 채택이 저해될 수 있습니다. 지난 몇 분기 동안 기기 내 지연 시간과 관련해 여러 개선사항이 적용되었습니다. 입찰 서비스 구축 및 확장 (B&A)은 필요에 따라 계속됩니다. 이러한 기능을 활용하는 방법에 관한 자세한 내용을 포함하도록 지연 시간 권장사항 가이드가 업데이트되었습니다. 또한 새로운 지연 시간 개선사항 개발도 모색하고 있으며, 일부는 여기에서 확인할 수 있습니다.
B&A의 로깅 동작 (테스트 vs. 프로덕션) B&A 서비스의 테스트 모드와 프로덕션 모드 간 로깅 동작의 차이점에 관한 설명 특히 클라우드 로그의 가용성과 프로덕션 모드가 로깅에 미치는 영향에 대해 설명합니다. 먼저 prod vs. non_prod 빌드와 하드코딩된 테스트 암호화 키를 사용 설정하는 별도의 TEST_MODE 매개변수를 구분하는 것이 중요합니다. 아래 설명에서는 빌드 유형에 중점을 둡니다.
non_prod 빌드에서 B&A 서버는 로깅을 위한 구성 가능한 상세 수준을 제공합니다. 이러한 상세 로그는 표준 stdout/stderr 스트림에 기록됩니다. Google Cloud에서는 기본 로깅 인터페이스를 통해 액세스할 수 있고, Amazon Web Services에서는 연결된 콘솔 로그에서 확인할 수 있습니다.
프로덕션 빌드의 경우 로깅 동작이 더 제한적입니다. 상세도 수준은 고정되어 있으며 변경할 수 없습니다. 서버 시작 메시지, 대부분의 비정상 종료 오류와 같은 개인 정보 보호와 관련이 없는 일부 로그는 stdout/stderr에 계속 출력되지만 이 채널을 통해 요청별 로그는 사용할 수 없습니다. 프로덕션 빌드의 요청별 로그는 동의한 디버깅 토큰이 포함된 요청에만 해당하며, 이러한 로그는 OpenTelemetry를 통해서만 내보내집니다. 동의된 디버깅은 트래픽이 많으면 서버 성능이 저하되고 상태 점검 실패로 이어질 수 있으므로 주의해서 사용해야 합니다.
측정항목의 경우 모두 OpenTelemetry를 통해 내보내집니다. 개인 정보 보호에 민감하지 않은 측정항목은 '노이즈 추가' 없이 항상 있는 그대로 내보내집니다. 반대로 개인 정보 보호에 민감한 측정항목은 프로덕션 모드에서 실행되는 서버에서 내보낼 때 항상 '노이즈 처리'됩니다. 구체적인 원격 분석 구성에 따라 이러한 개인 정보 보호 관련 측정항목이 노이즈 처리된 상태로 내보내지는지, 노이즈 처리되지 않은 상태로 내보내지는지, 아니면 둘 다 내보내지는지가 결정됩니다.
브랜드 안전을 위해 신뢰할 수 있는 입찰 신호에 전체 페이지 경로 포함 신뢰할 수 있는 입찰 신호의 가져오기 요청에 호스트 이름 외에 최상위 페이지의 전체 URL 경로를 포함하도록 PA API 업데이트를 요청합니다.
기본 사용 사례는 더 세부적인 브랜드 안전성 관리 기능을 사용 설정하는 것입니다. 광고주는 일반적으로 도메인(예: news-site.com)은 괜찮지만 도메인의 특정 섹션(예: news-site.com/politics)에는 광고가 표시되지 않도록 차단해야 하는 경우가 많습니다. 이러한 차단 목록은 수백만 개의 항목으로 구성될 수 있으므로 서버 측에서 평가해야 합니다. 현재 사양에서는 호스트 이름만 전송하므로 trustedBiddingSignals 서버가 이 필수 경로 수준 평가를 실행할 수 없어 브랜드 안전 기능이 제한됩니다.
이 문제는 현재 여기에서 논의 중이며, 이전의 광범위한 논의는 여기에서 확인할 수 있습니다. 추가 의견을 환영합니다.
하지만 신뢰할 수 있는 입찰 신호 가져오기가 신뢰할 수 있는 실행 환경 (TEE) 내에서 실행되는 서버로 이동하는 경우에만 이 정보를 추가하는 것을 고려하고 있음을 알려드립니다.

보호된 입찰 (B&A 서비스)

의견 테마 요약 Chrome 응답
사용 가능 여부 테스트 Chrome 및 B&A 환경에서 테스트할 수 있는 키/값 (KV) v2의 가용성에 관한 정보입니다. KV v2는 B&A와 Chrome에서 모두 사용할 수 있습니다. 추가 안내는 여기에서 확인할 수 있습니다.
KV 서버 구현 KV 서버 사용에 관한 명확한 설명 요청, 특히 광고 소재 렌더링 URL을 요청 데이터에 매핑하는 것, 렌더링 URL에서 매개변수를 정의하기 위한 SSP와 DSP 간의 조정 필요성, KV 모드에서 필요한 조정 및 데이터 스토리지를 설명하는 문서의 가용성에 관한 요청입니다. KV 서비스는 renderURL을 키로 사용합니다. URL이 새 URL이면 저장됩니다. 존재하는 경우 scoreAd에서 사용할 값이 반환됩니다. 반환 형식은 설정에 따라 다릅니다. 'Bring Your Own Server' (BYOS)는 모든 값을 허용하는 반면, 신뢰할 수 있는 KV 서비스에는 사용자 정의 함수가 필요합니다.
항상 필요한 것은 아니지만 매크로 대체 (예: ${AD_WIDTH})을 renderURL에 추가하여 동적 광고 맞춤설정과 확인을 사용 설정합니다.
필요한 조정 수준을 파악하기 위해 하나의 DSP로 간단한 테스트를 시작하는 것이 좋습니다. 또한 KV 문서를 업데이트하는 중이며, 완료되면 공개적으로 공유할 예정입니다.
B&A용 BYOS B&A가 KV의 BYOS 모드와 유사한 BYOS 모드를 제공하지 않는 이유는 무엇인가요? B&A는 TEE가 필요하므로 BYOS 모델이 허용되지 않습니다. 아래에 설명된 대로 개인 정보 보호 메커니즘의 적용이 필요한 매우 민감한 데이터 조합을 처리하기 때문입니다.
DSP:
B&A는 게시자 컨텍스트 (판매자가 auctionSignals / perBuyerSignals를 통해 명시적으로 전송하는 경우 전체 URL일 수 있음)를 상세 사용자 IG 데이터와 결합하여 처리합니다. TEE는 이 조합을 안전하게 처리하고 잠재적인 사용자 재식별을 방지하는 데 필수적입니다. KV BYOS에서는 전체 URL을 전송할 수 없습니다.
SSP:
입찰에 참여하는 IG (및 해당 DSP 소유자)의 조합만 알아도 식별 서명을 생성할 수 있습니다. 여기에서 TEE 사용이 필요한 채핑 솔루션이 사용됩니다.
따라서 이러한 결합된 민감한 신호의 안전한 처리와 개인 정보 보호 메커니즘의 시행에는 TEE의 관리되고 증명된 환경이 필요합니다.

디지털 광고 측정

Attribution Reporting (및 기타 API)

의견 테마 요약 Chrome 응답
소음 정책 ARA 구현은 일부 시장 참여자에게 유용했으며 Google은 이벤트 수준 보고를 계속 유지해야 합니다. Google은 ARA와 3PC가 모두 사용 가능한 시나리오에서 소음 정책을 완화하는 것을 고려해야 합니다. 성능 광고주는 ARA 유연한 이벤트의 현재 '값' 필드 구현을 점점 더 많이 사용하고 있으며, 제한이 적은 노이즈 정책은 지연과 부정확한 보고를 줄이는 데 도움이 됩니다. 이 메커니즘은 개별 추적을 방지하여 사용자 개인 정보를 보호하기 위한 ARA 설계의 기본 부분입니다. Google에서는 Chrome에서 사용자에게 3PC 선택권을 제공하는 현재 접근 방식을 유지하겠다는 2025년 4월 발표에 따라 향후 개인 정보 보호 샌드박스 API의 역할과 잠재적인 향후 개선사항을 계속 평가하면서 노이즈로 인해 발생하는 보고 문제에 관한 의견을 고려하고 있습니다.
로드맵 및 장기적 지원 3PC용 사용자 선택 메커니즘 도입을 진행하지 않겠다는 발표에 따라 ARA의 제품 로드맵과 장기 투자 및 지원을 확인 요청 개인 정보 보호 샌드박스팀은 생태계와 소통하여 앞으로 개인 정보 보호 샌드박스 API가 수행할 역할을 파악하고 향후 투자를 평가하고 있습니다.
교차 환경 측정 (앱-웹) ARA를 활용하여 교차 환경 측정을 지원하고, 더 깔끔하고 신뢰할 수 있는 데이터 흐름을 제공하며, 다양한 플랫폼에서 사용자 상호작용을 연결하는 기능을 개선하는 솔루션을 요청합니다. 동일한 기기에서 앱-웹은 이미 ARA에서 지원됩니다. 교차 앱 및 웹 측정 솔루션에 대한 자세한 내용은 여기 여기를 참고하세요.
교차 브라우저 기여 분석 ARA에 대한 통합된 교차 브라우저 접근 방식은 오픈 웹에서 ROI를 측정하는 기능을 크게 개선하고 잠재적인 규제 변화에 앞서 안정적인 대안을 제공할 것입니다. Chrome은 이와 같은 솔루션에 관해 Safari팀과 협력해야 합니다. Google은 이미 W3C 내 PATCG 및 PATWG 그룹에서 다른 브라우저 공급업체와 상호 운용 가능한 API를 살펴보고 있습니다. 이 작업은 예비 단계이며 이해관계자는 여기에서 진행 상황을 확인할 수 있습니다.
교차 기기/오프라인 측정 ARA 내에서 교차 기기 전환 측정을 지원할 수 없는 것은 심각한 제한사항입니다. 온라인-오프라인 전환을 측정하는 것도 매우 중요하며 브라우저는 측정 공급업체와 협력하는 데 역할을 할 수 있습니다. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
멀티 터치 기여 분석 광고주가 개인 정보 보호 샌드박스 데이터를 편향되지 않은 '정답'으로 사용하여 기존 기여 분석 모델을 검증하고 보정할 수 있도록 허용해 달라는 요청 이는 ARA의 브라우저 제공 데이터를 신뢰할 수 있는 보정 신호로 사용하여 사실의 기준을 만듦으로써 달성할 수 있습니다. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
동의 없는/선택 해제된 트래픽 측정 상호 운용 가능한 비공개 기여 분석과 같은 개인 정보 보호 솔루션을 사용하면 동의가 없는 트래픽에 대한 측정이 가능합니다. 이렇게 하면 추적을 선택 해제한 사용자의 데이터를 포함하여 캠페인 실적을 더 포괄적으로 파악할 수 있으며, 동의 요건으로 인해 발생하는 측정의 주요 격차를 해결할 수 있습니다. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
서버 간 기여 분석 정교한 서버 측 인프라를 갖춘 광고 기술이 사용자 개인 정보를 보호하면서 클라이언트 측에서만 관리하기 어려운 사용 사례를 수용하는 보다 유연한 방식으로 ARA와 통합할 수 있도록 허용해 달라고 요청합니다. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.
다중 도메인 등록 ARA에 여러 도메인을 등록할 때 제한사항과 주의사항에 관해 명확히 설명해 주세요. 특히 집계 서비스와 교차 출처 기여 분석에 관해 설명해 주세요. 여러 도메인에서 ARA를 사용할 때의 주요 제한사항은 다음과 같습니다.
• 기여 분석 범위는 단일 출처로 지정됩니다. 한 도메인의 클릭을 다른 도메인의 전환과 일치시킬 수 없습니다. 기여 분석은 소스와 트리거 모두에 대해 동일한 출처로 샌드박스 처리됩니다.
• 집계 서비스는 다중 출처 일괄 처리를 지원하지 않습니다. 출처가 다른 보고서는 별도로 일괄 처리하고 처리해야 합니다. 향후 이 기능을 지원할 방법을 모색하고 있습니다.
간단히 말해 하나의 법인에 여러 도메인을 등록할 수 있지만, 현재는 기여도 분석 및 집계와 같은 모든 ARA 함수가 출처별로 처리되어야 합니다.

Aggregation Service

이번 분기에 받은 의견이 없습니다.

Private Aggregation API

의견 테마 요약 Chrome 응답
한도 및 노이즈 수준 Private Aggregation API 내 집계 키 크기 및 집계 값 제한에 관한 우려사항 집계 키와 값 크기는 네트워크 및 스토리지 비용을 제한하면서도 높은 세부사항을 갖도록 선택되었습니다. 유연성을 극대화하려면 키를 할당할 때 해싱을 사용하는 것이 좋습니다.
사용자 데이터를 보호하는 다른 요소도 있지만 노이즈 추가는 Private Aggregation API의 개인 정보 보호의 중요한 부분입니다.
Google의 2025년 4월 발표에 따라 Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지될 예정이므로, Google은 의견을 고려하여 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 고려하는 동시에 적절한 매개변수 선택을 계속 평가할 것입니다.
개인 정보 보호와 유용성 개인 정보 보호 샌드박스의 접근 방식은 유용성보다 개인 정보 보호를 우선시하여 채택을 저해할 수 있습니다. 측정 및 광고 개인 최적화를 개선하기 위해 사용자 동의를 통해 더 세부적인 데이터 공유를 허용하자는 제안 집계 키와 값 크기는 네트워크 및 스토리지 비용을 제한하면서도 높은 세부사항을 갖도록 선택되었습니다. 유연성을 극대화하려면 키를 할당할 때 해싱을 사용하는 것이 좋습니다.
Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.

은밀한 추적 제한

사용자 에이전트 축소/사용자 에이전트 클라이언트 힌트

의견 테마 요약 Chrome 응답
스팸 감지 스팸 감지 시스템을 사용하는 웹사이트의 첫 번째 요청이 클라이언트 힌트를 사용하는 경우 추적 또는 감지 시스템이 요청을 식별하거나 올바르게 분류하지 못할 수 있습니다. 첫 번째 요청에서 User-Agent Client Hints(UA-CH)에 액세스해야 하는 사용 사례는 중요한 클라이언트 힌트를 사용해야 합니다.
API 의견 Sec-CH-USA-Wow64는 더 이상 최신 웹과 관련이 없으므로 지원 중단을 고려하세요. 이 요청을 검토 중이며 여기에서 추가 의견을 보내주시면 감사하겠습니다. 또한 Windows를 넘어 wow64를 확장하는 것이 유용하다는 의견도 접수되었습니다.

IP 보호 (이전 명칭: Gnatcatcher)

의견 테마 요약 Chrome 응답
컨트롤 사이트가 시크릿 모드 외부에서 선택적으로 사용할 수 있도록 IP 보호 전환 요청 의견을 보내주셔서 감사합니다. 이 문제에 관한 추가 의견이 있으시면 여기에 남겨주세요.
부정행위 경찰이 플랫폼의 위법 행위에 대한 IP 주소 공개를 요청할 때 NULL 값이 발생하는 확률적 공개 토큰 (PRT)으로 인해 가해자 식별이 방지되나요? 도메인이 사기 및 악용 감지에만 사용되는 경우 마스크 처리된 도메인 목록 (MDL)에 포함되지 않을 수 있으므로 IP 보호의 영향을 받지 않습니다. 따라서 이러한 도메인에는 PRT가 필요하지 않습니다.
도메인이 MDL에 포함된 경우 현재 PRT가 프록시 요청의 원래 IP 주소를 파악하는 유일한 방법입니다. PRT는 개별 식별이 아닌 집계 분석을 지원하도록 특별히 설계되었으므로 대부분의 경우 PRT에 IP 주소가 포함되지 않는 것이 사실입니다. 하지만 IP 보호는 서드 파티 컨텍스트에만 적용되므로 게시자는 사용자가 온라인 플랫폼의 사이트를 방문하는 것과 같은 퍼스트 파티 상호작용에 대해 프록시되지 않은 IP 주소를 계속 수신하게 됩니다. 따라서 설명된 시나리오에서 미치는 영향은 제한적일 것으로 예상됩니다.
사기 방지 프록시 액세스 속도 제한 및 인증 토큰 발급에 관한 세부정보를 비롯해 IP 보호를 위한 Google의 사기 방지 조치의 구체적인 내용은 무엇이며 PRT의 구체적인 사용 사례는 무엇인가요? IP 보호의 비율 제한 및 인증 토큰은 사기 방지 및 스팸 방지 전략에 자세히 설명된 대로 봇이 프록시에 과도하게 액세스하여 광고 사기를 실행하지 못하도록 설계되었습니다. PRT의 추가 사용 사례는 여기의 PRT 설명 문서에 설명되어 있습니다.
시크릿 모드 시크릿 모드의 IP 보호 기능은 여전히 3분기에 출시될 예정인가요? 현재 시크릿 모드에서 IP 보호 출시를 위한 3분기 일정은 변경되지 않습니다.

이탈 추적 감소

의견 테마 요약 Chrome 응답
API 의견 Chrome은 바운스 추적 완화 (BTM)를 적용할 때 쿠키/저장소 액세스를 파티셔닝하는 대신 차단해야 합니다. Safari의 '파티셔닝' 방법으로 인해 의도하지 않은 동작과 혼란이 발생하기 때문입니다. 이 제안을 환영합니다. 현재 BTM에는 쿠키/저장소 파티셔닝이 포함되지 않으며 대신 유예 기간이 지나면 삭제됩니다. 쿠키에 대한 즉각적인 조치가 포함된 BTM의 후속 설계가 있는 경우 쿠키를 파티셔닝하는 것보다 차단하는 것을 선호할 예정입니다.

크로스 사이트 개인 정보 보호 경계 강화

이번 분기에 받은 의견이 없습니다.

Fenced Frames API

이번 분기에 받은 의견이 없습니다.

Shared Storage API

의견 테마 요약 Chrome 응답
API 기능 요청 공유 저장소에 광고 조회수 및 클릭수를 추가하도록 요청합니다. Chrome에서 사용자에게 서드 파티 쿠키 선택권을 제공하는 현재 접근 방식이 유지된다는 Google의 2025년 4월 발표에 따라 개인 정보 보호 샌드박스 API가 앞으로 어떤 역할을 할지 평가할 때 이 의견을 고려하고 있습니다.

CHIPS

의견 테마 요약 Chrome 응답
API 질문 Chrome의 서드 파티 쿠키 제어가 CHIPS와 상호작용하는 방식, 특히 서드 파티 쿠키가 사용 중지될 때 파티셔닝되지 않은 쿠키가 파티셔닝된 쿠키로 변환되는지, 파티셔닝된 쿠키가 활성 상태로 유지되는지에 관한 명확한 설명 요청 서드 파티 쿠키가 사용 중지되면 파티셔닝되지 않은 쿠키는 서드 파티 컨텍스트에서 저장, 검색 또는 전송되지 않습니다. 하지만 파티셔닝된 쿠키는 3PC를 사용 중지하는 브라우저 설정의 영향을 받지 않으므로 서드 파티 컨텍스트에서 계속 저장, 검색, 전송됩니다.
개인 정보 보호 문제 싱글 사인온과 같은 영구 식별자가 있는 삽입된 당사자가 파티셔닝된 쿠키를 사용하더라도 삽입 당사자와 삽입된 당사자 모두 전역 디지털 식별자를 획득할 수 있다는 우려가 있습니다. 삽입된 당사자에게 영구 식별자가 있을 수 있지만 이 식별자는 파티셔닝된 쿠키에 저장된 경우 삽입에 의해 쿠키가 설정된 사이트에서만 액세스할 수 있습니다. 이 식별자를 교차 사이트에서 결합하려면 로그인 작업이 필요하며, 로그인 작업은 파티셔닝된 쿠키를 사용하지 않더라도 인증 토큰 형태의 식별자 교환을 이미 허용합니다.

FedCM

의견 테마 요약 Chrome 응답
API 사용량 특정 오류 없이 계정이 여러 개인 사용자의 자동 미디에이션이 실패함 자동 미디에이션 동작은 사용 가능한 계정이 하나인 매우 구체적인 경우를 위해 설계된 기능입니다. 무음 미디에이션이 불가능한 경우 FedCM이 사용자에게 계정 선택기를 표시하도록 대체되는 '선택사항' 미디에이션을 대신 사용하는 것이 좋습니다.
API 사용량 navigator.credentials.get는 일반적인 오류를 반환하므로 사용자 닫기 또는 쿨다운 기간과 같은 구체적인 거부 사유를 포착할 수 없습니다. 개발자가 사용자가 FedCM 대화상자를 닫는 경우와 네트워크 오류가 발생하는 경우, 사용자가 이전에 대화상자를 닫아 FedCM이 '쿨다운 기간'에 있는 경우를 구분할 수 없는 것도 사용자의 개인 정보를 보호하기 위한 설계된 기능입니다. 이러한 기능을 사용하면 웹사이트에서 다양한 ID 제공업체(IdP)의 사용자 로그인 상태를 추론할 수 있다는 우려가 있습니다.
로그인 로그인된 계정이 여러 개인 경우 계정 선택 동작이 일관되지 않는 것으로 확인되었습니다. 여러 계정에 로그인한 시나리오에서 특정 계정을 간헐적으로 선택할 수 없는 것이 FedCM의 간헐적인 버그인지 아니면 테스트 시스템과 관련된 문제인지 명확하지 않습니다. Google은 신고자와 협력하여 이 문제를 해결하고 있으며, 문제를 더 잘 이해하기 위해 추가 세부정보를 요청했습니다.
API 사용량 사용자가 FedCM으로 승인하는 동안 대화상자를 닫으면 쿨다운 상태에 있다는 사실이 포착 가능한 오류를 통해 보고되지 않습니다. 예, 이 경우 사용자 개인 정보를 보호하기 위해 일반 오류 코드가 생성됩니다.
API 사용량 '자동 재인증'에 성공한 후 FedCM이 10분간의 무음 기간으로 전환되는 이유는 무엇인가요? 자동 재인증은 사용자가 시작한 작업 없이 발생하므로 사용자가 웹사이트로 돌아가되 다른 계정으로 로그인하려면 FedCM이 사용자를 자동 재인증하지 않는 기간이 필요합니다. '무음 모드'를 사용하면 사용자가 다른 계정을 사용하여 수동으로 로그인할 수 있습니다. 이 '조용한 기간'에 관한 자세한 내용은 블로그 게시물을 참고하세요.
경량 FedCM 경량 FedCM 제안이 호환되지 않는 두 구현 (FedCM과 경량 FedCM)을 지원해야 하므로 IDP에 추가 복잡성을 도입한다는 우려가 있습니다. 경량 FedCM은 기존 FedCM과 호환됩니다. IdP는 사용할 구현 방법을 선택할 수 있으며 두 가지를 모두 지원할 필요는 없습니다.
경량 FedCM은 FedCM의 푸시 메커니즘입니다. IdP가 이 기능을 사용하기로 선택하면 사용자가 로그인할 때 계정 정보를 브라우저에 푸시하여 신뢰 당사자 (RP)가 FedCM을 호출할 때 IdP의 계정 엔드포인트 대신 브라우저에서 계정을 가져올 수 있습니다.
경량 FedCM 경량 FedCM 제안에서 이름, 이메일, 프로필 사진과 같은 개인 사용자 데이터가 RP에 노출되는 것에 대한 우려 이 의견을 받은 후 경량 FedCM 제안서가 업데이트되어 메서드 응답에서 이름, 이메일, 프로필 이미지가 삭제되었습니다.
경량 FedCM 로그인된 여러 계정 관리가 경량 FedCM 제안에서 너무 엄격한 것으로 보입니다. 이 제안은 현재 계정별 개별 세션 수명 또는 미묘한 로그인 상태를 지원하지 않습니다. 만료는 현재 사용자 인증 정보 객체 내의 IdP에 연결되어 있습니다. 계정별 만료는 미해결 질문으로 기록되었으며 향후 개발에 이 의견을 고려할 예정입니다.
경량 FedCM '로그인됨'과 '선택 가능'의 구분이 명확하게 정의되어 있지 않아 경량 FedCM 제안의 사용자 환경에 영향을 미칠 수 있습니다. 현재 FedCM 사용자 인터페이스 (UI)에서 계정이 로그인되었는지 로그아웃되었는지 구분하는 기능은 지원되지 않습니다. 로그아웃된 계정은 나열되지 않아야 합니다.
계정이 로그아웃되어 목록에 표시되고 사용자가 활성 상태로 로그인되지 않은 계정을 선택하면 연속 API를 사용하여 사용자가 다시 로그인하도록 할 수 있습니다.
API 사용량 getUserInfogiven_name 필드와 FedCM UI에서의 사용 간 불일치 이 문제는 getUserInfo에서 given_name를 처리하는 방법을 조정하기 위해 Mozilla와 여기에서 자세히 논의했습니다.
API 사용량 IdentityProviderAccount의 UI에 사용되는 모든 필드가 getUserInfo에 제공되지는 않습니다(특히 telusername). 이는 동기화가 필요함을 시사합니다. Mozilla 및 기타 FedID 커뮤니티 그룹 회원과의 토론IdentityProviderAccount의 어떤 필드가 getUserInfo.로 전송되는지 조정하는 문제에 관해 진행되고 있습니다.
Enterprise FedCM 엔터프라이즈 IdP 사용 사례에 대한 FedCM 지원 요청 핵심 문제는 관리자가 웹 트래커에 의해 모방되거나 악용될 수 없는 특정 RP에 사용자가 액세스하도록 허용하는 데 미리 동의했음을 IdP가 브라우저에 알리는 신뢰할 수 있는 메커니즘이 필요하다는 것입니다. 이 문제는 4월 22일 FedID CG 회의에서 논의되었으며(회의 노트 참고) 브라우저 확장 프로그램과 엔터프라이즈 정책 (관리 기기용)의 조합이 잠재적인 해결책으로 제시되었습니다. 이 문제에 관한 추가 의견은 여기에서 보내주시기 바랍니다.

스팸 및 사기 퇴치

Private State Token API (및 기타 API)

이번 분기에 받은 의견이 없습니다.