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

의견 보고서 - 2024년 1분기
bookmark_border 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

개인 정보 보호 샌드박스 제안 및 Chrome의 대응에 대해 받은 생태계 의견을 요약한 2024년 1분기 분기 보고서입니다.

CMA에 대한 약속의 일환으로 Google은 개인 정보 보호 샌드박스 제안서의 이해관계자 참여 절차에 관한 분기별 보고서를 공개적으로 제공하기로 합의했습니다 (약속의 12항 및 17항(c)(ii) 참고). 이러한 개인 정보 보호 샌드박스 의견 요약 보고서는 GitHub 문제, privacysandbox.com에 제공된 의견 양식, 업계 이해관계자와의 회의, 웹 표준 포럼 등 의견 개요에 나열된 다양한 소스에서 Chrome이 수신한 의견을 집계하여 생성됩니다. Chrome은 생태계로부터 받은 의견을 환영하며, 학습한 내용을 디자인 결정에 통합할 방법을 적극적으로 모색하고 있습니다.

의견 주제는 API별로 발생 빈도에 따라 순위가 매겨집니다. 이는 Chrome팀이 특정 주제와 관련하여 받은 의견의 양을 집계하고 수의 내림차순으로 정렬하여 수행됩니다. 일반적인 의견 주제는 공개 회의(W3C, PatCG, IETF), 직접적인 의견, GitHub, Google 내부 팀 및 공개 양식을 통해 자주 제기되는 질문을 검토하여 확인했습니다.

구체적으로 웹 표준 기관 회의의 회의록을 검토하고 직접적인 의견의 경우 Google의 1:1 이해관계자 회의 기록, 개별 엔지니어가 받은 이메일, API 메일링 목록, 공개 의견 양식을 고려했습니다. 그런 다음 Google은 이러한 다양한 홍보 활동에 참여하는 팀 간에 조정하여 각 API와 관련하여 나타나는 주제의 상대적 발생 빈도를 확인했습니다.

Chrome의 의견에 대한 응답에 관한 설명은 게시된 FAQ, 이해관계자가 제기한 문제에 대한 실제 응답, 이 공개 보고서 작성의 목적을 위한 구체적인 입장을 결정하는 데서 비롯되었습니다. 현재 개발 및 테스트의 중점을 반영하여 특히 Topics, Protected Audience, Attribution Reporting API와 관련된 질문과 의견이 접수되었습니다.

현재 보고 기간이 종료된 후에 받은 의견은 아직 Chrome에서 고려하지 않았을 수 있습니다.

약어 용어집

ARA: Attribution Reporting API
CHIPS: 독립적으로 파티션된 상태의 쿠키
DSP: 수요측 플랫폼
FedCM: Federated Credential Management
FPS: 퍼스트 파티 세트
IAB: 인터넷광고협회
IDP: ID 공급업체
IETF : 인터넷 엔지니어링 태스크포스: 인터넷 엔지니어링 태스크포스
IP: 인터넷 프로토콜 주소
openRTB: 실시간 입찰
연장전: Origin 무료 체험
PAT API: Protected Audience API (이전 명칭: FLEDGE)
PatCG: 비공개 광고 기술 커뮤니티 그룹
RP: 신뢰 당사자
RWS: 관련 웹사이트 세트 (이전의 퍼스트 파티 세트)
SSP: 공급측 플랫폼
TEE: 신뢰할 수 있는 실행 환경
UA: 사용자 에이전트 문자열
UA-CH: 사용자 에이전트 클라이언트 힌트
W3C: World Wide Web Consortium
WIPB: 의도적 IP 무시

일반적인 의견이며 특정 API 또는 기술이 없음

의견 주제	요약	Chrome 응답
거버넌스	개인 정보 보호 샌드박스의 거버넌스 업데이트에 대한 공개 의견 제출 기간에 관심이 있습니다.	Google은 개인 정보 보호 샌드박스의 향후 거버넌스를 비롯하여 개인 정보 보호 샌드박스와 관련된 중요한 사안에 대해 합리적인 이해관계자 의견을 수렴하고 있습니다.
테스트	현재 1% 의 Chrome을 통한 테스트 외에도 3PCD를 위한 추가 테스트 단계	Google은 1월 초부터 사용 설정된 현재 Chrome 트래픽의 1%를 넘어서는 Chrome을 통한 테스트를 제공할 계획이 없습니다.
웹 to 앱	웹과 앱 간의 완전한 상호 운용성이 달성되기 전에는 휴대기기에서 3PCD가 발생해서는 안 됩니다.	Google은 앱과 웹 상호 운용성을 지원하는 것이 바람직하다는 데 동의하며 교차 앱 및 웹 기여 분석 측정을 출시하고 웹-앱 타겟팅 솔루션을 모색하고 있습니다. 하지만 모바일 웹의 3PCD는 지연되지 않습니다. 3PCD가 끝날 때 100% 노출 범위를 달성하는 것은 목표가 아닙니다. 대신 Android에서 교차 앱 및 웹 측정에 대한 호환성은 3PCD에서 상당히 높고 사용자가 휴대전화를 업데이트함에 따라 시간이 지남에 따라 증가할 것으로 예상됩니다.
브라우저 역할	Chrome이 광고 서버 또는 SSP의 역할을 하는 것으로 보입니다.	Chrome은 광고 서버 또는 SSP의 역할을 하지 않습니다. Chrome은 PA API를 통해 광고 서버, SSP, DSP, 기타 광고 기술이 자체 입찰 및 점수 산정 로직을 가져올 수 있는 컨테이너를 제공합니다.
사용 사례 안내	개인 정보 보호 샌드박스 API에서 지원하는 사용 사례에 관한 더 명확한 안내	개인 정보 보호 샌드박스 프로젝트 초기에 개발자 문서는 주로 개발자를 모든 제안서에 대한 논의 및 의견 제출 절차에 참여시키는 데 중점을 두었습니다. 즉, 콘텐츠는 일반적으로 프로젝트의 동기와 개념을 이해하는 것을 중심으로 구성되었으며, 그다음에는 각 제안서의 초기 개발 및 테스트 세부정보가 이어졌습니다. 이러한 접근 방식은 제안서를 개발하는 데 있어 실제 생태계 협력을 구축하는 데 효과적이었지만, API가 정식 버전으로 출시되면서 기본 개발에 기여하기보다는 API를 기반으로 빌드하는 것을 주로 목표로 하는 새로운 개발자층이 생겨났습니다. 최근 Google에서는 IAB Tech Lab의 최근 개인 정보 보호 샌드박스 태스크 포스 보고서와 유사한 분류를 사용하여 사용 사례에 중점을 두도록 개인 정보 보호 샌드박스 개발자 사이트의 탐색을 업데이트했습니다. 문서에 대한 사용 사례 기반 접근 방식은 앞으로도 계속될 것입니다.
로컬 개발 환경	쿠키가 SameSite=Secure이고 백엔드가 CDN으로 프런트엔드에 연결된 경우 http://localhost에서 로컬로 프런트엔드를 계속 개발하고 테스트하려면 어떻게 해야 하나요?	이 문제는 여기에서 논의 중이며 생태계의 추가 의견을 기다리고 있습니다.
3PCD 완화	서드 파티 쿠키가 차단되었는지 또는 휴리스틱이 활성화되었는지 프로그래매틱 방식으로 확인할 수 있는 방법이 있나요?	Chrome에서는 iframe에서 호출되는 기능 감지와 document.hasStorageAccess를 통해 개발자가 iframe의 출처에 3PC에 대한 액세스 권한이 있는지 알 수 있습니다.
동영상 테스트	현재 개인 정보 보호 샌드박스에서는 동영상 광고를 테스트할 수 없습니다.	Chrome은 현재 PA API를 사용하여 동영상을 실행할 수 있는 몇 가지 방법에 관한 토론 및 데모를 게시했습니다 (GitHub의 데모 저장소에서 242 및 254 참고). 이는 광고 기술에서 대량으로 채택할 샘플 코드가 아니라 PA API로 VAST 동영상 렌더링을 지원할 수 있는 기법의 개념 증명 및 데모용입니다. 이러한 논의 과정에서 오늘날 이미 동영상 렌더링이 가능하지만 Chrome에서 PA API를 사용한 구현을 간소화할 수 있는 변경사항이 있음이 분명해졌습니다. 예를 들어 서드 파티 광고 인증자 브랜드 안전 사용 사례에 대한 의견을 바탕으로 이미 해결할 계획이었던 매크로 대체 ( 여기에서 설명) 업데이트는 구매자가 렌더링에 사용할 판매자 매크로를 찾는 동영상 사용 사례의 의견도 해결할 수 있습니다. 지금까지의 대부분의 논의는 특히 VAST 동영상 광고 렌더링에 중점을 두었습니다. 네이티브 광고 렌더링은 동일한 접근 방식을 사용할 수 있으며 여러 가지 면에서 더 쉽습니다. 현재 네이티브 광고는 동영상보다 관심을 덜 받고 있는 것처럼 보이지만 이는 구현에 대한 기술적 장벽이 아니라 광고 기술 업계의 우선순위 문제일 뿐입니다.
광고 외 측정	3PCD는 광고와 관련 없는 잠재고객 측정 솔루션에 영향을 줄 수 있습니다.	측정 API는 사용 사례가 광고 관련일 필요가 없습니다. ARA는 일반적인 광고 여정에 더 구체적으로 적용되는 반면 비공개 집계는 범용입니다. 이 두 가지 구성요소는 다양한 측정 활동을 처리하는 데 사용할 수 있습니다.
콘텐츠 크리에이터	개인 정보 보호 샌드박스는 콘텐츠 크리에이터가 자체 사이트에서 YouTube용 콘텐츠를 더 많이 제작하도록 유도하도록 설계되었습니다.	개인 정보 보호 샌드박스 이니셔티브는 개방적이고 자유로운 인터넷에서 사용자의 활동을 비공개로 유지하는 데 중점을 둡니다. Google은 게시자가 광고를 통해 콘텐츠를 제작하고 최대한 많은 사용자에게 제공하고 있음을 잘 알고 있습니다. 광고주는 사용자가 원하는 신제품이나 혜택을 찾을 수 있도록 도와줍니다. 개인 정보 보호 샌드박스 기능을 사용하면 콘텐츠 크리에이터와 협력하는 사이트를 비롯한 모든 종류의 웹사이트에서 사용자의 신원을 해당 당사자에게 공개하지 않고도 다양한 당사자와의 활동을 기반으로 사용자에게 유용한 광고를 표시할 수 있습니다.
더 명확한 타임라인	개인 정보 보호 샌드박스 기술의 출시 일정이 더 명확하고 상세해졌습니다.	개인 정보 보호 샌드박스 API 문서에는 API 상태 및 사용 가능 여부 페이지가 포함되어 있습니다. 이 페이지에는 예정된 기능과 타임라인 (예: PA API, ARA)이 나와 있습니다. 여기에서 이러한 상태를 한눈에 확인할 수 있습니다.
머신러닝	3PCD가 1%를 초과할 때까지 광고 기술은 머신러닝 모델을 제대로 학습시킬 수 없습니다.	테스트를 위해 3PCD를 더 많은 브라우저로 확장해도 API의 사용 빈도가 늘어날 것이라고 보장할 수 없습니다. 이는 광고 기술이 머신러닝 모델을 추가로 학습하기 위해 찾고 있는 것일 수 있습니다. 광고 기술이 머신러닝 모델을 추가로 학습하기 위해 더 광범위한 생태계 사용을 추구하지 않는다면 3PCD를 확장할 이유가 없습니다. 더 많은 트래픽으로 모델을 학습하려는 광고 기술은 현재 3PCD를 늘리지 않고도 그렇게 할 수 있기 때문입니다. 이는 Chrome이 정지 상태가 종료되기 전에 3PCD에서 진행되는 것처럼 보이지 않고도 가능합니다.
지원되지 않는 사용 사례	현재 셀프서비스 DSP 사용 사례는 고려되지 않고 있습니다.	API에 대한 공개 의견을 정기적으로 제공하는 여러 개의 셀프서비스 DSP가 있습니다. 정기적으로 공개 의견을 제공하는 DSP 중 일부는 테스터로 등록하기도 했습니다. 또한 Chrome은 동영상 및 서드 파티 광고 서버와 같은 일반적인 셀프서비스 DSP 주제에 적극적으로 참여하고 있습니다. 최근 주간 PA API 호출에서 이 주제를 다뤘습니다.
Origin 트라이얼	3PCD의 보다 공격적인 램프업 및 테스트 범위를 원하는 사이트의 OT 요청	Chrome은 현재 오리진에서 서드 파티 지원 중단 동작을 선택할 수 있는 퍼스트 파티 OT를 개발하고 있습니다. 이 무료 체험판에 등록하고 토큰을 배포하는 최상위 출처는 사용자 기기에 추적 보호가 사용 설정된 것처럼 3PC가 차단됩니다. 이 OT는 사이트가 CMA와의 상의 후 예정된 3PC의 단계적 지원 중단에 앞서 3PC의 장기적인 대안을 더 광범위하게 테스트할 수 있는 소중한 기회를 제공합니다. YouTube는 아직 OT 출시 일정을 최종적으로 확정하기 위해 노력하고 있습니다.
IAB Tech Lab 보고서	IAB Tech Lab 보고서에서 받은 개인 정보 보호 샌드박스에 관한 의견	Google은 여기에서 IAB Tech Lab 보고서에 대해 자세히 설명했습니다. 또한 '보고서에서는 분산된 문서, 상업적 요구사항, 서드 파티 감사, 업계 인증, 확장성, 투명성, 향후 거버넌스에 관해 질문을 제기하며, Google은 생태계와 협력하고 이에 따라 공개 FAQ를 업데이트할 예정입니다.'라고 언급했습니다. 이전에 분산된 문서를 해결합니다. Google은 '데이터 보장'의 여기에서 상업적 요구사항을 다루고 있으며 일부 Google Ads 제품은 접근 방식을 공유했습니다. 여기의 '알고리즘 무결성 보장'에서 서드 파티 감사에 대해 설명합니다. 인증과 관련하여 이러한 기관은 기술 자체가 아닌 기술 사용을 포함한 제품을 계속 인증할 것으로 예상됩니다. 확장성과 관련하여 Google은 문제를 보여주는 개발자 데이터를 계속 수집하고 있습니다. 투명성과 거버넌스와 관련하여 Google은 GitHub 및 W3C와 같은 포럼에서 공개적으로 개발을 계속하면서 약속에 따라 CMA와 협력하고 있습니다.
Google 로그인	Google 로그인을 사용하면 Google이 약관에 반하여 교차 식별 로그인 데이터를 사용할 가능성이 있습니다.	Google 로그인을 통해 Google에서 약속에 위배되는 데이터를 사용할 수는 없습니다.
호환성	개인 정보 보호 샌드박스 API 지원 및 전방 / 후방 호환성 계획은 무엇인가요?	Chrome에서 기능을 정식 버전으로 출시하면 해당 기능에 대한 지원을 유지하는 것을 목표로 합니다. 물론 하위 호환성을 유지할 수 없는 경우도 있습니다. 이러한 경우 기존 기능을 지원 중단하고 삭제하는 명확한 절차가 있으며 이는 여기에 설명되어 있습니다. Google은 향후 지원이 개선되면 도움이 될 사용 사례에 관한 생태계의 의견을 바탕으로 개인 정보 보호 샌드박스 API에 더 많은 기능을 추가할 예정입니다. 이러한 경우 새로운 기능을 실험하는 데 관심이 있는 광고 기술이 브라우저에 기능이 지원되는지 직접 물을 수 있도록 일종의 기능 감지 기법을 포함하는 경향이 있습니다. 일부 기능이 모든 Chrome 사용자에게 동시에 출시되지 않을 수 있으므로 개발자에게 특정 Chrome 버전 번호를 확인하도록 요청하는 것보다 낫습니다. 예를 들어 PA API의 기능 감지 작업은 여기에서 확인할 수 있습니다.
서버 구현	Chrome은 자체 구현에 결합하는 대신 신뢰할 수 있는 신호 서버, 집계 서버, 기타 필요한 브라우저 외 구성요소의 만족스러운 구현이 충족해야 하는 동작을 지정해야 합니다. 이를 통해 허용 가능한 개인 정보 보호 범위 내에서 혁신을 실현할 수 있습니다.	Google은 외부 당사자의 혁신 의지를 높이 평가하고 환영합니다. Google은 모든 API 및 서비스에 대해 광고 기술이 기능을 구현할 수 있는 유연성을 제공하는 것을 목표로 합니다. 예를 들어 Google에서는 광고 기술이 입찰의 입찰 로직을 설계할 때 기밀 비즈니스 정보를 사용할 수 있도록 허용합니다. 또한 Google은 광고 기술의 의견을 지속적으로 수렴하고 타당한 경우 설계에 반영합니다. 다른 사용자가 신뢰할 수 있는 실행 환경에서 자체 코드를 실행할 수 있도록 하려면 개인 정보 보호 샌드박스에서 코드 (및 변경사항)를 검토하여 개인 정보 보호 보장을 충족하는지 확인해야 합니다. 이를 위해서는 개인 정보 보호 샌드박스팀의 상당한 노력이 필요합니다. 따라서 이해관계자가 현재 Google에서 제공하지 않는 어떤 이점을 얻고자 하는지 파악하고자 합니다.
휴리스틱	휴리스틱에 대한 장기 계획은 무엇인가요?	다른 브라우저에서 언급한 바와 같이, Google은 대체 솔루션이 널리 사용되면 추가 타당성 분석을 거쳐 이러한 휴리스틱을 폐기할 계획입니다. 여기에서 공유해 드렸습니다.
테스트 볼륨	측정기준을 비교할 때 트래픽 양이 다름	1% 실험에는 Chrome 클라이언트의 여러 집단 간에 실험 자격 요건에 차이가 발생하는 제외 기준이 있습니다. 예를 들어 실험에서 Chrome Enterprise 사용자를 제외하므로 주말에는 실험 라벨이 있는 트래픽의 비율이 더 높을 것으로 예상됩니다. 지역, 날짜, 플랫폼과 같은 다양한 데이터 슬라이스에서 트래픽 비율이 다르게 표시되는 것은 당연한 일이며 이는 Chrome 데이터에서 확인할 수 있는 결과와 일치합니다.
3PC 수동으로 다시 사용 설정	사이트에서 3PCD가 시행된 후 쿠키를 수동으로 다시 사용 설정한 사용자의 비율을 알 수 있나요?	중단이 발생하면 사용자는 사용자 우회 기능을 통해 사이트 수준에서 서드 파티 액세스를 다시 사용 설정할 수 있습니다. 3PC는 Storage Access API와 같은 다른 조치에 의해 다시 사용 설정될 수도 있습니다. 사이트에서 3PC가 사용 설정되어 있는지 여부를 감지할 수 있는 기술적 조치(예: hasStorageAccess())가 있습니다. 하지만 Chrome에서는 웹사이트가 재사용 설정 이유를 알 수 있는 방법을 제공하지 않습니다.
추적 보호	Chrome의 추적 보호 UI 기능은 언제까지 사용할 수 있나요?	주소 표시줄의 추적 보호 UI는 3PC가 지원 중단된 후에도 계속 표시될 것으로 예상됩니다.
(이전 분기에도 신고됨) 교차 브라우저 지원	개인 정보 보호 샌드박스 API를 채택하는 다른 브라우저 공급업체	Apple, Mozilla, Microsoft와 같은 다른 브라우저 공급업체는 개인 정보 보호 원칙과 브라우저 기반 접근 방식이 논의되는 공개 포럼에 적극적으로 참여하고 있습니다. 최근 W3C 연례 TPAC 회의와 진행 중인 W3C PATCG 포럼과 같은 포럼에서 이루어지는 협력적인 논의는 합의의 조짐을 보여주며 고무적입니다. 예를 들어 Microsoft Edge는 최근 PA API 및 ARA와의 '문법적 호환성을 극대화하는 것을 목표로 하는 계획'을 발표하고 개발자를 위한 추가 기능도 제공했습니다.
3PCD 이후 호환되지 않는 삽입에 대한 대체 옵션	서드 파티 iframe / 삽입이 3PCD를 준수하는지 여부를 감지하는 API 후크를 제공합니다.	여기에서 요청에 대해 논의하고 있으며 생태계의 추가 의견을 기다리고 있습니다.
테스트	맞춤설정된 동작을 일시적으로 사용 중지하는 추가 플래그를 관리 Chrome 인스턴스에서 요청합니다.	Chrome의 관리형 인스턴스에 대한 이 요청을 고려 중이며, 이러한 플래그가 유용하다면 생태계의 추가 의견을 기다리고 있습니다.

