2023 年第 1 季的季度報告匯總了我們在 Privacy Sandbox 提案和 Chrome 回覆中收到生態系統的意見回饋。
根據對 CMA 的承諾,Google 同意公開提供每季報告,說明其 Privacy Sandbox 提案的相關人員參與程序 (請參閱承諾第 12 和 17(c)(ii) 項)。這些 Privacy Sandbox 意見回饋摘要報表是匯集 Chrome 從意見回饋總覽頁面上列出的各種來源的意見回饋匯總而成,包括但不限於:GitHub 問題、privacysandbox.com 上的意見回饋表單、與業界相關人士的會議,以及網頁標準論壇。Chrome 十分歡迎生態系統收到的意見回饋,並積極探索如何將所學知識整合至設計決策中。
意見回饋主題是依 API 的常見程度排名,方法是擷取 Chrome 團隊針對特定主題收到的意見回饋總數,並依數量遞減排序。我們透過公開會議 (W3C、PatCG、IETF)、直接意見回饋、GitHub 及 Google 內部團隊和公開表單提出的常見問題,找出常見的意見回饋主題。
更明確地說,網路標準體系會議的會議分鐘數都經過審查,而為了直接提供意見回饋,Google 的 1:1 相關人員會議記錄、個別工程師收到的電子郵件、API 郵寄清單和公開意見回饋表單接著,Google 會和參與這些各種外聯活動的團隊協調,判斷各主題相對於各 API 的相對情況。
我們根據已發布的常見問題、對利害關係人提出問題的實際回應,制定了 Chrome 回應回應的說明,並針對這項公開報告練習制定專屬定位。回顧目前的開發和測試重點,以及有關 Topics、FLEDGE 和 Attribution Reporting API 的問題和意見回饋。
在目前的報表統計期結束後收到的意見回饋,可能尚未視為 Chrome 的回應。
縮寫詞
- 方塊
- 具有獨立分區狀態的 Cookie
- DSP
- 需求端平台
- FedCM
- Federated Credential Management
- FPS
- 第一方集合
- IAB
- 互動廣告協會
- 印尼盾
- 識別資訊提供者
- 網際網路工程任務組 (IETF)
- 網際網路工程任務組
- IP
- 網際網路通訊協定位址
- openRTB
- 即時出價
- 延長賽
- 來源試用
- PatCG
- 私人廣告科技社群
- RP
- 宗教派對
- 賣方平台
- 供應端平台
- TEE
- 受信任的執行環境
- UA
- 使用者代理程式字串
- UA-CH
- 使用者代理程式用戶端提示
- W3C
- 全球資訊網協會
- 建構中
- 有益 IP 盲點
一般意見回饋,無特定 API/技術
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
測試與試用 | 測試的關聯性,用於告知 CMA 評估作業,如果測試開始時未完成 Privacy Sandbox API 評估 | 正在開發 Privacy Sandbox API。這些 API 目前已可供測試的來源試用,且在今年夏天將開放給 100% 的流量使用。 此外,我們已針對在 2026 年之前不會受到影響的特定功能 (例如 FLEDGE 事件層級報表、使用 iframe 進行 FLEDGE 算繪) 清楚說明,並提供相關說明。 我們鼓勵生態系統測試 API,並根據測試人員在第三方 Cookie 淘汰後預期仰賴的事項,提供意見回饋給 CMA。這有助於他們評估第三方 Cookie 淘汰可能造成的影響。 |
使用者控制項 | 對於 Privacy Sandbox API 的使用者控制選項可能造成的影響,明確說明生態系統 | 我們無法針對使用者控制生態系統的可用內容,提供法律建議。同時,Chrome 正嘗試對極少數使用者顯示更新版 Privacy Sandbox (「加強型廣告隱私權」) 使用者控制項,藉此持續改善 Privacy Sandbox 技術。更新內容包括更清晰、更實用的語言和版面配置。Chrome 評估完這些修正內容,並決定是否將其擴大至更廣泛的人口後,便能夠與生態系統分享更多資訊。 |
資料外洩 | 如果瀏覽器遭到入侵,第一方資料就會導致 Google 和其他單位的資料外洩 | 我們的 FLEDGE 說明頁面清楚指出,廣告技術的資料僅會與同一廣告技術 (與其工作清單或信任的伺服器共用),或由該廣告技術明確分享 (例如買家顯示想要顯示的廣告網址) 時。有一個例外是,k-anonymity 檢查必須由全域集中式伺服器完成,而我們持續投入大量資源。請參閱 K-anonymity 說明,瞭解我們如何考量隱私權。 此外,我們也很樂意針對 k-anonymity 伺服器設計中採用的廣告技術保護措施提供詳細資訊。 |
其他討論論壇 | 要求向 W3C 提供其他論壇,讓非技術生態系統玩家提供意見回饋 | Privacy Sandbox 意見回饋表單適用於一般評論、技術性和非技術性質。 改善網路廣告業務群組是一個論壇,您可以透過每週呼叫和 GitHub 存放區參與討論。 developer.chrome.com 的 Privacy Sandbox 意見回饋頁面說明其他提供意見回饋和參與討論的機制。此外,Chrome 也會持續保留公開諮詢時間等事件,方便使用者提問和分享內容。此外,Chrome 上一季還舉辦或參加過超過十場產業活動。 |
時間軸說明 | 說明預計在 2023 年第 3 季正式發布的確切日期 | 根據 PrivacySandbox.com 上發布的時程,預計從 Chrome 115 版開始推出。 |
reCAPTCHA | Sandbox API 對 reCATPCHA 垃圾內容偵測用途的影響 | 我們會定期收到 reCAPTCHA 提供的意見回饋,確保 Privacy Sandbox 提案不會對網路安全性或詐欺行為造成顯著影響。他們目前正在製定自己的計畫,為第三方 Cookie 淘汰預做準備和調整,因此他們最適合回答這個問題。 |
Chrome 擴充功能 | 反耦合追蹤 (ACT) 等 Privacy Sandbox 技術是否適用於 Chrome 擴充功能? | 對於 ACT 是否適用於 Chrome 擴充功能,目前我們尚未發布任何公告。不過,如果技術會廣泛收集使用者資訊,這種情況就不符合我們的隱私權原則。 |
顯示相關內容和廣告
主題
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
TAG 設計審查 | TAG 發布 Topics 的早期設計審查。 | 我們持續致力於開發 Topics,並在最新更新頁面和這個問題中分享有關 Topics 的最新消息。我們會逐一回應 TAG 審核,並分享這份更高層級的願景。 Topics API 仍會是 Google Ads 生態系統在 2023 年應測試的 API 集合。我們希望聽到這些測試意見回饋及我們獲得的實作體驗,日後致力發展跨瀏覽器標準在這個領域發揮良好成效。我們期待繼續與生態系統互動,瞭解如何簡化 Topics API 的可行性,讓 Topics API 符合跨瀏覽器相容性的協議標準。 |
Topics 方法 | Chrome 必須開發 Topics API,支援開放式方法 | 我們很重視這樣的情緒,期待能繼續與業界團體合作開發 Topics API,為整個生態系統帶來價值。 |
(同樣在 2022 年第 3 季皆有報告) 主題分類的精細程度不足 |
廣泛主題分類不包含較精細的主題,包括特定區域。 | 第 1 季更新: 改善分類是我們持續努力的成果,我們會在第 2 季宣布 Topics API 的更新分類。為了建立這個新的分類,我們與生態系統中的公司密切合作。 我們正積極向大環境提供最實用的分類意見回饋。在評估是否要擴大主題數量或納入更精細的主題時,需要考量以下幾點:1) 潛在的隱私權影響 (更多主題可能會帶來數位指紋採集風險),以及 2) 擷取先前觀察到的主題 (例如建立更多主題時,廣告技術過去可能較不常看到所選主題)。 |
(另記錄於 2022 年第 4 季) 對第一方信號的影響 |
主題信號可能極具價值,因此會降低其他第一方興趣信號的價值。 | 我們認為按照興趣顯示廣告是網路的重要用途,而 Topics 也能支援這種使用情境。我們瞭解,有些大型發布者擔心 Topics 會對第一方資料策略造成負面影響。我們很期待進行生態系統測試,藉此深入分析 Topics 對發布商的影響。 |
與廣告無關的 Topics 使用案例 | 將 Topics 用於顯示按照興趣顯示的廣告以外的用途 | Topics 的用意是因應「按照興趣顯示」的廣告用途,而我們認為這是自由開放的網路環境的重要用途。我們目前正在評估其他用途的相關意見回饋,並正在評估當中。 |
預設採用狀態 | Topics 同意聲明預設值會依區域法規影響 | 我們無法對法律意見發表意見。 |
(同樣在 2022 年第 3 季一併顯示) 分類錯誤的網站 |
指定網站主題分類錯誤的廣告指定目標 | 第 1 季更新: 我們在第 2 季宣布更新 Topics API 的分類器,並期待能與這個生態系統互動。 為回應目前的意見回饋,我們結合了人工收錄的覆寫清單來分類網站,其中含有最受歡迎的網站和裝置端機器學習模型。Chrome 會持續評估網站是否要納入 Topics 分類,所有公用程式的改善都必須權衡隱私權和濫用風險。舉例來說,網站可能會以「自主標籤」形式將不同 (可能敏感) 含意相關主題編碼;網站以牟利為目的而謊報主題;網站藉由攻擊主題為他人激增 (例如濫發無意義的雜訊,濫發垃圾內容)。 大眾可以透過 chrome://topics-internals 或這個 colab 取得工具,檢查這些元件。透過測試,我們期望能隨著時間改善分類功能,也歡迎你針對可能分類錯誤的網站提供意見回饋。 |
主題分類器 | 要求傳回其他資訊,顯示「沒有主題」傳回給呼叫端以進行偵錯的原因 | 我們瞭解偵錯工具正致力將 Topics API 整合至自家系統,因此對開發人員很有幫助。然而,公開其他資訊 (例如未傳回 Topics 的原因) 可能會無意間分享資訊,讓各方能進一步掌握其他詳細資料 (例如,使用者處於無痕模式,或已停用 API 等),進而危害使用者隱私。我們暫時不打算提供其他偵錯工具,但還是歡迎您提供意見,說明哪些工具對您有價值。 |
擷取私人資訊 (PIR) | 要求 Topics API 採用私人資訊擷取功能 | 我們先前已使用 PIR 進行調查,並參閱此處的優缺點。 |
出價串流 | Topics 在出價串流中是否與賣方定義目標對像不同? | Topics API 是 Chrome 開發的 Privacy Sandbox 提案,與 IAB Tech Lab 的「Seller-Defined Audiences」 提案不同。我們預期出價串流中會明確表示這兩者。瞭解 Topics 如何在 OpenRTB 出價要求中表示。 |
Protected Audience API (舊稱「FLEDGE」)
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
FLEDGE 功能適用情況 | 針對 FLEDGE 功能的測試和實作時程說明,例如 Fenced Frame 強制執行、K-Anonymity 等。 | 我們已分享了一篇網誌文章介紹了各種限定範圍的 FLEDGE 功能及支援的時機。我們會持續開發 FLEDGE,歡迎針對公告提供其他意見回饋。 |
產品顯示限制 | 要求放寬 FLEDGE Fenced Frames 多方針限制的廣告 | 如同我們 2 月的公告,在至少 2026 年之前,你還是可以選擇是否要使用 Fenced Frame,且 urn-iframes 將支援 iframe 行為。我們希望您可以進一步討論這個主題。 |
擴充性問題 | 根據用量規模調整 FLEDGE 效能 | 我們會積極追蹤創作者的意見回饋並進一步瞭解背景資訊,進而提供可行的解決方案。第一步是將意見回饋分為兩個類別:
|
(另於 2022 年第 3 季一併報告) 出價邏輯的瀏覽權限 |
瞭解 DSP 出價邏輯會在 JavaScript 中公開 | 第 1 季更新: 我們分享了一項提案,主要是限制有心人士以探索 (強制瀏覽) 的方式從伺服器要求資料。我們也歡迎生態系統玩家分享他們的意見回饋或支持提案。 |
測試問題 | 可讓較小的 DSP 正確測試 FLEDGE,並降低廣告客戶只想使用大型 DSP 進行測試的風險 | 我們致力於與較小的 DSP 合作,並強烈建議在 FLEDGE 移至正式發布階段後,進一步在 DSP 和各種大小的廣告客戶之間進行擴大測試。我們想瞭解該如何有效協助該公司與生態系統中的其他人員測試 FLEDGE,並歡迎提供想法和業界的想法,鼓勵廣告客戶透過較小的 DSP 進行測試。 |
動態再行銷 | 在第三方 Cookie 淘汰後,FLEDGE 仍可進行動態再行銷嗎? | 我們正在考慮回答這個問題,也歡迎生態系統業者分享更多深入分析,說明他們打算如何使用動態再行銷。 |
詐欺/濫用 | 這個生態系統如何降低風險,並阻止惡意行為人或買家將自己定位為理想的目標對象? | 我們期待能進一步與生態系統玩家交流互動,瞭解詐欺和濫用行為,也歡迎針對這方面提供意見回饋。 |
受使用者喜愛 | 儲存使用者偏好設定並用於廣告選擇的程序 | 針對特定廣告,相關的廣告技術是最適合用來控管顯示廣告素材或選取方式的一方。 |
量化測試提案 | 為確保量化測試保持公平,是否應在沒有第三方 Cookie 的流量,或透過僅使用 FLEDGE 的賣方平台執行測試?如何避免混合使用第三方 Cookie 的信號? | 我們十分重視這項意見回饋,也正與 CMA 合作設計實驗,協助您全面瞭解第三方 Cookie 淘汰作業的影響,以及 Privacy Sandbox 提案對生態系統的影響。我們建議針對 CMA 的量化測試提案提供額外意見回饋,並直接與 CMA 分享。 |
說明文件內容更清楚 | 要求提供更清楚的競價設定說明文件 | 我們預計在未來幾週內發布一篇網誌文章,並提供有關 FLEDGE 競價報表的額外總覽。 |
平行處理 | 出價和競價 (B&A) 服務是否支援平行處理功能? | 使用「出價 / 競價」伺服器的廣告技術可以啟動多個可以同時放送結果的伺服器。 |
緩解濫用行為 | 使用私人狀態權杖的 FLEDGE k-anonymity 伺服器是否足以保護使用者隱私? | k-anonymity 的動機較不專注在微指定上,而是著重於在 FLEDGE 提供事件層級報表的過渡階段設定一些反向停止。我們已分享更多想法,也歡迎提供其他意見回饋。 |
ES 模組衝突 | 要求將 generateBid 捨棄為全域函式,因為該函式與 ES 模組發生衝突 |
我們正在討論這項要求,也歡迎您提供意見。 |
組件競價 | 要求發布商進一步控管競價設計 | 支援元件競價的出價和競價計畫,與裝置端 Chrome 相同。 |
民宿時間表 | 針對有意測試 B&A 伺服器的廣告技術人員,清楚掌握時間表 | 我們日前更新了 B&A 說明並更新時間軸一節,在配合 CMA 標準後,針對 Chrome-B&A 測試的不同階段加入明確定義。 |
逾時控製配置 | 強化 FLEDGE 目前可用的逾時控制項配置 | 這是有趣的提案,我們會將該提案排入待研究的提案佇列,然後回報我們開發的成果。 |
廣告素材出價串流 | 可根據廣告素材 | 這是有趣的提案,我們會將該提案排入待研究的提案佇列,然後回報我們開發的成果。 |
reportWin |
建議針對其他興趣群組擁有者 (而非 reportWin 函式中的勝出者) 提供額外資訊,提供額外相關資訊 |
這是有趣的提案,建議您在匯總報表中加入其他信號,也歡迎在這裡提供其他意見回饋。 |
事件類型 | 與 FLEDGE 整合時, 將各個評估 API 的事件類型標準化 | 這是有趣的提案,我們會將該提案排入待研究的提案佇列,然後回報我們開發的成果。這項功能需要與我們廣泛投入的努力合作,因為這會影響 FLEDGE 以外的其他 Privacy Sandbox API。歡迎點選這裡,提供其他意見回饋。 |
事件層級報表的長期解決方案 | 即使在第三方 Cookie 淘汰後,依然有興趣保留特定資料 (例如 highestScoringOtherBid ) |
如 2 月份的網誌文章所述,在「至少 2026 年以前」,系統將支援事件層級競價勝出報表。目前我們無法提供進一步的詳細資訊,但也歡迎提供其他意見,說明為何在第三方 Cookie 淘汰後,保留某些資料十分重要。 |
興趣群組限制 | 來源可新增單一瀏覽器的興趣群組數量上限為何? | Chrome 允許每位擁有者最多有 1,000 個興趣群組,以及最多 1,000 位興趣群組擁有者。這些資訊旨在做為防護機制,而非在一般作業中發揮作用。 |
事件層級信號 | 支援具備 generateBid 和 reportWin 的事件層級信號,可用於進行機器學習訓練 |
我們已分享我們對瀏覽器設計的信號和廣告技術定義信號的決定,同時也歡迎提供其他意見回饋。 |
出價指令碼 | 在出價指令碼的網址中加入使用者 ID。 | FLEDGE 不會這麼做,因為興趣群組擁有者、出價指令碼網址和顯示的廣告素材都必須有 k 匿名化才能顯示廣告。 |
K-anon 違規處置 | 是否針對 (componentAd、size) 配對強制執行 k-anonymity? | 是,這有。請參閱 turtledove/issues/312。 |
出價和競價服務相關規定 | B&A Services 如何支援與裝置端 FLEDGE 及其他 B&A 服務的參與者整合? | 我們仍在確認設計階段,歡迎在這裡提供其他意見回饋。 |
瀏覽後轉換歸因 | 是否支援瀏覽後轉換歸因? | 我們目前沒有任何類型的可視度標準定義,而是仰賴廣告素材本身標示觀看事件。請參閱 turtledove/issues/452。 |
類似指定目標 | Privacy Sandbox 是否支援「指定類似指定目標」? | 我們正在討論用途,歡迎提供更多輸入內容。 |
即時監控 API | 即時 FLEDGE 監控方法的提案 | 我們正在討論提案內容,並在此歡迎你輸入其他資料。 |
FLEDGE 報表 | reportWin 和 reportResult 應隨機進行順序,以免過度回報或遭到低估。 |
reportResult() 需要先由賣方執行,才能在 reportWin() 之前執行,這樣賣方信號才能加入 reportWin() 中。reportResult() 詳情請參閱相關說明。 |
自訂鍵/值 (K/V) 伺服器 | 未來是否會支援自訂 K/V 伺服器? | 我們正在在這裡討論問題,也歡迎您提供意見。 |
頂層競價 | 一定要讓廣告伺服器執行頂層競價機制嗎? | FLEDGE API 不會指定必須呼叫該方的一方;FLEDGE 的設計中沒有任何規定。任何人都可以執行 FLEDGE 競價 (包括多重賣方競價)。如 2022 年第 4 季報告所述,FLEDGE 可讓每個發布商選擇競價結構,包括選擇頂層和元件賣方的選項。 |
API 範圍 | FLEDGE 是否打算處理第一方資料? | 我們將在 2023 年第 2 季發布內容,明確指出第一方資料確實可與 FLEDGE 搭配使用,以便:1) 以邏輯判斷興趣群組成員;以及 2) 以動態饋給做為後續產生出價邏輯的使用者出價信號。 |
跨網域興趣群組 | 建立跨網域興趣群組的可能性 | 將瀏覽器加入興趣群組時的任何資訊,都可用來告知目標對象。逐步停用第三方 Cookie 後,系統就無法提供跨網站資料來協助建立興趣群組。 |
用戶端出價邏輯 | 將現有的伺服器端出價邏輯移植到用戶端 | 我們期望進一步瞭解哪些方面較難或缺少攜碼轉移程序,也歡迎提供其他意見回饋或深入分析結果。 |
K/V 伺服器值 | K/V 伺服器值是否為類型字串? | 此值需要字串,但可以將物件儲存在 JSON 或通訊協定緩衝區中,並將其序列化為字串。 |
廣告主封鎖清單 | 哪些信號適合為廣告客戶封鎖清單提供買方? | 適當位置位於 auctionSignals 或 perBuyerSignals 中。 |
出價單位 | 支援不同的出價單元,例如單次安裝出價和千次曝光出價 | 我們希望進一步瞭解為什麼目前的設計需要這麼做,也希望收到其他意見回饋。 |
競價邏輯 | 瀏覽器或廣告伺服器會決定競價的勝出者嗎? | 所有勝出組合都會在沙箱中執行,且所有決定都是由賣方的程式碼所決定。瀏覽器只提供一個密封的私密環境,供買方和賣方程式碼執行。 |
權限 -政策 | 來源試用結束後,目前的 FLEDGE 權限政策是否會繼續強制執行? | 在來源試用中,這兩項功能目前的預設許可清單是暫時性的,之後將變更。Google 想知道廣告技術人員需要花多少時間做好準備,才能落實這項異動。 |
信號大小限制 | 系統會將受信任的出價信號要求,與 trustedBiddingSignalsUrl 相同的多個興趣群組相輔相成。2MB 的大小限制是一種限制。 |
裝置端的呼叫端設有此限制,以免裝置的資源過大。B&A 伺服器的呼叫者將擁有更嚴格的限制。 |
報表信號 | 新增其他信號「指令碼錯誤」,以擷取每個興趣群組擁有者和每個 computeBid 或 reportWin / reportResult 的用戶端錯誤次數。 |
我們正在思考本提案的潛在隱私權疑慮,並歡迎生態系統玩家分享更多深入分析,說明為何需要這麼做。 |
K-Anon 視窗大小 | 將 K-Anon 視窗大小提高目前的 7 天上限。 | 這屬於考慮性質,我們目前還在等候生態系統中的其他輸入內容。 |
裝置成效 | 如果使用者屬於大量興趣群組,FLEDGE 會如何處理裝置效能? | FLEDGE 針對賣方平台和需求端平台提供多個逾時、優先順序和限制選項,讓廣告技術人員能精細控管裝置在大量興趣群組時參與競價的情況。 |
民宿服務測試 | 要求生態系統玩家在測試階段使用自己的伺服器,以便取得更多用於偵錯的記錄 | B&A 可讓使用者透過核准的雲端服務供應商啟動及調度伺服器。為維護使用者隱私,我們強制必須在受信任的執行環境 (TEE) 中執行執行作業。我們即將推出 B&A TEE 偵錯說明,目前正在開發支援這項功能的功能。我們正在針對這個主題尋求其他意見回饋。 |
法規要求 | FLEDGE 是否會與不同國家/地區的雲端服務供應商合作,以符合當地法規要求? | 我們一直樂意推薦其他雲端服務供應商,但目前我們至少打算在強制執行第三方 Cookie 的淘汰時,支援 GCP 和 AWS。詳情請參閱這份指南。 |
評估數位廣告
Attribution Reporting (和其他 API)
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
噪音影響資料分析 | 如何執行資料分析對雜訊的影響的指南 | 我們已分享有關雜訊和設計決策的其他說明文件,這些說明文件可用於變更雜訊對廣告技術資料造成的影響。 您也可以參閱更詳盡的指南。 |
空值報表 | 空值報表的導入作業清楚明確 | 我們目前正在研究如何導入空值報表,很快會再分享更多詳情。導入空值報表可讓我們在兼顧隱私的前提下,減少報表延遲。 |
噪音水平 | 根據歸屬期長度調整雜訊等級 | 我們歡迎這個提案,也有意將提案納入規格中。歡迎點選這個連結,提供其他意見。 |
觸發事件資料大小 | 為什麼觸發事件資料大小上限是 3 位元? | 大小上限為 3 位元和 8 個不同的值,以確保使用者的相關跨網站/背景資訊有限。我們歡迎生態系統玩家提交意見回饋,說明目前的事件層級報表參數化作業是否合理。 |
事件層級報表觸發條件 | 允許在簡化鍵中設定優先順序 | 我們正在探索關於這個問題的解決方案,並歡迎您提供其他意見。 |
偵錯支援 | 第三方 Cookie 淘汰後產生的偵錯說明 | 在第三方 Cookie 淘汰後,我們希望能支援偵錯功能,並思考各種選項。我們希望提供其他意見回饋和想法。 |
點閱後轉換替代方法 | 取得更多點閱後轉換的替代指引 | 我們鼓勵生態系統使用 Attribution Reporting API,做為適用的轉換評估用途的長期不公開評估系統。還有其他替代做法,廣告技術供應商必須根據他們需要的隱私權和公用程式需求,決定合適的解決方案。 |
帳單用途 | Attribution Reporting 將支援以轉換為準帳單使用情境 | 我們正致力於公開發布相關資訊,清楚說明 Attribution Reporting API 的計費範圍。Attribution Reporting API 一開始並未以直接支援單次轉換出價計費的方式,而支援單次點擊出價和千次曝光出價的計費方式,後者是廣告技術人員使用的計費結構。 日後如有其他生態系統意見回饋,我們可能會支援這項功能。 |
用途支援 | Measurement API 的用途說明文件 | 我們正在努力釐清所有 Privacy Sandbox 報表介面的說明文件。 |
點擊品質 | 要求新增信號來區分廣告意圖和意外點擊 | 我們正在討論這項要求,並歡迎您提供意見。 |
成效評估解決方案 | 支援多個需求端平台的成效評估解決方案 | 評估服務供應商可使用 Attribution Reporting API 來簡化多個需求端平台之間的資料。此外,我們也建議支援 attributionsrc 中的網址清單,方便需求端平台支援評估服務供應商 Attribution Reporting API 要求。歡迎針對上述提案提供其他意見。 |
事件層級報表 | 申請提前幾天後直接取得報表 | 廣告技術可根據目前可用的資訊計算這項要求。我們尚未收到其他生態系統對這項要求的意見,但還是希望收到相關的意見回饋。 |
source_registration_time |
在事件層級的歸因報表中加入 source_registration_time 。 |
我們會考慮這項要求,並歡迎提供其他意見回饋,協助我們瞭解生態系統玩家是否認為這項功能實用。 |
無痕模式 | 當使用者處於無痕模式時,是否可以使用成效評估解決方案? | 不行,在無痕模式下無法使用成效評估解決方案。在無痕模式中,第三方 Cookie 皆預設為關閉。 |
資料無塵室 | Measurement API 是否與資料無塵室相容? | 一般的資料無塵室是環境,其中不同來源的個別 ID 資料會上傳到資料庫,並根據合併該基礎資料執行分析。Privacy Sandbox API 的兩種評估架構是事件層級報表和摘要報表。事件層級報表包含廣告技術提供的事件 ID 可用於資料無塵室,但與轉換端相關的資訊有限,且具雜訊度。已加密的可匯總報表無法直接在資料無塵室中使用,但匯總服務提供的摘要結果可做為分析的輸入內容,或是做為補充資訊的輸入內容。 |
匯總服務
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
(另於 2022 年第 4 季一併顯示)。 報表延遲 |
報表預計會延遲多久? | 2023 年第 1 季更新: 根據合作夥伴的意見回饋,我們分享了減少延遲 和減少延遲影響的提案。 廣告技術在 WICG 呼叫期間支援這兩個提案。 |
沒有重複的規則 | 如果有共用 ID 相同的可匯總報表,要如何處理「延遲可匯總報表」? | 我們提出了一項提案,說明如何在可匯總報表的共用資訊中加入額外的報表延遲,以及匯總服務的共用 ID 定義,藉此部分解決匯總 API 延遲損失的影響。歡迎對提案提出任何意見 |
資料處理 | 要求啟用多資料票證支援功能,同時兼顧差異化隱私 | 我們正在探討如何更靈活地使用隱私預算來實現此用途,也歡迎提供其他意見回饋。 |
(同樣於 2022 年第 2 季一併報告) 查詢人體工學 | 啟用索引鍵匯總功能。 | 2023 年第 1 季最新消息: 我們仍會將這項功能要求列入考量,但目前沒有任何提案可以分享。 |
來源試用限制 | 說明匯總服務的範圍,例如目前未在來源試用中套用的「沒有重複規則」。 | 我們正在更新說明文件,以釐清在來源試用與 Google Analytics (分析) 中有哪些功能。 |
Private Aggregation API
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
私人匯總貢獻預算 | L1 捐款預算限制過多。 | 每次呼叫 Private Aggregation API 都稱為貢獻。為保護使用者隱私,系統可向個別使用者收集貢獻內容數量有限。 當您將所有匯總鍵的所有可匯總值加總時,總和必須小於貢獻預算。 在目前的設計下,我們會限制特定報表來源在過去 24 小時內 (採滾動式期間) 的貢獻量。這是意見回饋中提及的 L1 貢獻預算。 我們建議開發人員根據預期數量調整他們貢獻的值 (即不要只使用 1 的值)。因此,為較常見的事件設定較小的值可能有助於避免用完預算。 我們目前希望針對 Private Aggregation API 對數字範圍和範圍的貢獻預算提出一些意見回饋。我們正在考慮將範圍從每個來源移至個別網站,並將現有的繫結移至每日上限較高的 10 分鐘時段。 |
限制轉換追蹤
使用者代理程式縮減/使用者代理程式用戶端提示
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
UA-R 採用 | 在英國前 10,000 名網站中,只有 1% 使用程式輔助廣告的網站傳送 HTTP 用戶端提示。尚未遷移的需求端平台可能會影響反詐欺功能。 | 針對相同資料集執行分析後,我們發現如果您透過 HTML <meta> 標記和 JavaScript API 計算 UA-CH 用量,則使用 UA-CH 的網站數量遠高於意見回饋中提供的 1% 數值。根據上述結果及其他資料 (包括生態系統意見回饋),我們很有信心地進一步推動通用 Analytics (分析) 縮減的第 6 階段,以發布的時程為依據,同時讓 CMA 隨時掌握相關資訊。我們注意到網站有將近兩年的前置時間準備進行移轉,但也有網站還沒做好淘汰試用的準備,可能還是會提供淘汰試用。 |
其他板型規格的提示 | 要求 UA-CH 提供電視、VR 等額外的板型規格 | 我們歡迎這個提案,也有意將提案與設計整合。歡迎提出其他意見回饋。 |
自動化測試 | 要求在 UAR 第 6 階段出貨前,透過無頭 Chrome 解決 UA-CH 錯誤 | 相關錯誤已修正。 |
iOS 上的 UA-CH 支援 | 如果網站需要精細的通用 Analytics (分析) 資訊用於廣告用途,請注意,不支援 iOS 版 Chrome。 | 針對非 Safari iOS 瀏覽器 (包括 iOS 上的 Chrome),WebKit 專案必須新增 UA-CH 的支援,才能啟用 UA-CH (因為他們會控制網路堆疊)。 |
IP 保護 (原稱 Gnatcatcher)
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
(同樣在第 4 季一併報告) 地理位置用途 | IP 保護可能會防止合法的地理位置用途日後順利運作,例如根據地理位置進行內容個人化。 | 我們的回應自 2022 年第 4 季起維持不變: 「我們正在與相關人員合作,確保 Chrome 能持續支援 IP 位址的正當使用情境。我們希望針對 IP 地理位置的精細程度,提供生態系統意見回饋。」 |
監管法規遵循 | 如果某個地區的人口少於 100 萬,目前 IP 防護的門檻為 100 萬,因此網站無法使用 IP 位址來規範法規遵循。 | 我們正在與利害關係人合作,確保 Chrome 持續支援 IP 位址的正當使用案例。因此,我們目前正請針對 IP 保護的法規遵循情形,向相關生態系統徵求意見回饋。 |
緩解濫用行為 | 雙方可以分享未遮蓋的 IP 位址,藉此規避 IP 保護。 | 我們留意到目前的 IP 保護提案在技術上可能並未防止各方與他人分享未遮蓋的 IP 位址。我們正在設法降低這項濫用風險。 在我們持續改進提案的過程中,我們鼓勵您提出更多意見並進一步討論。具體而言,我們希望瞭解各方認為需要與其他方分享未遮蓋的 IP 位址。 |
聯播網封鎖 | 雙方可以使用 IP 防護 Proxy 規避網路封鎖。 | 執行封鎖作業的實體必須為此情境停用「IP 保護」。我們已回應相關問題,也歡迎提供其他意見回饋。 |
受 IP 保護提案影響的 IP 位址封鎖清單 | 許多廣告技術公司會使用基本的 IP 位址封鎖清單 (例如 TAG 資料中心 IP 清單),防止對極可能涉及詐欺 (或至少無法營利) 的廣告空間出價。如果廣告技術也是追蹤工具,且可能受到 IP 保護的提案影響,該公司可能無法在購買廣告空間前,對廣告執行基本檢查。 | 我們鼓勵您針對潛在問題和解決方案提供進一步意見,並討論 IP 防護提案。其中一種做法是將類似的清單套用至 IP 保護,這樣我們就不會使用先前標記 IP 位址的用戶端代理用戶端。 |
強化跨網站隱私界線
第一方集合
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
(第 4 季一併回報) 網域限制 | 要求增加相關網域數量 | 我們的回應和 2022 年第 4 季沒有任何異動: 「在 WICG 呼叫中,我們清楚說明瞭 Chrome 致力提供可行的解決方案,並將使用者的隱私權利益納入考量。透過這個做法,我們歡迎社群提供意見,說明可能會受到網域限制影響的特定用途,讓團隊可以考慮解決這些用途,同時繼續保護使用者隱私。」 |
提交替代每秒影格數 | 提議採取替代方式,提交每秒影格數適用的全球清單 | 我們目前正準備在 Chrome 中運送第一方集合 (FPS),並已設定集中式 GitHub 存放區來接受集合提交內容。我們希望 FPS 能彌補現有網路平台解決方案的不足,進而為第三方 Cookie 淘汰做準備,所以我們期待能向網站作者說明 FPS 的使用方式。隨著組合清單不斷增加,且生態系統也因應第三方 Cookie 的後續發展,我們也可以改進相關流程,進而考慮採取其他去中心化配置,例如提出的建議。在目前的流程中,我們期望能確立生命週期,以便逐步改善攝入程序。待提交程序通過後,我們就能重新審視這個想法。 |
存放區管理 | 針對 FPS 提交存放區的社群審核措施,避免濫用。不肖人士可能會輕鬆處理使用工作倦怠的源頭來提出組合,而大量要求可能會影響原始組合提案的作業。 | 我們正透過技術驗證檢查來盡可能執行檢查。我們認為這是提交程序最可擴充的方法。為了實現這個目標,我們也會致力確保這項程序不受垃圾內容 / 燒錄物影響。 |
相關聯的子集 | FPS 是否能透過相關聯的子集,支援第三方廠商/軟體式服務 (SaaS) 流程用途? | 第三方廠商 / 軟體式服務 (SaaS) 流程並非適用第一方集合的使用案例。我們也歡迎您提供其他意見回饋,協助我們瞭解跨網站 Cookie 如何因應這些用途。 |
FPS + CHIPS 整合 | 要求進行 FPS + CHIPS 整合作業,以支援 A/B 測試等用途 | 我們正在討論這個使用案例,同時也考慮在 WICG 呼叫中進一步討論這個部分,也歡迎在這裡提供其他輸入內容。 |
GDPR | 提議將 GDPR 概念用於新的 FPS 子集提案 | 我們內部討論了這項提案,並根據收到的其他意見回饋和隱私權目標來評估提案。我們提供了答案,解釋為何我們目前無法推薦這個提案。 |
記憶體容量 | 加入 FPS 清單時,瀏覽器記憶體大小的預期變化 | 一直以來,瀏覽器為了儲存這類清單而盡可能減少記憶體影響,例如「中斷連線追蹤保護清單」。雖然第一方集合清單會複製到每個 Chrome 用戶端,但我們會持續監控檔案大小,確保我們能最佳化記憶體用量。 |
Fenced Frames API
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
圍欄頁框限制 | 圍欄框架設定的限制清楚呈現 | 我們在 3 月時更新了圍欄框架說明,提供有關其功能的資訊。我們也歡迎提供任何其他意見回饋。 |
展開存取權資訊 | 要求擴大鄰近影格相關資訊的存取權 | 我們想進一步瞭解這項生態系統規定的原因,也歡迎提供其他意見回饋。 |
圍欄頁框和 iframe | 關於 Fenced Frame 與 iframe 的功能對等性的相關問題 | 所有可用的 Privacy Sandbox API 和報表都將能以相同方式適用於 iframe 和 FencedFrames。 |
調整圍欄頁框大小 | 限制影格大小變更會影響特定用途。 | 我們希望進一步瞭解這類限制影響的用途類型,也歡迎您提供其他意見回饋。 |
Shared Storage API
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
第三方 Worklet | 第三方可以依來源區分共用儲存空間嗎?或是要呼叫其他 Worklet 進行第三方評估? | 執行程式碼的瀏覽環境來源會決定資料寫入所屬共用儲存空間。在網頁中加入第三方程式碼後,該第三方程式碼會以本身的瀏覽情境的形式嵌入 iframe 中,讓第三方程式碼得以寫入本身的來源。第三方程式碼也可以嵌入為指令碼而非 iframe,因為 iframe 不會切換瀏覽情境,且第三方可以寫入嵌入器的共用儲存空間。請注意,只有該共用儲存空間的擁有者才能從該共用儲存空間讀取資料。 |
簡化 | 不過,您無法為 Chrome 生態系統以外的互動刪除重複資料。 | 共用儲存空間旨在在 Chrome 中提供以 Chrome 為基礎的不重複觸及輸出內容。我們希望與廣告技術合作,瞭解如何將這些輸出內容做為整體觸及模型的一部分。我們瞭解輸出內容本身可能只佔一部分互動,且有意與廣告技術合作,探索可疊加的其他模擬方法。 |
轉換回溯期 | 申請設定轉換率的回溯期,以便瞭解轉換次數的長期變化 | 您可以利用共用儲存空間處理用戶端上的各種轉換路徑,藉此實作這個模式,這樣一來,就不用透過安全的非分區瀏覽器儲存空間進行進階分析,還能享有更多彈性。 |
商品過期期間 | 要求將到期日延長至 90 天 | 資料保留政策於 2022 年 11 月更新,指出每個金鑰會在上次寫入的三十天後清除。我們歡迎您提供其他意見回饋,瞭解新政策是否適用於大環境。 |
廣告素材輪播 | 廣告素材輪播用途不會反映競價後的實際動作。 | 我們想瞭解其他買方廣告技術公司,瞭解廣告素材輪播說明文件是否正確。 |
方塊
本季沒有任何意見回饋。
FedCM
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
身分宣告端點 | 明確允許對身分宣告端點發出任意要求。 | 我們正針對這項提取要求與 Mozilla 合作,藉此限制網站在不造成使用者乾擾的情況下,以靜音方式提出跨來源憑證要求。此外,我們也會繼續審查並處理其他意見回饋。 |
預先填入身分 | FedCM 是否可以使用 FedCM 清單中的識別資訊提供者預先填入登入表單? | 這個使用案例的疑慮是,當使用者無法查詢使用者所用的網站時,可能會導致資訊外洩。我們正在進一步討論這個問題,也歡迎提供更多意見回饋。 |
選取內容比對帳戶 | 在帳戶選取使用者介面中加入比對內容信號的提案 | 我們正在考慮這項提案,並歡迎您進行其他討論。 |
打擊垃圾內容和詐欺
Private State Token API (和其他 API)
意見回饋主題 | 摘要 | Chrome 回應 |
---|---|---|
能力收集問卷調查 | 我們在第 1 季上半年完成了問卷調查結果,收集到各種反詐欺用途所需的功能並公開分享 (分鐘、 結果) | 我們計劃在開發新提案和原型時,以針對專門的隱私保護 API 進行反詐欺功能開發新提案和原型。我們希望在有充足需求的開發上優先開發,同時提供現有技術,用於將這項功能導入網路功能,同時保障使用者隱私。舉例來說,裝置和啟動完整性受到較高的排名,許多平台的現有 API 可透過安全的方式共用裝置完整性的評估機制,因此非常適合在社群群組中追逐探索。 |
PST 計畫傳送意見回饋的意願 | 為進行出貨,我們收到了一項問題,原因為使用舊版 Privacy Pass。我們也收到了某些部分的意見回饋,指出其中某些章節的規格不明確,因此需要改善,以便提高瀏覽器相容性。 | 我們計劃在提供產品至 Google Analytics (分析) 前,先實作其中許多建議的規格變更,以及一些 API 變更。我們在第 1 季末收到的意見回饋,因此會透過 GitHub 問題追蹤具體細節,以及推出計畫的更新內容 (發布後,這份意見回饋報告發布後)。 對於 API 的較大變更,我們十分樂意考量這些異動,但我們認為最好的方式是繼續執行正式發布,並取得更多開發人員的實際意見。我們希望繼續討論並推動瀏覽器標準化。如果日後出現新標準,我們會考慮採用並制定計畫,謹慎地轉換標準。 |