Trang này được dịch bởi Cloud Translation API.

Báo cáo phản hồi – Quý 1 năm 2024

Báo cáo hằng quý cho quý 1 năm 2024 tóm tắt ý kiến phản hồi của hệ sinh thái nhận được đối với các đề xuất liên quan đến Hộp cát về quyền riêng tư và phản hồi của Chrome.

Theo cam kết của Google với CMA, Google đã đồng ý cung cấp công khai báo cáo hằng quý về quy trình tham gia của các bên liên quan đối với các đề xuất của Hộp cát về quyền riêng tư (tham khảo đoạn 12 và 17(c)(ii) của Cam kết). Các báo cáo tóm tắt ý kiến phản hồi về Hộp cát về quyền riêng tư này được tạo bằng cách tổng hợp ý kiến phản hồi mà Chrome nhận được từ nhiều nguồn như liệt kê trong phần tổng quan về ý kiến phản hồi, bao gồm nhưng không giới hạn ở các vấn đề về GitHub, biểu mẫu phản hồi có trên privacysandbox.com, cuộc họp với các bên liên quan trong ngành và diễn đàn tiêu chuẩn web. Chrome hoan nghênh ý kiến phản hồi từ hệ sinh thái và đang tích cực tìm hiểu những cách thức để tích hợp những kiến thức học được vào các quyết định thiết kế.

Các chủ đề phản hồi được xếp hạng theo mức độ phổ biến của mỗi API. Việc này được thực hiện bằng cách tổng hợp số lượng ý kiến phản hồi mà nhóm Chrome đã nhận được liên quan đến một chủ đề nhất định và sắp xếp theo số lượng giảm dần. Chúng tôi xác định các chủ đề phản hồi phổ biến bằng cách xem xét các chủ đề thảo luận của các cuộc họp công khai (W3C, PatCG, IETF), ý kiến phản hồi trực tiếp, GitHub và các câu hỏi thường gặp mà các nhóm nội bộ và biểu mẫu công khai của Google gửi đến.

Cụ thể hơn, biên bản cuộc họp cho các cuộc họp của các cơ quan tiêu chuẩn web đã được xem xét và để lấy ý kiến phản hồi trực tiếp, hồ sơ của Google về các cuộc họp bên liên quan 1:1, email mà từng kỹ sư nhận được, danh sách gửi thư của API và biểu mẫu phản hồi công khai đã được xem xét. Sau đó, Google đã phối hợp các nhóm tham gia vào nhiều hoạt động tiếp cận khác nhau để xác định mức độ phổ biến tương đối của các chủ đề xuất hiện liên quan đến từng API.

Phần giải thích về các câu trả lời của Chrome được phát triển dựa trên các Câu hỏi thường gặp đã phát hành, câu trả lời thực tế cho các vấn đề mà các bên liên quan nêu ra và xác định vị trí dành riêng cho mục đích của bài tập báo cáo công khai này. Phản ánh trọng tâm hiện tại của hoạt động phát triển và kiểm thử, chúng tôi đã nhận được các câu hỏi và ý kiến phản hồi cụ thể về API Chủ đề, Protected Audience và Attribution Reporting API.

Chrome có thể chưa xem xét phản hồi nhận được sau khi kỳ báo cáo hiện tại kết thúc.

Bảng chú giải thuật ngữ viết tắt

ARA (đề xuất được tự động áp dụng): API Báo cáo phân bổ
Cookie có trạng thái được phân vùng độc lập (CHIPS): Cookie có trạng thái được phân vùng độc lập
DSP (Bộ xử lý tín hiệu kỹ thuật số): Nền tảng bên cầu
FedCM: Quản lý thông tin xác thực liên kết
FPS: Nhóm bên thứ nhất
IAB (Cục Quảng cáo tương tác): Cục quảng cáo tương tác
Nhà cung cấp danh tính (IDP): Nhà cung cấp danh tính
IETF (Lực lượng chuyên trách kỹ thuật Internet): Lực lượng chuyên trách kỹ thuật Internet
Số hiệp ném bóng: Địa chỉ giao thức Internet
openRTB: Đặt giá thầu theo thời gian thực
QUÁ GIỜ: Bản dùng thử theo nguyên gốc
API PAT: Protected Audience API (trước đây là FLEDGE)
PatCG: Nhóm cộng đồng công nghệ quảng cáo riêng tư
RP: Đảng trung thành
RWS: Nhóm trang web có liên quan (trước đây là Nhóm bên thứ nhất)
Nền tảng bên bán (SSP): Nền tảng bên cung
TEE: Môi trường thực thi đáng tin cậy
UA: Chuỗi tác nhân người dùng
UA-CH: Gợi ý của ứng dụng tác nhân người dùng
W3C: World Wide Web Consortium
WIPB (Danh sách mở rộng): Khiếm thị IP có ý định

Phản hồi chung, không có API hoặc công nghệ cụ thể

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Quản lý	Mức độ quan tâm đến thời gian lấy ý kiến công khai đối với mọi bản cập nhật về hoạt động quản trị đối với Hộp cát về quyền riêng tư.	Chúng tôi sẵn sàng đón nhận ý kiến phản hồi hợp lý của các bên liên quan về bất kỳ sự phát triển quan trọng nào liên quan đến Hộp cát về quyền riêng tư, bao gồm cả việc quản lý Hộp cát về quyền riêng tư trong tương lai.
Kiểm thử	Các giai đoạn kiểm thử bổ sung cho công nghệ 3PCD ngoài các giai đoạn kiểm thử hiện tại có hỗ trợ Chrome.	Chúng tôi không có ý định cung cấp thử nghiệm hỗ trợ Chrome vượt quá 1% lưu lượng truy cập Chrome hiện tại được bật kể từ đầu tháng 1.
Web với ứng dụng	3PCD trên thiết bị di động không được diễn ra trước khi đạt được khả năng tương tác đầy đủ giữa web và ứng dụng.	Chúng tôi đồng ý rằng việc hỗ trợ khả năng tương tác giữa ứng dụng và web là cần thiết, đồng thời đã triển khai tính năng đo lường mô hình phân bổ trên nhiều ứng dụng và web, đồng thời đang tìm hiểu các giải pháp nhắm mục tiêu giữa các ứng dụng. Tuy nhiên, chúng tôi không có kế hoạch trì hoãn việc sử dụng 3PCD trên web dành cho thiết bị di động. Chúng tôi không có mục tiêu đạt được mức độ phù hợp 100% khi kết thúc 3PCD. Thay vào đó, chúng tôi dự kiến rằng khả năng tương thích trên Android đối với hoạt động đo lường trên web và ứng dụng ở mức 3PCD sẽ ở mức cao và sẽ tăng lên theo thời gian khi người dùng cập nhật điện thoại.
Vai trò của trình duyệt	Có vẻ như Chrome đang đảm nhận vai trò của máy chủ quảng cáo hoặc SSP.	Chrome hiện không đảm nhận vai trò của máy chủ quảng cáo hoặc SSP. Với API PA, Chrome sẽ cung cấp một vùng chứa cho các máy chủ quảng cáo, SSP, DSP và công nghệ quảng cáo khác để áp dụng logic đặt giá thầu và tính điểm riêng.
Hướng dẫn về trường hợp sử dụng	Hướng dẫn rõ ràng hơn về những trường hợp sử dụng sẽ được API Hộp cát về quyền riêng tư hỗ trợ.	Khi bắt đầu dự án Hộp cát về quyền riêng tư, tài liệu dành cho nhà phát triển chủ yếu tập trung vào việc đưa nhà phát triển vào quy trình thảo luận và phản hồi về tất cả đề xuất. Điều này có nghĩa là nội dung thường được cấu trúc xoay quanh việc tìm hiểu động lực và khái niệm đằng sau dự án, sau đó là chi tiết về quá trình phát triển và thử nghiệm ban đầu cho từng đề xuất. Cách này hiệu quả trong việc xây dựng cộng tác trong hệ sinh thái thực tế trong quá trình phát triển các đề xuất, nhưng khi các API đã được phát hành rộng rãi, thì có một đối tượng mới gồm các nhà phát triển chủ yếu tập trung vào việc xây dựng API thay vì đóng góp vào quá trình phát triển nền tảng của họ. Gần đây, chúng tôi đã cập nhật cách điều hướng của developer Sandbox.google.com/bài viết về quyền riêng tư tương tự vào báo cáo này. Chúng tôi sẽ tiếp tục áp dụng phương pháp tiếp cận tài liệu dựa trên trường hợp dựa trên trường hợp đó.
Môi trường phát triển cục bộ	Làm cách nào để tiếp tục phát triển và kiểm thử giao diện người dùng cục bộ trên http://localhost khi cookie là SameSite=Secure và phần phụ trợ được đặt trước một CDN?	Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh những ý kiến phản hồi khác từ hệ sinh thái.
Giảm thiểu 3PCD	Có cách lập trình nào để biết 3 máy tính bị chặn hay khi các phương pháp phỏng đoán đang hoạt động không?	Trong Chrome, cả tính năng phát hiện tính năng và document.hasStorageAccess được gọi trong iframe cho phép nhà phát triển biết liệu nguồn gốc trong iframe có quyền truy cập vào 3 máy tính hay không.
Thử nghiệm video	Hiện không thể thử nghiệm quảng cáo dạng video trong Hộp cát về quyền riêng tư.	Chrome đã đăng một cuộc thảo luận và minh hoạ một số cách có thể thực hiện được video bằng API PA hiện nay (xem 242 và 254 trong kho lưu trữ bản minh hoạ của chúng tôi trên GitHub). Xin lưu ý rằng đây không phải là mã mẫu mà các công nghệ quảng cáo sẽ sử dụng bán buôn, mà là bằng chứng về ý tưởng và minh hoạ các kỹ thuật có thể hỗ trợ hiển thị video VAST bằng PA API. Trong cuộc thảo luận này, chúng ta cũng đã thấy rõ rằng hiện nay đã có thể kết xuất video, nhưng Chrome có thể thực hiện một số thay đổi nhằm đơn giản hoá quá trình triển khai bằng API PA. Ví dụ: nội dung cập nhật đối với việc thay thế macro (thảo luận tại đây) mà chúng tôi dự định giải quyết dựa trên ý kiến phản hồi về các trường hợp sử dụng an toàn thương hiệu của trình xác minh quảng cáo bên thứ ba cũng sẽ giải quyết phản hồi trong trường hợp sử dụng video khi người mua tìm kiếm macro nào của người bán để sử dụng trong hiển thị. Hầu hết thảo luận cho đến nay đều đặc biệt tập trung vào việc hiển thị quảng cáo dạng video VAST. Việc hiển thị Quảng cáo gốc có thể tận dụng các phương pháp tương tự và dễ dàng hơn theo nhiều cách. Quảng cáo gốc có vẻ hiện ít được chú ý hơn so với quảng cáo dạng video. Tuy nhiên, đây chỉ là vấn đề về mức độ ưu tiên của ngành công nghệ quảng cáo chứ không phải bất kỳ rào cản kỹ thuật nào đối với việc triển khai.
Đo lường không phải quảng cáo	3PCD có thể ảnh hưởng đến các giải pháp đo lường đối tượng không liên quan đến quảng cáo.	API đo lường không yêu cầu trường hợp sử dụng liên quan đến quảng cáo. Mặc dù ARA dành riêng cho một hành trình quảng cáo thông thường,còn tính năng Tổng hợp riêng tư chỉ dùng cho mục đích chung. Hai yếu tố nền tảng này có thể được dùng để xử lý nhiều hoạt động đo lường.
Nhà sáng tạo nội dung	Hộp cát về quyền riêng tư được xây dựng để khuyến khích các nhà sáng tạo nội dung tạo nhiều nội dung hơn cho YouTube và ít nội dung hơn trên trang web của họ.	Sáng kiến Hộp cát về quyền riêng tư tập trung vào việc bảo mật hoạt động của người dùng trên một môi trường Internet mở và miễn phí. Chúng tôi biết các nhà xuất bản dựa vào quảng cáo để sản xuất nội dung và cung cấp nội dung càng rộng rãi càng tốt. Nhà quảng cáo giúp mọi người khám phá các sản phẩm hoặc ưu đãi mới mà họ có thể muốn. Các tính năng của Hộp cát về quyền riêng tư cho phép mọi loại trang web (bao gồm cả những trang web làm việc với nhà sáng tạo nội dung) hiển thị cho người dùng quảng cáo hữu ích dựa trên hoạt động của họ với các bên khác nhau mà không tiết lộ danh tính của người dùng cho các bên đó.
Tiến trình rõ ràng hơn	Lịch phát hành rõ ràng, chi tiết hơn cho các công nghệ Hộp cát về quyền riêng tư.	Tài liệu về API Hộp cát về quyền riêng tư bao gồm các trang về trạng thái API và phạm vi cung cấp. Các trang này liệt kê các tính năng sắp ra mắt và tiến trình của các tính năng đó (ví dụ: API PA, ARA). Bạn có thể xem chính giữa các trạng thái này tại đây.
Học máy	Các công nghệ quảng cáo không thể huấn luyện đúng cách các mô hình học máy cho đến khi 3PCD vượt quá 1%.	Việc mở rộng 3PCD sang nhiều trình duyệt hơn để thử nghiệm không đảm bảo rằng các API sẽ được sử dụng nhiều hơn. Đây có lẽ là điều mà các công nghệ quảng cáo đang tìm kiếm để huấn luyện thêm các mô hình học máy. Nếu việc sử dụng hệ sinh thái rộng hơn không phải là điều mà các công nghệ quảng cáo mong muốn để đào tạo thêm các mô hình học máy, thì không có lý do gì để mở rộng 3PCD vì một công nghệ quảng cáo muốn huấn luyện các mô hình trên nhiều lưu lượng truy cập hơn có thể làm như vậy ngay hôm nay mà không cần tăng 3PCD. Bạn có thể thực hiện việc này mà không cần Chrome chuyển sang thao tác 3PCD trước khi quá trình chờ kết thúc.
Trường hợp sử dụng không được hỗ trợ	Các trường hợp sử dụng DSP tự phục vụ hiện chưa được xem xét.	Có nhiều DSP tự phục vụ thường xuyên cung cấp phản hồi công khai về API. Một số DSP thường xuyên đưa ra ý kiến phản hồi công khai cũng đã tự liệt kê mình là người kiểm thử. Ngoài ra, Chrome cũng đang tích cực tương tác với các chủ đề điển hình về DSP tự phục vụ như video và máy chủ quảng cáo bên thứ ba. Các lệnh gọi API PA hàng tuần gần đây đã đề cập đến những chủ đề này.
Bản dùng thử theo nguyên gốc	Yêu cầu OT cho các trang web muốn tăng cường linh hoạt hơn và kiểm tra phạm vi bao phủ cho công nghệ 3PCD.	Chrome hiện đang phát triển một nền tảng trực tuyến (OT) bên thứ nhất, cho phép các nguồn gốc chọn tham gia hoạt động loại bỏ 3PC. Những nguồn gốc cấp cao nhất đăng ký bản dùng thử này và mã thông báo triển khai sẽ bị chặn 3 máy tính như thể thiết bị của người dùng đã bật tính năng chống theo dõi. OT này sẽ mang đến một cơ hội quý giá để các trang web triển khai việc thử nghiệm các giải pháp thay thế dài hạn cho 3PC, trước khi 3 máy tính cuối cùng được dự kiến ra mắt sau khi tham khảo ý kiến của CMA. Chúng tôi vẫn đang nỗ lực hoàn thiện tiến trình triển khai OT.
Báo cáo của IAB Tech Lab	Ý kiến phản hồi về Hộp cát về quyền riêng tư nhận được từ Báo cáo của IAB Tech Lab.	Chúng tôi đã phản hồi chi tiết về báo cáo của IAB Tech Lab tại đây. Chúng tôi cũng công nhận rằng "báo cáo này đặt ra những câu hỏi xoay quanh các tài liệu rời rạc, các yêu cầu thương mại, kiểm tra của bên thứ ba, sự công nhận của ngành, khả năng mở rộng, tính minh bạch và hoạt động quản trị trong tương lai. Chúng tôi sẽ tương tác với hệ sinh thái và cập nhật các câu hỏi thường gặp công khai tương ứng." Trước đây, chúng tôi đã xử lý tài liệu rời rạc. Chúng tôi giải quyết các yêu cầu về thương mại trong mục "Đảm bảo dữ liệu" tại đây và một số sản phẩm quảng cáo của Google đã chia sẻ phương pháp tiếp cận của mình. Chúng tôi xử lý các hoạt động kiểm tra của bên thứ ba theo "Đảm bảo tính toàn vẹn của thuật toán" tại đây. Liên quan đến việc chứng nhận, chúng tôi mong muốn các cơ quan đó tiếp tục chứng nhận cho các sản phẩm, bao gồm cả việc sử dụng công nghệ, thay vì tự công nhận các công nghệ. Về khả năng có thể mở rộng, chúng tôi tiếp tục sẵn sàng tiếp nhận dữ liệu cho thấy có vấn đề của các nhà phát triển. Về tính minh bạch và quản trị, chúng tôi tiếp tục phát triển một cách tự do trên GitHub và tại các diễn đàn như W3C, đồng thời hợp tác với CMA theo Cam kết.
Đăng nhập bằng Google	Việc đăng nhập bằng Google sẽ dẫn đến khả năng Google sử dụng dữ liệu đăng nhập nhận dạng nhiều trái với Cam kết.	Tính năng Đăng nhập bằng Google không cho phép Google sử dụng dữ liệu trái với Cam kết.
Khả năng tương thích	Có những kế hoạch gì để hỗ trợ API Hộp cát về quyền riêng tư và khả năng tương thích tiến / lùi?	Sau khi Chrome phát hành một tính năng ở giai đoạn phát hành rộng rãi, chúng tôi sẽ cố gắng duy trì hỗ trợ cho tính năng đó. Tất nhiên, không phải lúc nào chúng tôi cũng có thể duy trì khả năng tương thích ngược. Trong những trường hợp như vậy, chúng tôi có quy trình rõ ràng về việc ngừng sử dụng và xoá các tính năng hiện có, như mô tả tại đây. Chúng tôi dự kiến sẽ tiếp tục bổ sung thêm tính năng cho các Privacy Sandbox API (API Hộp cát về quyền riêng tư) theo thời gian, dựa trên ý kiến phản hồi của hệ sinh thái về các trường hợp sử dụng sẽ được hưởng lợi từ dịch vụ hỗ trợ tốt hơn. Trong những trường hợp như vậy, chúng tôi có xu hướng bao gồm một số loại kỹ thuật Phát hiện tính năng, để một công nghệ quảng cáo quan tâm đến việc thử nghiệm một tính năng mới có thể trực tiếp hỏi trình duyệt xem tính năng đó có được hỗ trợ hay không. Cách này hiệu quả hơn so với việc yêu cầu nhà phát triển kiểm tra số phiên bản Chrome nhất định, vì một số tính năng có thể không được triển khai cùng lúc cho tất cả người dùng Chrome. Ví dụ: bạn có thể tìm thấy hoạt động phát hiện tính năng của chúng tôi cho API PA tại đây.
Triển khai máy chủ	Thay vì tự triển khai, Chrome nên chỉ định các hành vi phải đáp ứng yêu cầu triển khai thoả đáng Máy chủ tín hiệu đáng tin cậy, Máy chủ tổng hợp và mọi thành phần bắt buộc khác không phải trình duyệt. Điều này sẽ tạo điều kiện cho sự đổi mới trong khuôn khổ các ranh giới quyền riêng tư có thể chấp nhận được.	Chúng tôi trân trọng và hoan nghênh mong muốn đổi mới của các bên ngoài. Đối với tất cả các API và dịch vụ, chúng tôi đều hướng đến việc giúp các công nghệ quảng cáo có thể linh hoạt triển khai các chức năng của chúng. Ví dụ: chúng tôi cho phép các công nghệ quảng cáo sử dụng thông tin kinh doanh bí mật trong việc thiết kế logic đặt giá thầu cho phiên đấu giá. Hơn nữa, chúng tôi liên tục tiếp nhận ý kiến phản hồi của các công nghệ quảng cáo và nếu thấy hợp lý, chúng tôi sẽ đưa ý kiến đó vào thiết kế của mình. Để cho phép người khác chạy mã của riêng họ trong Môi trường thực thi đáng tin cậy, Hộp cát về quyền riêng tư sẽ cần xem xét mã (và mọi thay đổi) để xác nhận rằng mã đó đáp ứng các đảm bảo về quyền riêng tư. Điều này sẽ đòi hỏi nhóm Hộp cát về quyền riêng tư phải bỏ nhiều công sức. Do đó, chúng tôi muốn biết các bên liên quan đang tìm cách đạt được những lợi ích gì mà hiện nay chúng tôi chưa đáp ứng được.
Liệu pháp luận	Kế hoạch dài hạn cho công cụ suy nghiệm là gì?	Để phù hợp với những gì các trình duyệt khác đã chỉ ra, chúng tôi dự định cuối cùng sẽ gỡ bỏ các phương pháp phỏng đoán này khi các giải pháp thay thế được sử dụng rộng rãi, phụ thuộc vào việc phân tích tính khả thi sâu hơn. Chúng tôi đã chia sẻ thông tin này tại đây.
Âm lượng kiểm tra	Lưu lượng truy cập khác nhau khi so sánh các phương diện khác nhau.	Thử nghiệm 1% có tiêu chí loại trừ dẫn đến sự khác biệt về khả năng đủ điều kiện tham gia thử nghiệm, giữa các tập hợp ứng dụng Chrome khác nhau. Ví dụ: thử nghiệm không bao gồm người dùng Chrome Enterprise, do đó, dự kiến tỷ lệ lưu lượng truy cập có nhãn thử nghiệm sẽ cao hơn vào các ngày cuối tuần. Việc thấy tỷ lệ phần trăm lưu lượng truy cập khác nhau trên các phần dữ liệu khác nhau (chẳng hạn như địa lý, ngày và nền tảng) là điều bình thường và điều này phù hợp với những gì chúng ta đang thấy trong dữ liệu Chrome.
Bật lại 3 máy tính theo cách thủ công	Các trang web có thể biết có bao nhiêu người dùng (%) đã bật lại cookie theo cách thủ công sau khi thực thi 3PCD không?	Người dùng có thể bật lại quyền truy cập vào 3 máy tính ở cấp trang web thông qua tính năng User Bỏ qua nếu họ gặp sự cố. 3PC cũng có thể được bật lại bằng các biện pháp khác, chẳng hạn như Storage Access API. Có các biện pháp kỹ thuật, chẳng hạn như hasStorageAccess(), cho phép các trang web phát hiện xem 3PC được bật hay tắt. Tuy nhiên, Chrome sẽ không cung cấp cách nào để các trang web biết lý do bật lại.
Tính năng chống theo dõi	Tính năng Giao diện người dùng Chống theo dõi của Chrome sẽ hoạt động trong bao lâu?	Giao diện người dùng Chống theo dõi trong thanh địa chỉ dự kiến sẽ vẫn còn sau khi 3PC không được dùng nữa.
(Cũng được báo cáo trong các quý trước) Hỗ trợ trên nhiều trình duyệt	Các nhà cung cấp trình duyệt khác sử dụng API Hộp cát về quyền riêng tư.	Các nhà cung cấp trình duyệt khác (chẳng hạn như Apple, Mozilla và Microsoft) là những người tích cực tham gia các diễn đàn công khai, nơi thảo luận về các nguyên tắc bảo mật và phương pháp tiếp cận dựa trên trình duyệt. Chúng tôi được khuyến khích bởi các cuộc thảo luận cộng tác trên các diễn đàn như cuộc họp TPAC thường niên của W3C gần đây và các diễn đàn PATCG của W3C đang diễn ra, nơi chúng tôi thấy dấu hiệu hội tụ. Ví dụ: gần đây Microsoft Edge đã công bố kế hoạch của sản phẩm này là "nhằm tối đa hoá khả năng tương thích về cú pháp" với API PA và ARA, đồng thời cung cấp thêm nhiều tính năng cho nhà phát triển.
Tuỳ chọn dự phòng cho các tệp nhúng không tương thích sau 3PCD	Cung cấp hook API để phát hiện xem iframe / Nhúng của bên thứ ba có tuân thủ 3PCD hay không.	Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh những ý kiến phản hồi khác từ hệ sinh thái.
Kiểm thử	Yêu cầu gắn thêm cờ trong các phiên bản Chrome được quản lý tạm thời tắt các hành vi tuỳ chỉnh.	Chúng tôi đang xem xét yêu cầu này đối với các phiên bản Chrome được quản lý và hoan nghênh dữ liệu đầu vào bổ sung từ hệ sinh thái nếu cờ này hữu ích.