등록 및 증명

의견 주제	요약	Chrome 응답
증명 인증	Google에서는 어떻게 증명서의 진위를 보장하나요?	모든 등록자는 API를 사용하는 동안 증명 파일을 유지해야 합니다. Google은 파일이 있고 문법이 올바른지 확인하지만 증명 언어와 관련하여 광고 기술의 동작은 확인하지 않습니다.
Private Aggregation API 등록 절차	Private Aggregation API 등록 상태를 확인할 수 있는 방법이 있나요?	등록이 확인되면 등록 지원팀에서 모든 승인된 등록자에게 이메일을 통해 알립니다. 등록 과정에서 궁금한 점이 있으면 등록 양식을 제출할 때 연결된 지원팀에 문의할 수 있습니다. 지원팀에서 응답하고 질문에 답변하며 필요한 추가 안내를 제공합니다.

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

주제

의견 주제	요약	Chrome 응답
(이전 분기에도 보고됨) 분류 기준 타임라인 및 문서	분류를 검토할 수 있는 어떤 형태의 메커니즘이든 있어야 하며, 적어도 분류 모드에서 카테고리를 결정하는 방식에 대한 투명성이 추가되어야 합니다.	Google의 답변은 이전 분기와 동일합니다. "사이트가 잘못 분류되면 주제 신호가 전반적으로 약간 덜 유용해질 수 있지만, 잘못 분류된 특정 사이트는 다른 사이트보다 더 나쁘거나 더 나은 영향을 받지 않습니다. 이는 사이트의 문맥 정보를 사이트의 입찰에 항상 사용할 수 있으므로 잘못 분류된 경우에도 올바른 주제와 비슷한 정보를 제공할 수 있기 때문입니다. 이 주제에 관한 의견이 있으시면 여기에서 보내주세요."
Google Ad Manager	Google Ad Manager는 이미 대부분의 사이트에 삽입되어 있으며, 사이트 수가 적은 경쟁업체보다 사용자 주제에 대한 정보를 훨씬 더 많이 보유하고 있습니다.	관찰 요구사항은 Topics API로 대체하는 기술 (서드 파티 쿠키 포함)을 사용할 때보다 더 많은 개체에 사용자 데이터가 공유되지 않도록 하기 위한 것입니다. Prebid과 같은 다른 업계 솔루션은 수만 개의 사이트에서 작동하며 시장 참여자가 해당 기술을 통해 Topics API를 호출할 수 있도록 지원합니다. 또한 주당 최대 5개의 인기 주제 제한은 평등화 효과를 가질 수 있습니다. 여러 사이트에 있는 시장 참여자가 3PC를 사용하여 5개 이상의 주제를 학습할 수 있지만 5개로 제한되기 때문입니다.
(이전 분기에도 보고됨) 다양한 유형의 이해관계자용 유용성	트래픽 수준이나 콘텐츠의 전문도에 따라 사이트에서 창출된 가치와 가치의 분배에 대한 우려	Google은 전문 사이트가 일반 관심분야 도메인보다 더 세부적인 주제를 제공할 가능성이 높다는 점을 알고 있습니다. 하지만 모든 전문 사이트가 상업적으로 가치 있는 주제를 제공하는 것은 아닙니다. 또한 이러한 동적은 현상을 반영하며 Chrome에서 3PC 지원 종료와는 전혀 무관합니다. 또한 현재 환경에서 일부 사이트는 3PC 기반 광고 관련성 시스템에서 다른 사이트보다 더 많은 가치를 제공합니다. 또한 전문 사이트의 주제는 서로에게 도움이 될 수 있습니다. 다양한 광고주가 다양한 주제에 걸쳐 캠페인을 운영할 수 있고 입찰 로직이 다양한 주제에서 가치를 관찰할 수 있기 때문입니다.
호스트 이름과 전체 URL 비교	웹사이트의 호스트 이름을 기반으로 한 분류가 충분히 효과적이며 전체 URL에 비해 개인 정보 보호 위험을 줄여주나요?	Google은 호스트 이름 외에도 정보 URL 또는 페이지 제목을 사용하는 것을 고려했으나, 잠재적인 이익보다 사용자 개인 정보 보호 및 보안상의 위험이 더 크다고 판단했습니다. 사용자 개인 정보 보호 위험의 예로는 URL 또는 페이지 제목에 포함된 민감한 정보를 사용자의 주제로 분류하는 것이 있습니다.
신호로서의 주제	Topics를 다른 신호와 결합하는 방법과 유용한 다른 신호에 관한 안내를 요청합니다.	광고 기술 솔루션은 문맥 데이터, 광고 소재 데이터, 퍼스트 파티 데이터와 함께 머신러닝, 개인 정보 보호 API의 개인 정보 보호 신호와 같은 사용 가능한 모든 도구를 결합하여 최상의 결과를 얻을 수 있습니다. 자세한 내용은 여기를 참고하세요.

Protected Audience API (이전의 FLEDGE)

