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

의견 보고서 - 2024년 1분기

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

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

등록 및 증명

의견 테마	요약	Chrome 응답
증명 확인	Google에서는 어떻게 증명의 신뢰성을 보장하나요?	모든 등록자는 API를 사용하는 동안 증명 파일을 보관해야 합니다. Google은 파일이 준비되었고 구문이 올바른지 확인하지만, 증명 언어와 관련하여 광고 기술의 동작을 확인하지는 않습니다.
Private Aggregation API 등록 프로세스	Private Aggregation API 등록 상태를 확인할 수 있는 방법이 있나요?	등록이 확인되면 승인된 모든 등록자에게 등록 지원팀에서 이메일을 통해 알림이 전송됩니다. 등록 과정에서 궁금한 점이 있는 등록자는 지원팀에 문의할 수 있습니다. 지원팀은 등록 양식을 제출할 때 연락할 수 있습니다. 지원팀에서 질문에 답변하고 필요한 추가 안내를 제공합니다.

관련성 있는 콘텐츠 및 광고 표시

주제

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

Protected Audience API (이전 명칭: FLEDGE)

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

Protected Audience 서비스

의견 테마	요약	Chrome 응답
신뢰할 수 있는 실행 환경 (TEE)	온프레미스 광고 기술 데이터 센터와 달리 퍼블릭 클라우드에서 TEE를 실행하는 데 비용이 더 많이 드나요?	Google의 응답은 이전 분기와 비슷합니다. 현재 TEE 보안 모델은 퍼블릭 클라우드 구현 관행의 이점을 누리고 있습니다. 특히, 현재의 하드웨어 기반 TEE는 모든 물리적 공격을 방어하지 못합니다. 기존의 지원되는 퍼블릭 클라우드 제공업체인 AWS 및 GCP에서는 직원을 비롯한 물리적 액세스 위험에 대한 완화 방법을 설계 및 구현했습니다. 온프레미스 지원에 관한 자세한 내용은 아래를 참조하세요. 광고 기술 업체에서는 클라우드 서비스를 실행하는 비용이 온프레미스 광고 기술 데이터 센터보다 비용이 많이 든다고 언급했습니다. Google은 이러한 진술을 평가할 수는 없지만 비용에 관한 추가 의견을 언제든지 환영하며 TEE 지원을 확대하기 위한 옵션을 계속 평가하고 있습니다.
TEE	비공개 클라우드 환경에서 TEE 지원	Google의 응답은 이전 분기와 비슷합니다. 퍼블릭 클라우드 기반 솔루션 이외의 옵션에 대한 지원을 계속 모색하고 있지만 온프레미스 TEE를 지원할 현재 계획은 없습니다. 이 단계에서는 개인 정보 보호 샌드박스의 보안 요구사항과 온프레미스 배포로 인해 발생하는 중대한 과제를 고려할 때 클라우드 기반 배포를 지속적으로 확장 및 개선 (예: AWS 외에 Google Cloud 지원)하는 것이 생태계에 가장 유익하다고 생각합니다. 그러나 개인 정보 보호 및 보안상의 제약을 감안하여 이러한 요구사항이 필요하고 실행 가능한 이유에 관한 추가 의견을 환영합니다.
기타 클라우드 제공업체	다른 클라우드 제공업체 지원	Google은 언제든지 다른 클라우드 제공업체를 제안할 수 있지만 3PCD가 시행될 때 최소한 GCP 및 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의 '신뢰할 수 있는/시행된 구성요소와 선택사항'에 관한 문서를 참조하면 자체 배포 이미지 및 인프라 세트를 보유한 일부 광고 기술과 혼동을 일으킬 수 있습니다.	Google은 '신뢰할 수 있음/적용된 구성요소와 선택사항 비교'에 대한 문서를 개선할 방법을 찾고 있으며, 이러한 작업의 우선순위를 지정해야 할 경우 생태계의 의견을 듣고자 합니다.
API 개선	KV 서버 호출의 HTTP 상태 코드도 scoreAd() 함수에 매개변수로 사용할 수 있어야 합니다.	YouTube는 이 요청을 평가하고 있으며 생태계의 추가 의견을 기다리고 있습니다.
문서	UDF 실행으로 JS 및 WASM 워크로드를 정확하게 처리하는 방법에 대한 자세한 정보를 제공하세요.	Google은 이 정보를 제공하기 위해 노력하고 있으며 여기에서 추가 의견을 보내주시기 바랍니다.
문서	저장소 이름 업데이트 요청입니다.	저장소 이름을 'protected-auction-key-value-service'로 변경했습니다. 이는 이 저장소가 속한 서비스 모음의 용어와 일치하며 Protected Audience Services 토론 및 Protected 입찰 서비스 문서 저장소와 같은 다른 저장소도 포함됩니다.
문서	입찰_auction_services_gcp_guide.md에서 Cloud Debugger API에 대한 참조를 삭제합니다.	문서를 업데이트하고 참조를 삭제했습니다.
API 사용량	KV 조회로 인한 지연 시간이 50밀리초 이상 걸립니다. 거의 100ms가 걸립니다. 다른 영업 담당자에게 효과적인 방법이 궁금하신가요? 제한 시간 및 타이밍을 측정하는 방법에 대한 제안사항이 있나요?	KV 서버 호출은 스크립트 실행기, 즉 Chrome 브라우저 내부의 특수하게 보호되는 환경 내에서 이루어집니다. 이는 이러한 스크립트 실행기의 정보를 API 이외의 액세스로부터 보호하기 위한 것입니다. 자세한 내용은 여기를 참고하세요.
API 사용량	KV 서버가 특정 시간 내에 응답하는 데 제한 시간이 있나요?	판매자는 입찰 구성에서 'perBuyerCumulativeTimeouts' 필드를 지정할 수 있습니다. 이 제한 시간에는 신뢰할 수 있는 입찰 신호를 가져오는 데 필요한 시간이 포함됩니다.
지연 시간	개인 정보 보호 샌드박스팀은 지연 시간을 해결하기 위해 어떤 노력을 하고 있나요?	지연 시간을 허용 가능한 한도 내로 유지하기 위한 전략은 여기를 참고하세요.