Đăng ký và chứng thực

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Xác minh chứng thực	Google sẽ đảm bảo tính xác thực của các chứng thực bằng cách nào?	Tất cả người đăng ký phải lưu giữ tệp chứng thực trong khi sử dụng API. Google xác thực rằng tệp nằm đúng vị trí và cú pháp là chính xác nhưng Google không xác thực hành vi của công nghệ quảng cáo liên quan đến ngôn ngữ chứng thực.
Quy trình đăng ký API Tổng hợp riêng tư	Có cách nào để kiểm tra trạng thái đăng ký API tổng hợp riêng tư không?	Sau khi xác thực xong yêu cầu đăng ký, tất cả những người đăng ký được phê duyệt đều sẽ nhận được thông báo qua email của Nhóm hỗ trợ đăng ký. Nếu người đăng ký có bất kỳ thắc mắc nào trong quá trình đăng ký, họ có thể liên hệ với nhóm hỗ trợ (mà họ đã được liên hệ khi gửi biểu mẫu đăng ký). Nhóm hỗ trợ sẽ phản hồi và trả lời các câu hỏi cũng như cung cấp thêm mọi hướng dẫn cần thiết.

Hiển thị nội dung và quảng cáo có liên quan

Chủ đề

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
(Cũng được báo cáo trong các quý trước) Tiến trình và tài liệu của trình phân loại	Cần có một số hình thức cơ chế để xem xét việc phân loại hoặc ít nhất là có thêm sự minh bạch về cách chế độ phân loại xác định danh mục.	Phản hồi của chúng tôi không thay đổi so với các quý trước: "Việc phân loại sai các trang web có thể khiến tín hiệu Chủ đề kém hữu ích hơn đôi chút so với một tín hiệu nói chung, nhưng các trang web cụ thể bị phân loại sai không bị điều này gây hại nhiều hơn và không ít bị thiệt hại hơn so với bất kỳ trang web nào khác. Điều này là do thông tin theo bối cảnh của một trang web sẽ luôn có sẵn cho các phiên đấu giá trên trang web đó. Thông tin này sẽ cung cấp thông tin tương đương với chủ đề chính xác, ngay cả trong trường hợp phân loại sai. Chúng tôi hoan nghênh ý kiến phản hồi về chủ đề này tại đây."
Google Ad Manager	Google Ad Manager đã được nhúng trên hầu hết các trang web và sẽ có thông tin rộng hơn nhiều về các chủ đề người dùng so với các đối thủ cạnh tranh có trên ít trang web hơn.	Chúng tôi đưa ra yêu cầu về việc quan sát để đảm bảo Topics API không khiến dữ liệu người dùng bị chia sẻ với nhiều thực thể hơn công nghệ mà API đang thay thế (bao gồm cả 3 máy tính). Các giải pháp khác trong ngành như Prebid hoạt động với 10.000 trang web và cho phép các bên tham gia thị trường gọi Topics API thông qua công nghệ của họ. Hơn nữa, điều đáng chú ý là giới hạn tối đa 5 chủ đề hàng đầu mỗi tuần có thể có tác động cân bằng, vì những người tham gia thị trường có mặt trên nhiều trang web có thể học nhiều hơn 5 chủ đề tương đương thông qua 3PC sẽ bị giới hạn ở 5 chủ đề.
(Cũng được báo cáo trong các quý trước) Mức độ hữu ích đối với các kiểu bên liên quan	Lo ngại về giá trị được tạo ra và việc phân phối giá trị đó cho các trang web tuỳ thuộc vào mức độ lưu lượng truy cập hoặc mức độ chuyên biệt của nội dung.	Chúng tôi nhận thấy rằng các trang web chuyên biệt có nhiều khả năng đóng góp các chủ đề chi tiết hơn so với các miền sở thích chung. Tuy nhiên, không phải tất cả các trang web chuyên biệt đều đóng góp các chủ đề có giá trị thương mại. Ngoài ra, tính năng động này phản ánh hiện trạng và hoàn toàn độc lập với việc ngừng hỗ trợ 3 máy tính trong Chrome. Ngoài ra, trong môi trường hiện tại, một số trang web cung cấp nhiều giá trị hơn các trang web khác trong hệ thống mức độ liên quan của quảng cáo dựa trên 3PC. Ngoài ra, các chủ đề trong số các trang web chuyên biệt có thể mang lại lợi ích lẫn nhau cho nhau vì các nhà quảng cáo đa dạng có thể chạy chiến dịch trên nhiều nhóm chủ đề và logic đặt giá thầu có thể ghi nhận giá trị của nhiều chủ đề.
Tên máy chủ và URL hoàn chỉnh	Việc phân loại dựa trên tên máy chủ của trang web có đủ hiệu quả không và điều này có làm giảm rủi ro về quyền riêng tư so với URL hoàn chỉnh không?	Chúng tôi đã cân nhắc việc sử dụng URL thông tin hoặc tiêu đề trang ngoài tên máy chủ và xác định rằng rủi ro đối với quyền riêng tư và bảo mật của người dùng sẽ không lớn hơn những lợi ích có thể có được. Một ví dụ về rủi ro về quyền riêng tư của người dùng bao gồm việc phân loại thông tin nhạy cảm có trong URL hoặc tiêu đề trang thành các chủ đề của người dùng.
Chủ đề đóng vai trò là tín hiệu	Yêu cầu hướng dẫn về cách kết hợp Chủ đề với các tín hiệu khác và những tín hiệu khác có thể hữu ích.	Các giải pháp công nghệ quảng cáo có thể thu được kết quả tốt nhất bằng cách kết hợp tất cả công cụ hiện có, chẳng hạn như công nghệ học máy và tín hiệu đảm bảo quyền riêng tư của API bảo đảm quyền riêng tư, cùng với dữ liệu bối cảnh, dữ liệu mẫu quảng cáo và dữ liệu của bên thứ nhất. Bạn có thể xem thêm hướng dẫn về vấn đề này tại đây.