의견 주제	요약	Chrome 응답
테스트 트래픽 볼륨	테스터가 PA API 입찰의 입찰 응답 수가 적다고 신고하고 있습니다.	1. 입찰 밀도는 PA API의 생태계 참여도와 관련이 있으며, 2024년 이후에도 계속 증가할 것으로 예상됩니다. 캠페인 예산을 어떻게 할당할지는 궁극적으로 광고주, 대행사, 기술 제공업체가 결정합니다. 일부 생태계 참여자는 3PCD 이후까지 PA API를 비롯한 다양한 '쿠키 없는' 솔루션에 대한 투자를 지연할 수 있습니다. 이때 이러한 솔루션에 대한 캠페인 예산 할당이 늘어날 것으로 예상됩니다. 2. PA API 입찰의 입찰 요청 수에는 (1)의 영향이 있을 수 있습니다. 즉, 게시자와 광고 기술 제공업체는 수요가 적다고 판단되면 PA API 입찰을 시작하지 않을 수 있습니다. 페이지 업데이트 및 참여의 우선순위는 게시자가 결정합니다. 이러한 이유로 게시자가 트래픽을 테스트하고 점진적으로 늘리는 데 시간이 걸릴 수 있습니다. 이 보고서에는 PA API 참여에 대한 게시자 관리에 관한 Google Ad Manager의 응답도 포함되어 있습니다.
(이전 분기에도 신고됨) 사기 / 악용	생태계는 어떻게 위험을 줄이고 악의적인 행위자나 구매자가 바람직한 잠재고객으로 포지셔닝하는 것을 막을 수 있을까요?	PA API 광고의 보고 메커니즘은 현재 사람과 봇 트래픽을 구분하는 데 사용되는 정보를 보관합니다. 또한 현재 도메인 기반의 도메인 포함 또는 제외 기법을 PA API에서 사용할 수 있습니다. 자세한 내용은 IAB Tech Lab의 개인 정보 보호 샌드박스 보고서에 대한 Google의 응답에서 확인할 수 있습니다.
IG 소유자 및 입찰 로직 URL의 동일 출처 제한	동일한 출처 요구사항이 적용되면 IG 소유자의 엔드포인트가 동일한 부하 분산기를 거쳐야 하므로 리디렉션이 거부될 수 있습니다.	스크립트 로드의 동일 출처 요구사항은 중요한 보안 보호 조치입니다. 여기에서 생태계 의견과 기타 고려사항의 균형을 맞추는 제안된 해결 방법에 관한 세부정보를 확인하세요.
다중 슬롯 비공개 입찰	노이즈를 사용하고 광고의 현재 관행과 더 긴밀하게 통합하여 개인 정보 보호 범위 내에서 멀티 슬롯 비공개 입찰을 허용할 여지가 많습니다.	Google은 이 의견을 고려하고 있으며, 이 기능과 관련된 복잡성 증가 및 개인 정보 보호 위험에 대비하여 다중 태그 입찰 요청을 평가하고 있습니다. 이 문제는 여기에서 PA API 웹 인큐베이터 커뮤니티 그룹 (WICG) 회의에서 자세히 논의되었습니다.
최상위 판매자	PA API의 현재 구조는 게시자 또는 구성요소 판매자보다 노출의 상대적 가치에 관한 훨씬 더 많은 데이터와 이해를 모든 최상위 판매자에게 제공합니다.	복수 판매자 입찰에서는 각 판매자가 최고 입찰가를 제시합니다. 또한 Google은 생태계에서 게시자가 협력하는 각 판매자의 최고 입찰가 외에 직접 판매된 수요도 고려할 수 있다는 사실을 알게 되었습니다. 게재할 광고를 결정하려면 이러한 잠재적인 수익 창출 기회를 모두 살펴봐야 합니다. 게재할 광고를 선택하기 위해 일부 행위자가 전체 옵션을 확인해야 하는 이 상황은 PA API 이전부터 존재했습니다. PA API는 다중 판매자 입찰과 게시자가 직접 판매된 광고 캠페인(해당하는 경우) 옆에 각 판매자의 최고 입찰가를 고려하려는 의도를 지원하는 것을 목표로 합니다. 즉, 현재와 같이 이러한 수익 창출 기회 중에서 선택할 수 있는 메커니즘이 필요합니다. 게재할 광고를 선택하는 것은 브라우저의 역할이 아니라고 생각했습니다. 따라서 다양한 가능성 중에서 낙찰 광고를 선택하려면 최상위 판매자라는 개념이 필요합니다. 이 최상위 판매자의 로직은 게시자가 협력하기로 선택한 각 판매자의 최적 입찰가를 고려할 수 있어야 합니다. 판매자의 로직에 따라 해당 정보가 제공되는 경우 게시자의 직접 판매 캠페인에 대한 정보를 제공할 수도 있습니다. 이러한 모든 정보는 최상위 광고 선택 로직에서 고려될 수 있습니다. 즉, 최상위 로직은 PA API 입찰에서 가장 높은 입찰가를 확인하고, 해당하는 경우 게시자의 직접 판매 광고 옵션을 확인하여 낙찰자를 결정합니다. Google Ad Manager는 이 보고서의 '정보 액세스' 테마에서 PA API를 최상위 판매자로 구현하는 방법을 자세히 설명합니다.
경쟁 광고 구분	경쟁 브랜드의 광고가 나란히 게재되지 않도록 하는 등 경쟁 광고 분리를 요청합니다.	오늘날의 프로그래매틱, 입찰, 다중 판매자 디지털 광고 생태계에서 경쟁적 분리를 보장하는 방법을 알 수 없습니다. 그러나 PA API를 사용하면 판매자가 광고 소재 점수를 매길 때 scoreAd() 중에 사용할 수 있는 renderURL과 호스트 이름(게시자 도메인을 나타냄) 조합을 기반으로 실시간 신호를 추가로 가져올 수 있습니다. 게시자가 이 규칙을 시행하려는 경우 판매자는 경쟁 브랜드의 광고가 나란히 게재되지 않도록 하는 데 이 속성을 사용할 수 있습니다.
제한된 정보	PA API는 광고 가치, 구성요소 구매자 이름, 광고주 이름, 방문 페이지 URL, 광고 소재 크기, 응답 시간, 입찰가, 실패한 입찰가와 같이 게시자에게 제공되는 정보를 줄입니다.	여기에서 몇 가지 해결 방법을 제안했으며 생태계의 추가 의견을 기다립니다.
이벤트 수준 보고	이벤트 수준 보고 PA API가 지원 중단된 후 게시자는 게재된 광고에 대한 충분한 정보를 얻을 수 없습니다.	Google은 이벤트 수준 보고가 지원 중단될 때 계속 지원해야 하는 다양한 보고 사용 사례를 알고 있습니다. 따라서 이벤트 수준 보고의 지원 중단 날짜를 2026년 이후로 정했습니다. 그때까지는 개인 정보를 보호하는 방식으로 정보를 얻기 위한 새로운 아이디어를 포함할 수 있는 지속 가능한 방향으로 생태계와 협력할 때 적극적인 참여를 부탁드립니다.
여러 SSP	게시자에게는 여러 SSP를 사용하는 것에서 얻을 수 있는 부가가치가 너무 낮습니다.	Google은 이 주장이 올바르지 않다고 생각하며, 이 주장의 근거를 파악하기 위해 생태계의 추가 의견을 환영합니다.
선별 활동	PA API로는 선별 활동을 할 수 없습니다.	판매자가 PA API를 사용하여 웹 전반에서 구매자에게 잠재고객 정보를 제공하는 기능 (잠재고객 확장이라고도 함)에 대한 의견이 있었습니다. 오늘날에는 비즈니스 계약과 함께 PA의 위임 기능을 사용하여 이를 실현할 수 있다고 생각합니다. 동시에 이러한 유형의 사용 사례를 더 효과적으로 수용할 수 있는지, 어떻게 수용할 수 있는지 적극적으로 고려하고 있습니다.
구매자 선택 해제	구매자 기본 선택 해제하면 구성요소 입찰의 결과가 낮아질 수 있습니다.	단일 판매자 PA 입찰을 정의하든 다중 판매자 PA 입찰을 정의하든 판매자는 AuctionConfig의 interestGroupBuyers 필드에 구매자를 명시적으로 나열해야 합니다. 이는 판매자가 일부 구매자와 계약을 맺고 다른 구매자와는 계약을 맺지 않았으므로 입찰에 포함할 구매자를 명시적으로 관리해야 한다는 생태계의 의견을 바탕으로 합니다. GitHub에서 추가 논의를 환영합니다.
Adsize	adsize 및 adSlotSize를 기반으로 사전 필터링을 실행할 수 없습니다.	이 기능을 추가하기 위해 노력하고 있으며 자세한 내용은 여기에서 확인하실 수 있습니다.
제외 IG 타겟팅 지원	제외 IG 타겟팅을 지원하는 API: 사용자가 IG에 속하지 않는 경우에만 광고를 게재합니다.	이 GitHub 문제에서는 브라우저가 광고 서버에 특정 광고 요청에 적용해야 하는 제외 타겟팅 규칙을 직접 알려주는 제외 타겟팅을 구현하는 대체 방법을 제안했습니다. 이는 매력적인 접근 방식으로 보이지만 조사한 이 아이디어의 모든 버전은 서버가 사용자를 고유하게 식별할 수 있도록 하는 것으로 나타났습니다.
디지털 서비스법	게시자가 펜스 프레임을 사용하면서도 디지털 서비스법의 적용을 받는 정보가 포함된 응답이 렌더링되지 않도록 하려면 어떻게 해야 하나요?	다른 신기술과 마찬가지로 각 회사는 개인 정보 보호 샌드박스를 사용하는 것이 법규를 준수하는지 확인할 책임이 있습니다. Google은 다른 회사에 법적 조언을 제공할 수 없습니다. Google에서는 각 API에 대해 광범위한 기술 문서를 게시했으며, 이 문서는 필요한 법적 평가를 위한 기반을 제공합니다. 펜싱된 프레임은 2026년 이전에는 PA API에서 사용할 필요가 없으므로 이해관계자는 이 기술을 사용할 때 모든 관련 법규를 준수하는지 확인할 수 있는 추가 시간을 확보할 수 있습니다.
문서	updateAdInterestGroups()는 일시적인가요?	updateAdInterestGroup 지원 중단 계획은 발표되지 않았습니다. 향후 Google은 다른 IG 업데이트 메커니즘에 대해 공개적으로 언급한 것과 유사한 개인 정보 보호 조치를 적용할 수 있습니다(예: IP 주소를 프록시로 사용하고 업데이트가 실행되기 전에 약간의 지연을 추가하는 경우).
DSP가 아닌 매입 측 메타데이터 및 로직 소유권 지원	DSP의 프록시 역할을 하는 방법을 요청합니다.	Google은 DSP 외 부문에서 제기된 이 의견을 인지하고 있으며 이 요청을 검토하고 있습니다. 생태계의 추가 의견을 기다리고 있습니다.
보고	비공개 집계 보고에서 신호 버킷 / 값에 맞춤 핸들러 기능을 추가해 달라는 요청	YouTube는 이 기능 요청을 인지하고 있으며 추가 검토를 위해 대기열에 추가했습니다. 여기에서 생태계의 추가 의견을 보내주세요.
문서	광고주와 (위임된) 소유자 도메인에서 설정해야 하는 모든 응답 헤더를 볼 수 있는 링크가 있나요?	Google은 이를 명확히 설명하기 위해 문서를 업데이트할 계획이며 생태계의 추가 의견을 환영합니다.
멀티 타워 입찰	PA API 컨텍스트에서 멀티 타워 접근 방식이 구현되는 방식에 관한 아키텍처 / 블록 다이어그램을 통해 워크플로 (학습 및 추론)에 대한 설명을 요청합니다.	의견을 주셔서 감사합니다. 이 주제에 관한 몇 가지 프레젠테이션이 있으며, 이를 바탕으로 추가 문서를 작성할 예정입니다.
제외 타겟팅	개인 정보 보호 샌드박스의 기능으로 민감한 잠재고객과 미성년자를 도박과 같은 부적절한 광고로부터 보호할 수 있습니다.	PA API는 표시된 광고의 콘텐츠를 고려하지 않습니다. 이는 PA를 사용하는 광고 기술 개발자가 관리합니다. 일반적으로 게시자와 광고 기술 제공업체는 페이지의 문맥 정보와 게시자 규칙 세트를 사용하여 Protected Audience 입찰 내에서 광고 소재를 차단할 수 있습니다. 이는 오늘날 이러한 문제에 대한 생태계의 접근 방식에 대한 Google의 이해를 반영합니다. 구매자의 경우 일부 규정 준수 사용 사례에 IG 제외 타겟팅 기능이 유용할 수도 있습니다.
API 설계	Google은 이를 거부하고 있으며 광고 기술이 허용되는 여러 IG에서 서로 다른 biddingLogicURL이 아닌 유니버설 입찰 기능을 사용하여 지연 시간을 늘리기를 원합니다.	입찰 지연 시간에 관해 논의하는 과정에서 구매자의 모든 IG에서 동일한 스크립트를 재사용하면 구매자의 입찰이 더 빨리 실행된다는 점을 강조했습니다. PA API 입찰 지연 시간을 개선하기 위한 다른 권장사항과 함께 자세한 내용은 여기를 참고하세요.
계정 기반 마케팅	PA API는 계정 기반 마케팅 사용 사례에 적합한 API가 아닙니다.	불가능하다고 생각되는 특정 사용 사례에 관한 생태계의 의견을 환영하며 생태계 참여자는 공개 GitHub 저장소 또는 주간 통화를 통해 이 논의를 계속 이어나가시기 바랍니다.
A/B 테스트	게시자를 위해 GAM에서 PA API가 구성된 경우 현재 모든 인벤토리 또는 인벤토리 중 하나에 대해 사용 설정해야 합니다. 따라서 게시자가 실행할 수 있는 실용적인 A/B 테스트의 범위가 제한됩니다.	Google Ad Manager에서 제공한 응답: Google Ad Manager (GAM) 내의 PA API 제어는 API를 사용할 수 있는 경우 GAM의 API 사용 능력에 영향을 미칩니다. 따라서 게시자는 Chrome의 권한 정책 기능을 사용하여 A/B 테스트의 대조군으로 사용할 트래픽 하위 집합에서 API 사용을 사용 중지하여 A/B 테스트를 실행할 수 있습니다.
머신러닝	게시자는 GAM에서 제안하는 머신러닝 사용에 대해 더 많은 제어 권한을 가져야 합니다.	Google Ad Manager의 답변: 2024년 1월, Google은 게시자가 머신러닝 제한 기능을 사용 중지하고 모든 트래픽에서 Google 이외의 판매자를 대상으로 PA API 입찰을 사용 설정할 수 있는 관리 기능을 출시했습니다. 이 관리 기능에 대한 자세한 내용은 고객센터를 참고하세요.
(이전 분기에도 보고됨) 최상위 입찰	GAM에 최상위 PA API 입찰을 제어할 권한을 부여하지 않고도 Google의 게시자 광고 서버를 사용할 수 있습니다.	Google Ad Manager에서 제공한 응답: Google의 2023년 3분기 보고서에 설명된 이유로 GAM의 PA API 통합 계획에는 최상위 입찰을 제어하지 않고 GAM을 게시자 광고 서버로 사용하는 게시자를 지원하는 내용이 포함되어 있지 않습니다.
정보에 대한 액세스	GAM은 문맥 입찰가, 구매자가 PA API 입찰을 위해 SSP에 제공한 신호, SSP의 구성 매개변수 등 경쟁업체의 가치 있는 정보에 액세스할 수 있습니다.	Google Ad Manager의 답변: Google은 오랜 기간 입찰의 공정성에 중점을 두고 있으며, 그중 하나로 미보장 광고 항목 가격을 포함하여 게시자의 미보장 광고 소스에서 제공하는 가격은 입찰에 참여하기 전에 다른 구매자와 공유하지 않겠다는 약속을 지키고 있습니다. 이 약속은 나중에 프랑스 경쟁 당국에 대한 Google의 약속에서 재확인되었습니다. PA API 입찰의 경우 Google은 약속을 지키고 복수 판매자 입찰에서 입찰이 완료되기 전에 입찰 참여자의 입찰가를 다른 입찰 참여자와 공유하지 않을 계획입니다. 명확히 말씀드리자면, 이 업데이트에 설명된 대로 Google은 Google의 입찰을 포함한 어떠한 구성요소 입찰에도 문맥 입찰의 가격을 공유하지 않습니다. 또한 Google은 구매자가 SSP에 제공하는 신호를 비롯한 구성요소 입찰 구성에 관한 정보를 자체 입찰의 일부로 사용하지 않습니다. 실제로 Google은 구성요소 판매자가 최상위 판매자로부터 난독화된 방식으로 구성요소 입찰 구성을 지정할 수 있도록 PA API를 변경하는 것을 환영합니다.
구성요소 입찰	최상위 입찰인 GAM은 각 광고 기회에 대해 구성요소 입찰을 실행하는 SSP를 제어합니다.	Google Ad Manager에서 제공하는 응답: 게시자 광고 서버인 GAM은 게시자가 Google 게시자 태그 (GPT) API를 통해 구성요소 입찰 구성을 지정하는 데 사용할 수 있는 SSP용 경량 API를 제공합니다. 자세한 내용은 여기에서 확인하실 수 있습니다. SSP가 이 API를 통해 구성요소 입찰 구성을 제공하는 경우 해당 광고 기회의 구성요소 입찰 목록에 포함됩니다. GAM은 포함된 구성요소 입찰에 제한을 적용하지 않습니다. 구성요소 입찰을 실행하려는 SSP는 게시자가 게시자 페이지에서 필요한 코드를 실행하도록 허용한 경우 이를 실행할 수 있습니다.
구성요소 입찰	GAM은 각 구성요소 입찰 낙찰가에 구체적이고 비공개된 가격 하한선을 적용할 수 있습니다.	Google Ad Manager의 응답: GAM은 수년간 입찰의 공정성에 중점을 두고 노력해 왔습니다. Google에서는 공정하고 투명한 입찰을 유지하기 위해 특정 수요 세그먼트에만 적용되는 가격 하한선을 지원하지 않습니다. 이는 Google 제품의 일관된 원칙이며 PA API 입찰에도 계속 적용될 것입니다.
서드 파티 광고 서버	서드 파티 광고 서버는 상위 수준 입찰에 참여하는 Google에 액세스할 수 없으므로 PA API 맥락에서 Google SSP 수요의 혜택을 누릴 수 없습니다.	Google Ad Manager에서 제공한 응답: 현재 GAM은 여기에 설명된 API를 통해 GAM에서 여러 판매자를 대상으로 PA API 테스트를 지원합니다. 현재 다른 최상위 입찰에서 GAM이 구성요소 입찰로 참여하는 것은 지원되지 않습니다.
(이전 분기에도 보고됨) PA API 입찰 실적	PA API 입찰의 지연 시간이 길다는 테스터의 신고가 접수되고 있습니다.	지연 시간에 대한 우려가 제기되어 Google에서는 PA API의 일부로 SSP가 DSP 지연 시간에 한도를 설정하고 지연 시간을 줄일 수 있는 개선사항을 적용할 수 있는 여러 기능을 개발했습니다. 이러한 기능을 활용하는 방법에 관한 자세한 내용이 포함된 지연 시간 권장사항 가이드가 최근 업데이트되었습니다. 또한 새로운 지연 시간 개선사항을 지속적으로 개발하고 있으며, 그중 일부는 여기에서 확인할 수 있습니다.
(이전 분기에도 신고됨) 동영상 렌더링	PA API 및 펜스 처리된 프레임을 사용한 동영상 렌더링 지원	1월에 Google은 PA 입찰에서 인스트림 동영상이 작동하는 방식을 보여주는 데모를 게시하고 대체 접근 방식에 관한 추가 세부정보를 제공했습니다. 또한 생태계 참여자가 동영상 호환 renderURL 생성에 관한 GAM의 제안이나 전체 E2E 프로세스와 같이 생태계와 통합하는 파트너를 위해 동영상 렌더링이 작동하는 방식을 제안하기 시작했습니다. 또한 YouTube는 채택률을 높이기 위해 취할 수 있는 변경사항에 관한 생태계의 의견을 수렴하고 있으며, 이러한 변경사항 중 하나는 GitHub에 자세히 설명되어 있습니다. YouTube는 생태계와 지속적으로 적극적으로 협력하여 채택에 장애가 될 수 있는 다른 요소를 파악하고 적시에 해결하고자 합니다.
(이전 분기에도 보고됨) 데이터 처리 정책	IG / PA API의 데이터 처리 정책은 무엇인가요?	PA API 설계에서 인스타그램에 저장되거나 인스타그램에 있는 사용자에 관한 모든 데이터는 (i) 기기에 남아 있거나 (ii) 신뢰할 수 있는 실행 환경(TEE) 내에서 실행되는 입찰 서비스에서 처리됩니다. 두 경우 모두 다른 당사자가 데이터를 읽거나 입찰에서 입찰가를 생성하는 것 이외의 방식으로 데이터를 사용할 수 없습니다. 일부 Chrome에서 모색 중인 개인 정보 보호 개선사항에는 Google에서 운영하는 k-익명성 서버와의 상호작용이 포함됩니다. 이러한 상호작용은 사용자 정보를 공유하지 않도록 주의 깊게 설계되고 있으며, TEE에서 실행되어 광고 생태계 전반에서 정보의 동질성을 보장합니다. Google은 CMA에 Google 자체 비즈니스를 선호하여 경쟁을 왜곡하지 않는 방식으로 개인 정보 보호 샌드박스 제안을 설계하고 구현하며, 디지털 광고의 경쟁과 게시자 및 광고주에 미치는 영향을 고려하겠다고 약속했습니다. Google은 이러한 의무를 준수하기 위해 CMA와 긴밀하게 협력하고 있습니다.
(이전 분기에도 보고됨) IG 전체 기간	IG의 수명을 30일에서 90일로 연장해 달라고 요청합니다.	이러한 변경사항을 적용하려면 업계에 미치는 이점과 Chrome 사용자 및 기타 이해관계자에 미치는 영향을 신중하게 평가해야 합니다. YouTube에서는 이 요청을 검토 중이며 여기에서 추가 의견을 보내주시기 바랍니다.
(이전 분기에도 보고됨) modelingSignals	디스플레이 및 클릭 정보를 인코딩할 수 있는 modelingSignals 외에도 새 필드를 요청합니다.	여기에서 반론 제안을 통해 이 의견에 응답했습니다. Google은 업계와 적극적으로 소통하여 Google의 제안에 대한 업계의 의견을 파악하고 있으며 현재 업계에 미치는 이점과 Chrome 사용자 및 기타 이해관계자에 미치는 영향을 고려하고 있습니다.
reportWin()의 추가 비트	3PCD 이전의 현재 한도인 12에서 reportWin()에 추가 비트를 제공합니다.	현재 이 사용 사례를 지원하기 위한 접근 방식을 모색하고 있습니다. 장기적인 개인 정보 보호 계획을 수립하는 데 도움이 되는 접근 방식을 모색하고 있기 때문에 시간이 다소 걸리고 있습니다.
입찰 설계	렌더링 URL과 해당 점수를 반환하는 단일 입찰 요청입니다.	단일 PA 입찰에서 여러 개의 renderURL과 각 점수를 공유하는 것은 고려되었지만 개인 정보 보호 문제로 인해 구현되지 않았습니다. Google은 단일 페이지에서 사용자에게 동일한 광고를 여러 번 표시하지 않으려는 의도를 이해하며 GitHub에서 추가 논의를 환영합니다.
reportWin	reportWin() 함수에서 임의 필드를 로깅합니다.	이는 현재 테스트 기간 동안 이미 적용되고 있습니다. Chrome에서 3PC 지원이 종료되면 forDebuggingOnly 버전의 API가 다운샘플링 디버깅을 사용 설정하도록 이전합니다. 다운샘플링 디버깅은 여기에 지정되어 있습니다.
구성요소 판매자	자체 노출 및 기타 이벤트를 집계하는 독립적인 메커니즘이 있어야 하며 광고 기술의 보고서에만 의존할 필요가 없습니다.	이 기능 요청은 추가 검토를 위해 대기열에 있습니다. Chrome을 통한 테스트 기간에는 이 문제가 해결되지 않을 것으로 예상됩니다.
클릭당비용 결제	PA API에 클릭당비용 결제를 구현합니다.	Google은 여기에서 이 요청을 검토하고 있으며 현재 이 요청을 현재 API 노출 영역으로 구현하는 방법에 관한 제안 요청으로 보고 있습니다.
browserSignals	판매자의 browserSignals 보고 사양에 incomingBidInSellerCurrency를 추가합니다.	YouTube에서는 이 요청을 검토 중이며 여기에서 추가 의견을 보내주시기 바랍니다.
DSP가 아닌 애드테크의 구매 측 메타데이터 및 로직 소유권 지원	현재 API 설계로 인해 제품 수준의 리타겟팅 캠페인에 큰 변화가 있을 수 있으며, 이 경우 캠페인을 DSP 및 DCO 제공업체 역할을 모두 하는 플랫폼으로 이전해야 할 수 있습니다.	이 문제를 논의 중이며 여기 에서 추가 의견을 보내주세요.
DSP가 아닌 애드테크의 구매 측 메타데이터 및 로직 소유권 지원	DSP가 IG 소유자가 아닌 예시를 공유합니다.	입찰자가 아닌 사용자는 일부 IG 기능만 활용하고 싶어 한다는 점을 잘 알고 있습니다. YouTube는 이러한 사용 사례를 해결하기 위한 옵션을 적극적으로 평가하고 있으며 여기에서 추가 의견을 보내 주시기 바랍니다.
시간 제한 컨트롤	게시자는 참여할 수 있는 IG의 수와 최상위 시간 제한 / 전체 시간 제한을 지정할 수 있어야 합니다.	최상위 판매자와 구성요소 판매자 간의 제한 시간 제어 및 가시성을 개선하고자 하는 요청이 있으며 Google은 이 요청을 고려하고 있습니다.
여러 광고 크기	PA API에서 여러 광고 크기 사용 사례를 지원합니다.	Google은 이 요청을 검토 중이며 생태계의 추가 의견을 기다리고 있습니다.
문서	K-anon의 적용을 받는 IG 속성 목록이 있나요?	이 질문에 대한 답변은 여기에서 확인하실 수 있습니다.
디버깅	PA API의 디버깅 기능이 개선되었습니다.	Google은 PA API를 사용하는 개발자에게 강력한 디버깅 도구가 얼마나 중요한지 잘 알고 있습니다. Google은 .well-known 파일 가져오기를 개발자 도구와 더 효과적으로 통합하는 방법을 모색하여 개발자 환경을 개선하기 위해 노력하고 있습니다. Google의 목표는 개발 환경 내에서 가시성과 문제 해결 기능을 개선하는 것입니다. 이 문제에 대한 자세한 내용은 여기에서 확인하실 수 있으며 추가 의견을 보내주세요.
라벨	모드 B 처리 라벨의 모든 사용자에게 개인 정보 보호 샌드박스 API가 사용 설정되어 있나요?	Chrome 실험 그룹 할당은 무작위로 결정되며 사용자 구성 Chrome 설정과는 무관합니다. 이러한 API는 특정 처리 그룹 (예: treatment_1.*) 내의 사용자가 사용할 수 있지만 Chrome 설정을 통해 기능을 수정하거나 사용 중지할 수 있습니다. 모드 B control_2 그룹: 이 그룹에 포함되면 개인 정보 보호 샌드박스 관련성 및 측정 API가 기본적으로 사용 중지되며 사용자는 Chrome 설정에서 이 설정을 재정의할 수 없습니다.
API 사용량	reportWin() 호출과 광고 렌더링이 동시에 이루어지나요, 아니면 차례로 이루어지나요?	reportWin()은 runAdAuction()이 완료된 직후에 호출됩니다. 동시에 입찰 결과가 iframe 또는 펜스 프레임 내에 배치되면 광고 렌더링 프로세스가 시작될 수 있습니다. reportWin() 실행이 완료되고 광고 렌더링이 시작되면 sendReportTo()에 제공된 URL이 가져옵니다.
(이전 분기에도 보고됨) A/B 테스트 지원	PA API A/B 테스트 지원을 요청합니다.	여기에서 이 요청에 대해 논의하고 있으며 추가 의견을 보내주세요.
트래픽 형성	KV 서버를 통해 필요한 의사결정을 관리하자는 Google의 제안은 판매자가 백엔드와 상호작용할 수 없어 트래픽 형성에 어려움이 있으므로 도움이 되지 않습니다.	GitHub 문제에서 논의한 바와 같이 개별 DSP에 IG가 있는지 여부를 노출하면 사용자 지문 식별 문제가 발생할 수 있습니다. 이 문제에 대해 다른 대안을 제안했으며 추가 제안도 환영합니다.
트래픽 형성	캐싱 메커니즘은 상당한 복잡성을 추가하고 DSP가 입찰할 트래픽의 실제 형상을 알 수 없게 합니다.	캐싱 메커니즘은 단지 제안으로 제공되었습니다. 애드테크는 사용 사례에 적합한 추천을 선택할 수 있으며 여기에서 추가 논의를 환영합니다.
라벨	Chrome은 구매자 및 판매자 신뢰할 수 있는 서버에 대한 요청에서 라벨을 매개변수로 공유해야 합니다.	이는 책임감 있는 IG 데이터 활용이라는 목표와 대체로 일치하는 것으로 보이며 합리적인 요청으로 보입니다. 하지만 YouTube는 내부 검토를 거쳐 요청을 검토 중이며 논의가 진행되는 대로 이 문제에 대한 공개 업데이트를 제공할 예정입니다.
API 사용량	'테스트에 관한 서드 파티를 위한 추가 CMA 가이드' 문서에서 'control_1' 그룹의 명시적 정의를 명확히 했습니다. 특히 문구 변경으로 인해 control_1에서 모든 개인 정보 보호 샌드박스 API를 제외해야 한다는 오해의 소지가 있습니다.	이에 대한 Google의 견해는 이 GitHub 대화목록에 설명되어 있습니다. 하지만 YouTube는 CMA를 대변할 수 없으며 테스트 가이드의 해석과 관련된 문제는 CMA에 직접 문의하시기 바랍니다.
API 사용량	Chrome은 다른 리소스로 리디렉션하는 동안 빈 페이지에서 joinAdInterestGroup()을 호출하도록 허용하나요?	사용자가 사이트를 방문하는 경우 사이트 소유자는 joinAdInterestGroup을 호출하는 기능을 서드 파티에 위임할 수 있습니다. 이 위임을 사용하면 서드 파티가 빈 페이지를 통해 어떠한 종류의 리디렉션도 추가하지 않고도 IG를 빌드할 수 있습니다. 의도된 위임 메커니즘을 사용하는 대신 리디렉션 중간에 IG를 빌드하는 구체적인 이유에 관한 의견을 보내주세요.
API 사용량	거래소는 협력하는 게시자가 소유한 페이지에 IG를 작성할 수 있어야 하며, 그런 다음 해당 IG에 입찰할 권한을 특정 구매자 또는 DSP에 위임할 수 있어야 합니다.	의견을 접수했으며 이러한 요청을 지원할 수 있는지 평가하고 있습니다. 생태계의 추가 의견을 기다리고 있습니다.
API 사용량	PA API 입찰에서 낙찰자가 없으면 디버깅 손실 알림이 전송되지 않습니다.	Chrome의 reportWin 및 reportResult 함수는 개인 정보 보호 입찰 (PA) 시스템 내에서 이벤트 수준 낙찰 보고를 위해 설계되었습니다. PA 입찰 중에 모든 입찰이 거부되는 경우 낙찰자가 결정되지 않으므로 이러한 함수가 호출되지 않을 것으로 예상됩니다. 최근 Chrome 업데이트로 인해 forDebuggingOnly.reportAdAuctionLoss()에 전달된 URL이 DevTools 네트워크 패널에 표시되지 않는 불일치가 발생할 수 있습니다. Chrome의 Canary 또는 개발자 채널 빌드를 사용하여 이 기능을 확인하는 것이 좋습니다.
API 사용량	generateBid에서 반환된 adCost가 음수일 수 있나요 (이미 확률적으로 2바이트로 반올림됨)?	AdCost는 generateBid()에서 reportWin()으로 전달되는 광고주의 클릭 또는 전환 비용입니다. 이 값은 Null 또는 double일 수 있습니다. 음수 값은 무시되고 전달되지 않습니다. 값은 전달될 때 확률적으로 반올림됩니다.
API 개선	신뢰할 수 있고 암호화된 실행 서버를 Chrome 브라우저 대신 타겟팅 / 사용자 집단 / 기여 분석 및 입찰을 처리하는 데 사용할 수 있나요?	PA API의 TEE 기반 구성요소 및 옵션 (예: KV 서버 및 B&A 서비스)과 이 문제를 해결하는 기여 분석 및 비공개 집계의 TEE 기반 구성요소 (예: 집계 서비스)를 살펴보는 것이 좋습니다.
API 개선	개인 정보 보호 샌드박스 입찰 응답이 광고 응답 (예: 광고 태그)이 아닌 입찰 응답 (예: 헤더 입찰)일 수 있나요?	이러한 유형의 변경사항은 PA API의 개인 정보 보호 속성을 근본적으로 변경하므로 고려하지 않고 있습니다.
게시자 관리 기능	게시자는 페이지에서 PA API 광고 소재를 차단할 수 있나요?	Chrome에는 실시간 광고 소재 검사에 대한 제안서가 있지만 아직 테스트할 수 없습니다. 아직 사용할 수는 없지만 대부분의 SSP에서 이를 지원하는 솔루션을 만들었습니다.
API 사용량	perBuyerSignals의 크기 제한은 얼마인가요?	기존 형식의 perBuyerSignals에는 Chrome 내에서 고유한 크기 제한이 없습니다. 기본 제약 조건은 데이터가 JSON 직렬화 가능 상태로 유지되고 과도한 메모리 소비를 일으키지 않는다는 것입니다. 그러나 매우 크고 복잡한 perBuyerSignals는 성능에 부정적인 영향을 미칠 수 있습니다. directFromSellerSignalsHeaderAdSlot을 통해 perBuyerSignals를 전달하는 대체 방법이 있습니다. 이 접근 방식은 전체 헤더 응답의 최대 크기 제한인 10KB에 따라 헤더 내에서 perBuyerSignals를 전송합니다. 또한 개별 서버에서 최대 헤더 크기에 자체 제한을 적용할 수 있습니다.
문서	generateBid 내부에서 registerAdBeacon을 호출하는 방법에 관한 문서를 변경해야 합니다.	2월 17일에 이 문서 를 업데이트했습니다.
API 사용량	reportEvent는 등록된 여러 옵션 중에서 올바른 비콘 URL을 선택하는 방법은 무엇인가요?	각 입찰은 별도의 구성으로 이어지고, 이는 별도의 보고 맵으로 이어집니다. 개별 입찰 (및 그 결과 프레임)은 서로 완전히 분리되어 있으며 데이터를 공유하지 않습니다. '울타리 프레임 광고 보고' 설명에서는 이 주제에 관한 자세한 내용을 제공합니다.
Chrome UI	Chrome DevTools의 '애플리케이션 -> '관심분야 그룹' 탭에 필터를 추가하여 IG 소유자 (또는 IG 이름)를 기준으로 필터링할 수 있도록 합니다.	Google은 이 요청을 평가하고 있으며 생태계의 추가 의견을 기다리고 있습니다.
헤드리스 Chrome	헤드리스 Chrome에서 PA API 지원	Chrome에 연결된 PA API의 일부 구성요소(예: Google 서버에 대한 k-anon 호출)는 '이전' Headless Chrome에서 작동하지 않을 수 있습니다. Chrome 112에서 출시된 '새' 버전의 Headless Chrome으로 이 문제가 해결될 수 있습니다.
API 사용량	reportAdAuctionLoss를 사용한 손실 보고의 경우 대부분의 경우 'topLevelWinningBid=0'이 표시됩니다. 이 결과를 어떻게 해석해야 하나요?	topLevelWinningBid 값은 최상위 판매자 구성요소 내의 scoreAd() 함수에서 가져옵니다. 이 값은 최상위 입찰의 결과를 결정하는 데 중요한 역할을 합니다. 설명서에 따라 topLevelWinningBid 값이 0 또는 음수이면 해당 광고가 입찰에서 낙찰될 자격이 없음을 나타냅니다. 예를 들어 이 메커니즘은 문맥 타겟팅 후보를 초과하지 않는 관심분야 그룹 타겟팅 광고를 필터링하는 데 사용할 수 있습니다. topLevelWinningBid 값이 0이면 문맥 입찰이 우선 적용되었음을 나타낼 수 있지만 PA API 사양에서는 다른 요소가 이 결과에 기여할 수 있음을 인정합니다.
모드 A/B 테스트	모드 B 및 모드 A 트래픽 선택 및 선택 해제 메시지에 관한 설명	모드 A와 모드 B의 포함 기준은 동일합니다. 목표는 개인 정보 보호 샌드박스 API와 라벨 지정 방법을 지원하는 한 일반 Chrome 트래픽을 대표하는 그룹을 만드는 것입니다. 일부 클라이언트 구성은 호환되지 않기 때문입니다. 실험을 위해 라벨이 지정된 트래픽만 다른 라벨이 지정된 트래픽과 비교하는 것이 중요합니다. 모드 B의 사용자는 추적 보호 기능을 사용 설정했기 때문에 이 기능에 관한 알림을 받습니다.
API 개선	'lifetimeMs'를 joinAdInterestGroup 호출 내에 직접 속성으로 포함하거나 별도의 인수로 관리할 수 있나요?	Google은 PA API 제안서 내의 'joinAdInterestGroup' 기능과 관련하여 웹 개발 커뮤니티의 의견을 신중하게 고려하고 있습니다. 주요 논의 주제는 IG 수명을 관리하는 최적의 방법에 중점을 둡니다. 향후 사양을 개선할 때 유연성과 적응성을 높이는 데 도움이 되므로 'lifetimeMs' 매개변수에 별도의 인수를 사용하는 것이 유리한지 평가하고 있습니다. 여기에서 이 문제에 대해 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	엔트로피가 낮은 브라우저 ID와의 충돌로 인해 PA API 프레임워크에서 거짓 음성률이 증가할 수 있습니다.	Chrome팀은 PA API 프레임워크를 지속적으로 개선하기 위해 노력하고 있습니다. 브라우저 ID 충돌로 인해 발생할 수 있는 거짓음성 비율에 관한 논의를 진행해 주셔서 감사합니다. Google은 이 의견을 신중하게 평가하고 업데이트된 분석에 모든 관련 요소를 포괄적으로 반영하기 위해 노력할 것입니다. Google은 정확성과 안정성을 유지하면서 원하는 개인 정보 보호 결과를 달성하는 솔루션을 제공하기 위해 최선을 다하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	클라이언트가 k-익명 시스템에서 동일한 객체에 대한 'Join' 요청을 반복적으로 제출하지 못하도록 하려면 엔트로피가 낮은 브라우저 식별자가 필요한가요?	Google은 k-익명 시스템 구현 시 브라우저 식별자 사용에 관한 논의를 인지하고 있으며 이에 감사드립니다. Google은 이러한 식별자의 잠재적인 개인 정보 보호 관련 문제에 대해 우려하는 점을 잘 알고 있습니다. Google의 초기 구현에서는 악용 방지 메커니즘으로 엔트로피가 낮은 식별자를 사용했지만, Google은 시스템의 무결성을 유지하면서 사용자 개인 정보 보호를 우선시하는 대체 기술(예: 익명 집계 토큰)을 적극적으로 모색하고 있습니다. Google은 책임감 있는 데이터 사용과 강력한 개인 정보 보호 간의 균형을 맞출 수 있는 솔루션을 찾기 위해 노력하고 있으며 연구 커뮤니티와의 지속적인 대화를 환영합니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	AMP (Accelerated Mobile Pages)가 PA API를 지원하나요?	AMP는 현재 PA API를 기본적으로 지원하지 않습니다. AMP 지원이 중요한 경우 생태계의 추가 의견을 기다립니다.
API 개선	K-익명성 검사에서 유형을 삭제해 보세요.	Google은 k-익명성 요청 구조를 최적화할 수 있는 가능성에 관한 의견을 신중하게 고려하고 있습니다. Google은 매개변수를 통합하고 유형을 통일하여 절차를 간소화할 수 있다는 제안을 이해합니다. Google의 목표는 효율성과 유지보수성을 보장하는 것이며, Google은 개인 정보 보호 솔루션을 지속적으로 개발하면서 모든 옵션을 평가하고 있습니다. 여기에서 이 문제에 대해 논의하고 있으며 추가 의견을 환영합니다.
Chrome UI	기술에 능숙하지 않은 사용자가 가입한 IG를 쉽게 보고 관리할 수 있는 메커니즘을 요청합니다(예: 선택 해제할 수 있는 잠재적인 웹사이트 수준 관리 기능).	Google은 IG를 이해하고 관리하기 위한 사용자 친화적인 도구를 제공하는 것이 중요하다는 점을 잘 알고 있습니다. YouTube는 다양한 방법을 신중하게 고려한 결과, 가입한 웹사이트를 기준으로 IG를 식별하는 것이 명확성과 개인 정보 보호 간의 균형을 가장 잘 맞출 수 있다고 판단했습니다. 현재 IG의 전 세계 관리는 Chrome 설정에 있습니다. YouTube는 이 분야의 사용자 환경을 더욱 개선할 방법을 지속적으로 모색하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 안전	PA API는 펜싱된 프레임의 컨텍스트 내에서도 광고 소재 광고 상호작용을 통한 개인 정보 유출에 취약한가요?	Google은 정교한 광고 상호작용을 통해 정보가 유출될 수 있다는 점을 인지하고 있습니다. Google은 펜싱된 프레임, PA API, 잠재적 공격 벡터 간의 상호작용을 적극적으로 조사하고 있습니다. Google은 개인 정보 보호 위험을 완화하는 것을 최우선 과제로 삼고 있으며 혁신과 사용자 보호의 균형을 맞추는 강력한 솔루션을 개발하기 위해 최선을 다하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
지연 시간	구매자 입찰 로직의 기본 제한 시간 50ms가 현실적인 값인가요?	입찰 로직의 사양과 네트워크 요청 시점 간의 잠재적 불일치에 대한 우려사항을 확인했습니다. Google은 정확성을 보장하기 위해 사양을 적극적으로 검토하고 성능과 실현 가능성의 균형을 맞추기 위한 최적의 기본 시간 제한 설정을 조사하고 있습니다. 여기에서 이 문제에 대해 논의하고 있으며 추가 의견을 환영합니다.
문서	웹사이트에서 광고가 k-익명성 기준을 충족하지 못하는지 추론할 수 있는 사양의 잠재적 타이밍 유출 및 크로스 사이트 추적에 미칠 수 있는 잠재적 영향	Google은 시점 유출 가능성과 관련하여 제기된 문제를 인지하고 있습니다. Google은 사양의 불일치를 확인했으며 이러한 유출을 방지하기 위해 입찰 전에 광고의 k-익명성 상태가 결정되도록 조치를 취하고 있습니다. Google은 이러한 우려사항을 심각하게 받아들이며 이러한 변경사항을 반영하도록 사양을 업데이트할 예정입니다. 여기에서 이 문제에 대해 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	PA API 내에서 SSP 차단 목록을 구현하는 방법	Google은 SSP의 광고 제한을 관리하는 메커니즘의 필요성을 인식하고 있습니다. 기기 내 평가를 우선시하고 기존 광고 메타데이터를 활용하여 사용자 개인 정보를 보호하면서 유연성을 제공하는 솔루션을 모색하는 것이 좋습니다. Google은 개발자와 협력하여 PA API 내에서 최적의 접근 방식을 찾기 위해 최선을 다하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	사이트에서 감지할 수 없는 방식으로 PA API를 실행하는 것처럼 브라우저에 지시할 수 있나요?	현재의 형태로 PA API를 선택 해제하면 웹사이트에서 이를 감지할 수 있습니다. Google은 개인 정보 보호를 강화하고 감지할 수 없는 선택 해제 옵션을 제공하기 위해 추가 입찰, 제외 타겟팅, 펜싱 프레임 렌더링과 같은 기능을 적극적으로 개발하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
모드 A/B 테스트	처리 1.1인 것으로 주장하는 데이터 센터 트래픽	Chrome팀은 GAM팀으로부터 이 트래픽이 이제 실험에서 필터링되고 있다고 확인받았습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	PA API의 interestGroupBuyers 구현의 효율성과 공정성	Google은 PA API 입찰의 'interestGroupBuyers' 필드의 효율성과 공정성에 관한 논의가 진행 중임을 알고 있습니다. YouTube는 효율성, 개인 정보 보호, 시장 공정성 간의 균형을 인지하고 있습니다. 판매자는 구매자와의 비즈니스 관계를 관리해야 하지만 Google에서는 일치 프로세스를 최적화할 방법을 모색하고 있습니다. 여기에는 실시간 데이터 및 하이브리드 모델을 기반으로 하는 동적 조정이 포함될 수 있습니다. Google은 사용자 개인 정보 보호를 최우선으로 하고 경쟁력 있는 광고 생태계를 지원하는 솔루션을 찾기 위해 최선을 다하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
Chrome UI	Chrome의 IG와 관련된 잠재적인 메모리 문제 및 UI 선명도	DevTools에 IG를 표시하는 것에 대해 우려하시는 점 충분히 이해합니다. 현재 보기는 이전 추적을 위해 모든 IG 이벤트를 반영하지만 저장된 IG의 현재 상태를 더 명확하게 확인하는 것이 중요하다는 점을 알고 있습니다. 개발자 통계를 개선하기 위해 최적화 및 잠재적인 UI 개선사항을 살펴볼 예정입니다. 메모리 관리와 관련하여 IG 구현은 메모리 누수를 방지하도록 설계되었지만 리소스 사용량을 지속적으로 모니터링하고 최적화합니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
문서	원래 게시자가 'joinAdInterestGroup' 함수의 'sizeGroup' 필드 내에서 직접 이름이 지정된 광고 크기를 사용하려고 하면 오류가 발생합니다. 이는 의도된 동작인지 알고 싶어 합니다.	Google은 'joinAdInterestGroup' 함수 내에서 광고 구성을 간소화하는 것이 얼마나 중요한지 잘 알고 있습니다. 이 제한사항을 해결하기 위해 최선을 다하고 있으며 향후 업데이트에서 이 기능을 사용 설정할 계획입니다. 이번 개선사항은 개발자에게 광고 관리를 위한 유연하고 효율적인 도구를 제공하겠다는 Google의 노력의 일환입니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
Chrome을 통한 테스트 라벨	실험을 일관되게 추적할 수 있도록 sendReportTo에 모드 A와 B에 관한 직접적인 데이터와 정확한 라벨을 포함하도록 요청합니다.	여기에서 이 요청에 대해 논의하고 있으며 추가 의견을 환영합니다.
문서	판매자의 도메인 이름이 확인 목적으로 판매자의 신뢰할 수 있는 서버에 이루어진 요청에 포함되어 있나요?	Protected Audience KV Server API 문서에서 호스트 이름 매개변수가 처음 누락되었음을 확인했습니다. Google에서는 판매자의 도메인 이름이 판매자의 신뢰할 수 있는 서버에 대한 요청에 자동으로 포함되도록 개발자를 안내하고자 합니다. 이 기능은 강력한 광고 유효성 검사 프로세스에 필수적입니다. 이 누락을 해결하기 위해 문서를 업데이트했으며 앞으로도 개발자 커뮤니티를 위해 명확성과 투명성을 최우선으로 할 것입니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	보고 목적으로 광고 노출 추적 호출 내에 IG 이름을 포함하는 잠재적 방법	Google은 강력한 신고 메커니즘의 필요성과 사용자 개인 정보 보호의 기본 원칙 간의 균형을 유지하기 위해 최선을 다하고 있습니다. 광고 노출 추적에 IG 이름을 포함하는 경우 개인 식별을 방지하기 위해 고안된 k-익명성 보호 조치가 적용됩니다. Google은 이러한 개인 정보 보호 제약 조건 내에서 혁신적인 보고 솔루션을 계속 모색할 것입니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 기능	구매자 신뢰할 수 있는 서버가 클라이언트 힌트 HTTP 헤더를 수신하도록 요청합니다.	여기에서 이 기능 요청을 추적하고 있습니다.
API 사용량	위임 파일이 브라우저의 IG 멤버십 동작을 지정한다는 점을 고려할 때 로드하려면 'Access-Control-Allow-Origin' 헤더가 필요한지 여부	Google은 웹 보안 권장사항을 준수하기 위해 최선을 다하고 있습니다. 위임 파일에 'Access-Control-Allow-Origin' 헤더가 요구되므로 CORS 원칙을 준수하고 민감한 정보가 의도치 않게 노출되는 것을 방지할 수 있습니다. Google은 강력한 보안 상황을 유지하면서 이 절차를 최적화하는 방법을 모색하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	광고 서버가 PA API 프레임워크 내에서 광고 소재를 맞춤설정할 수 있도록 합니다.	Google은 광고 서버가 광고 소재 맞춤설정에 기여할 수 있는 역할을 인식하고 있습니다. Google은 입찰 및 광고 소재 선택 로직을 결합할 수 있는 '공동 IG' 모델과 같이 PA API 내에서 광고 서버를 강화하기 위한 솔루션을 적극적으로 모색하고 있습니다. Google의 목표는 강력한 광고 소재 기능을 제공하는 동시에 사용자 개인 정보를 보호하는 것입니다. 모든 이해관계자의 요구사항을 충족하도록 API를 발전시키기 위한 추가 협력과 의견은 여기에서 보내주세요.
사생활 침해 문제	대체 식별자 (예: RampID, ID5)를 사용하면 크로스 사이트 데이터 수집이 용이해져 PA API의 개인 정보 보호 목표가 저해될 수 있습니다.	Google은 교차 사이트 식별자와 PA API의 개인 정보 보호 목표 간에 잠재적인 긴장이 있음을 인지하고 있습니다. 게시자는 이러한 식별자를 공유할 수 있지만 PA API의 설계는 기본적으로 광고 선택을 교차 사이트 추적의 필요성으로부터 분리하는 것을 목표로 합니다. Google은 개인 정보 보호 중심의 광고 생태계를 조성하기 위해 노력하고 있으며 개발자는 PA API 접근 방식을 우선적으로 고려할 것을 권장합니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
캐싱	여러 입찰에서 입찰 스크립트를 재사용하지 못하도록 하는 방법이 있나요?	PA API 프레임워크 내에서 입찰 스크립트의 캐싱 동작이 관찰된 것을 확인했습니다. 표준 HTTP 캐싱 메커니즘은 지원되지만 기기 일시중지 동작과 입찰 실행자의 설계로 인해 입찰 전반에서 스크립트를 재사용할 수 있습니다. Google은 구매자가 입찰 전략을 효과적으로 관리할 수 있도록 스크립트 캐싱을 더 효과적으로 제어할 수 있는 솔루션을 모색하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	사용자 개인 정보를 존중하면서 DSP의 모든 IG에서 입찰 활동 보고를 중앙 집중화합니다.	Google은 PA API를 설계할 때 사용자 개인 정보 보호를 최우선으로 합니다. 교차 사이트 추적 위험으로 인해 개별 입찰 이벤트를 직접 보고하는 것은 불가능하지만 공유 저장소 및 비공개 집계와 같은 메커니즘을 제공합니다. 이를 통해 DSP는 사용자 개인 정보를 보호하는 방식으로 입찰 활동에 대한 집계된 통계를 얻을 수 있습니다.
API 사용량	reportResult()의 sendReportTo()에서 가져오는 작업은 forDebuggingOnly.reportAdAuctionWin()에 등록된 가져오기를 가져오는 것에 비해 94% 의 경우에만 발생합니다.	타이밍은 다를 수 있지만 두 URL이 동시에 가져올 수도 있습니다. 경우에 따라 구성요소 판매자의 워크렛이 삭제되어 reportResult() 함수를 실행하려면 다시 로드해야 할 수 있습니다. 그러나 점수 로직을 가져오는 데 걸리는 시간이나 워크렛을 새로고침하는 데 걸리는 시간은 reportResult()의 50ms 제한 시간에 영향을 미치지 않습니다. Chrome은 워크렛을 새로고침해야 하는 경우 캐싱 헤더를 사용하여 가져오기 동작을 정의합니다. PA 입찰의 단계에 대한 자세한 내용은 여기를 참고하세요.
K-익명성	interestGroup의 이름이 광고 게재의 k-익명성에 영향을 미치지 않는다는 확인을 요청합니다.	광고 소재가 k-익명으로 간주되려면 IG 소유자 URL, 입찰 스크립트 URL, 광고 소재 URL, 광고 크기의 튜플이 과거 기간 (w) 동안 지정된 기준점 (k)을 충족해야 합니다. k-익명성 상태는 주기적으로 업데이트됩니다 (p).
Chrome UI	많은 MVC, ORM 등 프레임워크에서 제공하는 '내부 공개 상태' 유형을 제공하기 위한 제안서입니다. 예를 들어 Dev Tools --> 애플리케이션 --> 애플리케이션 섹션의 새 패널에 선택한 내부 이벤트를 간단하게 로깅하는 것으로 시작합니다.	여기에서 제안서에 대해 논의하고 있으며 추가 의견을 보내주세요.
Chrome UI	Dev Tools IG 조인 시 우선순위 관련 요소가 표시되지 않습니다.	이 문제는 여기에서 해결되었습니다.
API 개선	광고 소재 광고 서버가 자체 이벤트를 추적하도록 허용하는 것이 좋습니다. 허용된 추적 도메인 목록을 구성할 수 있나요?	여기에서 제안서를 공유했으며 생태계의 추가 의견을 기다립니다.
API 기능 요청	PA API를 확장하여 RTB가 아닌 미디어 거래를 지원하고 광고 게재 및 DCO와 같은 중요한 사용 사례를 유지할 수 있나요?	여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
게시자 입찰 시간 초과	게시자는 특히 광고가 순차적으로 선택되는 헤더 입찰 설정에서 노출 손실을 방지하기 위해 입찰 기간을 관리해야 합니다.	Google은 게시자가 광고 입찰 시간 제한을 세부적으로 관리할 수 있도록 하는 것이 중요하다는 점을 잘 알고 있습니다. Google은 특이 사례를 신중하게 고려하면서 'auctionConfig' 객체 내에서 전역 입찰 시간 제한 메커니즘을 구현하는 방법을 적극적으로 모색하고 있습니다. 이 기능은 게시자의 노출 조회율을 최적화하는 것을 목표로 하며, Google은 최적의 솔루션을 찾기 위해 커뮤니티와 계속 협력할 것입니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 개선	PA API의 현재 IG 설계로 인해 renderURL이 길어 메타데이터 크기가 커집니다. 테스터는 이러한 URL을 압축하여 효율성을 높이고자 합니다.	Google은 특히 효율성이 중요한 광고 입찰의 경우 IG 메타데이터 크기를 최적화하는 것이 중요하다는 점을 잘 알고 있습니다. renderURL을 압축하기 위한 템플릿 기반 솔루션은 상당한 잠재력을 제공한다고 생각합니다. Google은 제안된 템플릿 디자인을 신중하게 평가하고 구현된 솔루션에 브라우저 안정성을 유지하기 위한 강력한 악용 방지 메커니즘이 포함되어 있는지 확인합니다. 웹 표준 커뮤니티와 협력하여 이러한 고려사항을 염두에 두고 최적의 접근 방식을 개발하는 것이 여전히 중요합니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	네이티브 광고 형식을 처리하는 테스터는 단일 호출에서 여러 광고 결과를 검색하여 네트워크 부하를 줄이고 광고 렌더링 속도를 개선하여 개인 정보 보호 샌드박스 입찰 프로세스를 최적화하려고 합니다.	Google은 개인 정보 보호 샌드박스의 네이티브 광고 렌더링과 관련하여 제기된 실적 문제를 인지하고 있습니다. Google은 효율성과 강력한 사용자 개인 정보 보호 간의 균형을 찾기 위해 노력하고 있습니다. 전체 점수를 사용하여 여러 광고를 반환하면 개인 정보 보호가 저하되지만 입찰 절차를 최적화하는 방법을 적극적으로 모색하고 있습니다. Google은 네이티브 광고 형식에 대한 PA API 지원을 개선하고 개인 정보 보호 샌드박스의 엄격한 개인 정보 보호 제약 조건 내에서 효율성을 개선하기 위한 대체 메커니즘을 모색하기 위해 노력하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	특히 우선순위 수준 또는 비공개 마켓플레이스 규칙을 나타내기 위해 개인 정보 보호 샌드박스 내에서 광고 입찰가를 평가하고 정렬하는 방법의 유연성	Google은 특히 복잡한 입찰 시나리오에서 개인 정보 보호 샌드박스 내에서 광고 점수 및 정렬을 세부적으로 제어할 필요가 있음을 잘 알고 있습니다. Google은 사용자 개인 정보 보호를 저해하지 않으면서 다차원 점수를 달성하기 위해 튜플과 수학 함수를 사용하는 제안된 솔루션을 인지하고 있습니다. 이러한 접근 방식은 개발자에게 복잡성을 추가할 수 있지만 필요한 표현력을 제공합니다. Google은 고급 입찰 로직에 개인 정보 보호 샌드박스 기능을 최적으로 사용할 수 있도록 도우미 함수 또는 가이드라인을 통해 이러한 프로세스를 간소화하는 방법을 모색하고 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
reportEvent()	광고 소재가 포함된 프레임이 초기화되면 브라우저에서 실행되는 새 예약된 이벤트 (자동 비콘)를 추가합니다.	여기에서 이 요청에 대해 논의하고 있으며 추가 의견을 보내주세요.
adCost	adCost 분석을 허용합니다.	각 비용 값은 입찰에서 제한된 양의 정보를 전송할 수 있는 기회입니다. 이러한 비용의 전체 목록 N을 허용하면 전체 사용자 식별자를 전송하여 교차 사이트 추적을 사용 설정할 수 있습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 기다리고 있습니다.
resolveToConfig	resolveToConfig를 최상위 수준에서 상속하고 browserSignals에 노출해야 하나요?	여기에서 이 요청에 대해 논의하고 있으며 추가 의견을 보내주세요.
향상된 도구	chrome://topics-internals와 유사하지만 PA API용인 것이 있나요?	정확히 동일한 것은 없습니다. 하지만 PA API를 위한 광범위한 개발자 도구 가 있습니다.
라벨	Chrome에서 라벨을 사용하여 20% 의 K-anon 인구를 식별할 수 있나요?	Google은 이 요청을 검토 중이며 생태계의 추가 의견을 기다리고 있습니다.
문서	개인 정보 보호 샌드박스 입찰 워크렛이 표준 워크렛 유형이 되나요?	고유한 개인 정보 보호 및 보안 요구사항으로 인해 이러한 워크렛은 표준 브라우저 워크렛 유형과 크게 다르므로 곧 HTML 사양 내에서 표준 워크렛 유형이 될 것으로 예상하지는 않습니다. Google은 입찰 워크렛의 구현 및 실행 환경에 관한 명확한 설명을 통해 개발자 리소스를 개선하고 개인 정보 보호 샌드박스 참여자가 이 정보를 더 쉽게 이용할 수 있도록 최선을 다하고 있습니다. 자세한 내용은 여기에서 확인하세요.
Bring-Your-Own-Server (BYOS) 키-값 (KV) 서버	당사자는 BYOS KV 서비스 설정의 KV 서비스 쿼리를 통해 사용자가 조인한 동일한 소유자의 여러 IG를 알 수 있습니다.	KV 서버가 TEE에서 실행되고 게시된 신뢰 모델을 준수할 수 있는 경우 더 이상 이러한 작업이 불가능합니다.
userBiddingSignals	'userBiddingSignals'의 일부를 업데이트하면서 다른 부분은 유지합니다.	API를 변경하지 않고도 이미 가능합니다.
API 사용량	KV 서버 또는 수정된 'prevWinsMs' 데이터를 사용하여 개인 정보 보호 샌드박스 내 여러 IG에 대해 게재빈도 한도를 구현합니다.	Google은 개인 정보 보호 샌드박스 내에서 고급 최대 게재빈도 설정 기능에 대한 요구사항을 인지하고 있습니다. 현재 IG 간의 데이터 공유에 적용되는 제한사항으로 인해 이러한 전략을 구현하는 데 어려움이 있을 수 있다는 점을 잘 알고 있습니다. KV 서버는 적절한 개인 정보 보호 장치가 있는 잠재적인 메커니즘을 제공하지만 개발자는 단일 IG 모델 내에서 솔루션을 모색하는 것이 좋습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
API 사용량	구성요소 판매자 (개인 정보 보호 샌드박스 내 중첩 입찰에 참여하는 판매자)는 자체 구성을 최적화하고 불필요한 지연을 방지하기 위해 최상위 입찰 시간 제한을 확인해야 합니다.	Google은 개인 정보 보호 샌드박스 내에서 최상위 판매자와 구성요소 판매자 간의 시간 제한 조정을 개선할 필요가 있음을 인식하고 있습니다. Google은 전체 입찰 시간 제한을 포함한 새로운 시간 제한 메커니즘을 추가하는 방안을 적극적으로 모색하고 있으며, 구성요소 입찰에 최상위 시간 제한을 적용하는 방법을 모색하고 있습니다. Google의 목표는 개인 정보 보호 샌드박스 입찰 프로세스의 모든 참여자의 효율성과 예측 가능성을 높이는 것입니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.

