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 về 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.
Trong khuôn khổ cam kết với CMA, Google đã đồng ý công bố báo cáo hằng quý về quy trình tương tác với các bên liên quan đối với các đề xuất về 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 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 phản hồi mà Chrome nhận được từ nhiều nguồn như được liệt kê trong phần tổng quan về phản hồi, bao gồm nhưng không giới hạn ở: Vấn đề trên GitHub, biểu mẫu phản hồi được cung cấp trên privacysandbox.com, các cuộc họp với các bên liên quan trong ngành và diễn đàn về tiêu chuẩn web. Chrome hoan nghênh ý kiến phản hồi nhận được từ hệ sinh thái và đang tích cực tìm hiểu cách tích hợp những điều đã 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 trên 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 về một chủ đề nhất định và sắp xếp theo thứ tự giảm dần về số lượng. Các chủ đề phản hồi phổ biến được xác định bằng cách xem xét các chủ đề thảo luận từ các cuộc họp công khai (W3C, PatCG, IETF), phản hồi trực tiếp, GitHub và các câu hỏi thường gặp xuất hiện thông qua các nhóm nội bộ và biểu mẫu công khai của Google.
Cụ thể hơn, chúng tôi đã xem xét biên bản cuộc họp của các tổ chức tiêu chuẩn web và đối với ý kiến phản hồi trực tiếp, chúng tôi đã xem xét bản ghi của Google về các cuộc họp 1:1 với các bên liên quan, email mà các kỹ sư cá nhân nhận được, danh sách gửi thư API và biểu mẫu phản hồi công khai. Sau đó, Google đã điều phối giữa các nhóm tham gia vào nhiều hoạt động tiếp cận này để xác định mức độ phổ biến tương đối của các chủ đề mới nổi liên quan đến từng API.
Nội dung giải thích về phản hồi của Chrome đối với ý kiến phản hồi được phát triển từ các câu hỏi thường gặp đã xuất bản, phản hồi thực tế đối với các vấn đề do các bên liên quan nêu ra và xác định một quan điểm cụ thể 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à thử nghiệm, chúng tôi nhận được các câu hỏi và ý kiến phản hồi cụ thể liên quan đến API Chủ đề, Protected Audience và Attribution Reporting.
Phản hồi nhận được sau khi kết thúc khoảng thời gian báo cáo hiện tại có thể chưa được Chrome xem xét.
Bảng thuật ngữ về từ viết tắt
- ARA
- Attribution Reporting API
- 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
- Khung hình/giây
- 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
- 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
- IP
- Địa chỉ giao thức Internet
- openRTB
- Đặt giá thầu theo thời gian thực
- QUÁ GIỜ
- Bản dùng thử Origin
- API PAT
- Protected Audience API (trước đây là FLEDGE)
- PatCG
- Nhóm cộng đồng về công nghệ quảng cáo riêng tư
- RP
- Bên phụ thuộc
- RWS
- Bộ trang web có liên quan (trước đây là Nhóm bên thứ nhất)
- SSP
- Nền tảng bên cung
- TEE (Môi trường thực thi đáng tin cậy)
- Môi trường thực thi đáng tin cậy
- UA
- Chuỗi tác nhân người dùng
- UA-CH
- Thông tin mô tả của ứng dụng tác nhân người dùng
- W3C
- World Wide Web Consortium
- WIPB
- Cố tình làm ngơ địa chỉ IP
Ý kiến 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ý | Muốn tham gia giai đoạn nhận ý kiến công khai đối với mọi nội dung cập nhật về việc quản lý Hộp cát về quyền riêng tư. | Chúng tôi luôn sẵn sàng tiếp nhận ý kiến phản hồi hợp lý của các bên liên quan về mọi sự phát triển quan trọng 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. |
| Thử nghiệm | Các giai đoạn kiểm thử bổ sung cho 3PCD ngoài Kiểm thử do Chrome hỗ trợ hiện tại (1%). | Chúng tôi không có ý định cung cấp tính năng kiểm thử do Chrome hỗ trợ ngoài 1% lưu lượng truy cập Chrome hiện tại được bật kể từ đầu tháng 1. |
| Web to App | Không nên triển khai 3PCD trên thiết bị di động 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 cần hỗ trợ khả năng tương tác giữa ứng dụng và web, đồng thời đã triển khai tính năng đo lường phân bổ trên nhiều ứng dụng và web, cũng như đang khám phá các giải pháp nhắm mục tiêu web đến ứng dụng. Tuy nhiên, chúng tôi không có kế hoạch trì hoãn việc triển khai 3PCD trên web dành cho thiết bị di động. Chúng tôi không có mục tiêu đạt mức độ phù hợp 100% vào cuối 3PCD. Thay vào đó, chúng tôi dự kiến khả năng tương thích trên Android để đo lường trên nhiều ứng dụng và web sẽ ở mức cao hợp lý ở 3PCD và 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ột máy chủ quảng cáo hoặc SSP. | Chrome không đóng vai trò là máy chủ quảng cáo hoặc SSP. Với PA API, Chrome cung cấp một vùng chứa cho máy chủ quảng cáo, SSP, DSP và các công nghệ quảng cáo khác để đưa ra logic đặt giá thầu và tính điểm của riêng họ. |
| 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 mà API Hộp cát về quyền riêng tư sẽ 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 cho tất cả các đề xuất. Điều này có nghĩa là nội dung thường được sắp xếp theo hướng hiểu rõ động lực và khái niệm đằng sau dự án, theo sau là thông tin chi tiết về quá trình phát triển ban đầu và kiểm thử cho từng đề xuất. Đây là cách hiệu quả để xây dựng sự cộng tác thực sự trong hệ sinh thái trong quá trình phát triển các đề xuất. Tuy nhiên, khi các API đã phát triển đến mức có thể sử dụng rộng rãi, một nhóm nhà phát triển mới đã xuất hiện, họ chủ yếu đến đây để xây dựng dựa trên các API thay vì đóng góp vào quá trình phát triển cơ bản của các API đó. Gần đây, chúng tôi đã cập nhật phần điều hướng của trang web dành cho nhà phát triển Hộp cát về quyền riêng tư để tập trung vào trường hợp sử dụng, sử dụng các cách phân loại tương tự như IAB Tech Lab trong báo cáo gần đây của Nhóm tác vụ về Hộp cát về quyền riêng tư. Chúng tôi sẽ tiếp tục sử dụng phương pháp tài liệu dựa trên trường hợp sử dụng đó. |
| 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 CDN hiển thị trước? | Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh ý kiến phản hồi khác từ hệ sinh thái. |
| Giải pháp giảm thiểu 3PCD | Có cách nào theo phương thức lập trình để biết 3PC bị chặn hoặc khi nào 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 một iframe đều 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 3PC 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 bài thảo luận và minh hoạ một số cách có thể thực hiện video bằng PA API ngày 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ẽ áp dụng hàng loạt, mà là mã minh chứng và minh hoạ các kỹ thuật có thể hỗ trợ kết xuất video VAST bằng PA API. Trong quá trình thảo luận này, chúng tôi cũng nhận thấy rõ rằng mặc dù hiện đã có thể kết xuất video, nhưng Chrome có thể thực hiện một số thay đổi để đơn giản hoá việc triển khai bằng PA API. Ví dụ: các nội dung cập nhật về việc thay thế macro (được 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 liên quan đến tính nă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 ý kiến phản hồi trong trường hợp sử dụng video, trong đó người mua đang tìm kiếm macro của người bán để sử dụng trong quá trình hiển thị. Hầu hết các cuộc thảo luận cho đến nay đều 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ể sử 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 dường như hiện đang nhận được ít sự chú ý hơn so với quảng cáo dạng video, nhưng đâ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 là 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 phải 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,nhưng Tính năng tổng hợp riêng tư lại có mục đích chung. Bạn có thể sử dụng hai khối xây dựng này để giải quyết 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 thiết kế để khuyến khích nhà sáng tạo tạo nhiều nội dung hơn cho YouTube và ít nội dung hơn trên trang web của riêng 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 mọi người trên một Internet mở và tự do. Chúng tôi biết rằng nhà xuất bản dựa vào quảng cáo để sản xuất nội dung và phân phối nội dung đó rộng rãi nhất có thể. 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 hợp tác với nhà sáng tạo nội dung, hiển thị cho mọi người nhữ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 và 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 và phạm vi cung cấp API. Các trang này liệt kê các tính năng sắp ra mắt và tiến trình phát triển của các tính năng đó (ví dụ: PA API, ARA). Bạn có thể xem trung tâm củ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 cho 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ó thể 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 tìm kiếm để huấn luyện 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 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 xuất hiện để di chuyển về phía trước trên 3PCD trước khi kết thúc trạng thái Dừng. |
| Trường hợp sử dụng không được hỗ trợ | Chúng tôi hiện không xem xét các trường hợp sử dụng DSP tự phục vụ. | Có nhiều DSP tự phục vụ thường xuyên đưa ra ý kiến phản hồi công khai về các API. Một số DSP trong số đó 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 đang tích cực tham gia vào các chủ đề DSP tự phục vụ thông thường như video và máy chủ quảng cáo của 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 những trang web muốn tăng tốc và tăng phạm vi kiểm thử cho 3PCD. | Chrome hiện đang phát triển một OT của bên thứ nhất, cho phép các nguồn gốc chọn sử dụng hành vi loại bỏ cookie của bên thứ ba. Các nguồn cấp cao nhất đăng ký thử nghiệm này và triển khai mã thông báo sẽ bị chặn 3PC 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 cơ hội quý giá để các trang web thử nghiệm rộng rãi hơn các giải pháp thay thế lâu dài cho 3PC, trước khi chúng tôi loại bỏ dần 3PC theo lịch trình sau khi tham khảo ý kiến của CMA. Chúng tôi vẫn đang nỗ lực để hoàn tất tiến trình triển khai OT. |
| Báo cáo của Phòng thí nghiệm công nghệ của IAB | Ý 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 Phòng thí nghiệm công nghệ của IAB. | 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 thừa nhận rằng "báo cáo này đặt ra các câu hỏi về tài liệu rời rạc, yêu cầu thương mại, kiểm tra của bên thứ ba, chứng nhận trong ngành, khả năng mở rộng, tính minh bạch và cách quản lý trong tương lai. Chúng tôi sẽ trao đổi với hệ sinh thái về những vấn đề này và cập nhật các câu hỏi thường gặp công khai cho phù hợp". Chúng tôi giải quyết tài liệu bị phân mảnh trước đây. Chúng tôi giải quyết các yêu cầu thương mại trong phần "Đả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 của họ. Chúng tôi giải quyết các cuộc kiểm tra của bên thứ ba trong phần "Cam kết về tính toàn vẹn của thuật toán" tại đây. Về việc công nhận, chúng tôi mong đợi các cơ quan đó sẽ tiếp tục công nhận các sản phẩm, bao gồm cả việc sử dụng công nghệ, thay vì công nhận riêng các công nghệ. Đối với khả năng mở rộng, chúng tôi vẫn tiếp tục tiếp nhận dữ liệu từ các nhà phát triển cho thấy vấn đề. Về tính minh bạch và hoạt động quản lý, chúng tôi tiếp tục phát triển công khai trên GitHub và tại các diễn đàn như W3C, đồng thời tương tác với CMA theo các cam kết. |
| Đăng nhập bằng Google | Việc đăng nhập bằng Google có thể khiến Google sử dụng dữ liệu đăng nhập nhận dạng chéo, 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 | Bạn có kế hoạch hỗ trợ API Hộp cát về quyền riêng tư và khả năng tương thích chuyển tiếp / ngược không? | Sau khi Chrome ra mắt một tính năng trên diện rộng, chúng tôi sẽ cố gắng duy trì việc hỗ trợ tính năng đó. Tất nhiên, không phải lúc nào chúng ta 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 để ngừng sử dụng và xoá các tính năng hiện có, như mô tả tại đây. Theo thời gian, chúng tôi dự kiến sẽ tiếp tục bổ sung thêm các tính năng vào API Hộp cát về quyền riêng tư để phản hồi ý 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ừ việc cải thiện khả năng hỗ trợ. Trong những trường hợp như vậy, chúng ta thường sử dụng một số kỹ thuật Phát hiện tính năng để một công nghệ quảng cáo muốn 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 tốt hơn so với việc yêu cầu nhà phát triển kiểm tra một 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 cho tất cả người dùng Chrome cùng một lúc. Ví dụ: bạn có thể xem công việc 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ì ghép nối với cách triển khai của riêng mình, Chrome phải chỉ định những hành vi mà việc triển khai một 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 không phải trình duyệt bắt buộc khác phải đáp ứng. Điều này sẽ cho phép đổi mới trong phạm vi quyền riêng tư được chấp nhận. | Chúng tôi đánh giá cao và hoan nghênh mong muốn đổi mới của các bên bên ngoài. Đối với tất cả API và dịch vụ, chúng tôi muốn cung cấp cho các công nghệ quảng cáo khả năng linh hoạt để triển khai 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 doanh nghiệp bảo mật trong quá trình 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 tham gia nhận ý kiến phản hồi từ các công nghệ quảng cáo và tích hợp ý kiến đó vào thiết kế của mình (nếu hợp lý). Để 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 cam kết về quyền riêng tư. Để làm được điều này, nhóm Hộp cát về quyền riêng tư cần phải nỗ lực rất nhiều. Do đó, chúng tôi muốn tìm hiểu những lợi ích mà các bên liên quan đang tìm cách đạt được, mà chúng tôi hiện chưa đáp ứng được. |
| Phương pháp phỏng đoán | Kế hoạch dài hạn cho phương pháp phỏng đoán là gì? | Cũng như các trình duyệt khác, chúng tôi dự định sẽ ngừng sử dụng 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, tuỳ thuộc vào kết quả phân tích khả thi hơn nữa. Chúng tôi đã chia sẻ thông tin này tại đây. |
| Kiểm thử âm lượng | Lưu lượng truy cập khác nhau khi so sánh các phương diện. | Thử nghiệm 1% có các tiêu chí loại trừ dẫn đến sự khác biệt về điều kiện tham gia thử nghiệm giữa các nhóm ứng dụng Chrome. Ví dụ: thử nghiệm không bao gồm người dùng Chrome Enterprise, vì vậy, dự kiến tỷ lệ lưu lượng truy cập có nhãn thử nghiệm sẽ cao hơn vào cuối tuần. Bạn có thể thấy tỷ lệ phần trăm lưu lượng truy cập khác nhau trên các lát cắt dữ liệu (chẳng hạn như vị trí địa lý, ngày và nền tảng). Điều này phù hợp với những gì chúng tôi thấy trong dữ liệu của 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 3PCD được thực thi không? | Người dùng có thể bật lại quyền truy cập 3PC ở cấp trang web thông qua tính năng Bỏ qua người dùng nếu gặp sự cố. 3PC cũng có thể được bật lại bằng các biện pháp khác như API Truy cập bộ nhớ. 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 3PCs đang bật hay tắt. Tuy nhiên, Chrome sẽ không tạo điều kiện để 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 của tính năng Chống theo dõi của Chrome sẽ hoạt động trong bao lâu? | Giao diện người dùng của tính năng Bảo vệ khỏi tính năng theo dõi trong thanh địa chỉ dự kiến sẽ vẫn hoạt động sau khi 3PC ngừng hoạt động. |
| (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 tham gia tích cực vào các diễn đàn công khai, nơi các nguyên tắc về quyền riêng tư và phương pháp dựa trên trình duyệt đang được thảo luận. Chúng tôi rất vui khi thấy các cuộc thảo luận cộng tác trong các diễn đàn như cuộc họp TPAC thường niên gần đây của W3C và các diễn đàn PATCG đang diễn ra của W3C, nơi chúng tôi nhận thấy các dấu hiệu hội tụ. Ví dụ: Microsoft Edge gần đây đã công bố kế hoạch "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 các tính năng bổ sung cho nhà phát triển. |
| Tuỳ chọn dự phòng cho các nội dung nhúng không tương thích sau 3PCD | Cung cấp các trình bổ trợ API để phát hiện xem iframe / nội dung 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 ý kiến phản hồi khác từ hệ sinh thái. |
| Thử nghiệm | Yêu cầu 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 ý kiến đóng góp 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 chứng thực bằng cách nào? | Tất cả người đăng ký đều phải duy trì tệp chứng thực trong khi sử dụng các API. Google xác thực rằng tệp đã được đặt đú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ý Private Aggregation API | Có cách nào để kiểm tra trạng thái đăng ký API tổng hợp riêng tư không? | Tất cả người đăng ký được phê duyệt sẽ nhận được thông báo qua email từ Nhóm hỗ trợ đăng ký sau khi quá trình đăng ký được xác thực. Nếu có thắc mắc trong quá trình đăng ký, người đăng ký có thể liên hệ với nhóm hỗ trợ (nhóm này sẽ liên hệ với họ sau khi họ gửi biểu mẫu đăng ký). Nhóm hỗ trợ sẽ trả lời và giải đáp thắc mắc cũng như cung cấp mọi hướng dẫn bổ sung cần thiết. |
Hiển thị nội dung và quảng cáo phù hợp
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) Tài liệu và tiến trình của bộ phân loại |
Phải có một số cơ chế để xem xét việc phân loại hoặc ít nhất là cung cấp thêm thông tin minh bạch về cách chế độ phân loại xác định danh mục. | Chúng tôi vẫn giữ nguyên câu trả lời như các quý trước: "Việc phân loại sai trang web có thể khiến tín hiệu Chủ đề kém hữu ích hơn một chút về tổng thể, nhưng những trang web cụ thể bị phân loại sai sẽ không bị ảnh hưởng nhiều hơn hay ít hơn so với bất kỳ trang web nào khác. Lý do là thông tin theo bối cảnh của trang web sẽ luôn có sẵn cho các phiên đấu giá trên trang web của họ. 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 rất mong nhận được ý kiến phản hồi của bạn 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ề chủ đề của người dùng so với các đối thủ cạnh tranh hiện diện trên ít trang web hơn. | Yêu cầu quan sát này nhằm đảm bảo Topics API không dẫn đến việc dữ liệu người dùng được chia sẻ với nhiều thực thể hơn so với các công nghệ mà API này đang thay thế (bao gồm cả 3PC). Các giải pháp khác trong ngành như tính năng Đặt giá thầu trước hoạt động với hàng chục nghìn trang web và cho phép những người tham gia thị trường gọi Topics API thông qua công nghệ của họ. Ngoài ra, bạn cần lưu ý rằng giới hạn tối đa 5 chủ đề hàng đầu mỗi tuần có thể mang lại hiệu quả cân bằng, vì những người tham gia thị trường xuất hiện trên nhiều trang web có thể tìm hiểu nhiều hơn 5 chủ đề tương đương bằng cách sử dụng 3 máy tính sẽ bị giới hạn ở mức 5. |
| (Cũng được báo cáo trong các quý trước) Mức độ hữu ích đối với các loại bên liên quan |
Mối 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 có mối quan tâm chung. Tuy nhiên, không phải trang web chuyên biệt nào cũng đóng góp các chủ đề có giá trị thương mại. Ngoài ra, sự thay đổi 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ợ 3PC 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 so với 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ủ đề trên các trang web chuyên biệt có thể mang lại lợi ích cho nhau vì nhiều nhà quảng cáo có thể chạy chiến dịch trên nhiều nhóm chủ đề và logic đặt giá thầu có thể quan sát giá trị trên nhiều chủ đề. |
| Tên máy chủ so với URL đầy đủ | Việc phân loại dựa trên tên máy chủ của trang web có đủ hiệu quả và có giúp giảm rủi ro về quyền riêng tư so với URL đầy đủ 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 lợi ích tiềm năng sẽ bị rủi ro về quyền riêng tư và bảo mật của người dùng lấn á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 chủ đề của người dùng. |
| Chủ đề dưới dạng 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 nào khác có thể hữu ích. | Các giải pháp công nghệ quảng cáo có thể mang lại kết quả tốt nhất bằng cách kết hợp tất cả các công cụ hiện có, chẳng hạn như công nghệ học máy và các tín hiệu đảm bảo quyền riêng tư từ API bảo đảm quyền riêng tư, cùng với dữ liệu theo 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 |
|---|---|---|
| Kiểm thử lưu lượng truy cập | Người kiểm thử báo cáo rằng số lượng phản hồi giá thầu cho phiên đấu giá API PA thấp. | 1. Mật độ giá thầu có liên quan đến mức độ tham gia của hệ sinh thái vào API PA. Chúng tôi dự đoán mật độ giá thầu sẽ tiếp tục tăng trong suốt năm 2024 và sau đó. Cuối cùng, nhà quảng cáo, đại lý và nhà cung cấp công nghệ của họ sẽ quyết định cách phân bổ ngân sách chiến dịch. Chúng tôi dự kiến một số bên tham gia hệ sinh thái có thể trì hoãn việc đầu tư vào nhiều giải pháp "không dùng cookie", bao gồm cả PA API, cho đến sau ngày 3PCD. Vào thời điểm đó, chúng tôi dự kiến họ có thể tăng mức phân bổ ngân sách chiến dịch cho các giải pháp như vậy. 2. Số lượng yêu cầu giá thầu trong phiên đấu giá PA API có thể chịu ảnh hưởng của (1) vì nhà xuất bản và nhà cung cấp công nghệ quảng cáo của họ có thể quyết định không bắt đầu phiên đấu giá PA API nếu họ cảm thấy nhu cầu thấp. Nhà xuất bản có thể tự quyết định mức độ ưu tiên cập nhật trang và tham gia. Chúng tôi dự kiến nhà xuất bản có thể cần 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 chế độ kiểm soát dành cho nhà xuất bản để tham gia PA API. |
| (Cũng được báo cáo trong các quý trước) Hành vi gian lận / lạm dụng |
Làm cách nào để hệ sinh thái có thể giảm thiểu rủi ro và ngăn chặn những đối tượng xấu hoặc người mua tự đặt mình vào vị trí là đối tượng mong muốn? | Cơ chế báo cáo của quảng cáo PA API giữ lại thông tin dùng để phân biệt lưu lượng truy cập của con người với lưu lượng truy cập của 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 để đưa vào hoặc loại trừ miền trong API PA. Đ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ế về cùng một nguồn gốc đối với chủ sở hữu IG và URL logic đặt giá thầu | Với yêu cầu về cùng một nguồn gốc, các điểm cuối của chủ sở hữu IG sẽ buộc phải đi qua cùng một bộ cân bằng tải, điều này có thể dẫn đến việc các lệnh chuyển hướng bị từ chối. | Yêu cầu 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. Có một số thông tin chi tiết về giải pháp đề xuất tại đây giúp cân bằng phản hồi về hệ sinh thái và các yếu tố cần cân nhắc khác tại đây. |
| Phiên đấu giá kín nhiều khung | Có rất nhiều cơ hội để cho phép Phiên đấu giá kín nhiều khung trong phạm vi quyền riêng tư bằng cách sử dụng tiếng ồn 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 về phiên đấu giá nhiều thẻ dựa trên mức độ phức tạp và rủi ro về quyền riêng tư gia tăng 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 hỗ trợ phát triển web API PA (WICG) tại đây. |
| Người bán cấp cao nhất | Cấu trúc hiện tại của API PA 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 đáng kể về giá trị tương đối của 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ó một giá thầu tốt nhất. Ngoài ra, chúng tôi đã tìm hiểu được từ hệ sinh thái rằng nhà xuất bản có thể muốn xem xét nhu cầu bán trực tiếp bên cạnh giá thầu tốt nhất của từng 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 quảng cáo nào sẽ phân phát. Tình huống này, trong đó một số thực thể cần xem toàn bộ các lựa chọn để chọn quảng cáo phân phát, đã có trước API PA. PA API nhằm hỗ trợ các phiên đấu giá nhiều người bán và mong muốn của nhà xuất bản là 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ó). Điều này có nghĩa là cần có một cơ chế để chọn trong số các cơ hội kiếm tiền đó như hiện nay. Chúng tôi không cho rằng trình duyệt nên có vai trò chọn quảng cáo để phân phát. Do đó, khái niệm về người bán cấp cao nhất là cần thiết để chọn một quảng cáo chiến thắng trong số nhiều quảng cáo có thể xuất hiện. Logic của người bán cấp cao nhất đó phải có khả năng xem xét giá thầu tốt nhất của từng người bán mà nhà xuất bản chọn hợp tác. Logic của người bán đó có thể chọn cung cấp thông tin về các chiến dịch do nhà xuất bản bán trực tiếp nếu 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 xét các giá thầu tốt nhất từ phiên đấu giá PA API và mọi lựa chọn quảng cáo được bán trực tiếp của nhà xuất bản (nếu có) để xác định người chiến thắng. Google Ad Manager trình bày chi tiết về việc triển khai PA API dưới vai trò là người bán cấp cao nhất trong báo cáo này theo chủ đề "Quyền truy cập thông tin". |
| Phân tách quảng cáo cạnh tranh | Yêu cầu tách 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 bên cạnh nhau. | Chúng tôi không biết cách đảm bảo sự tách biệt về khả năng cạnh tranh trong hệ sinh thái quảng cáo kỹ thuật số hiện nay, trong đó có nhiều người bán, đặt giá thầu và có lập trình. Tuy nhiên, PA API cho phép người bán tìm nạp các tín hiệu theo thời gian thực bổ sung dựa trên tổ hợp renderURL 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 tính năng 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 mà nhà xuất bản có thể xem, 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 ý 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ề quảng cáo được phân phát sau khi PA API báo cáo ở cấp sự kiện ngừng hoạt động. | Chúng tôi hiểu rằng có nhiều trường hợp sử dụng báo cáo mà chúng tôi phải tiếp tục hỗ trợ khi báo cáo ở cấp sự kiện ngừng hoạt động. Đó là lý do chúng tôi đặt mục tiêu ngừng cung cấp báo cáo cấp sự kiện muộn nhất vào năm 2026. Trong thời gian chờ đợi, chúng tôi mong bạn tích cực tham gia khi chúng tôi tương tác với hệ sinh thái theo những lộ trình bền vững, có thể bao gồm cả 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 không cho rằng điều này là chính xác và rất mong nhận được ý kiến phản hồi bổ sung từ hệ sinh thái để hiểu rõ lý do cho nhận định này. |
| Hoạt động tuyển chọn | Không thể thực hiện các hoạt động tuyển chọn bằng API PA. | Chúng tôi đã nhận được ý kiến phản hồi về khả năng người bán sử dụng API PA để cung cấp thông tin về đối tượng cho người mua trên web (còn gọi là phần mở rộng về đối tượng). Chúng tôi tin rằng điều này hiện có thể thực hiện được bằng cách 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 tích cực cân nhắc xem có thể điều chỉnh để phù hợp hơn với những 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 của người mua | Việc người mua chọn không tham gia theo mặc định có thể khiến kết quả của các phiên đấu giá thành phần thấp hơn. | Cho dù xác định 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 người mua trong trường interestGroupBuyers của AuctionConfig. Điều này dựa trên ý kiến phản hồi của hệ sinh thái cho biết người bán có thoả thuận hợp đồng với một số người mua và không có thoả thuận với những người mua khác. Do đó, họ cần có quyền kiểm soát rõ ràng đối với những người mua sẽ tham gia phiên đấu giá. Chúng tôi rất mong được thảo luận thêm trên GitHub. |
| Kích thước quảng cáo | Không thể lọc trước dựa trên adsize 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ợ tiêu chí nhắm mục tiêu phủ định trên Instagram | API hỗ trợ tiêu chí nhắm mục tiêu theo IG phủ định: chỉ hiển thị quảng cáo nếu người dùng không thuộc một IG. | Vấn đề này trên GitHub đề xuất một cách khác để triển khai tính năng nhắm mục tiêu tiêu cực, trong đó trình duyệt trực tiếp cho máy chủ quảng cáo biết những quy tắc nhắm mục tiêu tiêu cực 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 đã điều tra đều cho phép máy chủ nhận dạng người dùng một cách duy nhất. |
| Đạo luật Dịch vụ kỹ thuật số | Nhà xuất bản có thể sử dụng Khung được phân vùng nhưng đồng thời ngăn chặn việc hiển thị các phản hồi chứa thông tin thuộc phạm vi điều chỉnh của Đạo luật Dịch vụ kỹ thuật số bằng cách nào? | Giống như mọi công nghệ mới, mỗi công ty đều có trách nhiệm đảm bảo rằng việc sử dụng Hộp cát về quyền riêng tư của họ tuân thủ luật pháp; Google không thể tư vấn pháp lý cho các công ty 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 đánh giá pháp lý cần thiết. Khung được khoanh vùng không bắt buộc phải sử dụng trong API PA muộn nhất là vào năm 2026, cho phép các bên liên quan có thêm thời gian để đảm bảo rằng việc sử dụng công nghệ này tuân thủ tất cả các luật liên quan. |
| Tài liệu | updateAdInterestGroups() có tạm thời không? | Chúng tôi chưa thông báo về kế hoạch 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ư những biện pháp mà chúng tôi đã công bố cho các cơ chế cập nhật khác của Instagram, chẳng hạn như sử dụng một địa chỉ IP cũng là proxy và thêm một chút độ 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 phía bên mua cho các bên không phải là DSP | Yêu cầu về cách hoạt động như một proxy cho DSP. | Chúng tôi đã nhận được ý kiến phản hồi này từ 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 rất mong nhận được 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 tín hiệu / giá trị trong báo cáo Tổng hợp riêng tư. | Chúng tôi đã nắm được vấn đề này và yêu cầu về tính năng này đang nằm trong danh sách chờ để chúng tôi tìm hiểu thêm. Chúng tôi rất mong nhận được ý kiến phản hồi bổ sung của hệ sinh thái tại đây. |
| Tài liệu | Có đường liên kết nào để xem tất cả tiêu đề phản hồi mà nhà quảng cáo và miền của chủ sở hữu (được uỷ quyền) cần đặt không? | Chúng tôi đang lên kế hoạch cập nhật tài liệu để làm rõ vấn đề này và hoan nghênh ý kiến phản hồi bổ sung từ hệ sinh thái. |
| Đặt giá thầu nhiều tháp | Yêu cầu giải thích quy trình công việc (huấn luyện và suy luận) thông qua sơ đồ cấu trúc / khối về cách tiếp cận nhiều tháp được hình dung 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ản trình bày về chủ đề này và dự kiến sẽ xây dựng thêm tài liệu. |
| Tiêu chí nhắm mục tiêu phủ định | Khả năng của Hộp cát về quyền riêng tư trong việc bảo vệ các đối tượng nhạy cảm và trẻ vị thành niên khỏi quảng cáo không phù hợp, chẳng hạn như quảng cáo cờ bạc. | PA API không xem xét nội dung của quảng cáo hiển thị. Việc này do các nhà phát triển công nghệ quảng cáo sử dụng PA kiểm soát. 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 phiên đấu giá Protected Audience bằng cách sử dụng thông tin theo bối cảnh từ trang cũng như bộ quy tắc của nhà xuất bản. Điều này phản ánh cách chúng tôi hiểu về cách hệ sinh thái giải quyết 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 theo tiêu chí loại trừ trên Instagram cũng có thể hữu ích trong một số trường hợp sử dụng tuân thủ. |
| Thiết kế API | Google đang phản đối và muốn các công nghệ quảng cáo sử dụng hàm đặt giá thầu Universal, do đó làm tăng độ trễ, thay vì các biddingLogicURL khác nhau trong các IG khác nhau (điều này đượ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 lại cùng một tập lệnh trên tất cả IG của người mua sẽ giúp hoạt động đặt giá thầu của người mua đó diễn ra nhanh hơn. Thông tin này được nêu 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ề mọi trường hợp sử dụng cụ thể mà họ cho rằng không thể thực hiện được. Đồ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 về vấn đề này thông qua kho lưu trữ GitHub công khai hoặc các cuộc gọi hằng tuần. |
| Thử nghiệm A/B | Khi được định cấu hình trong GAM cho một nhà xuất bản, API PA hiện phải được bật cho tất cả khoảng không quảng cáo hoặc không được bật cho khoảng không quảng cáo nào. Điều này hạn chế khả năng nhà xuất bản chạy thử nghiệm A/B hiệu quả. | Phản hồi do Google Ad Manager cung cấp: Các chế độ 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. 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 để tắt việc sử dụng API trên một nhóm nhỏ lưu lượng truy cập để dùng làm nhóm đối chứng cho thử nghiệm A/B. |
| Học máy | 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. | Phản hồi của Google Ad Manager: Vào tháng 1 năm 2024, chúng tôi đã ra mắt một chế độ kiểm soát cho phép nhà xuất bản tắt trình điều tiết máy học và bật phiên đấu giá PA API với những bên bán không phải Google trên tất cả lưu lượng truy cập của họ. Bạn có thể xem 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, nên kế hoạch tích hợp API PA của GAM không bao gồm việc hỗ trợ các 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 kiểm soát được 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, tín hiệu do người mua cung cấp cho SSP cho phiên đấu giá API PA và các thông số cấu hình từ SSP. | Phản hồi của Google Ad Manager: Chúng tôi luôn chú trọng đến tính công bằng của phiên đấu giá trong nhiều năm qua, bao gồm cả lời hứa rằng chúng tôi sẽ không chia sẻ giá của bất kỳ nguồn quảng cáo không được đảm bảo nào của nhà xuất bản (bao gồm cả giá mục hàng không được đảm bảo) với người mua khác trước khi họ đặt giá thầu trong phiên đấu giá. Sau đó, chúng tôi đã tái khẳng định lời hứa này trong 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á API PA, chúng tôi dự định giữ lời hứa và không chia sẻ giá thầu của người tham gia phiên đấu giá với người tham gia phiên đấu giá khác trước khi phiên đấu giá kết thúc trong các phiên đấu giá nhiều người bán. Xin lưu ý rằng 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á của chính chúng tôi, như giải thích trong nội dung cập nhật này. Hơn nữa, 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ả các tín hiệu do người mua cung cấp cho SSP, trong phiên đấu giá của riêng chúng tôi. Trên thực tế, chúng tôi hoan nghênh những 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 của họ theo cách làm rối mã nguồn đối 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 những SSP nào chạy phiên đấu giá thành phần cho từng cơ hội quảng cáo. | Phản hồi do Google Ad Manager cung cấp: Với vai trò là một 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 phiên đấu giá thành phần thông qua API này, thì các SSP đó 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 dụng 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. Mọi SSP muốn chạy phiên đấu giá thành phần đều có thể thực hiện, 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 công bố cho từng giá thầu chiến thắng trong phiên đấu giá thành phần. | Phản hồi của Google Ad Manager: Trong nhiều năm, GAM luôn chú trọng đến tính công bằng của phiên đấu giá. Để duy trì một 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 một số phân khúc nhu cầu cụ thể. Đó là 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 đối với các phiên đấu giá API PA. |
| Máy chủ quảng cáo bên thứ ba | Máy chủ quảng cáo bên thứ ba sẽ không có quyền truy cập vào việc Google tham gia phiên đấu giá cấp cao hơn, hạn chế 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 PA API với nhiều người bán trên GAM thông qua API được mô tả tại đây. Hiện tại, chúng tôi không hỗ trợ việc tham gia của GAM dưới dạng 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 Phiên đấu giá API PA |
Báo cáo của người kiểm thử cho thấy các phiên đấu giá API PA có độ trễ cao. | Chúng tôi đã nhận được những mối lo ngại về độ trễ và đây là một trong những lý do khiến chúng tôi phát triển một số tính năng trong API PA để cho phép SSP vừa đặt giới hạn về độ trễ DSP vừa cải thiện để 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 các tính năng này. Chúng tôi cũng đang tiếp tục phát triển các tính năng cải thiện độ trễ mới, một số tính năng trong số đó có thể xem tại đây. |
| (Cũng được báo cáo trong các quý trước) Hiển thị video |
Hỗ trợ kết xuất video bằng API PA và Khung có hàng rào. | Vào tháng 1, chúng tôi đã xuất bản một bản minh hoạ cách hoạt động của quảng cáo dạng video trong luồng phát trong phiên đấu giá PA, cùng với thông tin chi tiết bổ sung về các phương pháp thay thế. Chúng tôi cũng nhận thấy các bên trong hệ sinh thái bắt đầu đề xuất cách hoạt động của tính năng 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 GAM về việc tạo renderURL 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 mà chúng tôi có thể thực hiện để tăng mức độ sử dụng. Một thay đổi như vậy được nêu chi tiết trong GitHub. Chúng tôi vẫn tích cực tham gia hệ sinh thái để xác định mọi trở ngại khác đối với việc sử dụng mà chúng tôi có thể gặp phả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ề những người dùng đang ở trong IG nào (i) vẫn nằm 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 bên trong Môi trường thực thi đáng tin cậy (TEE). Trong cả hai trường hợp, không bên nào khác có thể đọc dữ liệu này hoặc sử dụng dữ liệu này theo cách nào khác ngoài việc tạo giá thầu trong phiên đấu giá. Một số tính năng nâng cao về quyền riêng tư mà Chrome đang nghiên cứu có liên quan đến việc tương tác với máy chủ k-anonymity do Google điều hành. Hoạt động tương tác đó đang được thiết kế cẩn thận để tránh chia sẻ thông tin về người dùng và chạy trong một TEE để đảm bảo tính đồng nhất của thông tin trên hệ sinh thái quảng cáo. Google đã cam kết với CMA rằng sẽ thiết kế và triển khai các đề xuất về Hộp cát về quyền riêng tư theo cách không làm méo mó cạnh tranh bằng cách tự ưu tiên hoạt động kinh doanh của chính Google, đồng thời xem xét tác động đến hoạt động cạnh tranh trong quảng cáo kỹ thuật số cũng như tác động đến nhà xuất bản và nhà quảng cáo. Chúng tôi sẽ tiếp tục hợp tác chặt chẽ với CMA để đảm bảo hoạt động của mình tuân thủ các nghĩa vụ này. |
| (Cũng được báo cáo trong các quý trước) Thời gian hoạt động trên Instagram |
Yêu cầu kéo dài thời gian tồn tại của IG từ 30 lên 90 ngày. | Để thay đổi như vậy, chúng tôi cần phải đánh giá kỹ lưỡng, cân nhắc lợi ích cho ngành so 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 gửi thêm ý kiến phản hồi tại đây. |
| (Cũng được báo cáo trong các quý trước) modelingSignals |
Yêu cầu một trường mới ngoài modelingSignals chỉ có thể mã hoá thông tin về lượt hiển thị và lượt nhấp. | Chúng tôi đã phản hồ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 trao đổi với các bên trong ngành để hiểu rõ quan điểm của họ về đề xuất của chúng tôi, đồng thời đang cân nhắc lợi ích đối với ngành so 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 thêm bit trong reportWin() từ giới hạn hiện tại là 12 trước 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. Quá trình này sẽ mất chút 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ế phiên đấu giá | Yêu cầu cho một phiên đấu giá trả về URL hiển thị kèm theo điểm tương ứng. | Chúng tôi đã cân nhắc việc chia sẻ nhiều renderURL và điểm số tương ứng của các URL đó từ một phiên đấu giá PA, nhưng không triển khai do lo ngại về quyền riêng tư. Chúng tôi hiểu rằng bạn 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. Chúng tôi sẵn sàng 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 đang diễn ra trong suốt thời gian thử nghiệm. Sau khi Chrome ngừng hỗ trợ cookie của bên thứ ba, phiên bản forDebuggingOnly của API sẽ di chuyển để bật tính năng gỡ lỗi lấy mẫu giảm, đượ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 của chính mình, đồng thời không phải chỉ dựa vào báo cáo của các công nghệ quảng cáo. | Yêu cầu về tính năng này đang trong hàng đợi để chúng tôi tìm hiểu thêm. Chúng tôi không dự kiến sẽ giải quyết vấn đề này trong giai đoạn thử nghiệm với sự hỗ trợ của Chrome. |
| Thanh toán theo chi phí mỗi lượt nhấp | Triển khai tính năng thanh toán theo chi phí mỗi lượt nhấp trong API PA. | Chúng tôi đang xem xét yêu cầu này tại đây và hiện coi đây là yêu cầu đề xuất về cách triển khai yêu cầu đó bằng giao diện API hiện tại. |
| browserSignals | Thêm incomingBidInSellerCurrency vào thông số kỹ thuật báo cáo 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 gửi thêm ý kiến phản hồi tại đây. |
| Hỗ trợ quyền sở hữu logic và siêu dữ liệu phía bên mua cho các công nghệ không phải DSP | Thiết kế hiện tại của API có thể dẫn đến sự thay đổi đáng kể trong chiến dịch tái nhắm mục tiêu ở cấp sản phẩm, trong đó các chiến dịch có thể cần di chuyển sang các nền tảng đóng vai trò là cả DSP và nhà cung cấp DCO. | Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây. |
| Hỗ trợ quyền sở hữu logic và siêu dữ liệu phía bên mua cho các công nghệ không phải DSP | Chia sẻ ví dụ về trường hợp DSP không phải là chủ sở hữu tài khoản Instagram. | Chúng tôi hiểu rằng những người không phải là bên đặt giá thầu muốn sử dụng một số chức năng của IG nhưng không muốn sử dụng một số 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 những trường hợp sử dụng này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Chế độ điều khiển 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ờ toàn cầu. | Chúng tôi hiểu rằng bạn muốn có thêm các chế độ kiểm soát thời gian chờ và chế độ hiển thị giữa người bán cấp cao nhất và người bán thành phần. 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 Kích thước quảng cáo đa dạng. | Chúng tôi đang xem xét yêu cầu này và hoan nghênh ý kiến phản hồi bổ sung từ hệ sinh thái. |
| Tài liệu | Có danh sách các thuộc tính IG phải tuân thủ 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 nhận thấy tầm quan trọng của các công cụ gỡ lỗi mạnh mẽ đối với 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 của nhà phát triển bằng cách tìm hiểu các cách tích hợp tốt hơn tính năng tìm nạp tệp .well-known với các công cụ dành cho nhà phát triển. Mục tiêu của chúng tôi là cung cấp khả năng khắc phục sự cố và khả năng hiển thị tốt hơn trong môi trường phát triển. Chúng tôi đang thảo luận thêm về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn. |
| Nhãn | Tất cả người dùng trong nhãn phương thức xử lý chế độ B đều bật API Hộp cát về quyền riêng tư không? | Việc chỉ định nhóm thử nghiệm trên 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 điều trị cụ thể (ví dụ: treatment_1.*), nhưng chức năng của các API này có thể được sửa đổi hoặc tắt thông qua phần cài đặt Chrome. Nhóm control_2 của Chế độ B: Việc đưa vào nhóm này sẽ tự động tắt 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ườ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 reportWin() và quá trình hiển thị quảng cáo có diễn ra song song hay lần lượt không? | reportWin() được gọi ngay sau khi hoàn tất runAdAuction(). Đồ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 Khung có hàng rào. Sau khi cả 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 để sendReportTo() sẽ được tìm nạp. |
| (Cũng được báo cáo trong các quý trước) Hỗ trợ thử nghiệm A/B |
Yêu cầu hỗ trợ kiểm thử A/B API PA. | Chúng tôi đang thảo luận về yêu cầu này tại đây và rất mong nhận được ý kiến phản hồi bổ sung của bạn. |
| Định hình lưu lượng truy cập | Đề xuất của Google về việc quản lý việc đưa ra quyết định bắt buộc thông qua máy chủ KV 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ọ, khiế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 đề trên GitHub, việc tiết lộ liệu một DSP riêng lẻ có IG hay không có thể gây ra mối lo ngại về việc tạo vân tay người dùng. Chúng tôi đã đề xuất các giải pháp thay thế khác cho vấn đề này và luôn sẵn sàng tiếp nhận các đề xuất khác. |
| Định hình lưu lượng truy cập | Cơ chế lưu vào bộ nhớ đệm làm tăng đáng kể độ phức tạp và khiến DSP không biết được 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 đề 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 mình. Chúng tôi rất mong nhận được ý kiến thảo luận khác tại đây. |
| Nhãn | Chrome sẽ chia sẻ nhãn dưới dạng tham số trong các yêu cầu gửi đến 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ư phù hợp với mục tiêu sử dụng dữ liệu Instagram một cách có trách nhiệm. Tuy nhiên, chúng tôi đang xem xét yêu cầu này và sẽ xem xét nội bộ. Chúng tôi sẽ công bố thông tin cập nhật về vấn đề này khi quá trình thảo luận diễn ra. |
| Việc Sử Dụng API | Làm rõ định nghĩa rõ ràng của nhóm "control_1" trong tài liệu "Hướng dẫn bổ sung của CMA cho bên thứ ba về hoạt động kiểm thử". Cụ thể, có lo ngại rằng việc thay đổi cách diễn đạt có thể bị hiểu sai là yêu cầu loại trừ tất cả API Hộp cát về quyền riêng tư khỏi control_1. | Chúng tôi đã bày tỏ quan điểm của mình về vấn đề này trong luồng thảo luận này trên GitHub. Tuy nhiên, chúng tôi không thể thay mặt CMA phát ngôn. Bạn nên trực tiếp trao đổi với CMA về mọi vấn đề liên quan đến việc diễn giải hướng dẫn kiểm thử của họ. |
| 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 một số trang web, thì chủ sở hữu trang web có thể uỷ quyền cho bên thứ ba gọi joinAdInterestGroup. 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ề lý do cụ thể để tạo IG trong quá trình chuyển hướng thay vì sử dụng cơ chế uỷ quyền dự kiến. |
| 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, sau đó có thể uỷ quyền cho bất kỳ bên mua hoặc DSP nào đặt giá thầu trên IG đó. | Chúng tôi đã nhận được ý kiến phản hồi và đang đánh giá xem liệu có thể hỗ trợ yêu cầu đó hay không. Chúng tôi rất mong nhận được 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 gỡ lỗi về việc thua nếu không có ai thắng phiên đấu giá API PA. | Các hàm reportWin và reportResult của Chrome được thiết kế để báo cáo chiến thắng ở cấp sự kiện trong hệ thống Phiên đấu giá về quyền riêng tư (PA). Trong trường hợp tất cả giá thầu bị từ chối trong phiên đấu giá PA, các hàm này không được gọi vì không có người chiến thắng nào được xác định. Bản cập nhật gần đây cho Chrome có thể giải thích sự khác biệt khi các URL được chuyển đến forDebuggingOnly.reportAdAuctionLoss() không xuất hiện trong bảng điều khiển Mạng của Công cụ 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 kênh Canary hoặc kênh Dev của Chrome. |
| Việc Sử Dụng API | adCost được trả về từ hàm generateBid có thể âm không (giá trị này đã được làm tròn ngẫu nhiên thành 2 byte)? | AdCost là chi phí nhấp hoặc chi phí chuyển đổi của nhà quảng cáo được truyền từ generateBid() đến reportWin(). Giá trị này có thể là Rỗng hoặc một số thực. Giá trị âm sẽ bị bỏ qua và không được truyền. Giá trị này sẽ được làm tròn ngẫu nhiên khi được truyền. |
| Cải thiện API | Có thể sử dụng máy chủ thực thi đáng tin cậy và được mã hoá để xử lý tính năng nhắm mục tiêu / nhóm thuần tập / phân bổ và phiên đấu giá thay vì trình duyệt Chrome không? | Bạn nên khám phá các thành phần và tuỳ 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) để giải quyết câu hỏi này. |
| Cải thiện API | Phản hồi phiên đấu giá trong Hộp cát về quyền riêng tư có thể là phản hồi giá thầu (như tính năng đặ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 thay đổi cơ bản các thuộc tính quyền riêng tư của API PA, vì vậy, đây không phải là điều chúng tôi đang cân nhắc. |
| 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 PA API trên trang của họ không? | Chrome có đề xuất về tính năng quét mẫu quảng cáo theo thời gian thực nhưng chưa có bản thử nghiệm. Mặc dù tính năng này chưa có sẵn, nhưng chúng tôi nhận thấy hầu hết SSP đều đã tạo giải pháp để hỗ trợ tính năng này. |
| Việc Sử Dụng API | Giới hạn kích thước của perBuyerSignals là bao nhiêu? | Ở dạng cổ điển, perBuyerSignals không có giới hạn về kích thước cố hữu trong Chrome. Các quy tắc ràng buộc chính là dữ liệu vẫn có thể chuyển đổi tuần tự JSON và không gây ra tình trạng tiêu thụ bộ nhớ quá mức. Tuy nhiên, bạn cần lưu ý rằng các perBuyerSignals 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ế để truyền perBuyerSignals thông qua directFromSellerSignalsHeaderAdSlot. Phương pháp này truyền perBuyerSignals trong một tiêu đề, tuân theo giới hạn kích thước tối đa 10kb cho toàn bộ phản hồi tiêu đề. Ngoài ra, từng máy chủ có thể áp dụng các quy định hạn chế riêng về kích thước tiêu đề tối đa. |
| Tài liệu | Bạn 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 | reportEvent chọn URL beacon phù hợp từ nhiều tuỳ chọn đã đăng ký bằng cách nào? | Mỗi phiên đấu giá sẽ dẫn đến một cấu hình riêng biệt, từ đó dẫn đến một bản đồ báo cáo riêng biệt. Các phiên đấu giá riêng lẻ (và khung hình thu được từ các phiên đấu giá đó) hoàn toàn tách biệt với nhau và không chia sẻ dữ liệu. Bài viết giải thích "Báo cáo quảng cáo Khung hình được phân tách" cung cấp thêm thông tin chi tiết về chủ đề này. |
| Giao diện người dùng của Chrome | Thêm bộ lọc trong thẻ "Application -> "Interest groups" (Ứng dụng -> Nhóm mối quan tâm) của Chrome DevTools, cho phép lọc theo chủ sở hữu IG (hoặc có thể là theo tên IG). | Chúng tôi đang đánh giá yêu cầu này và rất mong nhận được ý kiến phản hồi bổ sung 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 liên kết với Chrome, ví dụ: các lệnh gọi k-anon đến máy chủ của Google có thể không hoạt động trong Chrome Headless "cũ". Chúng tôi tin rằng vấn đề này có thể được giải quyết bằng phiên bản "mới" của Chrome Headless được phát hành trong Chrome 112. |
| Việc Sử Dụng API | Trong trường hợp báo cáo tổn thất bằng reportAdAuctionLoss, chúng tôi nhận thấy "topLevelWinningBid=0" trong nhiều trường hợp. Bạn giải thích thế nào về điều này? | Giá trị topLevelWinningBid 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. Theo nội dung giải thích, giá trị topLevelWinningBid bằng 0 hoặc bất kỳ số âm nào cho biết quảng cáo tương ứng không đủ điều kiện để giành chiến thắng trong phiên đấu giá. Ví dụ: bạn có thể sử dụng cơ chế này để lọc ra những quảng cáo nhắm mục tiêu theo nhóm mối quan tâm không vượt trội hơn một đề xuất được nhắm mục tiêu theo ngữ cảnh. Mặc dù giá trị topLevelWinningBid bằng 0 có thể cho biết rằng một phiên đấu giá theo bối cảnh đã thắng thầu, nhưng thông số kỹ thuật của API PA thừa nhận rằng các yếu tố khác có thể góp phần tạo ra kết quả này. |
| Thử nghiệm A/B về chế độ | Thông tin làm rõ về 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 tiêu là có các nhóm đại diện cho lưu lượng truy cập thông thường trên Chrome, 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, vì một số cấu hình ứng dụng không tương thích. Đối với mục đích của thử nghiệm, điều quan trọng là chỉ 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 bảo vệ chống theo dõi và do đó, họ sẽ nhận được thông báo về tính năng đó. |
| Cải thiện API | Có thể đưa "lifetimeMs" vào làm thuộc tính trực tiếp trong lệnh gọi joinAdInterestGroup hoặc quản lý thuộc tính này dưới dạng đối số riêng biệt không? | Chúng tôi đang cân nhắc 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. Một điểm thảo luận chính tập trung vào phương pháp tối ưu để quản lý thời lượng của video trên Instagram. Chúng tôi đang đánh giá các lợi ích của một đối số riêng cho tham số "lifetimeMs", vì đối số này thúc đẩy tính linh hoạt và khả năng thích ứng cho 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Việc Sử Dụng API | Có khả năng tăng tỷ lệ kết quả âm tính giả trong khung API PA do xung đột với mã nhận dạng trình duyệt có độ hỗn loạn 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 cảm ơn bạn đã thảo luận về tỷ lệ âm tính giả có thể xảy ra do xung đột mã nhận dạng 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 số liệu phân tích mới cập nhật phản ánh đầy đủ tất cả các yếu tố liên quan. Chúng tôi cam kết cung cấp một giải pháp giúp đạt được kết quả mong muốn về quyền riêng tư trong khi vẫn 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Việc Sử Dụng API | Có cần mã nhận dạng trình duyệt có độ hỗn loạn thấp để ngăn ứng dụng gửi đi nhiều lần yêu cầu "Join" (Kết nối) cho cùng một đối tượng trong hệ thống k-anonymity không? | Chúng tôi ghi nhận và cảm ơn cuộc 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. Chúng tôi hiểu rằng bạn có những mối lo ngại về tác động tiềm ẩn đối với quyền riêng tư của những giá trị nhận dạng như vậy. Mặc dù cách triển khai ban đầu của chúng tôi sử dụng giá trị nhận dạng có độ hỗn loạn thấp làm cơ chế chống hành vi sai trái, nhưng chúng tôi đang tích cực khám phá các kỹ thuật thay thế, chẳng hạn như Mã thông báo tính số lượt truy cập ẩ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 việc bảo vệ quyền riêng tư một cách mạnh mẽ. Chúng tôi cũng hoan nghênh việc tiếp tục trao đổ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 ý kiến phản hồi khác. |
| Việc Sử Dụng API | AMP (Accelerated Mobile Pages) có hỗ trợ API PA không. | AMP hiện không hỗ trợ API PA theo cách gốc. Chúng tôi hoan nghênh ý kiến phản hồi khác từ hệ sinh thái nếu việc hỗ trợ AMP là ưu tiên hàng đầu. |
| Cải thiện API | Cân nhắc việc xoá loại này khỏi quy trình kiểm tra tính k-ẩn danh. | Chúng tôi đang cân nhắc kỹ lưỡng ý kiến phản hồi về khả năng tối ưu hoá cấu trúc yêu cầu k-anonymity. Chúng tôi hiểu rằng bạn đề 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 hiệu quả và khả năng bảo trì. Chúng tôi đang đánh giá tất cả các lựa chọn trong quá trình tiếp tục phát triển các giải pháp về quyền riêng tư. Chúng tôi đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn. |
| Giao diện người dùng của Chrome | Yêu cầu về cơ chế giúp người dùng không chuyên về kỹ thuật dễ dàng xem và quản lý các IG mà họ thuộc về, bao gồm cả các chế độ kiểm soát tiềm năng ở cấp trang web để chọn không tham gia. | Chúng tôi nhận thấy 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 để hiểu và quản lý IG. Chúng tôi đã cân nhắc kỹ lưỡng nhiều phương pháp và nhận thấy rằng việc xác định IG theo trang web mà người dùng đã tham gia là phương pháp cân bằng nhất giữa tính rõ ràng và khả năng bảo vệ quyền riêng tư. Hiện tại, bạn có thể quản lý toàn bộ IG trong phần cài đặt của Chrome. Chúng tôi liên tục tìm hiểu các cách để nâng cao 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| API An toàn | PA API có dễ bị rò rỉ quyền riêng tư thông qua các lượt tương tác với mẫu quảng cáo, ngay cả trong bối cảnh Khung có hàng rào không? | Chúng tôi thừa nhận rằng có khả năng rò rỉ thông tin thông qua các hoạt động tương tác phức tạp với quảng cáo. Chúng tôi đang tích cực điều tra mối tương tác giữa Khung được bảo vệ, API PA và các vectơ tấn công tiềm ẩn. Việc 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ẽ, giúp cân bằng giữa sự đổi mới và 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Độ trễ | Thời gian chờ mặc định là 50 mili giây cho logic đặt giá thầu của người mua có phải là giá trị thực tế không? | Chúng tôi ghi nhận những mối lo ngại được nêu ra về sự không nhất quán tiềm ẩn giữa thông số kỹ thuật và thời gian của các yêu cầu mạng đối với 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 tính chính xác và điều tra các chế độ cài đặt thời gian chờ mặc định tối ưu để cân bằng hiệu suất và khả năng thực hiện. Chúng tôi đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn. |
| Tài liệu | Có thể rò rỉ thời gian trong quy cách, trong đó trang web có thể suy luận xem một quảng cáo có vượt quá ngưỡng k-anonymity hay không và những tác động tiềm ẩn đối với hoạt động theo dõi trên nhiều trang web. | Chúng tôi nhận thấy vấn đề được nêu liên quan đến khả năng rò rỉ thời gian. Chúng tôi đã xác nhận có sự khác biệt trong thông số kỹ thuật và đang thực hiện các bước để đảm bảo rằng trạng thái ẩn danh hệ số k của quảng cáo được xác định trước phiên đấu giá để ngăn chặn những sự cố rò rỉ như vậy. Chúng tôi rất coi trọng những mối lo ngại này và sẽ cập nhật thông số kỹ thuật để 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Việc Sử Dụng API | Các 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ế về quảng cáo của SSP. Bạn nên tìm hiểu các giải pháp ưu tiên việc đánh giá trên thiết bị và tận dụng 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 trong khi vẫn đảm bảo tính linh hoạt. Chúng tôi cam kết hợp tác với các nhà phát triển để xác định các phương pháp tối ưu trong PA API. Chúng tôi đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn. |
| Việc Sử Dụng API | Có thể yêu cầu trình duyệt giả vờ thực hiện API PA theo cách mà các trang web không thể phát hiện không? | Chúng tôi xác nhận rằng ở dạng hiện tại, việc chọn không sử dụng API PA có thể bị các trang web phát hiện. 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 theo tiêu chí loại trừ, cùng với tính năng kết xuất Khung có hàng rào để tăng cường quyền riêng tư và nỗ lực cung cấp các lựa chọn chọn không tham gia không thể phát hiện được. Chúng tôi đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn. |
| Thử nghiệm A/B về chế độ | Lưu lượng truy cập của trung tâm dữ liệu được cho là thuộc biện pháp 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Việc Sử Dụng API | Hiệu quả và tính công bằng của việc triển khai interestGroupBuyers trong API PA. | Chúng tôi nhận thấy đang có cuộc thảo luận về hiệu quả và tính công bằng của trường "interestGroupBuyers" trong phiên đấu giá API PA. Chúng tôi thừa nhận sự đánh đổi giữa hiệu quả, quyền riêng tư và sự công bằng trên 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, nhưng chúng tôi đang tìm hiểu các cách để tối ưu hoá quy trình so khớp. Các điều chỉnh này có thể bao gồm các điều chỉnh linh động dựa trên dữ liệu theo thời gian thực và mô hình kết hợp. Chúng tôi vẫn cam kết tìm ra các giải pháp ưu tiên quyền riêng tư của người dùng và hỗ trợ xây dựng một 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Giao diện người dùng của Chrome | Các vấn đề tiềm ẩn về bộ nhớ và độ 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 được nêu ra về việc hiển thị IG trong DevTools. Mặc dù chế độ xem hiện tại phản ánh tất cả sự kiện IG để theo dõi dữ liệu trong quá khứ, nhưng chúng tôi nhận thấy 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ữ cũng rất có giá trị. Chúng ta sẽ khám phá các phương pháp tối ưu hoá và cải thiện giao diện người dùng tiềm năng để nâng cao thông tin chi tiết dành cho 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 liên tục theo dõi và tối ưu hoá mứ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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Tài liệu | Người đăng ban đầu gặp lỗi khi cố gắng sử dụng kích thước quảng cáo được đặt tên ngay trong trường "sizeGroup" của hàm "joinAdInterestGroup". Họ muốn biết liệu đây có phải là hành vi dự kiến hay không. | Chúng tôi nhận thấy tầm quan trọng của việc đơn giản hoá cấu hình quảng cáo trong hàm "joinAdInterestGroup". Chúng tôi đang tích cực nỗ lực để giải quyết hạn chế này và dự định sẽ bật chức năng này trong các bản cập nhật trong tương lai. Tính năng nâng cao này phù hợp với cam kết của chúng tôi là 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Nhãn kiểm thử do Chrome hỗ trợ | Yêu cầu có dữ liệu trực tiếp về Chế độ A so với B và 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 ý kiến phản hồi bổ sung |
| Tài liệu | Tên miền của người bán có nằm trong các yêu cầu được gửi đến 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 ban đầu đã bỏ qua thông số tên máy chủ khỏi tài liệu về Protected Audience KV Server API. 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 sẽ tự động được đưa vào các yêu cầu gửi đến máy chủ đáng tin cậy của người bán. Chức năng này là yếu tố thiết yếu đối với các quy trình xác thực quảng cáo mạnh mẽ. Chúng tôi đã cập nhật tài liệu để giải quyết vấn đề này và sẽ tiếp tục ưu tiên tính rõ ràng và minh bạch cho 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Việc Sử Dụng API | Các phương thức tiềm năng để đưa tên IG vào các 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 về 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 người dùng trên Instagram vào tính năng theo dõi lượt hiển thị quảng cáo phải tuân thủ các biện pháp bảo vệ tính ẩn danh k nhằm ngăn chặn việc nhận dạng cá nhân. Chúng tôi sẽ tiếp tục tìm hiểu các giải pháp báo cáo sáng tạo trong những giới hạn 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Tính năng API | Yêu cầu máy chủ đáng tin cậy của người mua nhận tiêu đề HTTP của Gợi ý cho ứ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 | Tệp uỷ quyền có cần tiêu đề "Access-Control-Allow-Origin" để tải hay không, vì tiêu đề này quy định hành vi thành viên IG cho 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 đảm bảo tính nhất quán với các nguyên tắc CORS và ngăn việc vô tình tiết lộ thông tin nhạy cảm. Chúng tôi đang tìm hiểu các cách để tối ưu hoá quy trình này trong khi vẫn duy trì một vị thế bảo mật vững chắc. Chúng tôi đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn. |
| 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 nhận thấy vai trò của máy chủ quảng cáo trong việc 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 để hỗ trợ máy chủ quảng cáo trong PA API, chẳng hạn như mô hình "IG chung", trong đó 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ạo ra sự cân bằng giữa việc hỗ trợ các tính năng mẫu quảng cáo mạnh mẽ và bảo vệ quyền riêng tư của người dùng. Chúng tôi hoan nghênh sự hợp tác và ý kiến phản hồi tiếp theo về việc phát triển API để đáp ứng nhu cầu của tất cả các bên liên quan tại đây. |
| Lo ngại về Bảo mật | Có sẵn giá trị nhận dạng thay thế (ví dụ: RampID, ID5) trong yêu cầu giá thầu theo bối 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 tạo điều kiện cho việc thu thập dữ liệu trên nhiều trang web. | Chúng tôi nhận thấy có thể có sự căng thẳng giữa giá trị nhận dạng trên nhiều trang web và các mục tiêu về quyền riêng tư của API PA. 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 việc 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 xây dựng 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 nhà phát triển ưu tiên phương pháp API PA. Chúng tôi đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn. |
| 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 trên 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 đã quan sát đượ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 khả năng sử dụng lại tập lệnh trên các phiên đấu giá vẫn tồn tại do hành vi tạm ngưng thiết bị và thiết kế của trình thực thi đặt giá thầu. Nhóm chúng tôi đ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ý chiến lược đặt giá thầu của họ một cách hiệu quả. Chúng tôi đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn. |
| Việc Sử Dụng API | Tập trung báo cáo hoạt động đặt giá thầu trên tất cả IG cho một DSP, đồng thời 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 từng sự kiện đặt giá thầu riêng lẻ do các rủi ro theo dõi trên nhiều trang web, nhưng chúng tôi cung cấp các cơ chế như Bộ nhớ dùng chung và Tổng hợp riêng tư. Các API này cho phép 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 vệ quyền riêng tư của người dùng. |
| Việc Sử Dụng API | Hoạt động tìm nạp từ sendReportTo() trong reportResult() chỉ xảy ra 94% thời gian so với việc đăng ký tìm nạp bằng forDebuggingOnly.reportAdAuctionWin(). | Mặc dù có thể không có cùng thời gian, nhưng cả hai URL đều có thể được tìm nạp cùng một 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 được tải lại để chạy hàm reportResult(). Tuy nhiên, thời gian tìm nạp logic tính điểm cũng như thời gian tải lại worklet không ả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 cần tải lại worklet. 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. |
| K-anonymity | Yêu cầu xác nhận rằng tên của interestGroup không ảnh hưởng đến tính năng ẩn danh hệ số k của hoạt động phân phát quảng cáo. | Để một mẫu quảng cáo được coi là k-anonymous, bộ ba 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 đã chỉ định (k) trong một khoảng thời gian trước đó (w). Trạng thái k-anonymity được cập nhật định kỳ (p). |
| Giao diện người dùng của 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 cách 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 phần Công cụ cho nhà phát triển --> Ứng dụng --> Ứng dụng | Chúng tôi đang thảo luận về đề xuất này tại đây và hoan nghênh ý kiến phản hồi khác. |
| Giao diện người dùng của Chrome | Tính năng tham gia IG của Công cụ dành cho nhà phát triển không hiển thị các phần 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 thiện API | Bạn nên cho phép máy chủ quảng cáo mẫu theo dõi các sự kiện của chính nó. Tôi 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ẻ một đề xuất tại đây và hoan nghênh ý kiến phản hồi khác từ hệ sinh thái. |
| Yêu cầu về tính năng API | Có thể mở rộng API PA để hỗ trợ các giao dịch nội dung nghe nhìn 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ề vấn đề này tại đây và hoan nghênh ý kiến phản hồi bổ sung. |
| Hết thời gian chờ trong 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á để tránh bị mất lượt hiển thị, đặc biệt là trong chế độ thiết lập đặt giá thầu dựa vào tiêu đề, trong đó quảng cáo được chọn theo tuần tự. | Chúng tôi nhận thấy 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ờ 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ờ của phiên đấu giá toàn cầu, có thể là trong đối tượng "auctionConfig", đồng thời cân nhắc kỹ các trường hợp hiếm gặp. Mục đích của tính năng này là tối ưu hoá tỷ lệ hiển thị cho nhà xuất bản. 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ề vấn đề này tại đây và hoan nghênh ý kiến phản hồi bổ sung. |
| Cải thiệ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 renderURLs dài. Người kiểm thử muốn có cách nén các URL này để tăng hiệu quả. | Chúng tôi nhận thấy tầm quan trọng của việc tối ưu hoá kích thước siêu dữ liệu trên Instagram, đặc biệt là đối với các phiên đấu giá quảng cáo nhạy cảm về hiệu quả. Chúng tôi cho rằng giải pháp dựa trên mẫu để nén renderURLs có 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ác cơ chế mạnh mẽ để ngăn chặn hành vi sai trái nhằm duy trì sự ổn định của trình duyệt. Việc cộng tác với cộng đồng tiêu chuẩn web để phát triển phương pháp tối ưu, cùng với những cân nhắc này, vẫn là ưu tiên hàng đầu. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh ý kiến phản hồi bổ sung. |
| 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 để giảm tải mạng và cải thiện tốc độ hiển thị quảng cáo. | Chúng tôi nhận thấy có những vấn đề về hiệu suất liên quan đến việc 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 tìm ra sự cân bằng giữa hiệu quả và các biện pháp bảo vệ quyền riêng tư mạnh mẽ cho người dùng. Mặc dù việc trả về nhiều quảng cáo có điểm số đầy đủ sẽ gây ảnh hưởng đến quyền riêng tư, nhưng chúng tôi đ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 cam kết tăng cường hỗ trợ API PA cho các định dạng quảng cáo gốc và điều tra các cơ chế thay thế để cải thiện hiệu quả trong những quy định 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ề vấn đề này tại đây và hoan nghênh ý kiến phản hồi bổ sung. |
| 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 quy tắc của trang web thương mại riêng tư. | Chúng tôi hiểu rằng bạn cần có quyền kiểm soát chi tiết đối với 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 ghi nhận các giải pháp được đề xuất sử dụng các bộ dữ liệu và hàm toán học để đạt được điểm số đa chiều mà không làm ảnh hưởng đến quyền riêng tư của người dùng. Mặc dù các phương pháp này có thể làm tăng độ phức tạp cho nhà phát triển, nhưng chúng mang lại khả năng biểu đạt cần thiết. Chúng tôi cam kết tìm hiểu các cách đơn giản hoá các quy trình này, có thể thông qua các hàm 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 phiên đấu giá nâng cao. Chúng tôi đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn. |
| reportEvent() | Thêm một sự kiện mới được đặt trước (có thể là beacon tự động) do 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à rất mong nhận được ý kiến phản hồi bổ sung của bạn. |
| adCost | Cho phép bảng chi tiết về 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 cho phép 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, 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 ý kiến phản hồi khác của bạn. |
| 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 ý kiến phản hồi bổ sung. |
| Công cụ tốt hơn | Có gì tương tự như 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ụ dành cho nhà phát triển chuyên sâu cho API PA. |
| Nhãn | Chrome có thể sử dụng nhãn để xác định 20% người dùng k-anon không? | Chúng tôi đang xem xét yêu cầu này và hoan nghênh ý kiến phản hồi bổ sung từ hệ sinh thái. |
| Tài liệu | Worklet phiên đấu giá trong 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 riêng về quyền riêng tư và bảo mật, các worklet này khác biệt đáng kể so với các loại worklet tiêu chuẩn của trình duyệt. Vì vậy, chúng tôi không dự kiến rằng các worklet này sẽ sớm trở thành các loại worklet tiêu chuẩn trong quy cách HTML. Chúng tôi cam kết cải thiện tài nguyên dành cho 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ủa worklet phiên đấu giá, giúp những người tham gia Hộp cát về quyền riêng tư dễ dàng 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ủ khoá-giá trị (KV) Tự mang máy chủ (BYOS) | Các bên có thể tìm hiểu nhiều IG (của cùng một chủ sở hữu) mà người dùng đã tham gia thông qua các truy vấn dịch vụ KV trong quá trình thiết lập Dịch vụ KV BYOS. | Điều này sẽ không còn xảy ra khi máy chủ KV chạy trong TEE và chúng tôi có thể đảm bảo rằng các máy chủ này có thể tuân thủ mô hình tin cậy đã xuất bản. |
| userBiddingSignals | cập nhật một phần "userBiddingSignals" trong khi duy trì các phần khác. | Bạn có thể thực hiện việc này mà không cần thay đổi API. |
| Việc Sử Dụng API | Triển khai 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ể sử dụng máy chủ KV hoặc dữ liệu "prevWinsMs" đã sửa đổi. | Chúng tôi hiểu rằng bạn 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 hiểu 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ể gây ra khó khăn khi triển khai những chiến lược này. Mặc dù máy chủ KV cung cấp một cơ chế tiềm năng với các biện pháp bảo vệ quyền riêng tư thích hợp, nhưng nhà phát triển nên khám phá 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
| Việc Sử Dụng API | Người bán thành phần (những người tham gia phiên đấu giá lồng nhau trong Hộp cát về quyền riêng tư) cần biết 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 bị chậm trễ không cần thiết. | Chúng tôi nhận thấy cần phải cải thiện khả năng điều phối 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ác cơ chế hết thời gian chờ mới, bao gồm cả thời gian chờ toàn bộ phiên đấu giá tiềm năng và tìm hiểu 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à nâng cao hiệu quả và khả năng dự đoán cho tất cả những người tham gia quy trình đấu giá trong 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à rất mong nhận được ý kiến phản hồi khác của bạn. |
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) | Chi phí chạy TEE trong đám mây công khai có đắt hơn so với trung tâm dữ liệu công nghệ quảng cáo tại chỗ không? | Câu trả lờ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 khai. Cụ thể, các TEE dựa trên phần cứng hiện tại không bảo vệ chống lại 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 khai hiện được hỗ trợ của chúng tôi, bao gồm AWS và Google Cloud, đã thiết kế và triển khai các biện pháp giảm thiểu rủi ro truy cập thực tế, bao gồm cả rủi ro từ nhân viên. Hãy xem thông tin chi tiết sau đây về dịch vụ hỗ trợ tại chỗ. Các công nghệ quảng cáo đã đề cập với chúng tôi rằng việc chạy dịch vụ trên đám mây 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ại chỗ. Mặc dù không thể đánh giá những tuyên bố đó, nhưng chúng tôi rất mong nhận được thêm ý kiến phản hồi về chi phí và tiếp tục đánh giá các lựa chọn để mở rộng phạm vi hỗ trợ TEE. |
| TEEs | Hỗ trợ TEE trong môi trường đám mây không công khai | Câu trả lời của chúng tôi tương tự như các quý trước: Mặc dù chúng tôi đang tiếp tục tìm hiểu việc hỗ trợ các lựa chọn ngoài các giải pháp dựa trên đám mây công cộng, nhưng hiện tại, chúng tôi không có kế hoạch hỗ trợ TEE tại chỗ. Ở giai đoạn này, do các yêu cầu bảo mật của Hộp cát về quyền riêng tư và những thách thức đáng kể khi triển khai trên máy chủ, chúng tôi tin rằng việc tiếp tục mở rộng và cải thiện các hoạt động triển khai trên đám mây (ví dụ: hỗ trợ Google Cloud ngoài AWS) sẽ mang lại nhiều lợi ích 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, xét đến các quy định hạn chế về quyền riêng tư và bảo mật. |
| Các 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 sẵn sàng tiếp nhận các đề xuất về nhà cung cấp dịch vụ đám mây khác, nhưng ít nhất chúng tôi dự định hỗ trợ Google Cloud và AWS khi 3PCD được thực thi. Hãy tham khảo bài viết giải thích này để biết thêm thông tin. |
| API Dịch vụ B&A | Google định hướng như thế nào cho API Dịch vụ B&A? Loại đối tượng này có được ưu tiên hơn hay thấp hơn Protected Audience của trình duyệt Chrome trong phiên đấu giá thiết bị không? | Câu trả lờ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 với thiết kế đặt giá thầu trên thiết bị hiện tại của Protected Audience. Các dịch vụ B&A được đề xuất để khám phá các giải pháp có thể hỗ trợ một số trường hợp sử dụng trong đó sức mạnh tính toán hoặc tốc độ mạng của thiết bị có thể bị hạn chế. |
| Chuẩn hoá | Các dịch vụ B&A chưa trải qua quy trình chuẩn hoá. | Đề xuất về Dịch vụ B&A đang ở giữa một giai đoạn của quy trình chuẩn hoá và chúng tôi hoan nghênh sự tham gia bổ sung để hỗ trợ mục tiêu đó. Đề xuất này bắt đầu bằng một đề xuất (dựa trên các đề xuất trước đó), đang được ươm tạo công khai thông qua cuộc thảo luận mở rộng 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ẫu thông thường để phát triển tính năng web, như mô tả 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 đủ cho máy chủ KV của người mua để nhắm mục tiêu theo nội dung / 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 ý kiến phản hồi khác từ hệ sinh thái. |
| Tài liệu | Tài liệu về "Thành phần đáng tin cậy/Bắt buộc so với không bắt buộc" trên GitHub gây nhầm lẫn cho một số công nghệ quảng cáo có bộ hình ảnh triển khai và cơ sở hạ tầng riêng. | Chúng tôi đang tìm cách cải thiện tài liệu về "Thành phần đáng tin cậy/Bắt buộc so với không bắt buộc" và rất mong nhận được ý kiến của hệ sinh thái nếu cần ưu tiên công việc này. |
| Cải thiện API | Mã trạng thái HTTP của lệnh gọi máy chủ KV cũng phải có sẵn cho hàm scoreAd() dưới dạng tham số. | Chúng tôi đang đánh giá yêu cầu này và rất mong nhận được ý kiến phản hồi bổ sung 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 bằng cách 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". Đây là tên phù hợp với tập hợp các dịch vụ mà kho lưu trữ này thuộc về. Tập hợp này cũng có các kho lưu trữ khác như cuộc thảo luận về Dịch vụ đối tượng được bảo vệ 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 trên đám mây trong bidding_auction_services_gcp_guide.md. | Chúng tôi đã cập nhật tài liệu và xoá nội dung tham khảo đó. |
| Việc Sử Dụng API | Độ trễ do lệnh tra cứu KV gây 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 cách thức đang mang lại hiệu quả cho người bán khác không? Bạn có đề xuất nào về cách đo lường thời gian chờ và thời gian không? |
Lệnh gọi máy chủ KV diễn ra trong ngữ cảnh của Trình chạy tập lệnh, 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 của việc này 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 nội dung giải thích chi tiết tại đây. |
| Việc Sử Dụng API | Có thời gian chờ để máy chủ KV phản hồi trong một khoảng thời gian cụ thể không? | Người bán có thể chỉ định trường "perBuyerCumulativeTimeouts" trong cấu hình phiên đấu giá. Thời gian chờ này bao gồm cả 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 gì để giải quyết độ trễ? | Để biết các chiến lược mà chúng tôi đang tìm hiểu để đả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 theo cách thủ công | ARA không hỗ trợ tính năng tối ưu hoá chiến dịch theo cách thủ công. | Chúng tôi đã thảo luận về trường hợp này với công nghệ quảng cáo và cho thấy 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 và linh hoạt trong công nghệ quảng cáo để giải quyết nhiều trường hợp sử dụng công nghệ quảng cáo. Một số đề xuất được đưa ra bao gồm việc sử dụng các cấu hình linh hoạt ở cấp sự kiện và sử dụng báo cáo ở cấp sự kiện cùng với báo cáo tóm tắt để giảm tác động của sự cố và đáp ứng nhu cầu tối ưu hoá thủ công và tự động. Chúng tôi luôn sẵn sàng tiếp nhận ý kiến phản hồi khác về hệ sinh thái liên quan đến khả năng tuỳ chỉnh và tính linh hoạt của cấu hình ARA. |
| Loại chuyển đổi | Google chỉ cho phép 8 loại chuyển đổi, điều này gây ra hạn chế. | Chúng tôi đã triển khai phần lớn tính năng Báo cáo linh hoạt ở cấp sự kiện. Tính năng này giúp các công nghệ quảng cáo linh hoạt hơn về số lượng khoảng thời gian báo cáo, số lượng báo cáo phân bổ và các bit dữ liệu về điều kiện kích hoạt mà họ 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 trong báo cáo tổng hợp | Số lượng tối thiểu là 20 sự kiện chuyển đổi cho mỗi báo cáo tổng hợp không phù hợp với những nhà quảng cáo nhỏ có ngân sách hạn chế. | Không có số lượng sự kiện chuyển đổi tối thiểu cần thiết cho mỗi báo cáo tổng hợp. Ngoài ra, bạn có thể đưa ra một số quyết định về 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 / phương diện chính được theo dõi, thử nghiệm các mức epsilon khác nhau, thử nghiệm tần suất tạo lô dài hơn và thử nghiệm các mức phân bổ ngân sách đóng góp khác nhau giữa các mục tiêu đo lường. Các công nghệ quảng cáo nhỏ hơn cũng có thể thử nghiệm việc kết hợp báo cáo cấp sự kiện và báo cáo tóm tắt để giảm tác động của sự 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 (ví dụ: về lượt nhấp, phiên và lượt chuyển đổi) mà DSP sử dụng để điều chỉnh chiến lược đặt giá thầu và đạt được hiệu quả chiến dịch tốt hơn là hành vi trái với cam kết duy trì các chức năng hiện có. | Ngay cả khi có ARA, lượt nhấp và phiên vẫn theo thời gian thực, còn lượt chuyển đổi luôn được tính sau này ngay cả khi có 3PC. |
| Các trường bị thiếu | Thiếu các yêu cầu trong quá trình triển khai sự kiện Linh hoạt đầy đủ: i) Trường đơn vị tiền tệ và ii) trường orderID / TransactionID. | Chúng tôi không có kế hoạch hỗ trợ trường Đơn vị tiền tệ hoặc trường Mã đơn đặt hàng / Mã giao dịch trong cấp sự kiện linh hoạt đầy đủ vì hiện đã có cách để thực hiện việc này với báo cáo cấp sự kiện hiện tại. Chúng tôi luôn sẵn sàng tiếp nhận ý kiến phản hồi bổ sung về các trường này và sẽ xem xét lại nếu có trường hợp sử dụng khác cần đến các trường này. Các cách sử dụng thiết kế hiện tại của ARA để đo lường thông tin về loại đơn đặt hàng và đơn vị tiền tệ: 1. Dựa trên ý kiến phản hồi, đơn vị tiền tệ được xác định theo thông tin địa lý của người dùng. Bạn có thể thêm thông tin này vào source_event_id để xác định đơn vị tiền tệ được sử dụng. 2. Dựa trên ý kiến phản hồi, bạn cần có trường mã đơn hàng để đảm bảo lượt chuyển đổi và giá trị không bị tính hai lần do nhầm lẫn. Bạn có thể thực hiện việc này bằng cách sử dụng khoá loại bỏ trùng lặp. |
| Hạn mức quyền riêng tư | Ngân sách quyền riêng tư ARA giới hạn khả năng đo lường trên nhiều phương diện | ARA được thiết kế để cho phép các công nghệ quảng cáo tuỳ chỉnh cấu hình ARA của riêng mình 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 cần phải cân nhắc giữa những phương diện quan trọng nhất để đo lường và tác động của nhiễu đến dữ liệu của họ. 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à điều cần thiết để bảo vệ quyền riêng tư. Chúng tôi luôn sẵn sàng tiếp nhận ý kiến phản hồi bổ sung về hệ sinh thái liên quan đến khả năng đo lường trên nhiều phương diện, nhưng cần hiểu rõ các trường hợp sử dụng cụ thể cần đến điều này. |
| Cập nhật thông số kỹ thuật | Mặc dù Google đã tuyên bố chuyển từ khoảng thời gian báo cáo sự kiện cố định sang linh hoạt, nhưng điều này chưa được phản ánh trong Thông số kỹ thuật của Google. Thông số kỹ thuật này 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 linh hoạt ở cấp sự kiện 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ổ cho 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/thời lượng 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 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 tạo nhật ký. Vì báo cáo tóm tắt cung cấp thông tin tổng hợp, nên các 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ị chậm trễ, nếu cần cho trường hợp sử dụng của họ. |
| 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à thêm nhiễu có thể ảnh hưởng đến hệ sinh thái nhiều hơn Google. | Google đã cam kết với CMA rằng sẽ thiết kế và triển khai các đề xuất về Hộp cát về quyền riêng tư theo cách không làm méo mó cạnh tranh bằng cách ưu tiên hoạt động kinh doanh của chính Google, đồng thời xem xét tác động đến hoạt động cạnh tranh trong quảng cáo kỹ thuật số cũng như 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 chính xác mô hình phân bổ. | Có nhiều giải pháp có sẵn trong ARA cung cấp chức năng xác minh: 1. Các công nghệ quảng cáo có thể xác minh rằng hành vi của ARA phù hợp với kỳ vọng của họ: – Mã phía máy khách ARA là mã nguồn mở. – Mã phía máy chủ ARA cũng là mã nguồn mở và Điều phối viên đảm bảo rằng chỉ các 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 Thư viện mô phỏng cho các công nghệ quảng cáo để xác minh hành vi phân bổ, trong đó công nghệ quảng cáo có thể kiểm thử cách ARA thực hiện 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 liệu quá trình xử lý dự kiến có xảy ra hay không và lý do có thể khiến quá trình xử lý dự kiến không xảy ra. |
| (Cũng được báo cáo trong các quý trước) Độ nhiễu |
Phản hồi về việc độ nhiễu quá cao và đang ảnh hưởng đến tính hữu ích của báo cáo. | Chúng tôi đã trao đổi với các công nghệ quảng cáo có cùng ý kiến phản hồi này và xác định được những cách để tuỳ chỉnh ARA cho phù hợp hơn với các trường hợp sử dụng của họ, ngay cả khi có tạp âm. Chúng tôi có tài liệu dành cho nhà phát triển chứa hầu hết các quyết định thiết kế và 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ế để cho phép các công nghệ quảng cáo tuỳ chỉnh cấu hình ARA của riêng họ để phù hợp với nhiều tình huống phân bổ. Tuy nhiên, các công nghệ quảng cáo cần cân nhắc giữa những phương diện quan trọng nhất để đo lường và tác động của nhiễu đối với dữ liệu của họ. Chúng tôi luôn sẵn sàng tiếp nhận ý kiến phản hồi bổ sung về hệ sinh thái liên quan đến tác động của nhiễu và có thể cung cấp thêm hướng dẫn về các đòn bẩy ARA có thể dùng để thay đổi tác động của nhiễu. |
| Mô hình phân bổ trên nhiều miền | Làm cách nào để 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 luôn sẵn sàng tiếp nhận ý kiến phản hồi bổ sung về hệ sinh thái liên quan đến khía cạnh thiết kế này của ARA. |
| Cải thiện API | Thường xuyên thay đổi hệ số tỷ lệ được sử dụng khi đăng ký mô hình phân bổ cho Báo cáo tóm tắt 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 có nhiều khả năng sẽ làm tăng độ nhiễu trong báo cáo tóm tắt so với chức năng hiện tại. Chúng tôi luôn sẵn sàng tiếp nhận ý kiến phản hồi bổ sung về nhu cầu sử dụng hệ số tỷ lệ trong báo cáo tổng hợp, nhưng muốn nêu rõ sự đánh đổi tiềm ẩn khi độ nhiễu tăng lên. Chúng tôi cũng đang đánh giá xem các tính năng ARA khác 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 hợp nhất cách chia sẻ sự kiện phân bổ với tất cả người tham gia, điều này 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 họ và mọi giới hạn mà họ gặp phải. |
| Kiểm thử lưu lượng truy cập | Lưu lượng truy cập thử nghiệm cho Chế độ B cho tất cả Chrome có ổn định không? | Việc đưa vào một nhóm thử nghiệm không chịu ảnh hưởng của (độc lập với) chế độ cài đặt Chrome. |
| Tài liệu | Hỗ trợ ARA cho Pixel. | Chúng tôi đã phát hành thông tin về cách hỗ trợ trường hợp sử dụng này và hoan nghênh ý kiến phản hồi bổ sung từ hệ sinh thái. |
| Việc Sử Dụng API | ARA có thể không được phân bổ cho nguồn chính xác 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 bằng lượt tiếp xúc cuối cùng. | Các công ty có thể sử dụng bộ lọc để ngăn việc phân bổ không chính xác (ví dụ: không tạo báo cáo lượt chuyển đổi). Chúng tôi cũng đang nghiên cứu một đề 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ợ trên nhiều trình duyệt không? | Chúng tôi hoan nghênh các trình duyệt khác sử 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 công khai về phương pháp 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 để phân phối ARA và thiết kế của ARA nhằm mục đích không phụ thuộc vào trình duyệt với các giá trị do nhà cung cấp chỉ định linh hoạt cho các nhà cung cấp có quan điểm khác nhau về quyền riêng tư. Các trình duyệt khác đang tự đưa ra lựa chọn về việc có cung cấp các giải pháp thay thế khả thi cho giá trị nhận dạng trên nhiều trang web có thể hỗ trợ hệ sinh thái kỹ thuật số của nội dung và dịch vụ hay không. Chúng tôi rất vui khi Microsoft Edge cho biết 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à các beacon tự động navigation_start/commit) là gì? | Điều này tuỳ thuộc vào việc các beacon này là tự động hay thủ công:
- được đặt trước.* sự kiện (tức là sự kiện tự động) thuộc 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ó phải là giới hạn cho mỗi sự kiện nguồn không? Giới hạn này là trên toàn cầu hay hằng ngày? Có kế hoạch tăng giới hạn không? | Giới hạn 20 báo cáo tổng hợp cho mỗi 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 và không thể định cấu hình. Mục đích của giới hạn này là tránh việc 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, chúng tôi không hỗ trợ trực tiếp trường hợp sử dụng này trong ARA (nếu bạn không 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 ý kiến phản hồi khác của bạn. |
| Epsilon | Khi nào giá trị epsilon cho API Tổng hợp đượ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 lên đến một ngưỡng được xác định trước do Hộp cát về quyền riêng tư xác định (hiện là 64). Bạn nên kiểm thử nhiều giá trị epsilon và xác định các điểm chuyển đổi 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ác công nghệ quảng cáo trước khi có bất kỳ thay đổi nào đối với phạm vi giá trị epsilon. |
| Cải thiệ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 trigger_data để so khớp với dữ liệu CRM bên ngoài, cho phé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 ý kiến phản hồi bổ sung 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 một trong những việc sau: 1. Đặt URL đích cuối cùng vào trường đích; 2. Trường Đích đến cho phép tối đa 3 URL, cho phép bạn đặt nhiều URL vào trường này. Bạn cần biết URL đích cuối cùng cho cả hai lựa chọn. 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ề tính năng 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 để quan sát trên Dịch vụ tổng hợp | Chúng tôi đang xem xét các lựa chọn để hỗ trợ khả năng quan sát tốt hơn và hoan nghênh ý kiến phản hồi từ hệ sinh thái tại đây. |
| Cải thiện API | Yêu cầu quyền truy vấn lại báo cáo. | Dịch vụ tổng hợp đang xử lý một đề xuất yêu cầu lại, trong đó các công nghệ quảng cáo có thể phân tách epsilon cho mỗi báo cáo. Điều này có thể làm tăng độ nhiễu trên 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 thiện API | Muốn liên kết nhiều nguồn gốc với cùng một mã nhận dạng AWS. | Giờ đây, Dịch vụ tổng hợp sẽ cho phép bạn thêm nhiều trang web trên cùng một tài khoản đám mây (Google Cloud hoặc AWS). Điều này sẽ cho phép các công nghệ quảng cáo sử dụng cùng một vùng chứa Dịch vụ tổng hợp để xử lý báo cáo từ nhiều trang web và nhiều nguồn gốc từ cùng một trang web. |
| Việc Sử Dụng API | Khi các lô có thể tổng hợp không thành công, không chắc ngân sách có được sử dụng hay không và liệu họ 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, các 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 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 sử dụng. Trong trường hợp hiếm gặp khi ngân sách đã được sử dụng, công nghệ quảng cáo có thể yêu cầu khôi phục ngân sách. Nếu công nghệ quảng cáo thường xuyên gặp lỗi công việc với lỗi ngân sách đã hết, thì họ nên xác nhận chiến lược phân lô. Bạn có thể xem hướng dẫn về cách tạo lô báo cáo chính xác và tránh báo cáo trùng lặp cũng như lỗi tại đây. Bạn có thể gửi ý 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á. Dịch vụ tổng hợp có những khả năng mở rộng nào? | Bản thân Dịch vụ tổng hợp không đặt giới hạn trên cho số lượng khoá hoặc báo cáo trong một lô, nhưng quy mô 10^14 báo cáo và 10^12 khoá hiện không được hỗ trợ do cần có bộ nhớ. Hướng dẫn định 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 để đạt được hiệu suất tối ưu dựa trên tải dự kiến và các loại phiên bản máy ảo trên đám mây được hỗ trợ. |
| Xử lý dữ liệu | Nếu dữ liệu được mã hoá có thông tin cá nhân, thì việc cung cấp dữ liệu được mã hoá cho Dịch vụ tổng hợp có được tuân thủ quy định pháp lý hay không? Bạn có thể cho biết liệu có đảm bảo rằng người điều phối 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ẻ dữ liệu người dùng / đã mã hoá với Trình điều phối. Dịch vụ Tổng hợp sử dụng trình điều phối để quản lý và ghi nhận khoá. Bạn có thể xem một số thông tin chi tiết về trình điều phối tại đây. Đối với việc kế toán, Dịch vụ tổng hợp chỉ chia sẻ mã nhận dạng dùng chung và nguồn gốc báo cáo với PBS để sử dụng ngân sách. Sau khi khởi chạy nhiều trang web, chúng ta sẽ thay thế nguồn gốc bằng trang web. Xin lưu ý rằng Dịch vụ tổng hợp chạy trong TEE, đây là nơi duy nhất có thể giải mã báo cáo từ ứ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 như đã nêu 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 được dùng trong các thử nghiệm của Google là gì? | Đối với API Tổng hợp riêng tư, giá trị ε được chỉ định trong truy vấn dịch vụ tổng hợp tương ứng với ngân sách đóng góp L1 là 2^16 được thực thi trên cơ sở 10 phút. Ngoài ra, còn có ngân sách đóng góp L1 "bảo vệ" là 2^20 được thực thi trên cơ sở 24 giờ. Vì vậy, về cơ bản, tham số quyền riêng tư là ε trên cơ sở 10 phút và là 16ε trên cơ sở 24 giờ (thay vì 144ε). Dịch vụ tổng hợp hiện hỗ trợ một phạm vi ε để thử nghiệm (tối đa 64) cho phép thử nghiệm với 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ố 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 xem xét lại giá trị epsilon tối đa được phép theo thời gian khi nhận được ý kiến phản hồi của người kiểm thử và thêm các tính năng cho phé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 ẩn
Giảm thiểu tác nhân người dùng/Thông tin mô tả của ứng dụng tác nhân người dùng
Chúng tôi không nhận được ý kiến phản hồi nào trong quý này.
Bảo vệ địa chỉ IP (trước đây là Gnatcatcher)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Mã giải pháp | Hộp cát về quyền riêng tư cần phải nói rõ hơn với báo chí rằng mã nhận dạng độ phân giải thường được tạo dựa trên địa chỉ IP là 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 muốn 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 (không chỉ liên quan đến cookie) được công bố trên cả privacysandbox.com và GitHub. Chúng tôi nỗ lực giảm hoạt động theo dõi qua nhiều trang web, bao gồm cả hoạt động theo dõi dựa trên địa chỉ IP. Tuy nhiên, cuối cùng thì các trang web riêng lẻ mới là bên quyết định 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 có nhiều quy định về việc tuân thủ quy định, các công ty nên hiểu rõ các phương pháp mà nhà cung cấp dịch vụ của họ áp dụng. |
| Chromecast | Tính năng Bảo vệ quyền sở hữu trí tuệ có ảnh hưởng đến Chromecast hoặc các thiết bị Chrome khác không? | Hiện tại, chúng tôi chưa có kế hoạch áp dụng tính năng Bảo vệ quyền sở hữu trí tuệ cho các thiết bị Chromecast. |
| Danh sách bảo vệ địa chỉ 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 nhiều trang web trên web có được công bố không? | Danh sách này sẽ được công bố sau khi hoàn tất, như đã thảo luận tại đây. |
Giảm thiểu hoạt động theo dõi tỷ lệ thoát
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Miễn trừ về tính năng Đăng nhập một lần (SSO) | Tính năng Giảm thiểu lượt thoát (BTM) sẽ xác minh các trường hợp sử dụng SSO để được miễn trừ như thế nào? | BTM sẽ bị Chrome tắt bằng phương pháp phỏng đoán. Xem nội dung giải thích để biết thông tin chi tiết. |
| Thử nghiệm ngừng sử dụng | 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 do thử nghiệm ngừng sử dụng tạo ra, như đã thảo luận tại đây. |
Hạn mức quyền riêng tư
Như đã nêu trong nội dung giải thích trên GitHub và trang web dành cho nhà phát triển,chúng tôi không còn xem xét nghiêm túc việc sử dụng 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ư.
Tăng cường ranh giới quyền riêng tư trên nhiều trang web
Bộ 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 | Hệ thống sẽ tự động cho phép truy cập vào CHIP và / hoặc tính năng Phân vùng bộ nhớ 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à khả năng thực hiện của một tính năng có thể thực hiện chức năng này. Một điểm cần cân nhắc là khoảng trống tiềm ẩn trong khả năng tương tác trên nhiều trình duyệt. RWS giải quyết vấn đề này bằng cách tận dụng API truy cập bộ nhớ. Hiện tại, không có chức năng nào 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. Nhà phát triển nên gửi trường hợp sử dụng của họ về vấn đề này để tạo điều kiện thảo luận tại đây. |
| Xoá các bộ 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ó. |
| Quy trình thực thi | Chưa rõ vai trò chủ quan của Google trong quy trình thực thi RWS. | Vì RWS là một dự án đang diễn ra và chúng tôi vẫn tiếp tục nhận được các đề xuất mới, nên các khía cạnh của quy trình và 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 nội dung cần nêu rõ toàn bộ yêu cầu đối với việc gửi nội dung. Từ giờ trở đi, chúng tôi sẽ bổ sung thêm thông tin chi tiết vào nguyên tắc gửi nội dung để tránh gây nhầm lẫn và mơ hồ. Mục đích của chúng tôi là quy trình gửi nội dung 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 và hoàn toàn dựa vào quy trình kiểm tra tự động. Những yêu cầu hỗ trợ như yêu cầu này đòi hỏi nhiều hoạt động 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. Tuy nhiên, những yêu cầu này cho phép chúng tôi xác định thêm nhiều lĩnh vực để tự động hoá và cách chúng tôi có thể sửa đổi nguyên tắc để tránh những vấn đề này trong tương lai. |
| Chia sẻ dữ liệu | Yêu cầu về một tính năng cho phép chủ sở hữu miền cho biết họ muốn bên thứ ba cũng chia sẻ dữ liệu RWS, với sự đồng ý của người dùng. | Chức năng được yêu cầu đã có sẵn thông qua các API như FedCM và API Truy cập 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ề mọi trường hợp sử dụng cụ thể mà họ cho là không thể. |
| 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ũng sẽ được diễn giải là 3PC không? | Bộ nhớ cục bộ, bộ nhớ phiên và các hình thức bộ nhớ 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. Hãy xem bài đăng này trên blog để biết thêm thông tin chi tiết. |
| Giới hạn bộ được liên kết | Điều gì sẽ 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 tự động cấp quyền truy cập vào bộ nhớ của chúng tôi 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 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 thiết kế tương tự hiện có trên tất cả các trình duyệt chính cho API requestStorageAccess. Bạn có thể chia sẻ thêm ý kiến phản hồi và trường hợp sử dụng trong vấn đề này trên GitHub để giúp chúng tôi ưu tiên yêu cầu này và cho phép thảo luận trên nhiều trình duyệt. |
| Cử chỉ của người dùng | Có cần 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 rất mong nhận được ý kiến phản hồi bổ sung từ hệ sinh thái về việc có nên thay đổi hành vi này hay không tại đây. |
Fenced Frames API
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| adComponent | Thiếu tài liệu và tính linh hoạt khi sử dụng AdComponents với Khung có hàng rào. | Chúng tôi sẽ chia sẻ thêm tài liệu về trường hợp sử dụng này. Ngoài ra, các thành phần quảng cáo được hỗ trợ trong Khung có hàng rào bằng cách 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) Hiển thị adComponent |
Yêu cầu mã mẫu về cách hiển thị adComponents trong Khung có hàng rào. | Chúng tôi đang nỗ lực chia sẻ một số mã mẫu tại đây. |
| Xác minh quảng cáo của bên thứ ba | Cần có thêm thông tin chi tiết về vai trò của dịch vụ xác minh quảng cáo của bên thứ ba trong bối cảnh Khung được phân vùng, đặc biệt là về sự an toàn theo ngữ cảnh/thương hiệu. | Hiện tại, Báo cáo quảng cáo trong khung được phân vùng cho phép DSP gửi dữ liệu ở cấp sự kiện đấu giá và lượt hiển thị đến trình xác minh quảng cáo bên thứ ba để kiểm tra tính an toàn cho thương hiệu sau khi hiển thị và thanh toán. |
| 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ỉ khác kích thước), thì trình nhúng có thể đổi kích thước Khung được phân vùng bằng kích thước quảng cáo thứ hai và trình duyệt sẽ điều chỉnh theo tỷ lệ phần tử Khung được phân vùng. |
| (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à quảng cáo gốc |
Khung được phân vùng có hỗ trợ khoảng không quảng cáo dạng video và quảng cáo gốc không? | Câu trả lời của chúng tôi tương tự như các quý trước: PA API hỗ trợ tính năng 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à video tương thích với Khung được phân vùng. Đây là một trong những lý do chúng tôi quyết định hoãn việc thực thi Khung được phân vùng đến năm 2026. Điều đó có nghĩa là nếu một đối tác quyết định thực thi Khung được phân vùng ngay bây giờ, thì đối tác đó sẽ không được hỗ trợ cho video và quảng cáo gốc. |
| Hội đồng cố vấn | Yêu cầu thành lập hội đồng 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 được phân vùng tuân thủ các tiêu chuẩn của ngành. | Bạn không bắt buộc phải sử dụng Khung có hàng rào trong API PA sớm nhất là vào năm 2026. Thời gian bổ sung này cho phép chúng tôi tiếp tục làm việc với các bên trong ngành để thiết kế và triển khai dịch vụ hỗ trợ cho nhiều trường hợp sử dụng quan trọng hơn. Như đã nêu trước đây, chúng tôi sẽ phát triển Khung được phân vùng trước khi yêu cầu duy trì khả năng hỗ trợ video và quảng cáo gốc bằng PA API. Theo cam kết của mình, chúng tôi sẽ trao đổi và thông báo cho CMA về mọi thay đổi như vậy. Đồng thời, chúng tôi sẽ tiếp tục thu thập ý kiến phản hồi từ hệ sinh thái trước khi yêu cầu sử dụng Khung có phân vùng. 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 mọi chuyên gia trong ngành hướng dẫn thiết kế trước khi yêu cầu. |
| (Cũng được báo cáo trong các quý trước) Sự khác biệt về kích thước trên các nền tảng |
Báo cáo rằng kích thước nội dung hiển thị trong Khung có hàng rào khác nhau giữa máy tính và điện thoại thông minh. | Đây là một vấn đề đã biết của Chromium mà chúng tôi đang điều tra. Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn tại đây. |
| Cải thiện API | Yêu cầu về Khung được phân vùng có bị đẩy lùi đến năm 2025 để quảng cáo gốc hiện được hỗ trợ 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 được khoanh vùng muộn nhất vào năm 2026, chúng tôi đã nhận thấy một "nỗ lực đáng kể để điều chỉnh" Khung được khoanh vùng. Chắc chắn một trong số đó là mã 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 đả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 ở các trường hợp sử dụng 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ề của Bộ nhớ dùng chung bên ngoài worklet có vẻ như 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 thử này tại đây. |
| Mở rộng phạm vi sử dụng | Bộ nhớ dùng chung phải là một tiêu chuẩn trên toàn ngành và có 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 tiếp tục tích cực tham gia các diễn đàn của 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 | 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 / logic kinh doanh (chẳng hạn như Giới hạn tần suất) dựa trên thông tin trên nhiều trang web và chọn một nhóm quảng cáo không? | Không, không thể đọc từ bộ nhớ dùng chung trong các công việc đặ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 |
|---|---|---|
| Dung lượng 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ẽ bị đẩ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. 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 iFrame của bên thứ ba | Nội dung iFrame nhúng của bên thứ ba mở một thẻ/cửa sổ mới đến cùng một trang web của bên thứ ba phải có quyền truy cập vào cùng một cookie được phân vùng với 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 ý kiến phản hồi bổ sung từ hệ sinh thái tại đây. |
| Cookie trùng lặp | Nếu có một cookie được phân vùng và một 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 trù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 được cookie nào là cookie nào. Bạn có thể xem thông số kỹ thuật RFC về vấn đề này tại đây. Thông số này giải thích rằng bạn không nên dựa vào thứ tự gửi cookie. |
| Yêu cầu tính năng | Chọn sử dụng cookie được phân vùng theo nguồn gốc. | Chúng tôi đang xem xét yêu cầu này và hoan nghênh ý kiến phản hồi khác của hệ sinh thái tại đây. |
FedCM
Chúng tôi không nhận được ý kiến phản hồi nào trong quý này.
Chống hành vi gian lận và nội dung rác
Private State Tokens API (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ó tồn tại trên nhiều Khung hiển thị web trên cùng một thiết bị di động (hồ sơ) không? | Mỗi ứng dụng sử dụng webview sẽ có một bộ nhớ cục bộ khác nhau, nghĩa là các nhà phát hành PST không thể phát hành mã thông báo trong webview của một ứng dụng, sau đó cho phép sử dụng mã thông báo trong một ứng dụng riêng biệt. Đ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 thành phần hiển thị web, 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à tiếp tục tìm hiểu các ứng dụng và cách điều chỉnh PST. Chúng tôi mong muốn 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ó? | Hiện tại, chúng tôi đã giảm thiểu vấn đề này bằng cách giới hạn số lượt sử dụng mã thông báo trên một trang web ở mức 2 nhà phát hành, bất kể nhà phát hành đó có mã thông báo hay không. Bạn cần tính một nhà phát hành vào giới hạn ngay cả khi không có mã thông báo nào, nếu không, trang web có thể lặp lại qua tất cả các nhà phát hành cho đến khi tìm thấy một kết quả trùng khớp. |
| Đăng ký | PST cần đăng ký trong bao lâu? | Trong tương lai gần, bạn vẫn sẽ phải đăng ký, như đã 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 khác dựa trên Chromium có được hỗ trợ thông qua kho lưu trữ Đăng ký 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 ứng dụng 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 thêm tính năng hỗ trợ đầy đủ hơn cho API, các trình duyệt đó sẽ cần thiết lập quy trình để nhận các cam kết chính cho ứng dụng, 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. Bạn có thể xem thêm thông tin chi tiết tại đây. |