Protected Audience API (trước đây là FLEDGE)

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Thử nghiệm lưu lượng truy cập	Người kiểm thử đang báo cáo lượng phản hồi giá thầu thấp cho phiên đấu giá API PA.	1. Mật độ giá thầu tương quan với việc tham gia hệ sinh thái trong PA API. Chúng tôi dự đoán rằng tỷ lệ này sẽ tiếp tục tăng trong suốt năm 2024 và xa hơn nữa. Cuối cùng, việc quyết định cách phân bổ ngân sách chiến dịch là do nhà quảng cáo, công ty quảng cáo và nhà cung cấp công nghệ của họ quyết định. Chúng tôi dự kiến một số người tham gia hệ sinh thái có thể trì hoãn việc đầu tư vào các giải pháp "không có cookie" khác nhau, bao gồm cả API PA cho đến sau thời điểm 3PCD. Tại thời điểm đó, chúng tôi cho rằng họ có thể tăng mức phân bổ ngân sách cho chiến dịch của mình cho các giải pháp như vậy. 2. (1) Nhà xuất bản và nhà cung cấp công nghệ quảng cáo có thể quyết định không bắt đầu phiên đấu giá API PA nếu thấy ít nhu cầu. Việc xác định mức độ ưu tiên cho việc cập nhật trang và việc tham gia là do nhà xuất bản quyết định. Chúng tôi dự kiến rằng các nhà xuất bản có thể dành thời gian để thử nghiệm và tăng dần lưu lượng truy cập vì những lý do này. Báo cáo này cũng bao gồm phản hồi của Google Ad Manager về các biện pháp kiểm soát cho nhà xuất bản đối với việc tham gia API PA.
(Cũng được báo cáo trong các quý trước) Gian lận / Sử dụng sai mục đích	Làm cách nào hệ sinh thái này có thể giảm thiểu rủi ro và ngăn chặn đối tượng xấu hoặc người mua tự định vị mình là đối tượng đáng mong muốn?	Cơ chế báo cáo của quảng cáo API PA giữ lại thông tin dùng để phân biệt con người với lưu lượng truy cập từ bot hiện nay. Ngoài ra, bạn có thể sử dụng các kỹ thuật hiện tại dựa trên miền để bao gồm hoặc loại trừ miền trong PA API. Điều này được mô tả chi tiết hơn trong phản hồi của chúng tôi đối với báo cáo của IAB Tech Lab về Hộp cát về quyền riêng tư.
Hạn chế Nguồn gốc giống nhau đối với chủ sở hữu IG và URL logic đặt giá thầu	Với yêu cầu cùng nguồn gốc, các điểm cuối cho chủ sở hữu IG sẽ buộc phải đi qua cùng một trình cân bằng tải. Điều này có thể khiến các lệnh chuyển hướng bị từ chối.	Yêu cầu về cùng nguồn gốc để tải tập lệnh là một biện pháp bảo mật quan trọng. Bài viết dưới đây trình bày một số thông tin chi tiết về giải pháp được đề xuất, trong đó cân bằng giữa ý kiến phản hồi trong hệ sinh thái và các yếu tố khác cần cân nhắc tại đây.
Phiên đấu giá kín nhiều vị trí	Chúng tôi có nhiều khả năng cho phép Phiên đấu giá kín nhiều vùng trong phạm vi quyền riêng tư bằng cách sử dụng nhiễu và tích hợp chặt chẽ hơn với các phương pháp quảng cáo hiện tại.	Chúng tôi đang xem xét ý kiến phản hồi này và đánh giá yêu cầu tham gia phiên đấu giá nhiều thẻ so với việc tăng độ phức tạp và rủi ro về quyền riêng tư liên quan đến tính năng này. Chúng tôi đã thảo luận thêm về vấn đề này trong cuộc gọi của Nhóm cộng đồng vườn ươm web API của PA (WICG) tại đây.
Người bán cấp cao nhất	Cấu trúc hiện tại của PA API cung cấp cho mọi người bán cấp cao nhất nhiều dữ liệu và thông tin hơn về giá trị tương đối của các lượt hiển thị so với nhà xuất bản hoặc người bán thành phần.	Trong phiên đấu giá nhiều người bán, mỗi người bán sẽ có giá thầu tốt nhất. Ngoài ra, chúng tôi đã học được từ hệ sinh thái rằng các nhà xuất bản có thể muốn xem xét nhu cầu được bán trực tiếp bên cạnh giá thầu tốt nhất của mỗi người bán mà họ hợp tác. Bạn cần xem xét tất cả các cơ hội kiếm tiền tiềm năng này để xác định xem nên phân phát quảng cáo nào. Trong trường hợp này, một số đối tượng cần phải xem tập hợp đầy đủ các tuỳ chọn để chọn quảng cáo nhằm phân phát, đã có trước API PA. PA API mong muốn hỗ trợ phiên đấu giá nhiều người bán và nhà xuất bản mong muốn xem xét giá thầu tốt nhất của từng người bán bên cạnh các chiến dịch quảng cáo được bán trực tiếp (nếu có thể áp dụng). Điều đó có nghĩa là cần có một cơ chế để lựa chọn trong số những cơ hội kiếm tiền đó như hiện nay. Chúng tôi không cho rằng trình duyệt phải có vai trò quyết định quảng cáo sẽ phân phát. Do đó, cần có khái niệm về người bán cấp cao nhất để chọn quảng cáo giành chiến thắng trong nhiều khả năng. Logic của người bán cấp cao nhất đó phải có thể xem xét giá thầu tốt nhất từ mỗi người bán mà nhà xuất bản chọn làm việc cùng. Và logic của người bán đó có thể chọn cung cấp thông tin về các chiến dịch bán trực tiếp của nhà xuất bản khi có thông tin đó. Tất cả thông tin này có thể được xem xét trong logic lựa chọn quảng cáo cấp cao nhất. Điều này có nghĩa là logic cấp cao nhất sẽ xem giá thầu tốt nhất từ phiên đấu giá API PA và nếu có, mọi lựa chọn quảng cáo được bán trực tiếp từ nhà xuất bản để xác định người chiến thắng. Google Ad Manager nêu chi tiết cách triển khai PA API với tư cách là người bán cấp cao nhất trong báo cáo này với chủ đề "Quyền truy cập thông tin".
Tách quảng cáo cạnh tranh	Yêu cầu tách riêng quảng cáo cạnh tranh, chẳng hạn như ngăn quảng cáo của các thương hiệu cạnh tranh xuất hiện cạnh nhau.	Chúng tôi chưa biết cách đảm bảo sự cạnh tranh trong hệ sinh thái quảng cáo kỹ thuật số nhiều người bán, đặt giá thầu và có lập trình hiện nay. Tuy nhiên, PA API cho phép người bán tìm nạp thêm tín hiệu theo thời gian thực dựa trên tổ hợp RenderScript và tên máy chủ (đại diện cho miền của nhà xuất bản) có thể được sử dụng trong scoreAd() khi tính điểm mẫu quảng cáo. Người bán có thể sử dụng quy tắc này để ngăn quảng cáo của các thương hiệu cạnh tranh xuất hiện cạnh nhau, giả sử nhà xuất bản muốn thực thi quy tắc này.
Thông tin hạn chế	PA API giảm thông tin có sẵn cho nhà xuất bản, chẳng hạn như giá trị quảng cáo, tên người mua thành phần, tên nhà quảng cáo, URL trang đích, kích thước mẫu quảng cáo, thời gian phản hồi và tỷ lệ giá thầu cũng như giá thầu thua cuộc.	Chúng tôi đã đề xuất một số giải pháp tiềm năng tại đây và hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái.
Báo cáo cấp sự kiện	Nhà xuất bản không thể nhận đủ thông tin về những quảng cáo được phân phát sau khi API PA báo cáo ở cấp sự kiện ngừng hoạt động.	Chúng tôi đã biết các trường hợp sử dụng báo cáo khác nhau mà chúng tôi phải tiếp tục hỗ trợ khi tính năng báo cáo cấp sự kiện bị ngừng hoạt động. Đó là lý do tại sao chúng tôi đặt ra ngày ngừng cung cấp báo cáo ở cấp sự kiện không sớm hơn năm 2026. Trong khoảng thời gian từ bây giờ đến lúc đó, chúng tôi hoan nghênh sự tham gia tích cực của chúng tôi khi tương tác với hệ sinh thái theo những lộ trình bền vững từ nay về sau, có thể bao gồm những ý tưởng mới để thu thập thông tin theo cách bảo đảm quyền riêng tư.
Nhiều SSP	Giá trị gia tăng từ việc có nhiều SSP sẽ quá thấp đối với nhà xuất bản.	Chúng tôi tin rằng đây không phải là sai lệch và rất mong nhận được ý kiến phản hồi bổ sung của hệ sinh thái để tìm hiểu lý do cho khẳng định này.
Hoạt động tuyển chọn	Các hoạt động tuyển chọn không thể thực hiện được với API PA.	Chúng tôi đã nhận được ý kiến phản hồi về khả năng người bán có thể sử dụng API PA để cung cấp thông tin đối tượng cho người mua trên web (còn gọi là tiện ích đối tượng). Chúng tôi tin rằng hiện nay, chúng tôi có thể làm được điều này nhờ sử dụng chức năng uỷ quyền của PA cùng với các thoả thuận kinh doanh. Đồng thời, chúng tôi đang chủ động xem xét xem liệu chúng tôi có thể điều chỉnh cho phù hợp hơn với các loại trường hợp sử dụng này hay không và bằng cách nào.
Chọn không tham gia người mua	Lựa chọn không tham gia mặc định của người mua có thể dẫn đến kết quả thấp hơn cho phiên đấu giá thành phần.	Cho dù việc xác định một phiên đấu giá PA của một người bán hay nhiều người bán, người bán phải liệt kê rõ ràng những người mua trong trườnginterestGroupbuyers của AuctionConfig. Điều này dựa trên ý kiến phản hồi về hệ sinh thái rằng người bán có thoả thuận theo hợp đồng với một số người mua chứ không phải những người mua khác. Vì vậy, họ cần có quyền kiểm soát rõ ràng đối với những người mua sẽ được đưa vào phiên đấu giá. Chúng tôi hoan nghênh các cuộc thảo luận thêm trên GitHub.
Kích thước quảng cáo	Không thể thực hiện lọc trước dựa trên kích thước quảng cáo và adSlotSize.	Chúng tôi đang nỗ lực bổ sung tính năng này. Bạn có thể xem thêm thông tin chi tiết tại đây.
Hỗ trợ tính năng nhắm mục tiêu IG phủ định	API hỗ trợ tính năng nhắm mục tiêu IG phủ định: chỉ hiển thị quảng cáo khi người dùng không thuộc IG.	Vấn đề GitHub này đã đề xuất một cách khác để triển khai tiêu chí nhắm mục tiêu phủ định, trong đó trình duyệt trực tiếp cho máy chủ quảng cáo biết quy tắc nhắm mục tiêu phủ định nào sẽ có hiệu lực đối với một yêu cầu quảng cáo cụ thể. Mặc dù đây có vẻ là một phương pháp hấp dẫn, nhưng tất cả các phiên bản của ý tưởng này mà chúng tôi đã tìm hiểu hoá ra lại cho phép máy chủ xác định danh tính chính xác của người dùng.
Đạo luật Dịch vụ kỹ thuật số	Làm cách nào để nhà xuất bản sử dụng Khung bảo vệ nhưng cũng ngăn được các phản hồi chứa thông tin tuân theo Đạo luật Dịch vụ kỹ thuật số hiển thị?	Giống như bất kỳ công nghệ mới nào, mỗi công ty có trách nhiệm đảm bảo việc sử dụng Hộp cát về quyền riêng tư của mình là tuân thủ pháp luật; Google không thể tư vấn pháp lý cho người khác. Đối với mỗi API, chúng tôi đã xuất bản tài liệu kỹ thuật chuyên sâu để cung cấp cơ sở cho việc thực hiện các đánh giá pháp lý cần thiết. Bạn không bắt buộc phải sử dụng Khung bảo vệ trong PA API trước năm 2026. Điều này giúp các bên liên quan có thêm thời gian nhằm đảm bảo rằng họ tuân thủ tất cả luật liên quan khi sử dụng công nghệ này.
Tài liệu	UpdateAdinterestGroups() có phải là tạm thời không?	Chúng tôi chưa thông báo bất kỳ kế hoạch nào về việc ngừng sử dụng updateAdinterestGroup. Trong tương lai, chúng tôi có thể áp dụng các biện pháp bảo vệ quyền riêng tư tương tự như đã đề cập đối với các cơ chế cập nhật IG khác, ví dụ: sử dụng cả proxy cho địa chỉ IP và thêm độ trễ trước khi quá trình cập nhật diễn ra.
Hỗ trợ siêu dữ liệu và quyền sở hữu logic của bên mua cho các nền tảng không phải DSP	Yêu cầu cách hoạt động làm proxy cho DSP.	Chúng tôi biết về ý kiến phản hồi này của các phân khúc không phải DSP và đang xem xét yêu cầu này. Chúng tôi hoan nghênh thêm ý kiến phản hồi từ hệ sinh thái.
Báo cáo	Yêu cầu thêm tính năng trình xử lý tuỳ chỉnh cho nhóm / giá trị tín hiệu trong báo cáo Tổng hợp riêng tư.	Chúng tôi đã biết và yêu cầu về tính năng này đang chờ chúng tôi tìm hiểu thêm. Chúng tôi hoan nghênh thêm ý kiến phản hồi từ hệ sinh thái tại đây.
Tài liệu	Có đường liên kết nào để có thể xem tất cả tiêu đề phản hồi mà nhà quảng cáo và miền chủ sở hữu (được uỷ quyền) cần đặt không?	Chúng tôi đang lập kế hoạch cập nhật tài liệu để làm rõ vấn đề này và hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái.
Đặt giá thầu nhiều tháp	Yêu cầu giải thích về quy trình (huấn luyện và dự đoán) thông qua sơ đồ cấu trúc / sơ đồ khối về cách hình dung phương pháp tiếp cận nhiều tháp trong ngữ cảnh API PA.	Cảm ơn bạn đã gửi ý kiến phản hồi. Chúng tôi có một số bài thuyết trình về chủ đề này và dự kiến sẽ xây dựng tài liệu bổ sung từ đó.
Nhắm mục tiêu phủ định	Khả năng Hộp cát về quyền riêng tư giúp bảo vệ đối tượng nhạy cảm và trẻ vị thành niên khỏi các quảng cáo không phù hợp, chẳng hạn như cờ bạc.	API PA không xem xét nội dung của quảng cáo xuất hiện. Điều này kiểm soát các nhà phát triển công nghệ quảng cáo sử dụng PA. Nhìn chung, nhà xuất bản và nhà cung cấp công nghệ quảng cáo của họ có thể chặn mẫu quảng cáo trong các phiên đấu giá Protected Audience bằng cách sử dụng thông tin theo bối cảnh trên trang cũng như bộ quy tắc dành cho nhà xuất bản. Điều này phản ánh hiểu biết của chúng tôi về cách tiếp cận của hệ sinh thái đối với những thách thức này hiện nay. Đối với người mua, chức năng nhắm mục tiêu IG phủ định cũng có thể hữu ích cho một số trường hợp sử dụng cần tuân thủ.
Thiết kế API	Google đang từ chối và muốn các công nghệ quảng cáo sử dụng chức năng Đặt giá thầu toàn cầu, do đó làm tăng độ trễ, thay vì các URL đặt giá thầu khác nhau trong các IG khác nhau được cho phép.	Trong quá trình thảo luận về độ trễ của phiên đấu giá, chúng tôi đã nhấn mạnh rằng việc sử dụng cùng một tập lệnh trên tất cả các IG của người mua sẽ giúp hoạt động đặt giá thầu của người mua đó chạy nhanh hơn. Điều này được trình bày chi tiết hơn tại đây, cùng với các đề xuất khác của chúng tôi để cải thiện độ trễ của phiên đấu giá API PA.
Tiếp thị dựa trên tài khoản	PA API không phải là API rõ ràng cho các trường hợp sử dụng tiếp thị dựa trên tài khoản.	Chúng tôi hoan nghênh ý kiến phản hồi của hệ sinh thái về bất kỳ trường hợp sử dụng cụ thể nào mà họ cho là không khả thi. Đồng thời, chúng tôi khuyến khích những người tham gia hệ sinh thái tiếp tục thảo luận thông qua kho lưu trữ GitHub công khai hoặc các cuộc gọi hằng tuần của chúng tôi.
Thử nghiệm A/B	Khi định cấu hình API PA trong GAM cho nhà xuất bản, bạn hiện phải bật API này cho tất cả khoảng không quảng cáo hoặc không bật. Điều này hạn chế khả năng chạy thử nghiệm A/B khả thi của nhà xuất bản.	Phản hồi do Google Ad Manager đưa ra: Các biện pháp kiểm soát API PA trong Google Ad Manager (GAM) ảnh hưởng đến khả năng sử dụng API của GAM, miễn là API có thể sử dụng được. Do đó, nhà xuất bản có thể chạy thử nghiệm A/B bằng cách sử dụng chức năng chính sách về quyền của Chrome để vô hiệu hoá việc sử dụng API trên một nhóm nhỏ lưu lượng truy cập nhằm dùng làm nhóm đối chứng cho thử nghiệm A/B.
Học máy	Các nhà xuất bản cần có nhiều quyền kiểm soát hơn đối với việc sử dụng công nghệ học máy mà GAM đề xuất.	Nội dung phản hồi do Google Ad Manager đưa ra: Vào tháng 1 năm 2024, chúng tôi đã ra mắt một biện pháp kiểm soát cho phép nhà xuất bản tắt trình điều tiết công nghệ học máy và cho phép đấu giá API PA với những người bán không thuộc Google trên tất cả lưu lượng truy cập của họ. Bạn có thể tìm thêm thông tin chi tiết về chế độ kiểm soát này trong trung tâm trợ giúp của chúng tôi.
(Cũng được báo cáo trong các quý trước) Phiên đấu giá cấp cao nhất	Có thể sử dụng máy chủ quảng cáo của nhà xuất bản của Google mà không cần cấp cho GAM quyền kiểm soát phiên đấu giá API PA cấp cao nhất.	Phản hồi của Google Ad Manager: Vì những lý do được giải thích trong báo cáo Quý 3 năm 2023 của Google, kế hoạch tích hợp PA API của GAM không hỗ trợ những nhà xuất bản sử dụng GAM làm máy chủ quảng cáo của nhà xuất bản mà không có quyền kiểm soát phiên đấu giá cấp cao nhất.
Quyền tiếp cận thông tin	GAM có quyền truy cập vào thông tin có giá trị từ các đối thủ cạnh tranh, bao gồm cả giá đấu giá theo bối cảnh, các tín hiệu do người mua cung cấp cho SSP cho phiên đấu giá API PA và các tham số cấu hình từ SSP.	Phản hồi do Google Ad Manager đưa ra: Nhiều năm qua, chúng tôi vẫn luôn chú trọng vào tính công bằng trong phiên đấu giá, trong đó có cam kết rằng sẽ không có giá nào từ bất kỳ nguồn quảng cáo không bảo đảm nào của nhà xuất bản, bao gồm cả giá của mục hàng không bảo đảm, sẽ được chia sẻ với một người mua khác trước khi họ đặt giá thầu trong phiên đấu giá. Sau đó, chúng tôi khẳng định lại cam kết của chúng tôi với Cơ quan cạnh tranh của Pháp. Đối với các phiên đấu giá PA API, chúng tôi dự định giữ đúng cam kết của mình và không chia sẻ giá thầu của bất kỳ người tham gia phiên đấu giá nào khác với bất kỳ người tham gia phiên đấu giá nào khác trước khi phiên đấu giá hoàn tất trong phiên đấu giá nhiều người bán. Xin làm rõ, chúng tôi sẽ không chia sẻ giá của phiên đấu giá theo bối cảnh với bất kỳ phiên đấu giá thành phần nào, kể cả phiên đấu giá thành phần của chúng tôi, như đã giải thích trong lần cập nhật này. Ngoài ra, chúng tôi không sử dụng thông tin về cấu hình phiên đấu giá thành phần, bao gồm cả tín hiệu do người mua cung cấp cho SSP, trong phiên đấu giá riêng của chúng tôi. Trên thực tế, chúng tôi hoan nghênh các thay đổi đối với API PA, cho phép người bán thành phần chỉ định cấu hình phiên đấu giá thành phần theo cách bị làm rối mã nguồn với người bán cấp cao nhất.
Phiên đấu giá thành phần	Là phiên đấu giá cấp cao nhất, GAM sẽ kiểm soát SSP nào chạy các phiên đấu giá thành phần cho mỗi cơ hội quảng cáo.	Phản hồi do Google Ad Manager cung cấp: Là máy chủ quảng cáo của nhà xuất bản, GAM cung cấp một API gọn nhẹ cho các SSP mà nhà xuất bản có thể đang hợp tác để chỉ định cấu hình phiên đấu giá thành phần thông qua API Thẻ nhà xuất bản của Google (GPT). Bạn có thể xem thêm thông tin chi tiết tại đây. Nếu một SSP cung cấp cấu hình đấu giá thành phần thông qua API này, thì SSP này sẽ được đưa vào danh sách phiên đấu giá thành phần cho cơ hội quảng cáo đó. GAM không áp đặt bất kỳ quy định hạn chế nào đối với các phiên đấu giá thành phần được đưa vào. Bất kỳ SSP nào muốn chạy phiên đấu giá thành phần đều có thể chạy, miễn là nhà xuất bản đã cho phép họ thực thi mã cần thiết trên trang của nhà xuất bản.
Phiên đấu giá thành phần	GAM có thể áp dụng một giá sàn cụ thể và không được tiết lộ cho từng giá thầu giành chiến thắng trong phiên đấu giá thành phần.	Câu trả lời do Google Ad Manager đưa ra: Google Ad Manager vẫn luôn chú trọng tập trung vào tính công bằng trong phiên đấu giá trong nhiều năm. Để duy trì phiên đấu giá công bằng và minh bạch, chúng tôi không hỗ trợ giá sàn chỉ áp dụng cho các phân khúc nhu cầu cụ thể. Đó là một nguyên tắc nhất quán trong sản phẩm của chúng tôi và sẽ tiếp tục như vậy cho các phiên đấu giá API PA.
Máy chủ quảng cáo bên thứ ba	Các máy chủ quảng cáo của bên thứ ba sẽ không có quyền truy cập vào quyền tham gia của Google vào phiên đấu giá cấp cao hơn, điều này giới hạn khả năng hưởng lợi từ nhu cầu SSP của Google trong bối cảnh API PA.	Phản hồi do Google Ad Manager cung cấp: Hiện tại, GAM hỗ trợ thử nghiệm API PA với nhiều người bán trên GAM thông qua API được mô tả tại đây. Hiện chúng tôi không hỗ trợ việc tham gia GAM với tư cách là một phiên đấu giá thành phần trong các phiên đấu giá cấp cao nhất khác.
(Cũng được báo cáo trong các quý trước) Hiệu suất của các phiên đấu giá API PA	Báo cáo của người kiểm thử cho biết các phiên đấu giá trong API PA có độ trễ cao.	Chúng tôi được biết các mối lo ngại về độ trễ và đó là một phần lý do vì sao chúng tôi đã phát triển một số tính năng như một phần của API PA. API này sẽ giúp các SSP có thể đặt giới hạn cho độ trễ DSP cũng như thực hiện những cải tiến có thể giảm độ trễ. Gần đây, chúng tôi đã cập nhật hướng dẫn về các phương pháp hay nhất về độ trễ, trong đó có thêm thông tin về cách tận dụng những tính năng này. Chúng tôi cũng đang tiếp tục phát triển các điểm cải tiến mới về độ trễ, bạn có thể xem một số điểm tại đây.
(Cũng được báo cáo trong các quý trước) Kết xuất video	Hỗ trợ kết xuất video bằng API PA và Khung bảo vệ.	Vào tháng 1, chúng tôi đã công bố bản minh hoạ cách hoạt động của video trong luồng trong phiên đấu giá PA, kèm theo thông tin chi tiết bổ sung về các phương pháp thay thế. Chúng tôi cũng thấy các bên tham gia trong hệ sinh thái bắt đầu đề xuất cách kết xuất video cho các đối tác tích hợp với họ, chẳng hạn như đề xuất của Google Ad Manager về việc xây dựng RenderScript tương thích với video hoặc quy trình E2E đầy đủ. Ngoài ra, chúng tôi đang lắng nghe ý kiến phản hồi của hệ sinh thái về những thay đổi có thể làm để tăng mức độ sử dụng. Một thay đổi như vậy sẽ được nêu chi tiết trên GitHub. Chúng tôi vẫn tích cực phối hợp với hệ sinh thái để xác định mọi trở ngại khác trong việc áp dụng mà chúng tôi có thể gặp phải kịp thời và giải quyết kịp thời.
(Cũng được báo cáo trong các quý trước) Chính sách xử lý dữ liệu	Chính sách xử lý dữ liệu cho API IG / PA là gì?	Trong thiết kế API PA, tất cả dữ liệu được lưu trữ trong IG hoặc về dữ liệu của người dùng trong IG, (i) vẫn được lưu trên thiết bị hoặc (ii) được xử lý trong Dịch vụ Đặt giá thầu và Phiên đấu giá (B&A) chạy trong Môi trường thực thi đáng tin cậy (TEE). Trong cả hai trường hợp, dữ liệu này không được các bên khác đọc hoặc sử dụng theo bất kỳ cách nào khác ngoài việc đưa ra giá thầu trong phiên đấu giá. Một số nâng cao về quyền riêng tư mà Chrome đang khám phá có liên quan đến hoạt động tương tác với máy chủ k-anonymity do Google chạy. Hoạt động tương tác này được thiết kế cẩn thận để tránh việc chia sẻ thông tin về người dùng và diễn ra trong TEE nhằm đảm bảo sự đồng đều của thông tin trong hệ sinh thái quảng cáo. Google đã cam kết CMA thiết kế và triển khai các đề xuất trong Hộp cát về quyền riêng tư sao cho không bóp méo sự cạnh tranh bằng cách tự ưu tiên hoạt động kinh doanh của Google, đồng thời có tính đến tác động đối với sự cạnh tranh trong quảng cáo kỹ thuật số cũng như với nhà xuất bản và nhà quảng cáo. Chúng tôi tiếp tục hợp tác chặt chẽ với CMA để đảm bảo công việc của chúng tôi tuân thủ những nghĩa vụ này.
(Cũng được báo cáo trong các quý trước) Thời gian tồn tại của IG	Yêu cầu kéo dài tuổi thọ của các IG từ 30 lên 90 ngày.	Sự thay đổi như vậy đòi hỏi việc đánh giá cẩn thận, cân nhắc lợi ích cho ngành với tác động đối với người dùng Chrome và các bên liên quan khác. Chúng tôi đang xem xét yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây.
(Cũng được báo cáo trong các quý trước) modelSignals	Yêu cầu một trường mới ngoài modelSignals chỉ có thể mã hoá thông tin hiển thị và lượt nhấp.	Chúng tôi đã trả lời ý kiến phản hồi này bằng một đề xuất phản đối tại đây. Chúng tôi đang tích cực tham gia với toàn ngành để hiểu quan điểm của họ về đề xuất của chúng tôi và hiện đang cân nhắc lợi ích cho ngành với tác động đối với người dùng Chrome và các bên liên quan khác.
Các bit bổ sung trong reportWin()	Cung cấp các bit bổ sung trong reportWin() từ giới hạn hiện tại là 12 trước khi 3PCD.	Chúng tôi hiện đang tìm hiểu các phương pháp hỗ trợ trường hợp sử dụng này. Cần thời gian vì chúng tôi cũng đang tìm kiếm các phương pháp có thể giúp đảm bảo rằng chúng tôi có một kế hoạch dài hạn về quyền riêng tư.
Thiết kế đấu giá	Các yêu cầu trong một phiên đấu giá trả về URL hiển thị cùng với điểm số tương ứng.	Chúng tôi đã cân nhắc nhưng không triển khai vì những lo ngại về quyền riêng tư cho việc chia sẻ nhiều RenderScript và điểm số tương ứng từ một phiên đấu giá PA. Chúng tôi hiểu rằng mong muốn tránh hiển thị cùng một quảng cáo nhiều lần cho người dùng trên một trang và hoan nghênh các cuộc thảo luận thêm trên GitHub.
reportWin	ghi lại các trường tuỳ ý trong hàm reportWin().	Điều này hiện đang diễn ra trong suốt thời gian thử nghiệm. Sau khi Chrome ngừng hỗ trợ 3 máy tính, phiên bản forDebuggingOnly của API sẽ di chuyển để bật tính năng gỡ lỗi được lấy mẫu xuống, được chỉ định tại đây.
Người bán thành phần	Có cơ chế độc lập để tính số lượt hiển thị và các sự kiện khác, chứ không nhất thiết phải chỉ dựa vào báo cáo của công nghệ quảng cáo.	Yêu cầu về tính năng này đang nằm trong hàng đợi để chúng ta tìm hiểu thêm. Chúng tôi không lường trước được việc giải quyết vấn đề này trong giai đoạn thử nghiệm có hỗ trợ Chrome.
Lập hoá đơn chi phí mỗi lần nhấp chuột	Triển khai phương thức thanh toán chi phí mỗi lượt nhấp trong PA API.	Chúng tôi đang xem xét yêu cầu này tại đây và hiện tại, chúng tôi nhận thấy đây là một đề xuất về cách triển khai trên nền tảng API hiện tại.
browserSignals	Thêm đếnBidInSellerpriceCurrency vào báo cáo thông số kỹ thuật browserSignals cho người bán.	Chúng tôi đang xem xét yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây.
Hỗ trợ siêu dữ liệu bên mua và quyền sở hữu logic cho các nền tảng không phải DSP	Thiết kế hiện tại của API này có thể dẫn đến sự thay đổi đáng kể trong các chiến dịch nhắm mục tiêu lại ở cấp sản phẩm. Những chiến dịch đó có thể cần phải di chuyển sang các nền tảng phân phát cả dưới dạng DSP và nhà cung cấp DCO.	Chúng tôi đang thảo luận vấn đề này và hoan nghênh bạn có thêm ý kiến phản hồi tại đây.
Hỗ trợ siêu dữ liệu bên mua và quyền sở hữu logic cho các nền tảng không phải DSP	Chia sẻ ví dụ mà DSP không phải là chủ sở hữu IG.	Chúng tôi hiểu rằng những người không đặt giá thầu chỉ muốn sử dụng một số chức năng của IG, ngoại trừ những chức năng khác. Chúng tôi đang tích cực đánh giá các phương án giải quyết các trường hợp sử dụng này và hoan nghênh bạn phản hồi thêm tại đây.
Chế độ kiểm soát thời gian chờ	Nhà xuất bản phải có thể chỉ định số lượng IG có thể tham gia và thời gian chờ cấp cao nhất / thời gian chờ chung.	Chúng tôi hiểu rằng rất mong muốn có khả năng kiểm soát thời gian chờ nâng cao cũng như khả năng hiển thị giữa người bán cấp cao nhất và người bán thành phần, do đó chúng tôi đang xem xét yêu cầu này.
Nhiều kích thước quảng cáo	Hỗ trợ API PA cho các trường hợp sử dụng Nhiều kích thước quảng cáo.	Chúng tôi đang xem xét yêu cầu này và hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái.
Tài liệu	Có danh sách các thuộc tính IG phải tuân theo k-anon không?	Chúng tôi đã trả lời câu hỏi này tại đây.
Gỡ lỗi	Cải thiện khả năng gỡ lỗi cho API PA.	Chúng tôi hiểu tầm quan trọng của các công cụ gỡ lỗi mạnh mẽ đối với các nhà phát triển làm việc với API PA. Chúng tôi cam kết nâng cao trải nghiệm cho nhà phát triển bằng cách tìm hiểu những cách để tích hợp hiệu quả hơn phương thức tìm nạp tệp .well-known với các công cụ cho nhà phát triển. Mục tiêu của chúng tôi là tăng khả năng giám sát và khắc phục sự cố trong môi trường phát triển. Chúng tôi sẽ thảo luận thêm về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Nhãn	Tất cả người dùng ở nhãn xử lý chế độ B đều đã bật API Hộp cát về quyền riêng tư chưa?	Việc chỉ định nhóm thử nghiệm của Chrome được xác định ngẫu nhiên và độc lập với chế độ cài đặt Chrome do người dùng định cấu hình. Mặc dù người dùng có thể sử dụng các API này trong các nhóm thử nghiệm cụ thể (ví dụ: xử lý_1.*), nhưng bạn có thể sửa đổi hoặc tắt chức năng của các API này thông qua phần cài đặt của Chrome. Nhóm chế độ B Control_2: Việc đưa vào nhóm này vốn sẽ vô hiệu hoá các API đo lường và mức độ liên quan của Hộp cát về quyền riêng tư. Đồng thời, người dùng không thể ghi đè chế độ cài đặt này trong phần cài đặt của Chrome.
Việc Sử Dụng API	Lệnh gọi đến reportWin() và quá trình hiển thị quảng cáo diễn ra song song hay lần lượt?	reportWin() được gọi trực tiếp sau khi hoàn tất runAdTransaction(). Đồng thời, quá trình hiển thị quảng cáo có thể bắt đầu khi kết quả phiên đấu giá được đặt trong một iframe hoặc Fenced Frame (Khung bảo vệ). Sau khi cả hai reportWin() hoàn tất quá trình thực thi và quảng cáo bắt đầu hiển thị, các URL được cung cấp cho sendReportTo() sẽ được tìm nạp.
(Cũng được báo cáo trong các quý trước) Nhóm hỗ trợ thử nghiệm A/B	Yêu cầu hỗ trợ thử nghiệm A/B API PA.	Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Định hình lưu lượng truy cập	Việc đề xuất của Google để quản lý quá trình đưa ra quyết định cần thiết thông qua máy chủ KV là không hữu ích, vì người bán không thể tương tác với phần phụ trợ của họ, dẫn đến việc định hình lưu lượng truy cập trở nên khó khăn.	Như đã thảo luận trong vấn đề GitHub, việc tiết lộ liệu một DSP riêng lẻ có IG có thể gây ra mối lo ngại về việc tạo vân tay số cho người dùng hay không. Chúng tôi đã đề xuất các giải pháp thay thế khác liên quan đến vấn đề và sẵn sàng đón nhận thêm đề xuất.
Định hình lưu lượng truy cập	Cơ chế lưu vào bộ nhớ đệm làm tăng thêm một lớp phức tạp đáng kể và ngăn DSP biết hình dạng thực sự của lưu lượng truy cập mà họ sẽ đặt giá thầu.	Cơ chế lưu vào bộ nhớ đệm chỉ được cung cấp dưới dạng một đề xuất. Các công nghệ quảng cáo có thể chọn sử dụng các đề xuất phù hợp với trường hợp sử dụng của họ và chúng tôi hoan nghênh các cuộc thảo luận thêm tại đây.
Nhãn	Chrome sẽ chia sẻ nhãn dưới dạng thông số trong các yêu cầu tới máy chủ đáng tin cậy của người mua và người bán.	Đây có vẻ là một yêu cầu hợp lý vì có vẻ như sẽ phù hợp với mục tiêu sử dụng dữ liệu IG một cách có trách nhiệm. Tuy nhiên, chúng tôi đang xem xét yêu cầu và sẽ xem xét nội bộ, đồng thời sẽ cung cấp thông tin cập nhật công khai về vấn đề này khi các cuộc thảo luận diễn ra.
Việc Sử Dụng API	Làm rõ định nghĩa rõ ràng về nhóm "control_1" trong tài liệu "Hướng dẫn bổ sung về CMA cho bên thứ ba về hoạt động thử nghiệm". Cụ thể, ý kiến lo ngại rằng một thay đổi trong từ ngữ có thể bị hiểu sai thành yêu cầu loại trừ tất cả các API Hộp cát về quyền riêng tư khỏi Control_1.	Chúng tôi đã thể hiện quan điểm của mình về vấn đề này trong chuỗi bài đăng này trên GitHub. Tuy nhiên, chúng tôi không có quyền trao đổi thay cho CMA. Tuy nhiên, chúng tôi đề xuất trực tiếp nêu bất kỳ vấn đề nào liên quan đến việc diễn giải hướng dẫn xét nghiệm của họ với CMA.
Việc Sử Dụng API	Chrome có cho phép gọi joinAdinterestGroup() trên một trang trống trong khi chuyển hướng đến một tài nguyên khác không?	Nếu người dùng đang truy cập vào trang web nào đó thì chủ sở hữu trang web có thể uỷ quyền khả năng gọi joinAdinterestGroup cho bên thứ ba. Việc uỷ quyền này cho phép bên thứ ba tạo IG mà không cần thêm bất kỳ loại lệnh chuyển hướng nào thông qua một trang trống. Chúng tôi hoan nghênh ý kiến phản hồi về những lý do cụ thể để tạo IG giữa một lệnh chuyển hướng thay vì sử dụng cơ chế uỷ quyền như dự định.
Việc Sử Dụng API	Các sàn giao dịch phải có thể ghi IG vào các trang thuộc sở hữu của nhà xuất bản mà họ hợp tác và sau đó họ có thể uỷ quyền đặt giá thầu trên IG đó cho bất kỳ người mua hoặc DSP nào.	Chúng tôi đã nhận được ý kiến phản hồi và đang đánh giá xem liệu một yêu cầu như vậy có được hỗ trợ hay không. Chúng tôi hoan nghênh thêm ý kiến phản hồi từ hệ sinh thái.
Việc Sử Dụng API	Sẽ không có thông báo mất dữ liệu gỡ lỗi nếu không có ai thắng phiên đấu giá API PA.	Hàm reportWin và reportResult của Chrome được thiết kế cho báo cáo giành chiến thắng ở cấp sự kiện trong hệ thống Đấu giá quyền riêng tư (PA). Trong những trường hợp tất cả giá thầu bị từ chối trong phiên đấu giá PA, các chức năng này dự kiến sẽ không được gọi vì không xác định được người chiến thắng. Bản cập nhật gần đây cho Chrome có thể giải thích sự khác biệt trong đó các URL được chuyển đến forDebuggingOnly.reportAdauction Loss() không xuất hiện trong bảng điều khiển Mạng công cụ cho nhà phát triển. Bạn nên xác minh chức năng này bằng cách sử dụng bản dựng Chrome ở kênh Canary hoặc Dev.
Việc Sử Dụng API	AdCost được trả về từ generateBid có thể là số âm không (giá trị này đã được làm tròn một cách ngẫu nhiên thành 2 byte) không?	Chi phí quảng cáo là chi phí nhấp chuột hoặc chi phí chuyển đổi của nhà quảng cáo được chuyển từ generateBid() sang reportWin(). Giá trị này có thể là Rỗng hoặc gấp đôi. Hệ thống sẽ bỏ qua và không chuyển các giá trị âm. Giá trị sẽ được làm tròn một cách ngẫu nhiên khi được chuyển.
Cải tiến API	Máy chủ Thực thi đáng tin cậy và đã mã hoá có thể dùng để xử lý tiêu chí nhắm mục tiêu / nhóm thuần tập / phân bổ và phiên đấu giá thay vì dùng trình duyệt Chrome không?	Bạn nên tìm hiểu các thành phần và lựa chọn dựa trên TEE trong API PA (ví dụ: máy chủ KV và Dịch vụ B&A) cũng như các thành phần dựa trên TEE của Báo cáo phân bổ và Tổng hợp riêng tư (ví dụ: Dịch vụ tổng hợp) sẽ giải đáp câu hỏi này.
Cải tiến API	Phản hồi của phiên đấu giá Hộp cát về quyền riêng tư có thể là phản hồi giá thầu (như đặt giá thầu dựa vào tiêu đề) thay vì phản hồi quảng cáo (như thẻ quảng cáo) không?	Loại thay đổi này về cơ bản làm thay đổi các thuộc tính về quyền riêng tư của API PA, vì vậy chúng tôi không cân nhắc việc này.
Tùy chọn kiểm soát của nhà xuất bản	Nhà xuất bản có thể chặn mẫu quảng cáo API PA trên trang của họ không?	Chrome có một đề xuất cho tính năng quét mẫu quảng cáo theo thời gian thực và hiện chưa thử nghiệm được. Mặc dù chưa có phương án này, nhưng chúng tôi nhận thấy hầu hết các nền tảng bên bán (SSP) đều đã tạo giải pháp để hỗ trợ việc này.
Việc Sử Dụng API	Giới hạn kích thước đối với per biếnSignals là bao nhiêu?	Ở dạng cũ, perbuyerSignals không có giới hạn về kích thước vốn có trong Chrome. Hạn chế chính là dữ liệu vẫn có thể chuyển đổi tuần tự JSON và không gây tiêu thụ bộ nhớ quá mức. Tuy nhiên, xin lưu ý rằng chỉ số per BuyerSignals rất lớn và phức tạp có thể ảnh hưởng tiêu cực đến hiệu suất. Có một phương thức thay thế để chuyển perbuyerSignals qua DirectFromSellerSignalsHeaderAdSlot. Phương pháp này truyền per BuyerSignals trong tiêu đề, tuân theo giới hạn kích thước tối đa 10 kb cho toàn bộ phản hồi của tiêu đề. Ngoài ra, mỗi máy chủ riêng lẻ có thể áp dụng các hạn chế riêng về kích thước tiêu đề tối đa.
Tài liệu	Cần thay đổi tài liệu về lệnh gọi registerAdBeacon từ bên trong generateBid.	Chúng tôi đã cập nhật tài liệu này vào ngày 17 tháng 2.
Việc Sử Dụng API	Cách reportEvent chọn đúng URL beacon từ nhiều lựa chọn đã đăng ký?	Mỗi phiên đấu giá tạo ra một cấu hình riêng, do đó tạo ra một bản đồ báo cáo riêng. Từng phiên đấu giá riêng lẻ (và khung kết quả của phiên đấu giá) hoàn toàn tách biệt với nhau và không dùng chung dữ liệu. Phần giải thích về "Báo cáo quảng cáo dạng khung bảo vệ" sẽ cung cấp thêm thông tin chi tiết về chủ đề này.
Giao diện người dùng Chrome	Thêm bộ lọc trong thẻ "Ứng dụng -> "Nhóm mối quan tâm" của Chrome cho nhà phát triển, cho phép lọc theo chủ sở hữu IG (hoặc cũng có thể theo tên IG).	Chúng tôi đang đánh giá yêu cầu này và hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái.
Chrome không có giao diện người dùng	Hỗ trợ API PA trong Chrome không có giao diện người dùng.	Có một số thành phần của API PA gắn liền với Chrome, chẳng hạn như các lệnh gọi k-anon đến máy chủ của Google, các lệnh gọi này có thể không hoạt động trong Headless Chrome "cũ". Chúng tôi cho rằng điều này có thể được giải quyết bằng phiên bản "mới" của Headless Chrome được phát hành trong Chrome 112.
Việc Sử Dụng API	Trong trường hợp báo cáo thua lỗ bằng reportAdauctionDSA, chúng ta sẽ thấy giá trị "topLevelModifiedBid=0" trong nhiều trường hợp. Nội dung này có nghĩa là gì?	Giá trị toplevelLatestBid bắt nguồn từ hàm scoreAd() trong thành phần người bán cấp cao nhất. Giá trị này đóng vai trò trong việc xác định kết quả của phiên đấu giá cấp cao nhất. Như theo phần giải thích, giá trị toplevelBidBid bằng 0 hoặc là bất kỳ số âm nào cho thấy quảng cáo tương ứng không đủ điều kiện thắng phiên đấu giá. Ví dụ: bạn có thể sử dụng cơ chế này để lọc ra các quảng cáo được nhắm mục tiêu theo nhóm mối quan tâm không vượt qua ứng cử viên được nhắm mục tiêu theo ngữ cảnh. Mặc dù giá trị toplevel lựa chọn giá trị là 0 có thể cho biết phiên đấu giá theo bối cảnh đã thắng, nhưng thông số kỹ thuật của API PA xác nhận rằng các yếu tố khác có thể góp phần vào kết quả này.
Thử nghiệm A/B chế độ	Thông tin làm rõ về việc lựa chọn lưu lượng truy cập ở Chế độ B và Chế độ A, cũng như lời nhắc chọn không tham gia.	Tiêu chí đưa vào cho Chế độ A và Chế độ B là giống nhau. Mục đích là tạo các nhóm đại diện cho lưu lượng truy cập Chrome thông thường, miễn là các nhóm đó hỗ trợ API Hộp cát về quyền riêng tư và phương thức gắn nhãn, do đó, một số cấu hình ứng dụng không tương thích. Vì mục đích của thử nghiệm, bạn chỉ nên so sánh lưu lượng truy cập được gắn nhãn với lưu lượng truy cập được gắn nhãn khác. Người dùng ở Chế độ B đã bật tính năng Chống theo dõi và do đó, họ sẽ nhận được thông báo về tính năng đó.
Cải tiến API	Có thể đưa "lifetimeMs" vào dưới dạng tài sản trực tiếp trong lệnh gọi joinAdinterestGroup hay quản lý nó dưới dạng một đối số riêng không?	Chúng tôi đang xem xét kỹ lưỡng ý kiến phản hồi của cộng đồng phát triển web về chức năng "joinAdinterestGroup" trong đề xuất API PA. Điểm thảo luận chính sẽ tập trung vào phương pháp tối ưu để quản lý vòng đời của IG. Chúng tôi đang đánh giá lợi ích của một đối số riêng cho thông số "lifetimeMs", vì tham số này giúp tăng tính linh hoạt và khả năng thích ứng với các điểm cải tiến tiềm năng trong tương lai đối với thông số kỹ thuật. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Khả năng tăng tỷ lệ âm tính giả trong khung PA API do xung đột với các mã trình duyệt có entropy thấp.	Nhóm Chrome đang tích cực tham gia vào việc liên tục tinh chỉnh khung API PA. Chúng tôi đánh giá cao cuộc thảo luận về tỷ lệ âm tính giả có thể phát sinh từ xung đột ID trình duyệt. Chúng tôi đang đánh giá kỹ lưỡng ý kiến phản hồi này và sẽ nỗ lực để đảm bảo rằng các bản phân tích được cập nhật phản ánh đầy đủ tất cả các yếu tố có liên quan. Cam kết của chúng tôi là cung cấp một giải pháp vừa đảm bảo quyền riêng tư như mong muốn, vừa duy trì độ chính xác và độ tin cậy. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Tôi có cần giá trị nhận dạng trình duyệt có hàm lượng entropy thấp để ngăn ứng dụng khách liên tục gửi yêu cầu "Tham gia" cho cùng một đối tượng trong hệ thống ẩn danh k không?	Chúng tôi ghi nhận và đánh giá cao các nội dung thảo luận đang diễn ra về việc sử dụng giá trị nhận dạng trình duyệt trong quá trình triển khai hệ thống k-anonymity (k – ẩn danh). Chúng tôi hiểu những mối lo ngại tiềm ẩn liên quan đến các hệ quả về quyền riêng tư của các giá trị nhận dạng đó. Mặc dù triển khai ban đầu sử dụng giá trị nhận dạng có giá trị nhận dạng thấp làm cơ chế chống hành vi sử dụng sai mục đích, nhưng chúng tôi vẫn đang tích cực tìm hiểu các kỹ thuật thay thế như Mã thông báo đếm ẩn danh để ưu tiên quyền riêng tư của người dùng trong khi vẫn duy trì tính toàn vẹn của hệ thống. Chúng tôi cam kết tìm ra các giải pháp cân bằng giữa việc sử dụng dữ liệu có trách nhiệm với các biện pháp bảo vệ quyền riêng tư mạnh mẽ, đồng thời chúng tôi hoan nghênh việc tiếp tục đối thoại với cộng đồng nghiên cứu. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh các ý kiến phản hồi khác.
Việc Sử Dụng API	AMP (Accelerated Mobile Pages) có hỗ trợ PA API không.	AMP hiện không hỗ trợ API PA. Chúng tôi hoan nghênh thêm ý kiến phản hồi từ hệ sinh thái nếu hỗ trợ của AMP là ưu tiên cao.
Cải tiến API	Hãy cân nhắc việc xoá loại này khỏi quy trình kiểm tra k-anonymity.	Chúng tôi đang cân nhắc kỹ lưỡng ý kiến phản hồi về việc có thể tối ưu hoá cấu trúc yêu cầu ẩn danh k. Chúng tôi hiểu rằng đề xuất hợp nhất các thông số và có thể hợp nhất các loại để đơn giản hoá quy trình. Mục tiêu của chúng tôi là đảm bảo tính hiệu quả và khả năng duy trì. Đồng thời, chúng tôi sẽ đánh giá tất cả các phương án trong quá trình phát triển các giải pháp bảo vệ quyền riêng tư. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Giao diện người dùng Chrome	Yêu cầu cung cấp cơ chế để người dùng ít kỹ thuật có thể dễ dàng xem và quản lý IG, bao gồm cả các chế độ kiểm soát tiềm năng ở cấp trang web để chọn không sử dụng.	Chúng tôi hiểu tầm quan trọng của việc cung cấp các công cụ thân thiện với người dùng để họ hiểu rõ và quản lý các IG. Chúng tôi đã xem xét kỹ lưỡng nhiều phương pháp khác nhau và nhận thấy rằng việc xác định IG bằng trang web mà các trang web đó tham gia sẽ mang lại sự cân bằng tốt nhất giữa sự rõ ràng và khả năng bảo vệ quyền riêng tư. Hiện tại, tính năng quản lý chung IG nằm trong phần cài đặt của Chrome. Chúng tôi không ngừng khám phá những cách thức để nâng cao hơn nữa trải nghiệm người dùng trong lĩnh vực này. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Sự an toàn của API	API PA có dễ bị rò rỉ dữ liệu về quyền riêng tư khi tương tác với quảng cáo sáng tạo, ngay cả trong bối cảnh Khung bảo vệ không?	Chúng tôi thừa nhận rằng thông tin có thể có nguy cơ rò rỉ thông qua các hoạt động tương tác tinh vi với quảng cáo. Chúng tôi đang tích cực điều tra sự tác động qua lại giữa Khung bảo vệ, API PA và các vectơ tấn công tiềm ẩn. Giảm thiểu rủi ro về quyền riêng tư là ưu tiên hàng đầu và chúng tôi cam kết phát triển các giải pháp mạnh mẽ để cân bằng giữa sự đổi mới với việc bảo vệ người dùng. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Độ trễ	Có phải thời gian chờ mặc định 50 mili giây cho logic đặt giá thầu của người mua là giá trị thực tế không?	Chúng tôi thừa nhận những lo ngại nêu ra về những điểm không thống nhất tiềm ẩn giữa quy cách và thời gian yêu cầu mạng cho logic đặt giá thầu. Chúng tôi đang tích cực xem xét các thông số kỹ thuật để đảm bảo độ chính xác của chúng, đồng thời tìm hiểu chế độ cài đặt thời gian chờ mặc định tối ưu để cân bằng giữa hiệu suất và tính khả thi. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Tài liệu	Tình trạng rò rỉ thời gian có thể xảy ra trong quy cách, trong đó trang web có thể dự đoán liệu một quảng cáo có vượt qua được ngưỡng ẩn danh k hay không, cũng như các hệ quả có thể xảy ra đối với việc theo dõi trên nhiều trang web.	Chúng tôi nhận thấy vấn đề được nêu ra liên quan đến việc rò rỉ thời gian có thể xảy ra. Chúng tôi xác nhận có sự khác biệt trong quy cách và đang thực hiện các bước để đảm bảo rằng trạng thái ẩn danh k-anonymity của quảng cáo được xác định trước phiên đấu giá để ngăn chặn những rò rỉ như vậy. Chúng tôi rất coi trọng những vấn đề này và sẽ cập nhật quy cách để phản ánh những thay đổi này. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Cách triển khai danh sách chặn SSP trong API PA.	Chúng tôi nhận thấy cần có các cơ chế để quản lý các quy định hạn chế quảng cáo của SSP. Bạn nên tìm hiểu những giải pháp ưu tiên việc đánh giá trên thiết bị và khai thác siêu dữ liệu quảng cáo hiện có để bảo vệ quyền riêng tư của người dùng, đồng thời mang lại tính linh hoạt. Chúng tôi cam kết phối hợp với các nhà phát triển để xác định phương pháp tối ưu trong API PA. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Người khác có thể yêu cầu trình duyệt của họ giả vờ làm API PA theo cách mà các trang web không thể phát hiện không?	Chúng tôi công nhận rằng, trong biểu mẫu hiện tại, các trang web có thể phát hiện thấy việc chọn không sử dụng PA API. Chúng tôi đang tích cực phát triển các tính năng như Giá thầu bổ sung và Nhắm mục tiêu phủ định, cùng với hiển thị Khung bảo vệ, để nâng cao quyền riêng tư và hướng tới cung cấp các lựa chọn không sử dụng tính năng không phát hiện được. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Thử nghiệm A/B chế độ	Lưu lượng truy cập của trung tâm dữ liệu có mục đích xử lý 1.1.	Nhóm Chrome đã xác nhận với nhóm GAM rằng lưu lượng truy cập này hiện đang được lọc ra khỏi thử nghiệm. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Hiệu quả và tính công bằng của việc triển khaiinterestGroup Buyers trong API PA.	Chúng tôi ghi nhận các cuộc thảo luận đang diễn ra về tính hiệu quả và công bằng của trường "interestGroupPurchases" trong các phiên đấu giá API PA. Chúng tôi hiểu rõ sự đánh đổi giữa tính hiệu quả, quyền riêng tư và tính công bằng với thị trường. Mặc dù người bán cần quản lý mối quan hệ kinh doanh với người mua, chúng tôi đang nghiên cứu các cách để tối ưu hoá quá trình so khớp. Những mức điều chỉnh này có thể bao gồm các khoản điều chỉnh động dựa trên dữ liệu theo thời gian thực và các mô hình kết hợp. Chúng tôi vẫn cam kết tìm các giải pháp ưu tiên quyền riêng tư của người dùng và hỗ trợ hệ sinh thái quảng cáo cạnh tranh. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Giao diện người dùng Chrome	Những vấn đề tiềm ẩn về bộ nhớ và tính rõ ràng của giao diện người dùng liên quan đến IG trong Chrome.	Chúng tôi hiểu những mối lo ngại về việc hiển thị IG trong Công cụ cho nhà phát triển. Mặc dù chế độ xem hiện tại phản ánh tất cả sự kiện IG để theo dõi trước đây, chúng tôi thừa nhận giá trị trong việc cung cấp thông tin rõ ràng hơn về trạng thái hiện tại của các IG được lưu trữ. Chúng ta sẽ tìm hiểu các phương pháp tối ưu hoá và những cải tiến tiềm năng về giao diện người dùng để nâng cao thông tin chi tiết về nhà phát triển. Về việc quản lý bộ nhớ, việc triển khai IG được thiết kế để ngăn chặn rò rỉ bộ nhớ, nhưng chúng tôi vẫn liên tục theo dõi và tối ưu hoá việc sử dụng tài nguyên. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Tài liệu	Người đăng ban đầu gặp lỗi khi cố gắng sử dụng trực tiếp kích thước quảng cáo đã đặt tên trong trường "sizeGroup" của hàm "joinAdinterestGroup". Họ muốn biết liệu đây có phải là hành vi có chủ ý hay không.	Chúng tôi nhận thấy giá trị của việc tinh giản cấu hình quảng cáo trong hàm "joinAdinterestGroup". Chúng tôi đang tích cực tìm cách giải quyết hạn chế này và dự định bật chức năng này trong các bản cập nhật trong tương lai. Điểm cải tiến này phù hợp với cam kết của chúng tôi về việc cung cấp cho nhà phát triển các công cụ linh hoạt và hiệu quả để quản lý quảng cáo. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Nhãn thử nghiệm hỗ trợ Chrome	Yêu cầu có dữ liệu trực tiếp về Chế độ A so với B và các nhãn chính xác trong sendReportTo để chúng tôi có thể theo dõi thử nghiệm một cách nhất quán.	Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi
Tài liệu	Tên miền của người bán có được đưa vào các yêu cầu gửi tới máy chủ đáng tin cậy của người bán cho mục đích xác thực không?	Chúng tôi xác nhận việc bỏ qua ban đầu tham số tên máy chủ trong tài liệu về Protected Audience API Server KV. Chúng tôi muốn đảm bảo với nhà phát triển rằng tên miền của người bán tự động được đưa vào các yêu cầu tới máy chủ đáng tin cậy của người bán. Chức năng này đóng vai trò thiết yếu đối với những quy trình xác thực quảng cáo hiệu quả. Chúng tôi đã cập nhật tài liệu để giải quyết hoạt động giám sát này và sẽ tiếp tục ưu tiên sự rõ ràng và tính minh bạch đối với cộng đồng nhà phát triển. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Các phương pháp có thể dùng để đưa tên IG vào lệnh gọi theo dõi lượt hiển thị quảng cáo cho mục đích báo cáo.	Chúng tôi cam kết cân bằng nhu cầu sử dụng các cơ chế báo cáo mạnh mẽ với nguyên tắc cơ bản về quyền riêng tư của người dùng. Việc đưa tên IG vào hoạt động theo dõi lượt hiển thị quảng cáo phải tuân theo các biện pháp bảo vệ ẩn danh k – được thiết kế để ngăn việc nhận dạng các cá nhân. Chúng tôi sẽ tiếp tục khám phá các giải pháp báo cáo đổi mới trong những hạn chế về quyền riêng tư này. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Tính năng API	Yêu cầu máy chủ đáng tin cậy của người mua nhận các tiêu đề HTTP của Gợi ý từ ứng dụng.	Chúng tôi đang theo dõi yêu cầu về tính năng này tại đây.
Việc Sử Dụng API	Liệu tệp uỷ quyền có yêu cầu tiêu đề "Access-Control-Allow-Origin" để tải hay không, vì tệp đó quy định hành vi của tư cách thành viên IG đối với trình duyệt?	Chúng tôi cam kết tuân thủ các phương pháp hay nhất về bảo mật web. Yêu cầu về tiêu đề "Access-Control-Allow-Origin" cho các tệp uỷ quyền giúp đảm bảo tính nhất quán với các nguyên tắc của CORS và ngăn việc vô tình tiết lộ thông tin nhạy cảm. Chúng tôi đang nghiên cứu cách để tối ưu hoá quy trình này trong khi vẫn duy trì khả năng bảo mật mạnh mẽ. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Cho phép máy chủ quảng cáo cá nhân hoá mẫu quảng cáo trong khung API PA.	Chúng tôi hiểu vai trò của máy chủ quảng cáo trong hoạt động cá nhân hoá mẫu quảng cáo. Chúng tôi đang tích cực tìm hiểu các giải pháp giúp hỗ trợ các máy chủ quảng cáo trong API PA, chẳng hạn như mô hình "IG chung" có thể kết hợp logic đặt giá thầu và lựa chọn mẫu quảng cáo. Mục tiêu của chúng tôi là đạt được sự cân bằng giữa việc khai thác các chức năng mạnh mẽ của mẫu quảng cáo và việc bảo vệ quyền riêng tư của người dùng. Chúng tôi hoan nghênh cộng tác và đóng góp thêm ý kiến phản hồi về việc phát triển API này cho phù hợp với nhu cầu của tất cả các bên liên quan tại đây.
Vấn đề Bảo mật	Phạm vi cung cấp các giá trị nhận dạng thay thế (ví dụ: RampID, ID5) trong yêu cầu giá thầu theo ngữ cảnh có thể làm giảm mục tiêu về quyền riêng tư của API PA bằng cách hỗ trợ việc thu thập dữ liệu trên nhiều trang web.	Chúng tôi nhận thấy sự căng thẳng tiềm ẩn giữa giá trị nhận dạng trên nhiều trang web và mục tiêu về quyền riêng tư của PA API. Mặc dù nhà xuất bản có thể chọn chia sẻ các giá trị nhận dạng như vậy, nhưng về cơ bản, thiết kế của PA API nhằm tách biệt lựa chọn quảng cáo khỏi nhu cầu theo dõi trên nhiều trang web. Chúng tôi cam kết thúc đẩy một hệ sinh thái quảng cáo chú trọng vào quyền riêng tư và khuyến khích các nhà phát triển ưu tiên sử dụng phương pháp API PA. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Chức năng lưu vào bộ nhớ đệm	Có cách nào để ngăn việc sử dụng lại tập lệnh đặt giá thầu trong nhiều phiên đấu giá không?	Chúng tôi xác nhận hành vi lưu vào bộ nhớ đệm đã ghi nhận được của các tập lệnh đặt giá thầu trong khung API PA. Mặc dù các cơ chế lưu vào bộ nhớ đệm HTTP chuẩn được hỗ trợ, nhưng vẫn có khả năng tập lệnh được sử dụng lại trong các phiên đấu giá do hành vi tạm ngưng thiết bị và do thiết kế của các executor đặt giá thầu. Nhóm đang nghiên cứu các giải pháp giúp người mua có nhiều quyền kiểm soát hơn đối với việc lưu tập lệnh vào bộ nhớ đệm nhằm quản lý hiệu quả các chiến lược đặt giá thầu. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Tập trung báo cáo về hoạt động đặt giá thầu trên tất cả các IG cho DSP trong khi vẫn tôn trọng quyền riêng tư của người dùng.	Chúng tôi ưu tiên quyền riêng tư của người dùng khi thiết kế API PA. Mặc dù không thể báo cáo trực tiếp các sự kiện đặt giá thầu riêng lẻ do những rủi ro theo dõi trên nhiều trang web, nhưng chúng tôi có các cơ chế như Bộ nhớ dùng chung và Tổng hợp riêng tư. Việc này giúp các DSP thu thập thông tin chi tiết tổng hợp về hoạt động đặt giá thầu theo cách bảo đảm quyền riêng tư của người dùng.
Việc Sử Dụng API	Việc tìm nạp từ sendReportTo() trong reportResult() chỉ xảy ra 94% thời gian liên quan đến việc tìm nạp được đăng ký bằng forDebuggingOnly.reportAdBidWin().	Mặc dù chúng có thể không có cùng thời gian, nhưng có thể hai URL được tìm nạp cùng lúc. Trong một số trường hợp, worklet của người bán thành phần đã bị loại bỏ và cần tải lại để sau đó chạy hàm reportResult(). Tuy nhiên, cả thời gian tìm nạp logic tính điểm lẫn thời gian tải lại worklet đều ảnh hưởng đến thời gian chờ 50 mili giây của reportResult(). Xin lưu ý rằng Chrome sẽ sử dụng tiêu đề lưu vào bộ nhớ đệm để xác định hành vi tìm nạp trong trường hợp worklet cần tải lại. Bạn có thể tìm hiểu thêm về các giai đoạn của phiên đấu giá PA tại đây.
Ẩn danh K	Yêu cầu xác nhận rằng tên của nhóminterest không ảnh hưởng đến tính ẩn danh k của việc phân phát quảng cáo.	Để một mẫu quảng cáo được xem là k-anonymous, bộ URL của chủ sở hữu IG, URL tập lệnh đặt giá thầu, URL mẫu quảng cáo và kích thước quảng cáo phải đáp ứng ngưỡng được chỉ định (k) trong một khoảng thời gian qua (w). Trạng thái k-anonymity được cập nhật định kỳ (p).
Giao diện người dùng Chrome	Đề xuất cung cấp loại "khả năng hiển thị nội bộ" mà nhiều khung MVC, ORM, v.v. cung cấp. Ví dụ: bắt đầu bằng việc ghi nhật ký đơn giản các sự kiện nội bộ đã chọn vào một bảng điều khiển mới trong Công cụ dành cho nhà phát triển --> Ứng dụng --> phần Ứng dụng	Chúng tôi đang thảo luận đề xuất tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Giao diện người dùng Chrome	Việc tham gia IG của Công cụ dành cho nhà phát triển không hiển thị các yếu tố liên quan đến mức độ ưu tiên.	Chúng tôi đã giải quyết vấn đề này tại đây.
Cải tiến API	Máy chủ quảng cáo của mẫu quảng cáo nên theo dõi các sự kiện của riêng nó. Có thể định cấu hình danh sách các miền theo dõi được phép không?	Chúng tôi đã chia sẻ đề xuất tại đây và hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái.
Yêu cầu tính năng API	PA API có thể được mở rộng để hỗ trợ các giao dịch truyền thông không phải RTB và duy trì các trường hợp sử dụng quan trọng như phân phát quảng cáo và DCO không?	Chúng tôi đang thảo luận vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Thời gian chờ phiên đấu giá của nhà xuất bản	Nhà xuất bản cần kiểm soát thời lượng phiên đấu giá để ngăn chặn hiển thị bị mất, đặc biệt là trong thiết lập đặt giá thầu dựa vào tiêu đề mà quảng cáo được chọn tuần tự.	Chúng tôi hiểu tầm quan trọng của việc cung cấp cho nhà xuất bản quyền kiểm soát chi tiết đối với thời gian chờ của phiên đấu giá quảng cáo. Chúng tôi đang tích cực tìm hiểu cách triển khai cơ chế hết thời gian chờ đấu giá toàn cầu, có thể nằm trong đối tượng "auctionConfig", đồng thời xem xét cẩn thận các trường hợp hiếm gặp. Tính năng này nhằm tối ưu hoá tỷ lệ lấp đầy lượt hiển thị cho nhà xuất bản và chúng tôi sẽ tiếp tục cộng tác với cộng đồng để tìm ra giải pháp tốt nhất. Chúng tôi đang thảo luận vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Cải tiến API	Thiết kế hiện tại của IG trong API PA dẫn đến kích thước siêu dữ liệu lớn do các URL kết xuất dài. Người kiểm tra muốn nén các URL này để đạt hiệu quả cao hơn.	Chúng tôi hiểu tầm quan trọng của việc tối ưu hoá kích thước siêu dữ liệu IG, đặc biệt đối với các phiên đấu giá quảng cáo đòi hỏi tính hiệu quả. Chúng tôi cho rằng giải pháp nén URL kết xuất dựa trên mẫu cung cấp tiềm năng đáng kể. Chúng tôi sẽ đánh giá kỹ lưỡng các thiết kế mẫu được đề xuất và đảm bảo rằng mọi giải pháp được triển khai đều có cơ chế mạnh mẽ ngăn chặn hành vi sai trái để duy trì sự ổn định của trình duyệt. Ưu tiên việc hợp tác với cộng đồng các tiêu chuẩn web để phát triển phương pháp tối ưu, có lưu ý đến những yếu tố này. Chúng tôi đang thảo luận vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Người kiểm thử xử lý các định dạng quảng cáo gốc muốn tối ưu hoá quy trình đấu giá Hộp cát về quyền riêng tư bằng cách truy xuất nhiều kết quả quảng cáo trong một lệnh gọi duy nhất để giảm tải trên mạng và cải thiện tốc độ hiển thị quảng cáo.	Chúng tôi hiểu những mối lo ngại về hiệu suất xảy ra khi hiển thị quảng cáo gốc trong Hộp cát về quyền riêng tư. Chúng tôi cam kết cân bằng giữa tính hiệu quả và các biện pháp mạnh mẽ để bảo vệ quyền riêng tư của người dùng. Mặc dù việc trả về nhiều quảng cáo có điểm số đầy đủ ảnh hưởng đến quyền riêng tư, nhưng chúng tôi vẫn đang tích cực tìm hiểu các cách để tối ưu hoá quy trình đấu giá. Chúng tôi tập trung tăng cường khả năng hỗ trợ API PA cho các định dạng quảng cáo gốc và nghiên cứu các cơ chế thay thế để cải thiện hiệu quả trong những hạn chế nghiêm ngặt về quyền riêng tư của Hộp cát về quyền riêng tư. Chúng tôi đang thảo luận vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Tính linh hoạt trong cách tính điểm và sắp xếp giá thầu quảng cáo trong Hộp cát về quyền riêng tư, đặc biệt là để thể hiện các mức độ ưu tiên hoặc các quy tắc của thị trường tư nhân.	Chúng tôi hiểu nhu cầu kiểm soát chi tiết việc tính điểm và sắp xếp quảng cáo trong Hộp cát về quyền riêng tư, đặc biệt là trong các tình huống đặt giá thầu phức tạp. Chúng tôi công nhận các giải pháp được đề xuất bằng cách sử dụng bộ dữ liệu và hàm toán học để đạt được điểm đa chiều mà không ảnh hưởng đến quyền riêng tư của người dùng. Mặc dù những phương pháp này có thể khiến nhà phát triển trở nên phức tạp, nhưng chúng vẫn cung cấp được nội dung cần thiết. Chúng tôi cam kết tìm cách đơn giản hoá các quy trình này, có thể là thông qua các chức năng hoặc nguyên tắc trợ giúp, để đảm bảo sử dụng tối ưu các tính năng của Hộp cát về quyền riêng tư cho logic đấu giá nâng cao. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
reportEvent()	Thêm một sự kiện đặt trước mới (có thể là báo hiệu tự động) được trình duyệt kích hoạt sau khi khởi chạy một khung có mẫu quảng cáo.	Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
adCost	Cho phép phân tích chi tiết adCost.	Mỗi giá trị chi phí là một cơ hội để gửi một lượng thông tin hạn chế ra khỏi phiên đấu giá. Việc chỉ định toàn bộ danh sách N chi phí đó là đủ để gửi toàn bộ giá trị nhận dạng người dùng, qua đó cho phép theo dõi trên nhiều trang web. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
resolveToConfig	Có nên kế thừa resolveToConfig từ cấp cao nhất và hiển thị trong browserSignals không?	Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Công cụ tốt hơn	Có điều gì đó giống với chrome://topics-internals nhưng dành cho API PA không?	Không có gì giống hệt nhau. Tuy nhiên, có công cụ mở rộng dành cho nhà phát triển cho PA API.
Nhãn	Chrome có thể sử dụng nhãn để xác định 20% tổng số k-anon không?	Chúng tôi đang xem xét yêu cầu này và hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái.
Tài liệu	Worklet đấu giá cho Hộp cát về quyền riêng tư có trở thành loại worklet tiêu chuẩn không?	Do các yêu cầu đặc thù về bảo mật và quyền riêng tư, các công việc này khác biệt đáng kể so với các loại worklet trình duyệt tiêu chuẩn. Vì vậy, chúng tôi không dự đoán rằng chúng sẽ sớm trở thành loại worklet tiêu chuẩn trong phần đặc tả HTML. Chúng tôi cam kết cải thiện nguồn lực nhà phát triển bằng cách giải thích rõ ràng về môi trường triển khai và thực thi các worklet đấu giá, giúp những người tham gia Hộp cát về quyền riêng tư dễ tiếp cận thông tin này hơn. Chúng tôi đã thảo luận thêm về vấn đề này tại đây.
Máy chủ Bring-Your-Own-Server (BYOS) Key-Giá trị (KV)	Các bên có thể biết được nhiều IG (từ cùng một chủ sở hữu) do người dùng tham gia thông qua các truy vấn về dịch vụ KV trong quá trình thiết lập Dịch vụ BYOS KV.	Điều này sẽ không thể thực hiện được khi máy chủ KV chạy trong TEE và chúng tôi có thể đảm bảo rằng chúng có thể tuân thủ mô hình tin cậy đã xuất bản.
userBiddingSignals	cập nhật một phần của "userBiddingSignals" trong khi vẫn duy trì các phần tử khác.	Bạn có thể làm được điều này mà không cần thay đổi gì đối với API.
Việc Sử Dụng API	Triển khai tính năng giới hạn tần suất trên nhiều IG trong Hộp cát về quyền riêng tư, có thể bằng cách sử dụng máy chủ KV hoặc dữ liệu " thìWinsMs" đã sửa đổi.	Chúng tôi thừa nhận mong muốn có các tính năng giới hạn tần suất nâng cao trong Hộp cát về quyền riêng tư. Chúng tôi nhận thấy rằng các quy định hạn chế hiện tại về việc chia sẻ dữ liệu trên các IG có thể đặt ra nhiều thách thức khi triển khai các chiến lược này. Mặc dù máy chủ KV cung cấp một cơ chế tiềm năng kèm theo các biện pháp bảo vệ quyền riêng tư phù hợp, nhưng các nhà phát triển nên tìm hiểu các giải pháp trong một mô hình IG duy nhất. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Việc Sử Dụng API	Người bán thành phần (những người tham gia các phiên đấu giá lồng nhau trong Hộp cát về quyền riêng tư) cần nắm rõ thời gian chờ của phiên đấu giá cấp cao nhất để tối ưu hoá cấu hình của riêng họ và tránh sự chậm trễ không cần thiết.	Chúng tôi nhận thấy nhu cầu cải thiện việc phối hợp thời gian chờ giữa người bán cấp cao nhất và người bán thành phần trong Hộp cát về quyền riêng tư. Chúng tôi đang tích cực điều tra việc bổ sung cơ chế thời gian chờ mới, bao gồm cả thời gian chờ tiềm năng cho toàn bộ phiên đấu giá và tìm hiểu các cách áp dụng thời gian chờ ở cấp cao nhất cho các phiên đấu giá thành phần. Mục tiêu của chúng tôi là tăng tính hiệu quả và khả năng dự đoán cho tất cả người tham gia quá trình đấu giá Hộp cát về quyền riêng tư. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.