Protected Audience 서비스

의견 주제	요약	Chrome 응답
신뢰할 수 있는 실행 환경 (TEE)	온프레미스 광고 기술 데이터 센터에 비해 퍼블릭 클라우드에서 TEE를 실행하는 데 더 많은 비용이 드나요?	Google의 대응은 이전 분기와 비슷합니다. Google의 현재 TEE 보안 모델은 퍼블릭 클라우드 구현 관행의 이점을 누리고 있습니다. 특히 현재의 하드웨어 기반 TEE는 모든 물리적 공격을 방어하지는 못합니다. Google에서 지원하는 기존의 퍼블릭 클라우드 제공업체인 AWS와 Google Cloud는 직원을 포함한 물리적 액세스 위험에 대한 완화 조치를 설계하고 구현했습니다. 온프레미스 지원에 관한 다음 세부정보를 참고하세요. 광고 기술 업체는 클라우드 서비스를 운영하는 것이 온프레미스 광고 기술 데이터 센터보다 비용이 더 많이 든다고 언급했습니다. Google은 이러한 주장을 평가할 수 있는 위치에 있지는 않지만 비용에 관한 추가 의견을 환영하며 TEE 지원을 확대하기 위한 옵션을 계속해서 평가하고 있습니다.
TEEs	비공개 클라우드 환경에서 TEE 지원	Google의 답변은 이전 분기와 비슷합니다. Google은 퍼블릭 클라우드 기반 솔루션 이외의 옵션에 대한 지원을 계속 모색하고 있지만 현재 온프레미스 TEE를 지원할 계획은 없습니다. 현재로서는 개인 정보 보호 샌드박스 보안 요구사항과 온프레미스 배포에서 발생하는 심각한 문제를 고려할 때 클라우드 기반 배포 (예: AWS 외에도 Google Cloud 지원)를 지속적으로 확장하고 개선하는 것이 생태계에 가장 유익하다고 생각합니다. 하지만 개인 정보 보호 및 보안 제약 조건을 고려할 때 이러한 요구사항이 왜 필요하고 실행 가능한지에 관한 추가 의견을 보내주시기 바랍니다.
기타 클라우드 제공업체	기타 클라우드 제공업체 지원	YouTube는 다른 클라우드 제공업체에 대한 제안을 항상 환영하지만, 3PCD가 시행될 때는 적어도 Google Cloud와 AWS를 지원할 계획입니다. 자세한 내용은 이 설명을 참고하세요.
B&A 서비스 API	B&A Services API에 대한 Google의 방향은 무엇인가요? 기기 입찰에서 Chrome 브라우저 Protected Audience보다 우선순위가 높을까요, 낮을까요?	Google의 대답은 이전 분기와 비슷합니다. Google은 현재의 Protected Audience 기기 내 입찰 설계가 계속 유지되도록 최선을 다하고 있습니다. B&A 서비스는 기기의 계산 능력 또는 네트워크 속도가 제한될 수 있는 사용 사례의 하위 집합을 지원하기 위한 가능한 솔루션을 모색하기 위해 제안되었습니다.
표준화	B&A 서비스는 표준화 절차를 거치지 않았습니다.	B&A 서비스 제안은 표준화 프로세스의 한 단계에 있으며, 이 목표를 뒷받침하기 위한 추가 참여를 환영합니다. 이 제안은 이전 제안을 기반으로 시작되었으며 W3C에서 광범위한 공개 토론을 통해 공개적으로 인큐베이션되고 있습니다. 관심 있는 개발자는 이 제안을 실험하고 의견을 제공할 수 있습니다. 이는 웹 기능 개발의 일반적인 패턴으로, 여기에 있는 블로그 게시물에 설명되어 있습니다.
KV 서버	콘텐츠 / 문맥 / 사이트 타겟팅을 위해 구매자의 KV 서버에 전체 URL을 노출합니다.	이 요청은 여기에서 논의 중이며 생태계의 추가 의견을 기다리고 있습니다.
문서	GitHub의 '신뢰할 수 있는/강제 구성요소와 선택적 구성요소' 문서가 자체 배포 이미지 및 인프라를 보유한 일부 광고 기술에 혼란을 야기합니다.	'신뢰할 수 있는/강제 구성요소와 선택적 구성요소'에 관한 문서를 개선하고자 하며, 이러한 작업에 우선순위를 둘 필요가 있는지 생태계의 의견을 듣고자 합니다.
API 개선	KV 서버 호출의 HTTP 상태 코드도 scoreAd() 함수에 매개변수로 제공되어야 합니다.	Google은 이 요청을 평가하고 있으며 생태계의 추가 의견을 기다리고 있습니다.
문서	UDF 실행으로 JS 및 WASM 워크로드가 정확하게 처리되는 방식에 관한 자세한 정보를 제공합니다.	YouTube에서는 이 정보를 제공하기 위해 노력하고 있으며 여기에서 추가 의견을 보내주시기 바랍니다.
문서	저장소 이름 업데이트 요청입니다.	저장소 이름을 'protected-auction-key-value-service'로 변경했습니다. 이는 이 저장소가 속한 서비스 모음의 용어와 일치하며, 여기에는 Protected Audience 서비스 토론, Protected Auction 서비스 문서 저장소와 같은 다른 저장소도 있습니다.
문서	bidding_auction_services_gcp_guide.md에서 Cloud Debugger API에 대한 참조를 삭제했습니다.	문서를 업데이트하고 참조를 삭제했습니다.
API 사용량	KV 조회로 인한 지연 시간이 50밀리초를 초과합니다. 거의 100ms가 걸립니다. 다른 판매자에게 효과적이었던 방법에 대한 안내가 있나요? 제한 시간과 타이밍을 측정하는 방법에 관한 제안이 있으신가요?	KV 서버 호출은 스크립트 런너의 컨텍스트 내에서 발생합니다. 즉, Chrome 브라우저 내의 특별히 보호된 환경에서 발생합니다. 이러한 스크립트 런너의 정보를 API 이외의 액세스로부터 보호하기 위한 것입니다. 자세한 내용은 여기를 참고하세요.
API 사용량	KV 서버가 특정 시간 내에 응답해야 하는 제한 시간이 있나요?	판매자는 입찰 구성에서 'perBuyerCumulativeTimeouts' 필드를 지정할 수 있습니다. 이 제한 시간에는 신뢰할 수 있는 입찰 신호를 가져오는 데 필요한 시간이 포함됩니다.
지연 시간	개인 정보 보호 샌드박스팀은 지연 문제를 해결하기 위해 어떤 노력을 하고 있나요?	지연 시간을 허용 가능한 제한 내로 유지하기 위해 Google에서 모색하고 있는 전략은 여기를 참고하세요.