디지털 광고 측정

Attribution Reporting (및 기타 API)

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

집계 서비스

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

Private Aggregation API

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

은밀한 추적 제한

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

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

IP 보호 (이전 명칭: Gnatcatcher)

의견 테마	요약	Chrome 응답
해결 방법 ID	개인 정보 보호 샌드박스는 IP를 기반으로 구축된 해결 방법 ID가 광고주에게 지속 가능하지 않다는 점을 보다 적극적으로 설득해야 합니다.	개인 정보 보호 샌드박스는 Google이 크로스 사이트 추적을 줄이고자 한다는 점을 분명히 밝혔습니다. 쿠키뿐만 아니라 Google의 공개 이니셔티브는 privacysandbox.com과 GitHub에 모두 공개됩니다. Google은 IP 주소 기반의 크로스 사이트 추적을 줄이기 위해 노력하고 있습니다. 그러나 사전에 크로스 사이트 추적을 사용 설정할지 여부는 궁극적으로 개별 웹사이트에서 결정해야 합니다. 규제 준수에 대한 철저한 검토가 이루어지는 시대에 개별 기업은 서비스 제공업체가 사용하는 관행을 이해하는 것이 현명합니다.
Chromecast	IP 보호가 Chromecast 또는 다른 Chrome 기기에 영향을 주나요?	현재 Chromecast 기기에 IP 보호를 적용할 계획은 없습니다.
IP 보호 목록	웹 전반의 크로스 사이트 추적을 위해 IP 주소를 사용할 가능성이 있는 것으로 확인된 서드 파티의 목록이 게시되나요?	여기에 설명된 대로 목록이 확정되면 게시됩니다.

이탈 추적 감소

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

개인 정보 보호 예산

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

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

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

Fenced Frames API

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

Shared Storage API

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

CHIPS

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

FedCM