Dịch vụ Protected Audience

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Môi trường thực thi đáng tin cậy (TEE)	Việc vận hành TEE trên đám mây công cộng có tốn kém hơn so với việc vận hành trung tâm dữ liệu công nghệ quảng cáo tại chỗ không?	Phản hồi của chúng tôi tương tự như các quý trước: Mô hình bảo mật TEE hiện tại của chúng tôi được hưởng lợi từ các phương pháp triển khai đám mây công cộng. Cụ thể, các TEE dựa trên phần cứng hiện tại không chống lại được mọi cuộc tấn công vật lý. Các nhà cung cấp dịch vụ đám mây công cộng được hỗ trợ hiện tại của chúng tôi là AWS và GCP, đã thiết kế và triển khai các giải pháp giảm thiểu rủi ro khi truy cập vật lý, bao gồm cả rủi ro của nhân viên. Vui lòng xem thêm thông tin chi tiết dưới đây về dịch vụ hỗ trợ tại chỗ. Các công nghệ quảng cáo cho chúng tôi biết rằng việc vận hành dịch vụ đám mây sẽ tốn kém hơn so với các trung tâm dữ liệu công nghệ quảng cáo đặt tại cơ sở hạ tầng riêng. Mặc dù không có quyền đánh giá những nội dung đó, nhưng chúng tôi hoan nghênh ý kiến phản hồi bổ sung về chi phí và tiếp tục xem xét các phương án mở rộng dịch vụ hỗ trợ TEE.
TEE	Hỗ trợ TEE trong môi trường đám mây không công khai	Phản hồi của chúng tôi tương tự như các quý trước: Mặc dù chúng tôi vẫn đang tiếp tục tìm hiểu khả năng hỗ trợ cho các lựa chọn khác ngoài các giải pháp công khai trên đám mây, nhưng hiện tại chúng tôi chưa có kế hoạch hỗ trợ các TEE tại chỗ. Ở giai đoạn này, trước các yêu cầu về bảo mật của Hộp cát về quyền riêng tư cũng như những thách thức quan trọng khi triển khai tại cơ sở riêng, chúng tôi tin rằng việc tiếp tục mở rộng và cải thiện việc triển khai trên đám mây (ví dụ: hỗ trợ Google Cloud ngoài AWS) sẽ có lợi nhất cho hệ sinh thái. Tuy nhiên, chúng tôi hoan nghênh ý kiến phản hồi bổ sung về lý do yêu cầu này là cần thiết và khả thi, do có những hạn chế về quyền riêng tư và bảo mật.
Nhà cung cấp dịch vụ đám mây khác	Hỗ trợ các nhà cung cấp dịch vụ đám mây khác	Chúng tôi luôn đón nhận đề xuất của các nhà cung cấp dịch vụ đám mây khác. Tuy nhiên, hiện tại, chúng tôi dự định hỗ trợ GCP và AWS khi thực thi 3PCD. Hãy tham khảo thông tin giải thích này để biết thêm thông tin.
API Dịch vụ B&A	Google có định hướng như thế nào đối với B&A Services API? Phiên đấu giá này sẽ được ưu tiên hơn hay thấp hơn trong phiên đấu giá Protected Audience trên thiết bị của trình duyệt Chrome?	Phản hồi của chúng tôi tương tự như các quý trước: Chúng tôi vẫn cam kết thiết kế tính năng đặt giá thầu trên thiết bị cho Protected Audience hiện tại. Các dịch vụ B&A được đề xuất để tìm ra những giải pháp khả thi nhằm hỗ trợ một số trường hợp sử dụng có thể bị hạn chế về công suất tính toán hoặc tốc độ mạng của thiết bị.
Tiêu chuẩn hoá	Các dịch vụ B&A không trải qua quy trình tiêu chuẩn hoá.	Đề xuất về Dịch vụ B&A đang ở giữa một giai đoạn của quá trình tiêu chuẩn hoá và chúng tôi hoan nghênh các hoạt động tương tác khác để hỗ trợ mục tiêu đó. Đầu tiên, đề xuất này đang được thử nghiệm công khai thông qua các cuộc thảo luận mở tại W3C và các nhà phát triển quan tâm có thể bắt đầu thử nghiệm và đưa ra ý kiến phản hồi. Đây là mô hình thông thường để phát triển tính năng web, như mô tả ví dụ trong bài đăng trên blog của chúng tôi tại đây.
Máy chủ KV	Hiển thị URL đầy đủ đến máy chủ KV của người mua để nhắm mục tiêu theo nội dung / theo ngữ cảnh / trang web.	Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh những ý kiến phản hồi khác từ hệ sinh thái.
Tài liệu	Tài liệu về "Các thành phần đáng tin cậy/được thực thi so với các thành phần không bắt buộc" trên GitHub gây nhầm lẫn với một số công nghệ quảng cáo có bộ hình ảnh và cơ sở hạ tầng triển khai riêng.	Chúng tôi đang tìm cách cải thiện tài liệu cho "Thành phần đáng tin cậy/bắt buộc so với thành phần bắt buộc" và mong muốn nhận được thông tin từ hệ sinh thái nếu công việc đó cần được ưu tiên.
Cải tiến API	Bạn cũng phải có Mã trạng thái HTTP của lệnh gọi từ máy chủ KV cho hàm scoreAd() dưới dạng thông số.	Chúng tôi đang đánh giá yêu cầu này và hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái.
Tài liệu	Cung cấp thêm thông tin về cách xử lý chính xác khối lượng công việc JS và WASM khi thực thi UDF.	Chúng tôi đang xem xét việc cung cấp thông tin này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây.
Tài liệu	Yêu cầu cập nhật tên kho lưu trữ.	Chúng tôi đã đổi tên kho lưu trữ thành "Protected-auction-key-value-service". Điều này phù hợp với thuật ngữ tập hợp các dịch vụ của kho lưu trữ này, đồng thời có các kho lưu trữ khác như cuộc thảo luận về Protected Audience Services và kho lưu trữ tài liệu về Dịch vụ phiên đấu giá được bảo vệ.
Tài liệu	Xoá nội dung tham chiếu đến API Trình gỡ lỗi đám mây trong Bidding_auction_services_gcp_guide.md.	Chúng tôi đã cập nhật tài liệu và xoá tệp đối chiếu đó.
Việc Sử Dụng API	Độ trễ do hoạt động tra cứu KV đưa ra mất hơn 50 mili giây. Quá trình này mất gần 100 mili giây. Bạn có hướng dẫn nào về những mặt hàng đang mang lại hiệu quả cho những người bán khác không? Bạn có đề xuất nào về cách đo thời gian chờ và thời gian không?	Cuộc gọi máy chủ KV xảy ra bên trong ngữ cảnh của Script Runners, tức là môi trường được bảo vệ đặc biệt bên trong trình duyệt Chrome. Mục đích là bảo vệ thông tin trong các trình chạy tập lệnh này khỏi mọi quyền truy cập không phải API. Chúng tôi đã cung cấp thông tin giải thích chi tiết tại đây.
Việc Sử Dụng API	Máy chủ KV có hết thời gian chờ phản hồi trong một thời gian cụ thể không?	Người bán có thể chỉ định trường "per". Thời gian chờ này bao gồm thời gian cần thiết để tìm nạp các tín hiệu đặt giá thầu đáng tin cậy.
Độ trễ	Nhóm Hộp cát về quyền riêng tư đang làm việc như thế nào để giải quyết độ trễ?	Để biết những chiến lược mà chúng tôi đang tìm hiểu nhằm đảm bảo độ trễ luôn ở trong giới hạn có thể chấp nhận, hãy xem tại đây.