디지털 광고 측정

Attribution Reporting (및 기타 API)

의견 주제	요약	Chrome 응답
수동 캠페인 최적화	ARA는 수동 캠페인 최적화를 지원하지 않습니다.	Google은 광고 기술과 함께 이 시나리오를 논의하고 ARA를 사용하여 수동 캠페인 최적화를 지원하는 방법을 설명했습니다. ARA는 광고 기술 맞춤설정과 유연성을 통해 다양한 광고 기술 사용 사례를 해결할 수 있도록 설계되었습니다. 제안된 몇 가지 방법에는 다양한 유연한 이벤트 수준 구성을 사용하고 요약 보고서와 함께 이벤트 수준 보고서를 사용하여 노이즈의 영향을 줄이고 수동 및 자동 최적화 요구사항을 달성하는 것이 포함되었습니다. ARA 구성의 맞춤설정 가능성과 유연성에 관한 추가 생태계 의견을 기다리고 있습니다.
전환 유형	Google에서는 전환 유형을 8개만 허용하고 있어 제한적입니다.	유연한 이벤트 수준 보고의 대부분을 구현하여 광고 기술이 보고 기간 수, 기여 분석 보고서 수, 사용할 수 있는 트리거 데이터 비트 수를 더욱 유연하게 설정할 수 있도록 했습니다. 광고 기술은 최대 32개의 서로 다른 전환 유형을 측정할 수 있는 구성을 선택할 수 있습니다.
집계 가능한 보고서 이벤트 한도	집계 가능한 보고서당 전환 이벤트의 최솟값인 20회는 예산이 제한된 소규모 광고주에게는 적합하지 않습니다.	집계 가능한 보고서당 필요한 전환 이벤트의 최솟값은 없습니다. 또한 추적하는 주요 구조 / 측정기준을 변경하고, 다양한 수준의 에피론을 테스트하고, 더 긴 일괄 처리 빈도를 테스트하고, 측정 목표 간에 다양한 기여도 예산 할당을 테스트하는 등 소규모 광고주의 집계 가능한 보고서를 최적화하기 위해 취할 수 있는 여러 설계 결정이 있습니다. 소규모 광고 기술은 노이즈의 영향을 줄이기 위해 이벤트 수준 보고서와 요약 보고서를 결합하는 실험을 할 수도 있습니다.
실시간 데이터	DSP가 입찰 전략을 조정하고 캠페인 효과를 개선하는 데 사용하는 실시간 데이터 (예: 클릭수, 세션수, 전환수)를 DSP에서 박탈하는 것은 기존 기능을 유지하겠다는 약속을 어기는 것입니다.	ARA를 사용해도 클릭수와 세션수는 실시간으로 유지되며, 전환수는 3PC를 사용해도 항상 사후에 집계됩니다.
누락된 입력란	전체 유연한 이벤트 출시에서 요구사항(i) 통화 필드, (ii) orderID / TransactionID 필드가 누락되었습니다.	현재 이벤트 수준 보고를 통해 이미 이를 수행할 수 있는 방법이 있으므로 현재는 전체 유연한 이벤트 수준의 일부로 통화 필드 또는 주문 ID / 거래 ID 필드를 지원할 계획이 없습니다. 이러한 입력란에 관한 추가 의견을 보내주시면 이러한 입력란이 필요한 추가 사용 사례가 있는지 검토하겠습니다. ARA의 현재 설계를 사용하여 통화 및 주문 ID 유형 정보를 측정하는 방법은 다음과 같습니다. 1. 의견에 따라 통화는 사용자의 지역을 기준으로 결정되며, 이는 사용된 통화를 확인하는 방법으로 source_event_id의 일부로 추가할 수 있습니다. 2. 의견에 따르면 주문 ID 필드는 중복 삭제 키를 사용하여 전환 및 값이 실수로 중복 집계되지 않도록 하는 데 필요합니다.
개인 정보 보호 예산	ARA 개인 정보 보호 예산으로 인해 여러 측정기준에서 측정할 수 있는 기능이 제한됨	ARA는 광고 기술이 다양한 기여 분석 시나리오를 다루기 위해 자체 ARA 구성을 맞춤설정할 수 있도록 설계되었습니다. 현재의 ARA 설계로 광고 기술은 측정에 가장 중요한 측정기준과 노이즈가 데이터에 미치는 영향 간의 절충점을 고려해야 합니다. 측정하는 측정기준의 세부사항에 따라 데이터에 노이즈를 추가하는 것은 개인 정보 보호를 위해 필수적입니다. Google은 다양한 측정기준에서 측정하는 기능과 관련하여 추가 생태계 의견을 수렴하고 있지만, 이를 필요로 하는 구체적인 사용 사례를 파악해야 합니다.
사양 업데이트	Google은 고정된 이벤트 보고 기간에서 유연한 이벤트 보고 기간으로 전환했다고 발표했지만, Google의 기술 사양에는 아직 최소 1시간의 보고 기간이 반영되어 있습니다.	현재 유연한 이벤트 수준 보고를 통해 광고 기술은 소스 이벤트당 기여 분석 보고서 수, 트리거 데이터 비트, 보고 기간의 수/길이를 변경할 수 있습니다. ARA는 여전히 개인 정보를 보호하고 특정 유형의 기록 재구성 공격을 완화하는 데 필수적인 이벤트 수준 보고서의 최소 보고 기간을 1시간으로 유지하고 있습니다. 요약 보고서는 집계된 정보를 제공하므로 광고 기술은 사용 사례에 필요한 경우 지연 없이 집계 가능한 보고서를 즉시 수신하도록 선택할 수 있습니다.
API 설계	전환 보고서의 정보를 줄이고 노이즈를 추가하면 Google보다 생태계에 더 큰 영향을 미칠 수 있다는 우려	Google은 CMA에 개인 정보 보호 샌드박스 제안을 Google 자체 비즈니스를 선호하여 경쟁을 왜곡하지 않는 방식으로 설계하고 구현하며 디지털 광고 경쟁과 모든 규모의 게시자 및 광고주에 미치는 영향을 고려하겠다고 약속했습니다.
기여 분석 수정	ARA는 기술 제공업체가 올바른 기여 분석을 제어하고 확인할 수 있도록 허용하지 않습니다.	ARA에는 인증 기능을 제공하는 다양한 솔루션이 있습니다. 1. 애드테크는 ARA 동작이 기대치와 일치하는지 확인할 수 있습니다. – ARA 클라이언트 측 코드는 오픈소스로 제공됩니다. – ARA 서버 측 코드도 오픈소스로 제공되며, 코디네이터는 허용된 버전의 집계 서비스만 집계 가능한 보고서를 복호화하고 처리할 수 있도록 합니다. 2. Chrome은 광고 기술이 모의 환경에서 ARA가 기여 분석을 실행하는 방식을 테스트할 수 있는 기여 분석 동작을 확인하기 위한 시뮬레이션 라이브러리를 광고 기술에 제공했습니다. 3. ARA는 예상된 처리가 발생했는지 여부와 그 이유를 확인하는 데 도움이 되는 여러 디버그 신호를 지원합니다.
(이전 분기에도 신고됨) 노이즈	노이즈 수준이 너무 높아 보고의 유용성에 영향을 미친다는 의견	Google은 광고 기술에 동일한 의견을 전달했으며, 노이즈가 있더라도 사용 사례에 더 적합하도록 ARA를 맞춤설정하는 방법을 파악할 수 있었습니다. Google에서는 광고 기술과 논의한 대부분의 설계 결정 및 맞춤설정이 포함된 개발자 문서를 제공합니다. ARA는 광고 기술이 다양한 기여 분석 시나리오를 다루기 위해 자체 ARA 구성을 맞춤설정할 수 있도록 설계되었습니다. 하지만 광고 기술은 측정에 가장 중요한 측정기준과 노이즈가 데이터에 미치는 영향 간의 절충점을 고려해야 합니다. Google은 노이즈의 영향에 관한 추가 생태계 의견을 수렴하고 있으며 노이즈의 영향을 변경하는 데 사용할 수 있는 ARA 수단에 관한 추가 안내를 제공할 수 있습니다.
교차 도메인 기여 분석	교차 도메인 기여도를 추적하려면 어떻게 해야 하나요?	광고 기술은 이 사용 사례를 해결하기 위해 다른 보고 URL로 리디렉션할 수 있습니다. ARA의 이 디자인 측면에 관한 추가 생태계 의견을 기다립니다.
API 개선	ARA 요약 보고서의 기여 분석을 등록할 때 사용되는 배율을 정기적으로 변경합니다.	GitHub의 논의에 따르면 집계 서비스에서 여러 배율을 처리하면 현재 기능에 비해 요약 보고서에 더 많은 노이즈가 추가될 가능성이 높습니다. 집계 가능한 보고서의 일부로 배율의 필요성에 관한 추가 의견을 기다리고 있지만, 노이즈 증가와의 잠재적 절충점을 지적하고자 합니다. 향후 다른 ARA 기능이 이 사용 사례를 해결하는 데 도움이 될 수 있는지도 평가하고 있습니다.
API 사용량	기여 분석 이벤트가 모든 참여자와 공유되는 방식을 통합할 수 있는 기회로, SSP, DSP 등에 유용합니다.	Google은 광고 기술과 동기화하여 광고 기술의 의견과 발생하는 제한사항을 더 잘 이해할 계획입니다.
테스트 트래픽 볼륨	모든 Chrome의 모드 B 테스트 트래픽이 안정적인가요?	실험 그룹에 포함되는 것은 Chrome 설정의 영향을 받지 않습니다.
문서	Pixel용 ARA를 지원합니다.	이 사용 사례를 지원하는 방법에 관한 정보를 게시했으며 생태계의 추가 의견을 기다립니다.
API 사용량	마지막 터치에서 전환이 이루어지지 않은 경우 전자상거래 플랫폼의 서드 파티 판매자에게 올바른 소스에서 발생한 ARA가 기여도가 부여되지 않을 수 있습니다.	회사는 필터를 사용하여 잘못된 기여 분석이 발생하지 않도록 할 수 있습니다 (전환 보고서가 생성되지 않음). 이 사용 사례에 도움이 되는 사전 기여 분석 필터링 제안도 준비하고 있습니다.
브라우저 지원	ARA는 여러 브라우저에서 지원되나요?	다른 브라우저에서도 개인 정보 보호 샌드박스 API를 채택하는 것을 환영하며 W3C에서 Google의 접근 방식을 공개적으로 논의하는 데 계속 시간을 할애하고 있습니다. Google은 ARA 출시의 목표로 상호 운용성을 명시적으로 언급했으며 ARA의 설계는 개인 정보 보호 입장이 다른 공급업체를 위해 유연한 공급업체 지정 값을 사용하여 브라우저에 종속되지 않도록 의도되었습니다. 다른 브라우저는 콘텐츠 및 서비스의 디지털 생태계를 지원할 수 있는 교차 사이트 식별자의 대안을 제공할지 여부를 자체적으로 결정하고 있습니다. Microsoft Edge에서 ARA를 지원할 것임을 알린 것은 고무적인 일입니다.
API 사용량	registerAdBeacon/reportEvent (및 navigation_start/commit 자동 비콘)의 ARA 소스 등록에 예상되는 소스 종류는 무엇인가요?	이러한 비콘이 자동인지 수동인지에 따라 다릅니다. - 예약됨.* (즉, 자동) 이벤트가 탐색 소스 유형이어야 합니다. - 수동으로 트리거된 이벤트가 이벤트 소스 유형이 됩니다.
API 사용량	소스당 집계 가능한 보고서의 최대 한도가 20개라는 것은 소스 이벤트별로 20개라는 의미인가요? 한도는 전 세계적으로 적용되나요, 아니면 일일 한도인가요? 한도를 늘릴 계획이 있나요?	소스당 집계 가능한 보고서 20개 제한은 소스별로 집계 가능한 보고서를 20개 만들 수 있는 전역 제한입니다. 이 한도는 브라우저에서 설정하며 구성할 수 없습니다. 이 제한의 목적은 null 보고서로 실제 기여 분석 보고서의 보호 기능을 악용하는 것을 방지하는 것입니다. 자세한 내용은 여기에서 확인하세요.
API 사용량	ARA를 사용한 이메일 마케팅 지원	이메일 호스팅 사이트를 관리하지 않는 경우 현재 ARA에서는 이 사용 사례를 직접 지원하지 않습니다. 여기에서 이 문제를 논의하고 있으며 추가 의견을 기다리고 있습니다.
Epsilon	Aggregate API의 epsilon 값은 언제 결정되나요?	현재 에피론 값은 개인 정보 보호 샌드박스에서 정의한 사전 결정된 임곗값 (현재 64)까지 광고 기술에서 구성할 수 있습니다. 다양한 에피론 값을 테스트하고 자체 사용 사례의 변곡점을 파악한 후 의견을 제공하는 것이 좋습니다. Google은 에피론 값 범위를 변경하기 전에 광고 기술에 미리 알릴 예정입니다.
API 개선	광고주가 외부 CRM 데이터와 일치시키기 위해 trigger_data 필드에 식별자를 삽입하여 전환 품질을 확인할 수 있는 사용 사례를 지원합니다.	요청을 검토 중이며 여기에서 추가 의견을 보내주세요.
API 사용량	리디렉션 URL을 도착 URL로 처리하는 방법	광고 기술은 다음 중 하나를 할 수 있습니다. 1. 도착 필드( 2)에 최종 도착 URL을 입력합니다. 도착 란은 최대 3개의 URL을 허용하므로 이 입력란에 여러 URL을 입력할 수 있습니다. 두 옵션 모두 최종 도착 URL을 알아야 합니다. 자세한 내용은 여기 를 참고하세요.

Aggregation Service

의견 주제	요약	Chrome 응답
키 검색 메커니즘	키 검색 메커니즘 요청	키 검색에 관한 제안서가 있으며 생태계의 제안서에 대한 의견을 기다립니다.
API 사용량	집계 서비스의 관측 가능성 로드맵	Google은 더 나은 관찰 가능성을 지원하기 위한 옵션을 검토하고 있으며 여기에서 생태계의 의견을 기다리고 있습니다.
API 개선	보고서를 다시 쿼리할 수 있도록 요청합니다.	집계 서비스는 광고 기술이 보고서별로 에피론을 분할할 수 있는 재요청 제안을 준비하고 있습니다. 이렇게 하면 검색어당 노이즈가 더 많이 발생할 수 있지만 광고 기술이 개인 정보를 보호하면서 다시 쿼리할 수 있습니다.
API 개선	여러 출처를 동일한 AWS ID에 연결할 수 있습니다.	이제 집계 서비스로 여러 사이트를 동일한 클라우드 계정 (Google Cloud 또는 AWS)에 온보딩할 수 있습니다. 이를 통해 광고 기술은 여러 사이트의 보고서와 동일한 사이트의 여러 출처를 처리하는 데 동일한 집계 서비스 엔클레이브를 사용할 수 있습니다.
API 사용량	집계 가능한 일괄 처리가 실패하면 예산이 사용되었는지 여부와 일괄 처리를 다시 처리할 수 있는지 여부를 알 수 없습니다. 집계 서비스에서 중복 보고서에 대한 예산 오류가 발생하면 나머지 보고서는 손실됩니다. 이 손실을 최소화하려면 어떻게 해야 하나요?	일반적인 시나리오에서 전체 작업이 실패하면 예산이 소진되지 않습니다. 예산이 소진되는 드문 실패가 발생하는 경우 광고 기술은 예산 복구를 요청할 수 있습니다. 광고 기술에서 예산 소진 오류와 함께 작업 실패가 자주 발생하는 경우 일괄 처리 전략을 확인해야 합니다. 올바르게 일괄 처리하고 중복 보고서 및 오류를 방지하는 방법에 관한 안내는 여기를 참고하세요. 예산 복구에 관한 의견은 여기에서 보내주세요.
API 사용량	여기에 설명된 트리거와 함께 Private Aggregation API를 사용하면 모든 입찰에 대해 집계 가능한 보고서가 생성됩니다. 집계 서비스의 확장 기능은 무엇인가요?	집계 서비스 자체는 일괄 처리의 키 또는 보고서 수에 상한을 두지 않지만, 필요한 메모리로 인해 10^14 보고서 및 10^12 키의 규모는 현재 지원되지 않습니다. 크기 조정 가이드에는 예상 부하와 지원되는 Cloud VM 인스턴스 유형을 고려하여 최적의 성능을 위해 테스트 및 권장하는 범위가 표시됩니다.
데이터 처리	암호화된 데이터에 개인 정보가 포함된 경우 집계 서비스에 암호화된 데이터를 제공하는 법적 조치는 무엇인가요? 코디네이터가 암호화된 데이터에 액세스하지 못하도록 보장할 수 있나요?	집계 서비스는 암호화된 사용자 데이터를 코디네이터와 공유하지 않습니다. 집계 서비스는 키 관리 및 회계에 조정자를 사용합니다. 조정자에 관한 몇 가지 세부정보는 여기에서 확인할 수 있습니다. 계정 보고의 경우 집계 서비스는 예산 사용을 위해 공유 ID와 보고 출처만 PBS와 공유합니다. 멀티 사이트를 출시하면 출처가 사이트로 대체됩니다. 집계 서비스는 클라이언트의 보고서를 복호화할 수 있는 유일한 장소인 TEE에서 실행됩니다. TEE에서 실행되는 코드는 여기에 설명된 대로 오픈소스로 제공되며 외부 당사자가 감사합니다.