Đo lường quảng cáo kỹ thuật số

Báo cáo phân bổ (và các API khác)

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Tối ưu hoá chiến dịch thủ công	ARA không hỗ trợ tối ưu hoá chiến dịch theo cách thủ công.	Chúng tôi đã thảo luận về tình huống này với công nghệ quảng cáo và chỉ ra cách sử dụng ARA để hỗ trợ tối ưu hoá chiến dịch theo cách thủ công. ARA được xây dựng theo cách cho phép tuỳ chỉnh công nghệ quảng cáo và tính linh hoạt để giải quyết nhiều trường hợp sử dụng công nghệ quảng cáo. Chúng tôi đưa ra một số đề xuất bằng cách áp dụng các cấu hình linh hoạt khác nhau ở cấp sự kiện và sử dụng báo cáo cấp sự kiện cùng báo cáo tóm tắt để giảm ảnh hưởng của độ nhiễu, đồng thời đạt được các nhu cầu tối ưu hoá theo cách thủ công và tự động. Chúng tôi sẵn sàng tiếp nhận thêm ý kiến phản hồi về hệ sinh thái liên quan đến khả năng tuỳ chỉnh và tính linh hoạt của các cấu hình ARA.
Loại Chuyển Đổi	Google chỉ cho phép 8 loại chuyển đổi bị hạn chế.	Chúng tôi đã triển khai phần lớn Báo cáo cấp sự kiện linh hoạt, tính năng này giúp các công nghệ quảng cáo có thêm sự linh hoạt về số khoảng thời gian báo cáo, số lượng báo cáo phân bổ và lượng dữ liệu điều kiện kích hoạt mà chúng có thể sử dụng. Công nghệ quảng cáo có thể chọn một cấu hình cho phép đo lường tối đa 32 loại chuyển đổi.
Giới hạn sự kiện báo cáo tổng hợp	Mỗi báo cáo có thể tổng hợp nên có số sự kiện chuyển đổi tối thiểu là 20 sự kiện cho những nhà quảng cáo nhỏ có ngân sách hạn chế.	Mỗi báo cáo tổng hợp không yêu cầu số lượng sự kiện chuyển đổi tối thiểu cần thiết. Ngoài ra, bạn có thể đưa ra một số quyết định thiết kế để tối ưu hoá báo cáo tổng hợp cho các nhà quảng cáo nhỏ hơn, chẳng hạn như thay đổi cấu trúc khoá / phương diện được theo dõi, thử nghiệm nhiều cấp độ epsilon, kiểm thử tần suất tạo lô dài hơn và thử nghiệm nhiều mức phân bổ ngân sách đóng góp giữa các mục tiêu đo lường. Công nghệ quảng cáo nhỏ hơn cũng có thể thử nghiệm việc kết hợp các báo cáo cấp sự kiện và báo cáo tóm tắt để giảm độ nhiễu.
Dữ liệu theo thời gian thực	Việc tước bỏ dữ liệu theo thời gian thực cho các DSP (ví dụ: số lượt nhấp, số phiên và số lượt chuyển đổi) mà các DSP dùng để điều chỉnh chiến lược đặt giá thầu và đạt được hiệu quả cao hơn của chiến dịch, đi kèm với cam kết duy trì các chức năng hiện có.	Ngay cả với ARA, số nhấp chuột và số phiên vẫn theo thời gian thực và chuyển đổi luôn sau thực tế ngay cả với 3PC.
Các trường bị thiếu	Thiếu các yêu cầu trong việc triển khai sự kiện hoàn toàn linh hoạt: i) trường đơn vị tiền tệ và ii) trường orderID / TransactionID.	Chúng tôi hiện không có kế hoạch hỗ trợ trường Đơn vị tiền tệ hoặc trường Mã đơn hàng / Mã giao dịch trong cấp sự kiện linh hoạt hoàn toàn vì đã có nhiều cách để thực hiện việc này thông qua báo cáo hiện tại ở cấp sự kiện. Chúng tôi sẵn sàng đón nhận thêm ý kiến phản hồi về các trường này và sẽ xem xét lại nếu có thêm trường hợp sử dụng nào khác cũng cần các trường này. Cách sử dụng thiết kế hiện tại của ARA để đo lường đơn vị tiền tệ và thông tin về loại mã đơn hàng: 1. Dựa trên ý kiến phản hồi, đơn vị tiền tệ được xác định theo vị trí địa lý của người dùng. Bạn có thể thêm đơn vị tiền tệ này dưới dạng source_event_id để xác định đơn vị tiền tệ mà họ đã sử dụng. 2. Dựa trên phản hồi, trường mã đơn hàng cần thiết để đảm bảo lượt chuyển đổi và giá trị không được tính hai lần do nhầm lẫn, việc này có thể được thực hiện bằng cách sử dụng khoá loại bỏ trùng lặp.
Ngân sách quyền riêng tư	Ngân sách quyền riêng tư của ARA giới hạn khả năng đo lường trên nhiều phương diện	ARA được thiết kế theo cách cho phép các công nghệ quảng cáo tuỳ chỉnh cấu hình ARA của riêng chúng nhằm đáp ứng nhiều tình huống phân bổ. Với thiết kế ARA hiện tại, các công nghệ quảng cáo sẽ cần phải suy nghĩ về sự đánh đổi giữa những kích thước quan trọng nhất đối với việc đo lường và tác động của độ nhiễu đối với dữ liệu. Việc thêm nhiễu vào dữ liệu tuỳ thuộc vào mức độ chi tiết của các phương diện đang được đo lường là cần thiết để đảm bảo quyền riêng tư. Chúng tôi sẵn sàng nhận thêm ý kiến phản hồi của hệ sinh thái liên quan đến khả năng đo lường nhiều phương diện. Tuy nhiên, chúng tôi cần hiểu rõ những trường hợp sử dụng cụ thể đòi hỏi việc này.
Cập nhật thông số kỹ thuật	Mặc dù Google cho biết họ đã chuyển từ khoảng thời gian báo cáo sự kiện cố định sang linh hoạt, nhưng thay đổi này vẫn chưa được thể hiện trong Quy cách kỹ thuật của Google vì hiện vẫn có khoảng thời gian tối thiểu là một giờ.	Tính năng báo cáo cấp sự kiện linh hoạt hiện cho phép các công nghệ quảng cáo thay đổi số lượng báo cáo phân bổ trên mỗi sự kiện nguồn, số bit của dữ liệu điều kiện kích hoạt và số lượng/độ dài của khoảng thời gian báo cáo. ARA vẫn có khoảng thời gian báo cáo tối thiểu là 1 giờ đối với các báo cáo cấp sự kiện. Đây là khoảng thời gian cần thiết để duy trì quyền riêng tư và giảm thiểu một số loại tấn công tái thiết nhật ký. Vì báo cáo tóm tắt cung cấp thông tin ở dạng tổng hợp, nên công nghệ quảng cáo có thể chọn nhận báo cáo tổng hợp ngay lập tức mà không bị trì hoãn nếu cần cho các trường hợp sử dụng.
Thiết kế API	Lo ngại rằng việc giảm thông tin trong báo cáo lượt chuyển đổi và tăng độ nhiễu có thể ảnh hưởng đến hệ sinh thái nhiều hơn Google.	Google đã cam kết theo CMA để thiết kế và triển khai các đề xuất trong khuôn khổ Hộp cát về quyền riêng tư sao cho không cản trở sự cạnh tranh bằng việc tự ưu tiên hoạt động kinh doanh của chính Google, đồng thời có tính đến tác động đối với sự cạnh tranh trong quảng cáo kỹ thuật số, cũng như đến các nhà xuất bản và nhà quảng cáo thuộc mọi quy mô.
Sửa lỗi phân bổ	ARA không cho phép nhà cung cấp công nghệ kiểm soát và xác minh mô hình phân bổ chính xác.	Có nhiều giải pháp có sẵn trong ARA để cung cấp khả năng xác minh: 1. Công nghệ quảng cáo có thể xác minh rằng hành vi của ARA đáp ứng được kỳ vọng của họ: – Mã phía máy khách của ARA là mã nguồn mở. – Mã phía máy chủ của ARA cũng là nguồn mở và Điều phối viên đảm bảo rằng chỉ những phiên bản được phép của Dịch vụ tổng hợp mới có thể giải mã và xử lý báo cáo tổng hợp. 2. Chrome đã cung cấp cho các công nghệ quảng cáo một Thư viện mô phỏng để xác minh hành vi phân bổ, trong đó, công nghệ quảng cáo có thể kiểm tra cách ARA thực hiện hoạt động phân bổ trong môi trường mô phỏng. 3. ARA hỗ trợ một số tín hiệu gỡ lỗi giúp xác minh xem có thể hay không và lý do khiến quá trình xử lý dự kiến có thể không xảy ra.
(Cũng được báo cáo trong các quý trước) Tiếng ồn	Ý kiến phản hồi cho biết mức độ nhiễu quá cao và ảnh hưởng đến tính hữu ích của báo cáo.	Chúng tôi đã thảo luận với các công nghệ quảng cáo về cùng ý kiến phản hồi này và có thể xác định được cách tuỳ chỉnh ARA cho phù hợp hơn với trường hợp sử dụng của họ, ngay cả khi gây nhiễu. Chúng tôi có tài liệu dành cho nhà phát triển trong đó chứa phần lớn các quyết định thiết kế và cách tuỳ chỉnh mà chúng tôi đã thảo luận với các công nghệ quảng cáo. ARA được thiết kế theo cách cho phép các công nghệ quảng cáo tuỳ chỉnh cấu hình ARA của riêng chúng nhằm xử lý nhiều tình huống phân bổ. Tuy nhiên, các công nghệ quảng cáo sẽ cần phải cân nhắc đến sự đánh đổi giữa những kích thước quan trọng nhất đối với việc đo lường và tác động của độ nhiễu đối với dữ liệu. Chúng tôi sẵn sàng đón nhận thêm ý kiến phản hồi về hệ sinh thái liên quan đến tác động của độ nhiễu và có thể hướng dẫn thêm về các đòn bẩy ARA có thể dùng để thay đổi tác động của độ nhiễu.
Phân bổ trên nhiều miền	Cách theo dõi các lượt phân bổ trên nhiều miền?	Công nghệ quảng cáo có thể chuyển hướng đến nhiều URL báo cáo để giải quyết trường hợp sử dụng này. Chúng tôi sẵn sàng tiếp nhận thêm ý kiến phản hồi về hệ sinh thái liên quan đến khía cạnh thiết kế này của ARA.
Cải tiến API	Thường xuyên thay đổi hệ số tỷ lệ dùng khi đăng ký mô hình phân bổ cho Báo cáo tóm tắt của ARA.	Dựa trên cuộc thảo luận trên GitHub, có vẻ như việc xử lý nhiều hệ số tỷ lệ trong Dịch vụ tổng hợp nhiều khả năng sẽ dẫn đến độ nhiễu cao hơn trong báo cáo tóm tắt so với chức năng hiện tại. Chúng tôi sẵn sàng nhận thêm ý kiến phản hồi về nhu cầu sử dụng hệ số tỷ lệ trong báo cáo tổng hợp, nhưng muốn đề cập đến khả năng đánh đổi bằng độ nhiễu tăng. Chúng tôi cũng đang đánh giá xem các tính năng khác của ARA trong tương lai có thể giúp giải quyết trường hợp sử dụng này hay không.
Việc Sử Dụng API	Cơ hội thống nhất cách chia sẻ sự kiện phân bổ với tất cả người tham gia, có lợi cho SSP, DSP, v.v.	Chúng tôi dự định đồng bộ hoá với công nghệ quảng cáo để hiểu rõ hơn về ý kiến phản hồi của người dùng và mọi hạn chế mà họ gặp phải.
Thử nghiệm lưu lượng truy cập	Lưu lượng truy cập thử nghiệm cho Chế độ B đối với tất cả Chrome có ổn định không?	Việc thêm vào nhóm thử nghiệm sẽ không bị ảnh hưởng bởi (độc lập với) các chế độ cài đặt của Chrome.
Tài liệu	Hỗ trợ ARA cho pixel.	Chúng tôi đã công bố thông tin về cách hỗ trợ trường hợp sử dụng này và hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái.
Việc Sử Dụng API	ARA có thể không được phân bổ cho đúng nguồn cho người bán bên thứ ba trên các nền tảng thương mại điện tử nếu lượt chuyển đổi không được thực hiện ngay từ lần chạm cuối cùng.	Các công ty có thể sử dụng bộ lọc để ngăn chặn tình trạng phân bổ không chính xác (vì sẽ không có báo cáo lượt chuyển đổi nào được tạo). Chúng tôi cũng đang xây dựng đề xuất về tính năng lọc trước khi phân bổ để hỗ trợ trường hợp sử dụng này.
Hỗ trợ trình duyệt	ARA có được hỗ trợ trong các trình duyệt khác không?	Chúng tôi hoan nghênh các trình duyệt khác áp dụng API Hộp cát về quyền riêng tư và tiếp tục dành thời gian để thảo luận về hướng tiếp cận công khai của chúng tôi tại W3C. Chúng tôi đã nêu rõ khả năng tương tác là mục tiêu để truyền tải thiết kế của ARA và ARA, không phụ thuộc vào trình duyệt, với các giá trị linh hoạt do nhà cung cấp chỉ định cho những nhà cung cấp có lập trường khác nhau về quyền riêng tư. Các trình duyệt khác đang tự lựa chọn xem có nên cung cấp các giải pháp thay thế khả thi cho giá trị nhận dạng nội dung và dịch vụ kỹ thuật số trên nhiều trang web hay không. Microsoft Edge nhận được thông báo rằng Microsoft Edge đã cho biết phiên bản này sẽ hỗ trợ ARA.
Việc Sử Dụng API	Loại nguồn dự kiến cho các lượt đăng ký nguồn ARA cho registerAdBeacon/reportEvent (và navigation_start/commit báo hiệu tự động) là gì?	Điều này phụ thuộc vào việc các beacon này là tự động hay thủ công: – đặt trước.* sự kiện (tức là tự động) thành loại nguồn điều hướng. – Sự kiện được kích hoạt theo cách thủ công thuộc loại nguồn sự kiện.
Việc Sử Dụng API	Giới hạn tối đa 20 báo cáo tổng hợp cho mỗi nguồn có nghĩa là gì cho mỗi sự kiện nguồn không? Hạn mức này là trên toàn cầu hay hằng ngày? Google có dự định tăng giới hạn này không?	20 báo cáo tổng hợp cho mỗi giới hạn nguồn là giới hạn chung, trong đó bạn có thể tạo 20 báo cáo tổng hợp cho mỗi nguồn. Giới hạn này do trình duyệt đặt ra và không thể định cấu hình. Mục đích của giới hạn này là để tránh lợi dụng tính năng bảo vệ báo cáo phân bổ thực bằng báo cáo rỗng. Chúng tôi đã thảo luận thêm về vấn đề này tại đây.
Việc Sử Dụng API	Hỗ trợ tiếp thị qua email bằng ARA.	Hiện tại, không có dịch vụ hỗ trợ trực tiếp cho trường hợp sử dụng này trong ARA (nếu bạn không có quyền kiểm soát trang web lưu trữ email). Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi.
Epsilon	Khi nào giá trị của epsilon cho API tổng hợp sẽ được xác định?	Các công nghệ quảng cáo có thể định cấu hình giá trị epsilon hiện tại đến một ngưỡng định sẵn do Hộp cát về quyền riêng tư (hiện là 64) xác định. Bạn nên thử nghiệm nhiều giá trị epsilon và xác định các điểm uốn cho trường hợp sử dụng của riêng mình, đồng thời đưa ra ý kiến phản hồi. Chúng tôi sẽ đảm bảo thông báo trước cho công nghệ quảng cáo trước khi có bất kỳ thay đổi nào về phạm vi giá trị epsilon.
Cải tiến API	Hỗ trợ trường hợp sử dụng mà nhà quảng cáo có thể chèn giá trị nhận dạng vào trường dữ liệu kích hoạt để so khớp với dữ liệu CRM bên ngoài, nhằm giúp nhà quảng cáo xác minh chất lượng của lượt chuyển đổi.	Chúng tôi đang thảo luận về yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây.
Việc Sử Dụng API	Cách xử lý URL chuyển hướng dưới dạng URL đích.	Công nghệ quảng cáo có thể làm những việc sau: 1. Đặt URL đích cuối cùng vào trường đích; 2. Trường đích cho phép tối đa 3 URL, cho phép bạn đặt nhiều URL vào trường này. Cả hai lựa chọn đều yêu cầu bạn phải biết URL đích cuối cùng. Chúng tôi đã thảo luận thêm về vấn đề này tại đây.