Private Aggregation API

의견 주제	요약	Chrome 응답
API 사용량	구성요소 판매자가 TEE 내의 여러 집계 서버에 보고서를 전송할 수 있는 기능	현재 Private Aggregation API 상태는 이 기능을 지원하지 않습니다. 이 문제에 대한 자세한 내용은 여기를 참고하세요.
문서	Google 실험에 사용되는 에피론 값은 무엇인가요?	Private Aggregation API의 경우 집계 서비스 쿼리에 지정된 ε 값은 10분 단위로 적용되는 2^16의 L1 기여도 예산에 해당합니다. 또한 24시간 주기로 적용되는 2^20의 '백업' L1 기여도 예산이 있습니다. 따라서 기본적으로 개인 정보 보호 매개변수는 10분 단위로 롤링할 때는 ε이고 24시간 단위로 롤링할 때는 144ε가 아닌 16ε입니다. 집계 서비스는 현재 다양한 집계 전략을 실험하고 비공개 집계 및 기타 API에 대해 다양한 개인 정보 보호 매개변수를 사용하여 시스템의 유용성에 관한 의견을 제공할 수 있도록 테스트용 ε 범위(최대 64)를 지원합니다. Google은 테스터의 의견을 수렴하고 더 효율적인 개인 정보 보호 예산 사용을 허용하는 기능을 추가하면서 시간이 지남에 따라 허용되는 최대 에피론 값을 다시 검토할 계획입니다.

은밀한 추적 제한

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

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

IP 보호 (이전 명칭: Gnatcatcher)

의견 주제	요약	Chrome 응답
해결 방법 ID	개인 정보 보호 샌드박스는 IP를 기반으로 하는 해결 방법 ID가 광고주에게 지속 가능하지 않다는 점을 더 적극적으로 강조해야 합니다.	개인 정보 보호 샌드박스는 크로스 사이트 추적을 줄이는 것을 목표로 하고 있음을 분명히 밝히고 있습니다. 쿠키 외에도 Google의 공개 이니셔티브는 privacysandbox.com과 GitHub에서 모두 공개됩니다. Google은 IP 주소를 기반으로 하는 크로스 사이트 추적을 비롯한 크로스 사이트 추적을 줄이기 위해 노력하고 있습니다. 하지만 교차 사이트 추적을 사전에 사용 설정할지는 궁극적으로 개별 웹사이트에서 결정합니다. 규정 준수에 대한 감시가 강화되는 시대에 개별 기업은 서비스 제공업체가 사용하는 관행을 이해하는 것이 좋습니다.
Chromecast	IP 보호는 Chromecast 또는 기타 Chrome 기기에 영향을 미치나요?	현재 Chromecast 기기에 IP 보호를 적용할 계획은 없습니다.
IP 보호 목록	웹 전반의 교차 사이트 추적에 IP 주소를 사용하고 있는 것으로 확인된 서드 파티 목록이 게시되나요?	여기에 설명된 대로 최종 목록이 결정되면 게시됩니다.

이탈 추적 감소

의견 주제	요약	Chrome 응답
싱글 사인온 (SSO) 예외	이탈 추적 완화 (BTM)는 SSO 사용 사례의 예외를 어떻게 확인하나요?	BTM은 Chrome 휴리스틱에 의해 사용 중지됩니다. 자세한 내용은 설명 자료를 참고하세요.
지원 중단 체험판	3PC 지원 중단 체험판에 포함된 사이트에 BTM이 사용 설정되나요?	아니요. BTM은 여기에 설명된 대로 지원 중단 체험판에서 생성된 쿠키 예외를 준수합니다.

개인 정보 보호 예산

GitHub 설명 및 개발자 사이트에 명시된 대로 개인 정보 보호 예산은 더 이상 개인 정보 보호 샌드박스 제안의 일부로 적극적으로 고려되지 않습니다.

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

의견 주제	요약	Chrome 응답
기능 요청	Storage Access API나 사용자 상호작용 없이도 RWS 전반에서 CHIP 또는 스토리지 파티셔닝에 자동으로 액세스할 수 있습니다.	YouTube는 이 기능을 실행할 수 있는 기능의 이점과 실현 가능성을 고려하고 있습니다. 한 가지 고려사항은 교차 브라우저 상호 운용성의 잠재적 격차입니다. RWS는 Storage Access API를 활용하여 이 문제를 해결합니다. 현재 다른 브라우저에서 지원되는 이 요청된 기능과 동등한 기능은 없습니다. 개발자는 여기에서 토론을 용이하게 하기 위해 이 문제에 관한 사용 사례를 제출하는 것이 좋습니다.
정책을 준수하지 않는 세트 삭제	저장소에서 정책을 준수하지 않는 세트를 삭제하는 절차는 무엇인가요?	Google에서는 이 프로세스를 정의하기 위해 노력하고 있으며, 업데이트가 있으면 바로 공유해 드리겠습니다.
시정 조치 절차	RWS 시정 조치 절차에서 Google의 주관적 역할에 관한 명확성이 부족합니다.	RWS는 진행 중인 프로젝트이며 새로운 제출이 계속 접수되고 있으므로 절차와 기준은 아직 확정되지 않았습니다. 제출 가이드라인에 제출 요건을 완전히 설명하는 것이 중요하다는 데 동의하며, 앞으로 더 이상 모호함과 혼란을 피하기 위해 제출 가이드라인에 더 많은 세부정보를 추가할 예정입니다. YouTube는 사람의 개입을 점진적으로 중단하고 자동화된 검토에 전적으로 의존할 수 있도록 제출 절차를 최대한 기술적으로 만들고자 합니다. 이러한 PR은 예상치 못한 동작이 포함되어 있으므로 더 많은 사람의 상호작용이 필요하지만, 이를 통해 자동화할 영역을 더 많이 파악하고 향후 이러한 문제를 방지하기 위해 가이드라인을 수정할 수 있습니다.
데이터 공유하기	도메인 소유자가 사용자 동의를 얻은 후 서드 파티가 RWS 데이터도 공유하도록 지정할 수 있는 기능을 요청합니다.	요청된 기능은 사용자가 권한 메시지를 수락한 후 인증된 ID에 액세스할 수 있는 FedCM, Storage Access API와 같은 API를 통해 이미 사용할 수 있습니다. 불가능하다고 생각되는 특정 사용 사례에 관한 생태계의 의견을 기다립니다.
기타 스토리지 방법	로컬 스토리지 또는 세션 스토리지에 저장된 정보도 3PC로 해석되나요?	서드 파티 컨텍스트 내에서 사용되는 로컬 저장소, 세션 저장소, 기타 쿠키가 아닌 저장소 형식은 버전 115부터 Chrome에서 파티션화되었습니다. 자세한 내용은 이 블로그 게시물을 참고하세요.
연결된 세트 한도	'연결된 사이트는 5개로 제한'되어 있는데도 5개가 넘는 도메인을 제출하는 조직은 어떻게 되나요?	이러한 세트는 GitHub 프로세스를 통해 허용되지만 브라우저 (Chrome)는 Storage Access API 자동 부여 규칙을 처음 5개 도메인에만 적용하고 여기에 설명된 대로 나머지 도메인은 무시합니다.
find_robots_txt	find_robots_txt 검사는 리디렉션에서 작동하지 않습니다.	이 문제를 해결하기 위한 수정사항이 여기에 제출되었습니다.
사용자 동작	accessStorage()에 대한 사용자 동작 요구사항을 삭제합니다.	이 요구사항은 requestStorageAccess API에 대해 모든 주요 브라우저에 적용되는 유사한 설계를 기반으로 합니다. 이 요청의 우선순위를 정하고 교차 브라우저 토론을 진행하는 데 도움이 되도록 이 GitHub 문제에서 추가 의견과 사용 사례를 보내주세요.
사용자 동작	Chrome 또는 OS를 다시 시작한 후 서드 파티 저장소 액세스 권한을 부여하려면 사용자 동작이 필요한가요?	예. 하지만 이 동작을 변경할지 여부에 관한 생태계의 추가 의견은 여기에서 보내주세요.

Fenced Frames API

의견 주제	요약	Chrome 응답
adComponent	펜싱된 프레임에서 AdComponents를 사용하는 문서 및 유연성이 부족합니다.	이 사용 사례와 관련된 문서를 더 많이 공유할 예정입니다. 또한 광고 구성요소는 여기에 설명된 사양에 설명된 getNestedConfigs()를 사용하여 펜스 처리된 프레임에서 지원됩니다.
(이전 분기에도 신고됨) adComponent 렌더링	격리된 프레임에서 adComponents를 렌더링하는 방법에 관한 샘플 코드 요청	여기에서 샘플 코드를 공유할 예정입니다.
서드 파티 광고 인증	펜스 프레임 맥락에서 서드 파티 광고 인증의 역할은 특히 문맥/브랜드 안전성과 관련하여 더 자세히 설명해야 합니다.	현재 펜스 프레임 광고 보고를 사용하면 DSP가 렌더링 후 브랜드 안전성 확인 및 결제를 위해 노출 및 입찰 이벤트 수준 데이터를 서드 파티 광고 인증업체에 전송할 수 있습니다.
확장형 광고	확장형 광고 지원 요청	광고가 동일한 가로세로 비율의 두 크기 간에 전환해야 하고 두 크기 간에 기능적 차이가 없는 경우 (크기만 다름) 삽입자는 두 번째 광고 크기로 펜싱된 프레임의 크기를 조절할 수 있으며 브라우저는 그에 따라 펜싱된 프레임 요소의 크기를 조정합니다.
(이전 분기에도 신고됨) 동영상 및 네이티브 인벤토리 지원	펜스 프레임은 동영상 및 네이티브 인벤토리를 지원하나요?	YouTube의 응답은 이전 분기와 비슷합니다. PA API는 iframe을 사용하는 메커니즘을 사용하여 동영상 렌더링을 지원합니다. 하지만 아직 펜스 프레임과 호환되는 동영상 및 네이티브 광고 렌더링 솔루션을 설계하지 못했습니다. 이 때문에 펜스 프레임 시행을 2026년으로 미루기로 결정했습니다. 즉, 파트너가 지금 펜싱 프레임을 적용하기로 결정하면 동영상 및 네이티브에 대한 지원이 부족해집니다.
자문 위원회	펜스 프레임 구현이 업계 표준을 준수하도록 네이티브 광고 공급업체의 자문 위원회를 구성하도록 요청합니다.	2026년 이전에는 PA API에서 펜싱된 프레임을 사용할 필요가 없습니다. 추가 시간을 통해 업계와 계속 협력하여 더 광범위한 중요한 사용 사례에 대한 지원을 설계하고 구현할 수 있습니다. Google은 PA API로 동영상 및 네이티브 광고를 지원해야 하는 요구사항이 발생하기 전에 펜싱된 프레임을 개선할 것이라고 이전에 언급한 바 있습니다. Google은 약속한 대로 이러한 변경사항에 대해 CMA와 협력하고 CMA에 알릴 예정이며, 펜싱된 프레임을 요구하기 전에 생태계의 의견을 계속 수렴할 것입니다. W3C 및 IAB Tech Lab과 같은 광고 표준 조직의 생태계 참여 모델을 통해 모든 종류의 업계 전문가가 필요해지기 전에 설계를 안내할 수 있습니다.
(이전 분기에도 보고됨) 플랫폼 간 크기 차이	격리된 프레임에 표시되는 콘텐츠 크기가 데스크톱과 스마트폰에서 다르게 보인다는 신고가 접수되고 있습니다.	이 문제는 Google에서 조사 중인 알려진 Chromium 문제입니다. 여기에서 추가 의견을 보내주세요.
API 개선	이제 개인 정보 보호 샌드박스에서 네이티브 광고가 지원되도록 펜싱된 프레임 요구사항이 2025년으로 미뤄졌나요?	2026년 이전에 적용될 울타리 프레임 관련 공식 공지사항에서 언급했듯이 YouTube는 울타리 프레임을 '수용하기 위한 광범위한 노력'을 확인했습니다. 물론 네이티브 광고도 그중 하나였지만 유일한 요인은 아니었습니다. 이는 네이티브를 포함하되 이에 국한되지 않는 주요 사용 사례를 지원할 수 있도록 생태계 준비를 위한 시간을 더 확보하기 위한 조치였습니다.

Shared Storage API

의견 주제	요약	Chrome 응답
성능	워크렛 외부의 공유 저장소 반환 시간은 워크렛의 활동에 종속되는 것으로 보입니다.	이 테스트 결과는 여기에서 확인하실 수 있습니다.
더 광범위한 채택	공유 저장소는 여러 브라우저에서 사용할 수 있는 업계 전반의 표준이어야 합니다.	Google은 이러한 의견을 환영하고 확인합니다. Chrome은 WICG를 비롯한 W3C 포럼에 적극적으로 참여하여 제안을 지지하고, 의견을 구하고, 채택을 유도하고 있습니다.
입찰 Worklet	이미 워크렛에서 실행 중인 generateBid 내의 공유 저장소에서 읽어 교차 사이트 정보를 기반으로 광고 결정 / 비즈니스 로직(예: 최대 게재빈도 설정)을 적용하고 광고의 하위 집합을 선택할 수 있나요?	아니요. 입찰 워크렛 내에서 공유 저장소를 읽을 수는 없습니다.

CHIPS

의견 주제	요약	Chrome 응답
파티션 용량	파티션 용량을 초과할 때의 동작을 명확히 합니다.	용량에 도달하면 한도가 더 이상 초과되지 않을 때까지 가장 오래된 쿠키가 가장 최근에 액세스되지 않은 쿠키에서 제거되어 메모리가 확보됩니다. 개발자는 후속 요청에서 업데이트된 쿠키 헤더를 확인할 수 있습니다.
서드 파티 iframe 액세스	동일한 서드 파티 사이트로 새 탭/창을 여는 삽입된 서드 파티 iFrame 콘텐츠는 열기 도구와 동일한 파티션된 쿠키에 액세스할 수 있어야 합니다.	Google은 이 사용 사례를 논의하고 있으며 여기에서 생태계의 추가 의견을 기다리고 있습니다.
중복 쿠키	이름이 같은 파티션된 쿠키와 파티션되지 않은 쿠키가 있는 경우 브라우저는 어떤 키 값을 전송하기로 결정하나요?	이름이 같은 쿠키 (하나는 파티션된 쿠키, 하나는 파티션되지 않은 쿠키)가 두 개 있는 경우 두 쿠키가 모두 제공됩니다. 안타깝게도 어느 쿠키가 파티션된 쿠키인지 구분할 방법은 없습니다. 이와 관련된 RFC 사양은 여기에서 확인할 수 있으며, 여기에서 쿠키가 전송되는 순서를 신뢰해서는 안 된다고 설명합니다.
기능 요청	출처 파티션 쿠키를 선택합니다.	Google은 이 요청을 검토 중이며 여기에서 생태계의 추가 의견을 기다리고 있습니다.

FedCM