Dịch vụ tổng hợp

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Cơ chế khám phá khoá	Yêu cầu cơ chế khám phá khoá	Chúng tôi có một đề xuất về việc khám phá khoá và hoan nghênh ý kiến phản hồi của hệ sinh thái về đề xuất này.
Việc Sử Dụng API	Lộ trình để ghi nhận dịch vụ tổng hợp	Chúng tôi đang xem xét các phương án để tăng khả năng ghi nhận và hoan nghênh ý kiến phản hồi của hệ sinh thái tại đây.
Cải tiến API	Yêu cầu có thể truy vấn lại báo cáo.	Dịch vụ tổng hợp đang xử lý một đề xuất truy vấn lại, trong đó các công nghệ quảng cáo có thể phân tách epsilon của chúng cho mỗi báo cáo. Điều này có thể gây nhiễu hơn cho mỗi truy vấn, nhưng sẽ cho phép các công nghệ quảng cáo truy vấn lại và duy trì quyền riêng tư.
Cải tiến API	Muốn liên kết nhiều nguồn gốc với cùng một mã AWS.	Giờ đây, Dịch vụ tổng hợp sẽ cho phép đưa nhiều trang web vào cùng một tài khoản đám mây (GCP hoặc AWS). Việc này sẽ cho phép các công nghệ quảng cáo sử dụng cùng một Mạng lưới bảo mật dịch vụ tổng hợp để xử lý báo cáo của nhiều trang web và nhiều nguồn gốc của cùng một trang web.
Việc Sử Dụng API	Khi các lô tổng hợp bị lỗi, bạn không biết chắc liệu ngân sách đã được dùng hết hay chưa và liệu chúng có thể xử lý lại lô của mình hay không. Khi một dịch vụ tổng hợp gặp lỗi ngân sách đối với các báo cáo trùng lặp, những báo cáo còn lại sẽ bị mất. Làm cách nào để giảm thiểu tổn thất này?	Trong một trường hợp thông thường, nếu toàn bộ công việc không thành công, ngân sách sẽ không được dùng. Trong trường hợp một lỗi hiếm gặp xảy ra khi sử dụng hết ngân sách, công nghệ quảng cáo có thể yêu cầu khôi phục ngân sách. Nếu thường xuyên gặp lỗi khi hoạt động xảy ra lỗi hết ngân sách, công nghệ quảng cáo nên xác nhận chiến lược tạo lô của mình. Bạn có thể xem hướng dẫn về cách phân lô chính xác cũng như tránh các báo cáo và lỗi trùng lặp tại đây. Chúng tôi hoan nghênh ý kiến phản hồi về việc khôi phục ngân sách tại đây.
Việc Sử Dụng API	Việc sử dụng API tổng hợp riêng tư với điều kiện kích hoạt được mô tả tại đây sẽ tạo ra một báo cáo tổng hợp cho mỗi phiên đấu giá. Khả năng mở rộng quy mô của Dịch vụ tổng hợp là gì?	Bản thân Dịch vụ tổng hợp không đặt giới hạn trên về số lượng khoá hoặc báo cáo trong một lô. Tuy nhiên, hệ thống hiện không hỗ trợ quy mô 10^14 báo cáo và 10^12 khoá do bộ nhớ cần thiết. Hướng dẫn về kích thước của chúng tôi cho biết các phạm vi mà chúng tôi đã thử nghiệm và đề xuất để mang lại hiệu suất tối ưu với tải dự kiến và các loại phiên bản Cloud vm được hỗ trợ.
Xử lý dữ liệu	Nếu dữ liệu đã mã hoá có thông tin cá nhân thì thoả thuận pháp lý nào đối với việc cung cấp dữ liệu đã mã hoá cho Dịch vụ tổng hợp? Bạn có thể cho biết có đảm bảo rằng điều phối viên sẽ không truy cập vào dữ liệu đã mã hoá không?	Dịch vụ Tổng hợp không chia sẻ cho Điều phối viên dữ liệu người dùng / dữ liệu đã mã hoá. Dịch vụ Tổng hợp sử dụng trình điều phối để quản lý khoá và kế toán. Bạn có thể xem một số thông tin về người điều phối tại đây. Đối với hoạt động kế toán, dịch vụ Tổng hợp chỉ chia sẻ mã nhận dạng chung và nguồn gốc báo cáo với PBS để sử dụng ngân sách. Sau khi ra mắt trang web nhiều trang web, chúng tôi sẽ thay thế điểm gốc bằng trang web. Xin lưu ý rằng dịch vụ Tổng hợp chạy trong TEE, là nơi duy nhất có thể giải mã báo cáo của ứng dụng. Mã chạy trong TEE là mã nguồn mở và được các bên bên ngoài kiểm tra theo tại đây.

Private Aggregation API

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Việc Sử Dụng API	Khả năng người bán thành phần gửi báo cáo đến nhiều máy chủ tổng hợp trong một TEE.	Trạng thái hiện tại của API Tổng hợp riêng tư không hỗ trợ tính năng này. Chúng tôi đã thảo luận thêm về vấn đề này tại đây.
Tài liệu	Giá trị epsilon dùng trong các thử nghiệm của Google là bao nhiêu?	Đối với API tổng hợp riêng tư, giá trị ε được chỉ định trong một truy vấn dịch vụ tổng hợp tương ứng với hạn mức đóng góp L1 là 2^16 và được thực thi trong khoảng thời gian 10 phút. Ngoài ra, còn có ngân sách đóng góp L1 "backstop" là 2^20 được thực thi trên cơ sở 24 giờ luân phiên. Vì vậy, về cơ bản, tham số về quyền riêng tư là ε luân phiên trong 10 phút và 16ε trong 24 giờ luân phiên (thay vì 144ε). Dịch vụ tổng hợp hiện hỗ trợ một loạt ε để thử nghiệm (tối đa là 64) để cho phép thử nghiệm nhiều chiến lược tổng hợp và đưa ra ý kiến phản hồi về tiện ích của hệ thống với nhiều tham số về quyền riêng tư cho tính năng Tổng hợp riêng tư và các API khác. Chúng tôi dự định sau này sẽ xem xét lại giá trị epsilon tối đa khi nhận được ý kiến phản hồi của người kiểm thử và bổ sung các tính năng giúp sử dụng ngân sách quyền riêng tư hiệu quả hơn.

Giới hạn hoạt động theo dõi bí mật

Giảm thiểu tác nhân người dùng/Gợi ý ứng dụng tác nhân người dùng

Không nhận được phản hồi nào trong quý này.

Bảo vệ IP (trước đây là Gnatcatcher)

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Mã độ phân giải	Hộp cát về quyền riêng tư cần lên tiếng nhiều hơn để báo chí biết rằng mã giải pháp thường được tạo dựa trên IP sẽ không bền vững đối với nhà quảng cáo.	Hộp cát về quyền riêng tư đã nêu rõ rằng chúng tôi hướng đến việc giảm hoạt động theo dõi trên nhiều trang web. Các sáng kiến công khai của chúng tôi, ngoài cookie, được quảng bá cả trên privacysandbox.com và GitHub. Chúng tôi cố gắng giảm hoạt động theo dõi trên nhiều trang web, bao gồm cả hoạt động dựa trên địa chỉ IP. Tuy nhiên, cuối cùng các trang web riêng lẻ có quyết định xem có chủ động bật tính năng theo dõi trên nhiều trang web hay không. Trong thời đại ngày càng giám sát chặt chẽ việc tuân thủ quy định, các công ty cá nhân cần phải tìm hiểu kỹ về các phương thức mà nhà cung cấp dịch vụ của họ sử dụng.
Chromecast	Bảo vệ IP có ảnh hưởng đến Chromecast hoặc các thiết bị Chrome khác không?	Hiện chưa có kế hoạch nào cho việc áp dụng Bảo vệ IP cho các thiết bị Chromecast.
Danh sách bảo vệ IP	Danh sách các bên thứ ba được xác định là có khả năng sử dụng địa chỉ IP để theo dõi trên toàn trang web có được công bố không?	Danh sách này sẽ được xuất bản sau khi hoàn tất, như thảo luận tại đây.

Giảm hoạt động theo dõi số trang không truy cập

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Miễn trừ đăng nhập một lần (SSO)	Giải pháp giảm thiểu hoạt động theo dõi số trang không truy cập (BTM) sẽ xác minh các trường hợp sử dụng dịch vụ SSO để được miễn trừ như thế nào?	BTM sẽ bị tắt bởi tính năng phỏng đoán của Chrome. Xem tại đây để biết chi tiết.
Bản dùng thử không dùng nữa	BTM có được bật cho các trang web trong thử nghiệm ngừng sử dụng 3PC không?	Không, BTM tuân thủ các trường hợp ngoại lệ về cookie tạo ra trong quá trình dùng thử việc ngừng sử dụng, như được thảo luận tại đây.

Ngân sách quyền riêng tư

Như đã nêu trong tài liệu giải thích về GitHub và trang web dành cho nhà phát triển,chúng tôi không còn chủ động xem xét Ngân sách quyền riêng tư trong các đề xuất về Hộp cát về quyền riêng tư.

Củng cố ranh giới quyền riêng tư giữa nhiều trang web

Nhóm trang web có liên quan (trước đây là Nhóm bên thứ nhất)

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Yêu cầu tính năng	Các CHIP và / hoặc Phân vùng bộ nhớ sẽ tự động được cho phép truy cập trên RWS mà không cần API Truy cập bộ nhớ hay sự tương tác của người dùng.	Chúng tôi đang xem xét các lợi ích và tính khả thi của một tính năng có thể thực hiện chức năng này. Một yếu tố cần cân nhắc là lỗ hổng tiềm ẩn về khả năng tương tác trên nhiều trình duyệt mà RWS giải quyết bằng cách tận dụng Storage Access API (API Truy cập bộ nhớ). Hiện không có chức năng tương đương với chức năng được yêu cầu này được hỗ trợ trên các trình duyệt khác. Các nhà phát triển nên gửi các trường hợp sử dụng liên quan đến vấn đề này để thảo luận tại đây.
Xoá các Nhóm không tuân thủ	Quy trình xoá các tập hợp không tuân thủ khỏi kho lưu trữ là gì?	Chúng tôi đang nỗ lực xác định quy trình cho việc này và sẽ chia sẻ thông tin cập nhật ngay khi có sẵn.
Quy trình thực thi	Google không nêu rõ vai trò chủ quan của Google trong quy trình thực thi RWS.	Vì RWS là một dự án vẫn đang diễn ra và chúng tôi vẫn đang tiếp tục nhận được nội dung mới, nên các khía cạnh của quy trình và các tiêu chí của chúng tôi vẫn đang được củng cố. Chúng tôi đồng ý rằng nguyên tắc gửi bài của chúng tôi cần phải nêu ra đầy đủ các yêu cầu đối với quá trình gửi. Từ giờ trở đi, chúng tôi sẽ bổ sung chi tiết hơn vào nguyên tắc gửi bài để tránh gây nhầm lẫn và nhầm lẫn. Mục đích của chúng tôi là quy trình gửi bài dự thi phải mang tính kỹ thuật nhất có thể để chúng tôi có thể loại bỏ dần sự tham gia của con người mà hoàn toàn phụ thuộc vào quy trình kiểm tra tự động. Những PR như thế này đòi hỏi nhiều sự tương tác của con người hơn vì chúng bao gồm những hành vi mà chúng tôi không lường trước được, nhưng chúng cho phép chúng tôi xác định thêm nhiều lĩnh vực cho việc tự động hoá cũng như cách chúng tôi có thể khắc phục nguyên tắc của mình để tránh những vấn đề này trong tương lai.
Chia sẻ dữ liệu	Yêu cầu một tính năng cho phép chủ sở hữu miền cho biết rằng họ muốn có một bên thứ ba chia sẻ dữ liệu RWS khi đã có sự đồng ý của người dùng.	Chức năng yêu cầu đã có sẵn thông qua các API như FedCM và Storage Access API (API Quyền truy cập vào bộ nhớ) cho phép truy cập vào danh tính đã xác thực sau khi người dùng chấp nhận lời nhắc cấp quyền. Chúng tôi hoan nghênh ý kiến phản hồi của hệ sinh thái về bất kỳ trường hợp sử dụng cụ thể nào mà họ cho rằng không thể thực hiện được.
Các phương thức lưu trữ khác	Thông tin được lưu trên bộ nhớ cục bộ hoặc bộ nhớ phiên có cũng sẽ được hiểu là 3 máy tính không?	Bộ nhớ cục bộ, bộ nhớ phiên và các hình thức lưu trữ không phải cookie khác khi được sử dụng trong ngữ cảnh của bên thứ ba đã được phân vùng trong Chrome kể từ phiên bản 115. Xem bài đăng này trên blog để biết thêm chi tiết.
Giới hạn nhóm được liên kết	Điều gì xảy ra với những tổ chức gửi nhiều hơn 5 miền mặc dù "giới hạn ở 5 trang web được liên kết"?	Các nhóm này sẽ được chấp nhận thông qua quy trình GitHub, nhưng trình duyệt (Chrome) sẽ chỉ áp dụng các quy tắc cấp quyền tự động của Storage Access API cho 5 miền đầu tiên và bỏ qua các miền còn lại, như đã thảo luận tại đây.
find_robots_txt	quy trình kiểm tra find_robots_txt không hoạt động với các lệnh chuyển hướng.	Chúng tôi đã gửi bản sửa lỗi để giải quyết vấn đề này tại đây.
Cử chỉ của người dùng	Xoá yêu cầu về cử chỉ của người dùng đối với accessStorage().	Yêu cầu này được đưa ra dựa trên một thiết kế tương tự được áp dụng trên tất cả các trình duyệt chính cho API requestStorageAccess. Chúng tôi mong nhận được ý kiến phản hồi và các trường hợp sử dụng bổ sung trong vấn đề này trên GitHub để giúp chúng tôi ưu tiên giải quyết yêu cầu này, cũng như tạo điều kiện cho các cuộc thảo luận trên nhiều trình duyệt.
Cử chỉ của người dùng	Tôi có cần dùng cử chỉ của người dùng để cấp quyền truy cập vào bộ nhớ của bên thứ ba sau khi khởi động lại Chrome hoặc hệ điều hành không?	Có, nhưng chúng tôi hoan nghênh thêm ý kiến phản hồi từ hệ sinh thái về việc có thay đổi hành vi này hay không tại đây.

API Khung bảo vệ

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
adComponent	Thiếu tài liệu và thiếu tính linh hoạt khi sử dụng Thành phần quảng cáo với Khung được bảo vệ.	Chúng tôi muốn chia sẻ thêm tài liệu liên quan đến trường hợp sử dụng này. Ngoài ra, để bổ sung thêm, các thành phần quảng cáo được hỗ trợ trong Khung bảo vệ sử dụng getNestedConfigs() được ghi lại trong thông số kỹ thuật tại đây.
(Cũng được báo cáo trong các quý trước) Render adComponent	Yêu cầu mã mẫu về cách hiển thị adComponents trong Khung bảo vệ.	Chúng tôi đang chia sẻ một số mã mẫu tại đây.
Xác minh quảng cáo của bên thứ ba	Vai trò của quy trình xác minh quảng cáo của bên thứ ba trong bối cảnh của Khung bảo vệ cần thêm thông tin chi tiết, đặc biệt là về mức độ an toàn theo bối cảnh/thương hiệu.	Hiện nay, Báo cáo quảng cáo khung bảo vệ cho phép DSP gửi dữ liệu cấp sự kiện phiên đấu giá và lượt hiển thị cho trình xác minh quảng cáo bên thứ ba để kiểm tra và thanh toán an toàn thương hiệu sau khi hiển thị.
Quảng cáo có thể mở rộng	Yêu cầu hỗ trợ quảng cáo có thể mở rộng.	Nếu quảng cáo cần chuyển đổi giữa hai kích thước có cùng tỷ lệ khung hình và không có sự khác biệt về chức năng giữa hai kích thước này (chỉ kích thước), thì trình nhúng có thể đổi kích thước Khung bảo vệ với kích thước quảng cáo thứ hai và trình duyệt điều chỉnh tỷ lệ phần tử Khung bảo vệ sao cho phù hợp.
(Cũng được báo cáo trong các quý trước) Hỗ trợ khoảng không quảng cáo dạng video và khoảng không quảng cáo gốc	Khung bảo vệ có hỗ trợ khoảng không quảng cáo video và khoảng không quảng cáo gốc không?	Phản hồi của chúng tôi tương tự như các quý trước: API PA hỗ trợ kết xuất video bằng cơ chế dựa trên iframe. Tuy nhiên, chúng tôi chưa thiết kế giải pháp hiển thị quảng cáo gốc và quảng cáo video tương thích với Khung bảo vệ và đây là một trong những lý do khiến chúng tôi quyết định đẩy lùi việc thực thi Khung bảo vệ sang năm 2026. Điều đó có nghĩa là nếu một đối tác quyết định thực thi Khung bảo vệ ngay bây giờ, thì đối tác đó sẽ thiếu hỗ trợ cho video và gốc.
Ban cố vấn	Yêu cầu thành lập một ban cố vấn gồm các nhà cung cấp quảng cáo gốc để đảm bảo việc triển khai Khung bảo vệ tuân thủ các tiêu chuẩn ngành.	Bạn không bắt buộc phải sử dụng Khung bảo vệ trong API PA trước năm 2026. Khoảng thời gian bổ sung này giúp chúng tôi tiếp tục hợp tác với toàn ngành để thiết kế và hỗ trợ cho nhiều trường hợp sử dụng quan trọng hơn. Trước đây, chúng tôi đã tuyên bố rằng chúng tôi sẽ phát triển Khung bảo vệ trước yêu cầu duy trì khả năng hỗ trợ cho quảng cáo video và quảng cáo gốc với API PA. Theo cam kết của mình, chúng tôi sẽ tham gia và thông báo cho CMA về bất kỳ thay đổi nào như vậy và chúng tôi sẽ tiếp tục trao đổi với hệ sinh thái trước khi yêu cầu Khung bảo vệ. Mô hình tương tác với hệ sinh thái của chúng tôi tại W3C và các tổ chức tiêu chuẩn quảng cáo như IAB Tech Lab cho phép các chuyên gia trong ngành thuộc mọi kiểu định hướng thiết kế trước khi bắt buộc.
(Cũng được báo cáo trong các quý trước) Chênh lệch kích thước giữa các nền tảng	Báo cáo cho thấy kích thước của nội dung hiển thị trong Khung bảo vệ trông khác nhau giữa máy tính và điện thoại thông minh.	Đây là vấn đề Chromium đã biết mà chúng tôi đang điều tra. Chúng tôi mong nhận được thêm ý kiến phản hồi tại đây.
Cải tiến API	Có phải yêu cầu về Khung bảo vệ bị đẩy về năm 2025 để hỗ trợ quảng cáo gốc trong Hộp cát về quyền riêng tư không?	Như đã nêu trong thông báo công khai về việc thực thi Khung bảo vệ từ năm 2026, chúng tôi đã biết được về một "nỗ lực đáng kể để điều chỉnh Khung bảo vệ". Tất nhiên, một trong số đó là Gốc, nhưng đó không phải là yếu tố duy nhất. Mục đích là để có thêm thời gian nhằm đảm bảo hệ sinh thái sẵn sàng hỗ trợ các trường hợp sử dụng chính, bao gồm nhưng không giới hạn ở quảng cáo gốc.

Shared Storage API

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Hiệu suất	Thời gian trả về Bộ nhớ dùng chung bên ngoài worklet có vẻ phụ thuộc vào hoạt động trong worklet.	Chúng tôi đang thảo luận về kết quả kiểm tra này tại đây.
Áp dụng rộng rãi hơn	Bộ nhớ dùng chung phải là tiêu chuẩn cho toàn ngành và có thể sử dụng trên các trình duyệt.	Chúng tôi hoan nghênh và ghi nhận ý kiến phản hồi này. Chrome đang tiếp tục tham gia tích cực vào các diễn đàn W3C, bao gồm cả WICG, để ủng hộ đề xuất, thu thập ý kiến phản hồi và thúc đẩy việc áp dụng.
Worklet đặt giá thầu	Bạn có thể đọc từ Bộ nhớ dùng chung trong generateBid (đang chạy trong một worklet) để áp dụng logic quyết định quảng cáo / kinh doanh (chẳng hạn như Giới hạn tần suất) dựa trên thông tin về nhiều trang web và chọn một nhóm quảng cáo không?	Không, bạn không thể đọc dữ liệu từ bộ nhớ dùng chung trong các worklet đặt giá thầu.

Cookie có trạng thái được phân vùng độc lập (CHIPS)

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Sức chứa phân vùng	Làm rõ hành vi khi vượt quá dung lượng phân vùng.	Khi đạt đến dung lượng, các cookie cũ nhất sẽ được đẩy ra khỏi(các) cookie được truy cập gần đây nhất để giải phóng bộ nhớ cho đến khi không còn vượt quá giới hạn nữa. Nhà phát triển sẽ thấy tiêu đề Cookie đã cập nhật trong các yêu cầu tiếp theo.
Quyền truy cập vào iFrame của bên thứ ba	Nội dung iFrame của bên thứ ba được nhúng mở thẻ/cửa sổ mới vào cùng một trang web của bên thứ ba phải có quyền truy cập vào cùng cookie được phân vùng như trình mở.	Chúng tôi đang thảo luận về trường hợp sử dụng này và hoan nghênh bạn có thêm ý kiến phản hồi từ hệ sinh thái tại đây.
Cookie trùng lặp	Nếu có cookie được phân vùng và cookie không được phân vùng có cùng tên, trình duyệt sẽ quyết định gửi giá trị khoá nào?	Khi có hai cookie cùng tên (một cookie được phân vùng và một cookie không được phân vùng), bạn sẽ nhận được cả hai cookie – rất tiếc là không có cách nào để phân biệt cookie nào được phân vùng. Thông số kỹ thuật RFC về vấn đề này có tại đây, trong đó giải thích rằng thứ tự gửi cookie không nên được dựa vào.
Yêu cầu tính năng	Chọn sử dụng cookie được phân vùng nguồn gốc.	Chúng tôi đang xem xét yêu cầu này và hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái tại đây.

FedCM

Không nhận được phản hồi nào trong quý này.

Chống nội dung rác và lừa đảo

API Mã thông báo trạng thái riêng tư (và các API khác)

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Chế độ xem web	Mã thông báo trạng thái riêng tư (PST) có được duy trì trên nhiều Chế độ xem web trên cùng một thiết bị di động (hồ sơ) không?	Mỗi ứng dụng dùng chế độ xem web sẽ có một bộ nhớ cục bộ riêng, tức là nhà phát hành PST không thể phát hành mã thông báo trong chế độ xem web của một ứng dụng rồi sau đó trong một ứng dụng riêng biệt, bạn có thể cho phép sử dụng mã thông báo. Điều này cũng đúng đối với các dạng dữ liệu khác được lưu trữ cục bộ trên webview, chẳng hạn như cookie. PST chưa được hỗ trợ đầy đủ trong WebView. Chúng tôi dự kiến sẽ cung cấp thông tin cập nhật về vấn đề này vào cuối Quý 2.
Loại mã thông báo mới	Đề xuất về loại mã thông báo mới.	Chúng tôi rất cảm ơn đề xuất này và liên tục tìm hiểu các phương pháp ứng dụng cũng như điều chỉnh để thích ứng với PST. Chúng tôi hy vọng có thể tìm hiểu thêm về đề xuất này trong các cuộc họp sắp tới của Nhóm cộng đồng chống gian lận vào quý 2 năm 2024.
Nhận dạng người dùng	Làm cách nào để ngăn việc xác định người dùng dựa trên các PST cụ thể mà người dùng có?	Điều này hiện được giảm thiểu bằng cách giới hạn số lượt sử dụng trên trang web cho hai nhà phát hành, bất kể có mã thông báo nào từ nhà phát hành đó hay không. Bạn cần tính một nhà phát hành vào hạn mức ngay cả khi không có mã thông báo nào, nếu không thì trang web có thể lặp lại mã thông báo cho tất cả các nhà phát hành cho đến khi có kết quả trùng khớp dương tính.
Đăng ký	Thời gian đăng ký đối với PST sẽ là bao lâu?	Trong tương lai gần, bạn sẽ phải đăng ký tham gia, theo giải thích chi tiết hơn tại đây.
Hỗ trợ các trình duyệt Chromium khác	Việc đăng ký nhà phát hành PST cho các trình duyệt dựa trên Chromium khác có được hỗ trợ thông qua kho lưu trữ Gói đăng ký dành cho nhà phát hành Chrome không?	Chrome tìm nạp các cam kết chính và phân phối các cam kết đó cho các máy khách Chrome thông qua một cơ chế có tên là Trình cập nhật thành phần. Khi các trình duyệt khác bổ sung khả năng hỗ trợ đầy đủ hơn cho API, họ sẽ cần thiết lập một quy trình để nhận cam kết chính với ứng dụng khách, thông qua phương thức kiểu trình cập nhật thành phần hoặc một số phương thức khác. Chúng tôi sẽ giải quyết vấn đề này chi tiết hơn tại đây.