意見回饋報告 - 2023 年第 2 季

2023 年第 2 季季度報告，匯總了從生態系統中收到 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、Protected Audience 和 Attribution Reporting API。

目前報表統計期結束後收到的意見回饋可能尚未 視為 Chrome 的回應

縮寫詞詞彙表

CHIPS
具有獨立分區狀態的 Cookie
DSP
需求端平台
FedCM
聯合憑證管理
FPS
第一方集合
IAB
互動廣告局
IDP
識別資訊提供者
網際網路工程任務組 (IETF)
網際網路工程任務組
IP
網際網路通訊協定位址
openRTB
即時出價
延長賽
來源試用
PatCG
私人廣告技術社群群組
受限方
信賴方
SSP
供應端平台
TEE
受信任的執行環境
UA
使用者代理程式字串
UA-CH
使用者代理程式用戶端提示
W3C
全球資訊網協會
WIPB
惡意 IP 盲人

一般意見回饋，無特定 API/技術

意見回饋主題 摘要 Chrome 回應
資料管理與遵守法律規範 透過符合法規要求使用 Privacy Sandbox 的生態系統指南。 和任何新技術一樣，每間公司必須負責確保 Privacy Sandbox 使用行為符合法律規範。Google 無法向其他使用者提供法律建議。但我們也知道，這是廣告生態圈的重要領域。我們針對各個 API 發布了詳盡的技術文件，應提供進行必要法律評估的基礎資訊，我們也正在努力提供其他資料，協助公司為遵守法規要求而採行的措施
CMA 量化測試提案 進一步瞭解 CMA 量化測試提案 我們正在與 CMA 合作設計實驗，藉此瞭解第三方 Cookie 淘汰後的影響，以及在生態系統中推出 Privacy Sandbox 提案。CMA 於 4 月發布概略指南，說明測試與試用期間可能發生的狀況，並在 6 月發布詳細指南。我們鼓勵您針對 CMA 的量化測試提案提出問題或提供意見，直接與 CMA 分享。
由 Chrome 輔助的測試模式 測試時間表的詳細資訊和說明 我們在 5 月 18 日發布了一篇網誌文章，進一步說明瞭 Chrome 協助採用的兩種測試模式。這些細節並非最終版本，我們會在 2023 年第 3 季推出更多導入指南。
分區儲存空間 在 Chrome 協助執行的測試期間，是否會使用分區儲存空間？ 第三方 Cookie 淘汰實驗開始前，我們會先將儲存空間分區推出給所有使用者。因此，實驗中的所有組別都會啟用這項功能。在這段期間內，網站將可選擇啟用淘汰試用計畫，取回未分區的儲存空間。
生產支援 Chrome 目前採取哪些流程來支援 Privacy Sandbox 的技術問題，或是提報會影響生態系統的提報程序？ Google 提供多種管道，方便廣告技術回報問題及提出所有必要提報。
請參閱開發人員貼文，進一步瞭解如何在公開和私人論壇中取得意見回饋，並向上呈報相關資訊。
註冊時間表 目前的註冊期限太短 我們仍在評估違規處置的期限，希望業界和 YouTube 團隊分享更適合的時程。
鄧白氏環球編碼 進一步瞭解註冊和認證的鄧白氏環球編碼規定 參與者可以前往鄧白氏集團網站，瞭解取得鄧白氏環球編碼的相關規定。相關規定會因市場而異，因此請務必造訪自家網站，瞭解他們感興趣的特定市場。不過，一般而言，參與者必須提供商家基本資訊，例如商家名稱、地址，以及業主或管理員的聯絡資訊。也可能會要求參與者提供財務資訊，例如企業的年收益。申請完成後，D&B 會進行審查，並在申請獲準後核發鄧白氏環球編碼。
從來源試用轉換至正式發布版 如果從來源試用轉換至正式發布版，會影響目前的來源試用測試人員嗎？ 自 7 月起，測試人員將能正式發布關聯性和評估 API。這表示來源試用服務與正式發布階段會彼此重疊。
AdExchanger 研究 進一步瞭解問卷調查方法 並請作答者評估自家商家的同步處理率和收益。受訪者而各個問題解答的方法可由他們自行決定。
參數值 雜訊等級、匿名門檻和隱私預算等參數值如何決定？ 這個 GitHub 說明說明瞭 Privacy Sandbox API 背後的通用原則。許多價值觀仍未定案，歡迎針對這個主題提供寶貴意見。

顯示相關內容和廣告

主題

意見回饋主題 摘要 Chrome 回應
保護隱私權 評估 Topics API 保護隱私權的研究 我們積極參與研究社群，透過論文、報告和研討會簡報，就 Topics API 的隱私權特性進行研究。我們很高興能看到研究社群中更多外部成員與這個領域互動。

Topics API 會降低使用者難以大規模追蹤的網路活動，保護使用者不受網路的一般追蹤行為。這些論文顯示我們已成功使用 Topics API 完成這項操作。比第三方 Cookie 更私密性，能夠保護使用者並繼續支持喜愛的網站。
主題分類不夠精細 廣泛的主題分類不會包含更精細的主題，包括特定區域。 為因應這個大環境先前提供的意見回饋，我們在 6 月 15 日發布了一篇網誌文章，詳細介紹了新版分類的新分類，其中包括參考了生態系統的意見回饋。在調整新版分類方式的過程中，我們與整個生態系統中的多家公司合作，包括 Raptive (前身為 CafeMedia) 和 Criteo。新版分類方式會移除我們聽過不實用的類別，並優先採用更能符合廣告客戶興趣的類別，同時 Google 承諾排除可能具敏感性的主題。

我們鼓勵生態系統查看最新分類，並針對這些異動提供意見回饋。
分類和分類器更新程序 進一步瞭解 Topics 分類和分類器的發布頻率，以及公司如何為這類更新做好準備。 如同近期的網誌文章所述，分類方式應該會隨著時間的推移而調整，而分類管理最終目標則是轉變成代表業界利害關係人的外部第三方。我們也在 topics-announce 群組中分享了增加曝光量計畫。
對第一方信號的影響 在近期分類更新中，Topics 數量的增加可能極其重要，導致其他第一方興趣導向信號失效。 在 2023 年第 1 季的報告中，CMA 表示：「我們瞭解 Google 與廣告技術供應鏈的多個市場參與者討論了他們提出的新分類，少數大型發布商已表示，如果選擇較廣泛的主題，會使第一方資料解決方案的競爭更加激烈，但我們初步瞭解到整體競爭較有幫助，尤其是小型發布商在第三方 Cookie 淘汰後，仍能持續透過廣告空間營利。」我們的觀點與 CMA 所做的言論一致。
對不同類型利害關係人而言相當實用 與其他生態系統業者相較，做為賣方平台和需求端平台的廣告技術可能會有明顯的優勢。 我們上次的回覆與前幾季的回覆相同：

「Google 承諾在設計及實施 Privacy Sandbox 提案時，不會因為自主傾向 Google 自家業務而扭曲競爭，同時也會將對數位廣告、各種發布商和廣告主的競爭影響納入考量。我們會持續與 CMA 密切合作，確保我們的工作符合這些承諾。隨著 Privacy Sandbox 的進展，我們會評估幾個關鍵問題，那就是新技術對不同類型的利害關係人來說成效如何。改善技術設計時，意見回饋十分重要，特別是具體可行的意見回饋，協助我們進一步改善技術設計。我們與 CMA 合作開發量性測試方法，也支持 CMA 發表實驗設計附註，向市場參與者提供更多資訊，並開放對方分享實驗提案。」
子系主題 如果主題選擇條件是瀏覽器造訪的頻率，區隔零碎問題是否會導致其他主題一直無法歸類到頂端？ Chrome 正在評估其他排序方法，正在探索其他可改善排名的信號。我們會在適當情況下向 YouTube 生態系統傳達修訂版計畫。
機密等級 Topics API 的目標應是確保從 Topics API 取得或衍生的使用者資訊，與現今追蹤方法取得的使用者資訊較不敏感。 我們認為 Topics API 的隱私程度遠高於現有技術，因此可大幅限制使用者重新識別使用者身分，而且旨在排除敏感主題。我們深知，主題可連結或結合第一方資料，即可建立敏感類別，但我們認為 Topics API 會朝目標邁進，持續改善 API。
分類結構 在主題分類中加入 ID、版本管理和其他中繼資料結構 目前，我們在 API 回應中包含分類 ID。隨著我們走向長期管理，查看 Topics 物件，並視需要加入其他與版本管理相關的中繼資料。
發布商控制選項 發布商應能決定自家網站應歸類為哪些 Topics。 網站分類錯誤可能會降低 Topics 信號在整體信號上的實用性，但被歸類錯誤的網站就不再受到這個問題的影響，攻擊也不會因此降低。這是因為系統在他們的網站上持續提供內容比對資訊，即使發生分類錯誤的情況，也能提供與正確的主題相當的資訊。歡迎按這裡針對這個主題提供意見。

允許發布商控管分類可能會有風險。網站可能會刻意將網站誤分類、降低所有網站實用性，或是為較不常見的主題將敏感含義編碼，進而損害使用者隱私。
Chrome 擴充功能 允許 Chrome 擴充功能管理及篩選 Topics，類似於目前的 Cookie 管理擴充功能 如同 GitHub 上所述，應該已可採用。不過，我們也歡迎生態系統提供其他意見回饋。
轉換為正式發布版 如果從來源試用轉換為正式發布階段，Topics API 是否會受到影響？ 使用者從「來源試用」轉換至正式發布版的使用者不會遺失資料。
隱私權 主機名稱可能包含可能由 Topics API 公開的私人資訊 我們採取了多項因應措施來保護隱私，詳情請參閱這篇文章。
詐欺與濫用行為 如何防範詐欺性的造訪活動操弄 Topics 如要瞭解因應措施，請參閱這篇文章。
主題分類器 網站可以要求變更主題分類嗎？ 業界樂於聆聽這個主題的相關意見，也歡迎在這裡提供意見。
Topics 供應商網站 將含有許多主題內容的特定網站指定為「特殊主題供應商網站」並根據網頁提供的代碼訓練分類器 我們即將在這裡討論提案。歡迎你提供其他意見回饋。

Protected Audience API (舊稱 FLEDGE)

意見回饋主題 摘要 Chrome 回應
流量型態 賣方平台驅動篩選功能，以將每秒查詢次數 (QPS) 負載最佳化 我們花了大量時間思考流量型態，建議賣方平台善用快取功能。
測試音量 由於賣方平台和需求端平台難以獲得大量流量，因此很難測試 Protected Audience。 我們會持續與賣方平台和需求端平台合作夥伴合作，採用及測試 Protected Audience。目前已正式發布，我們確信已啟用私下競價的流量百分比將使合作夥伴更容易進行測試。
複雜度 導入 Protected Audience 解決方案需要投入大量心力和成本。 我們瞭解難以採用新技術，包括 Privacy Sandbox。Privacy Sandbox 團隊與許多相關人員密切合作，提供教育訓練和支援，並持續評估其他加速計畫，以支援採用生態系統。
受信任的執行環境 支援非公有雲環境中受信任的執行環境 (TEE) 雖然我們正在探索雲端解決方案以外的可能支援選項，但基於地端部署安全性限制，且需要對 Privacy Sandbox 進行耗時評估的地端部署 TEE，目前無法支援內部 TEE。有鑑於 Privacy Sandbox 安全性要求和地端部署部署作業面臨的重大挑戰，我們相信持續擴展及改善雲端型部署作業 (例如除了 AWS 外支援 GCP)，對整個生態系統帶來最大助益。不過，我們歡迎提供其他意見，協助我們瞭解為何有這類需求。
成本結構 出價和與用戶端模型相比，競價服務提案將增加廣告技術的費用和複雜度， 我們正在擬定指南，以估算支援「出價與競價」中支援出價和競價工作流程的費用競價伺服器，與廣告技術用途相關，可達成我們設計的其中一項目標。
K-Anon 時間軸 預定的 k-anonymity 限制何時會在「renderUrl」強制執行？ 我們正在準備公布政策的具體時間表，並預計在不久後發布。
runAdAuction 限制 Chrome 能否限制使用者只能從頂端呼叫 runAdAuction？ 雖然我們的設計完全支援 runAdAuction 從頂端呼叫，但我們認為將內容限制為只能從頂層網域呼叫，對發布商會更有害。

我們經由廣告生態系統收到明確表示，Privacy Sandbox 必須盡可能減輕發布商和廣告主的負擔。這些意見符合網頁開發的一般原則，網站擁有者可以使用第三方工具經營網站。Privacy Sandbox 的目標是鼓勵健全的生態系統，而非陳述發布商和廣告技術的運作方式。

我們認為，允許發布商選擇在網站上呼叫 runAdAuction 的方式和對象，為發布商提供更彈性的服務，方便他們找出符合需求的最佳路徑。
導入支援服務 Chrome 是否可以建置或參與多重賣方競價的開放原始碼實作？ Privacy Sandbox 的目標是開發不需要第三方 Cookie 或其他跨網站 ID 的隱私權保護技術。我們希望在不限制廣告技術工作需求的情況下，促進健全的生態系統。

我們已發布關於 API 在 GitHub 存放區中運作的指南，並樂於與業界一起探索解決方案。

我們不打算打造任何具體的實作項目，因為我們的核心責任是打造平台技術，而非決定使用這些技術的策略。我們的技術將協助廣告技術公司為客戶提供適當的隱私權保護措施。
多重賣方競價 Chrome 會強制分享「內容相關」如何贏得競價？ Protected Audience API 旨在幫助各方啟動多重賣方競價，將資訊傳遞給元件競價 (注意：只有在發起競價前)。

也就是說，我們沒有任何方法讓瀏覽器分辨特定資訊是否為內容相關勝出者，因此我們無法強制封鎖或要求某些資訊。
同意聲明追蹤的使用者偏好設定 廣告技術詢問「家庭」應如何正確導入使用者同意聲明追蹤功能 我們的回覆內容包括我們在第 1 季回答的內容：
「就特定廣告而言，相關廣告技術是最適當的工具，能控制要顯示哪些廣告素材或選擇廣告素材的方式。」

我們在 5 月 WICG Protected Audience 會議期間討論了多種與這個問題相關的情境，歡迎針對這個問題提供其他意見回饋和討論。
自訂目標對象 Protected Audience API 是否支援建立自訂目標對象的相關用途？ Protected Audience API 可讓賣方平台和其他廣告技術供應商擁有及管理自訂目標對象的擁有權。賣方平台如何與 PA API 進行整合，提供進一步指引，賣方平台和其他廣告技術供應商會提供進一步指引，協助對方進行整合。
格式 Protected Audience API 是否支援影片？ 影片廣告有兩種方式可放送：VAST XML 或 HTML (最終可將 VAST XML 載入影片播放器的串流外廣告)。買方可以透過轉譯網址傳回這兩種格式。VAST 規格最近已更新，現在可支援 Attribution Reporting API。放送影片廣告的網站必須對透過 Protected Audience API 放送廣告的方式做好準備。這表示確保刊登位置代碼可以將網址從 Protected Audience iframe 傳送至影片播放器。針對 Fenced Frames，我們會在使用 Fenced Frames (2026 年之前之前) 先滿足影片需求。
使用速度 使用速度用途如何與 Protected Audience API 搭配運作？ 感謝你提供寶貴的意見回饋。我們希望看到更多這項要求的情況，並提供更多來自更多賣方平台合作夥伴的詳細資料，因為這大多是需求端平台 (DSP) 有疑慮。
更新頻率 來自 dailyUpdate 的來電頻率 (每個興趣群組每天最多 1 次) 可能不足以用於特定用途 (例如更新產品資訊)。 感謝你提供寶貴的意見回饋。還有其他解決方案可讓廣告技術使用以不同頻率 (例如 K/V 查詢) 重新整理的信號。
廣告品質控管 發布商如何導入廣告品質控管功能？ 目前 Protected Audience API 的功能可讓發布商在出價前建立特定控制項，讓賣方平台瞭解可在出價前建立的特定控制項 (也就是根據與廣告相關聯的標籤建立拒絕清單)。我們歡迎發布商提供意見，分享這個生態系統所需的其他功能。
偵錯 forDebuggingOnly 功能何時會移除？ 我們預計淘汰由第三方 Cookie 淘汰的損失事件，forDebuggingOnly。我們預計在 2026 年最早淘汰獲勝活動的 forDebuggingOnly，
跨裝置興趣群組 為已驗證使用者代理程式啟用跨裝置興趣群組的提案 我們正在評估這個提案，但根據這個 GitHub 問題討論的，跨裝置指定功能明確會對隱私權造成重大疑慮。
(也記錄在第 1 季推出) 動態再行銷 在第三方 Cookie 淘汰後，還能使用 Protected Audience API 進行動態再行銷嗎？ 我們認為可以使用 Protected Audience 達成此用途，相關做法請參閱這裡的說明。
點擊相關資料 在「browserSignals.」中加入點擊相關資料 我們目前希望針對點擊發生的時間提供初步位置的說明。
(也已於 2022 年第 4 季報告) Protected Audience 中的使用者定義函式 Protected Audience API 如何支援使用者定義的函式 (UDF)？這些函式可由使用者編寫，擴充 API 的功能。 提出這個問題的廣告技術公司仍在評估他們能運用 UDF 的功能，因此在至少正式發布前，目前尚無法針對具體情況做出回應。
幣別 貨幣金額不得使用浮點值表示。 我們已在這裡詳細說明這個問題。
非需求端平台廣告選擇功能 在 Protect Audience API 競價中，廣告伺服器扮演什麼角色？ 我們瞭解廣告伺服器要求繼續提供出價後廣告選擇 / 動態廣告素材最佳化服務。我們正在評估目前 Protected Audience API 與這些要求的詳細差距分析。
GenerateBid 支援 Google Ads透過提案，從 generateBid 為每個廣告興趣群組傳回多個候選廣告，並將這些候選廣告記為「scoreAd」。 目前正在評估中。歡迎按這裡提供更多意見。
競價訂單 Protected Audience API 競價必須是最後一項執行，以便從所有其他競價的結果取得輸入內容嗎？ 即使未符合技術需求，Protected Audience API 也可持續執行。
非使用者啟動的瀏覽 公開非使用者啟動的瀏覽動作 我們正在審查這項要求，並在這裡討論 。歡迎您提供其他意見回饋。
快取 如果使用者狀態改變，賣方平台不應從快取建構特定 DSP 的 perBuyerSignals。 我們明白，快取功能不適用於所有個別買方信號，因此正在評估其他選項。歡迎生態系統提供其他意見回饋，協助我們瞭解快取功能是否適用於這些用途。
Attribution Reporting 和 Protected Audience Attribution Reporting API 和 Protected Audience API 如何搭配運作？ Attribution Reporting API 模式 (事件層級和摘要報表) 目前都支援 Protected Audience API 整合功能。我們已在 6 月 1 日分享更多有關 Protected Audience API 和 Attribution Reporting 整合的詳細資訊。您可以參閱這個網頁。
伺服器端點 在最後設計中，伺服器端點會成為信任的匯總伺服器嗎？ 伺服器端點是由廣告技術維護的端點，與用於處理收集和轉換報表的受信任匯總伺服器無關。我們目前沒有針對報表端點規劃任何變更。目前的設計旨在確保可匯總報表本身 (包含加密酬載) 不會洩漏跨網站資料，因此不應使用受信任的端點。另一個複雜問題是，不同廣告技術可能會有不同的想要的批次處理策略。歡迎按這裡提供更多意見。
WebIDL 目前的 Protected Audience API 規格與 WebIDL 規格不相容。 我們正在評估這項意見回饋並在此討論問題。
同意聲明管理 如何在 Protected Audience API 中傳送同意聲明信號？ 內容比對資訊不在 Protected Audience API 的範圍內。我們會在討論這個問題時提供其他意見回饋。
以帳戶為基礎的行銷 可以考慮使用帳戶進行行銷嗎？ Protected Audience API 支援多種以目標對象為依據的行銷用途。我們會繼續瞭解 Protected Audience API 如何最有效支援這個特定用途，也歡迎生態系統針對這個問題提供其他意見回饋。
元件競價 元件競價參與者的分數為何？ 元件競價不會直接為興趣群組評分，而是對需求端平台透過 generateBid 函式提交的廣告和出價進行評分。系統會為每個興趣群組執行 generateBid() 函式，而 DSP 在執行 generateBid 時會傳回下列內容：

return {
  'ad': adObject,
  'adCost': optionalAdCost,
  'bid': bidValue,
  'render': renderUrl,
  'adComponents':
    [adComponent1, adComponent2, ...],
  'allowComponentAuction': false,
  'modelingSignals': 123};
}

外部貢獻 要求支援鍵/值伺服器 GitHub 程式碼集的外部貢獻。 我們正努力更新相關程序，支援對 GitHub 程式碼的外部貢獻。
興趣群組規模 IG 支援的金鑰數量上限是多少？ 目前一個 IG 大小的上限是 50 KB，金鑰也會計入其中之一。歡迎進一步討論大小上限。
批次處理 如何減少 K/V 伺服器呼叫次數？ 您可以使用 HTTP Cache-Control 標頭來減少 K/V 呼叫次數。舉例來說，系統可能會在各元件競價和單一網頁上的不同廣告版位中快取此圖片。
版本管控 支援多個版本的廣告技術程式碼 出價和競價服務支援多個版本的廣告技術程式碼。在 Bidding and Auction API 中，SelectAd 要求可指定用於競價要求的程式碼版本 (例如用於出價 / 競價和製作報表)。
共用儲存空間 支援在出價和競價服務中寫入共用儲存空間。 「出價和競價服務」目前不支援「共用儲存空間」，但如果您想瞭解這個生態系統為何需要這類用途，歡迎提供其他意見。
網頁對應用程式 支援透過網頁到應用程式分享興趣群組。 目前在 Chrome 和 Android 上，Protected Audience API 部署作業的範圍尚未涵蓋「網頁至應用程式」，但我們想瞭解這個生態系統的重要性。
K-匿名性 如何處理 K-匿名性備用項目 我們會在討論問題時提供其他意見回饋。

評估數位廣告

Attribution Reporting (和其他 API)

意見回饋主題 摘要 Chrome 回應
其他瀏覽後轉換事件層級報表設定 對替代瀏覽後轉換事件層級報表設定提供意見 我們接獲一些意見回饋，指出目前的事件層級設定不夠理想，因此希望您提供意見，協助我們改善全域設定。我們很樂意收到更多相關意見回饋，並認為彈性事件層級說明也能協助你解決這個問題。
彈性事件層級設定 彈性事件層級設定功能的狀態為何？ 歡迎參考我們分享的彈性事件層級設定說明文件。這項功能仍在提案階段，我們希望取得更多意見回饋，瞭解這項功能是否對生態系統有實用價值。
彈性事件層級設定 如何核對不同方的報表？ 使用匯總報表可解決大部分的報表情境，而彈性事件層級設定提案特別適合用於事件層級報表，而這類報表通常用於最佳化用途。對於這個情境，歡迎透過生態系統提供其他意見/意見。
來源登錄 如果來源登錄作業在觸發事件登錄後發生，會發生什麼事？ 目前，如果在觸發事件登錄後登錄來源，來源和觸發事件將無法相互歸因。這似乎是極端情況。歡迎您針對此問題提供其他任何意見，如果多數廣告技術都遇到這種情況，我們會加以解決。
與多個廣告代理商合作 如果廣告客戶與多個廣告代理商合作，需求端平台如何使用 Attribution Reporting API？ 由於這個 API 支援重新導向，因此就算廣告客戶與多個廣告代理商合作也一樣。此外，為了確保 API 的隱私權防護機制，重新導向功能會有一些限制。我們也發現，在廣告技術人員提出的特定情境下，使用 Shared Storage API 還有一個可行的解決方法。歡迎您針對這個情況提供其他任何意見，並根據這些意見回饋繼續疊代。
目的地限制 自動重新整理廣告用途可能會因到達網頁限製而受到影響。 我們在 5 月 1 日 WICG 會議上討論了這項問題，希望您能提供合理限制的相關意見。我們在「含有事件層級報表的歸因報表說明」中新增了說明，指出瀏覽器可限制來源網站代表的「目的地」eTLD+1 數量。(請參閱提取要求)。
Attribution Reporting 和 Protected Audience Attribution Reporting API 和 Protected Audience API 如何搭配運作？ Attribution Reporting API 模式 (事件層級和摘要報表) 目前都支援 Protected Audience API 整合功能。我們已在 6 月 1 日分享更多有關 Protected Audience API 和 Attribution Reporting 整合的詳細資訊。您可以參閱這個網頁。
彈性事件層級設定 分享雜訊模擬的最佳做法，現在參數可供設定。 我們在 GitHub 上分享程式碼，任何想測試的彈性事件層級設定都能用來評估資訊獲益和雜訊影響。我們歡迎任何試用程式碼測試者的心得分享。
跨應用程式和網站歸因評估 何時可以進行跨應用程式和網站歸因評估？ 我們在 5 月 9 日宣布，一項透過 Attribution Reporting API 進行跨應用程式和網站歸因評估的實驗。雖然 Chrome 115 中的關聯性和評估 API 已預計正式發布，但跨應用程式和網站歸因評估功能目前不打算在 Chrome 115 正式發布。
刪除重複的轉換 如何與 ARA 協調獨立成效評估解決方案？ 如同現行的標準做法，廣告客戶必須與第三方獨立評估服務供應商合作，以刪除重複的轉換報表。對於事件層級報表，我們提供了實用資源，協助您瞭解如何刪除重複的轉換。
Attribution Reporting 資料庫更新期間的資料遺失 如先前公告所述，Chrome 更新 Attribution Reporting 資料庫，會造成任何資料遺失嗎？ 從 Chrome 穩定版 115 開始，根據預設，我們將開始為部分使用者啟用關聯性和評估 API。我們會監控潛在問題，因此正式發布版的測試會逐漸提高。預計在 2023 年第 3 季前，在幾週內達到 100% 可用性。這與關聯性和評估來源試用結束的時間相同。自 7 月起，測試人員將可以註冊正式發布這些 API。這表示透過註冊，可提供來源試用和正式發布的時間重疊。來源試用權杖的有效期限至 9 月 19 日，但建議您在到期日前註冊 API，以便順利轉換至來源試用過程，而不會中斷任何進行中的測試。

如這項公告所述，系統不會在更新後遷移舊版 (M113 以下版本) 註冊的資料，因此資料可能會遺失。這類資料遺失不會顯示在偵錯報表中，且我們會盡量避免資料在 114 至 115 之間遺失。
帳單 使用歸因報表計算單次轉換費用 如這篇文章所述，Attribution Reporting API 可能不適用於單次轉換費用帳單需求，這是因為事件層級和摘要報表加入了雜訊。我們鼓勵生態系統業者在 GitHub 上使用 Attribution Reporting API 提供意見回饋，說明各種計費模式的影響。

匯總服務

意見回饋主題 摘要 Chrome 回應
可匯總報表延遲變更 對提案做出正面反應，將可匯總報表延遲時間從 [10 到 60 分鐘] 變更為 [0 到 10 分鐘]，追蹤生態系統的意見回饋 我們很樂見這項提議的改變，並鼓勵業界持續對我們的提案提供意見。
地端部署解決方案 匯總服務可以部署在地端部署資料中心嗎？ 雖然我們正在探索雲端解決方案以外的可能支援選項，但基於地端部署安全性限制，且需要對 Privacy Sandbox 進行耗時評估的地端部署 TEE，目前無法支援內部 TEE。有鑑於 Privacy Sandbox 安全性要求和地端部署部署作業面臨的重大挑戰，我們相信持續擴展及改善雲端型部署作業 (例如除了 AWS 外支援 GCP)，對整個生態系統帶來最大助益。不過，我們歡迎提供其他意見，協助我們瞭解為何有這類需求。
重新處理不同時間範圍的報表 可重新處理不同時間範圍的報表 我們也聽說能讓不同日期範圍批次處理的類似要求，其中一項提案是讓您利用廣告技術定義的標籤擴充共用 ID，藉此將報表拆分為不同的批次。我們正在評估這個流程，且會隨著這份提案不斷演進，隨時更新生態系統。
受信任的執行環境的隱私權影響 對受信任執行環境的隱私權影響抱持正面觀感 我們很榮幸收到這個生態系統對提案的正面回應。在持續疊代與開發的過程中，歡迎各位提供其他寶貴意見。
服務條款 接受匯總服務條款的期限為何？ 雖然我們尚未指定接受條款及細則的期限，我們仍建議業界公司盡快接受條款及細則，以免註冊延誤。我們建議公司如有任何疑問，請主動與我們聯絡。
金鑰探索 主要探索功能可讓測試人員查詢匯總報表，而無需明確列出可能的按鍵組合，藉此處理跨聯播網歸因的摘要報表，進而改善成效和準確度。 我們目前正致力於探索可能的解決方案和解決方法，並歡迎生態系統中分享您寶貴的意見。

私密匯總 API

意見回饋主題 摘要 Chrome 回應
報表來源 如何定義報表來源？ 報表來源一律是私人匯總呼叫端的指令碼來源。
128 位元金鑰空間 明確說明 128 位元金鑰空間限制 我們會提高此鍵空間限制的明確性，並解決各網頁的不一致之處。建議您使用雜湊策略，以免留在這個鍵空間內。
每份報表貢獻上限 目前每份報表最多填入 20 筆貢獻資料過低。 我們不會增加貢獻數上限，而是考慮拆分報表，避免超過上限。隨著此提案不斷發展，我們將與生態系統交流互動。
觸及報表 索取跨平台/跨裝置報表的觸及數報表。觸及率是品牌宣傳廣告的基礎指標。廣告主在分析觸及與展示頻率報表時，會參考跨平台/跨裝置的概略資訊，以便分析廣告活動並分配支出。觸及模型會使用第三方 Cookie 做為評估第三方環境中廣告的信號，因此廣告技術在第三方 Cookie 淘汰後，已提出替代解決方案的要求。
 在第三方 Cookie 淘汰後，Privacy Sandbox 團隊正在探索相關功能，希望支援跨網域觸及方法。
歡迎生態系統提供意見回饋。

限制隱藏追蹤

使用者代理程式縮減/使用者代理程式用戶端提示

意見回饋主題 摘要 Chrome 回應
(同時回報於 2023 年第 1 季) 其他板型規格的相關提示 要求提供使用者代理程式用戶端提示 (UA-CH) 以提供其他板型規格，例如電視、VR 我們仍在研擬一些重要的設計決策 (是提供「電視」等單一值，或提供板型規格功能清單)，但還是有興趣在這個構想原型設計上。
隱私公開程度上限 基於隱私預算限制，如果傳送過多請求，可能會導致 UA-CH 要求失去確定性。 「隱私公開程度上限」提案目前沒有任何更新，但我們承諾會在第三方 Cookie 淘汰前，避免限制通用 Analytics 用戶端提示的要求。
網站相容性 網站使用 UA-CH 品牌來限制某些瀏覽器存取網站。 以下列舉有效的品牌清單應用情境，其中之一非常相容。通用 Analytics 可讓多個品牌協助處理這些問題。

IP 保護 (原稱 Gnatcatcher)

意見回饋主題 摘要 Chrome 回應
詐欺與濫用 公司可以透過 IP 保護設定反詐騙措施？ 我們瞭解反詐欺用途的重要性，以及這些用途可能造成的影響。我們預計會在今夏稍晚發布更多有關反詐騙支援的詳細資訊。我們希望透過生態系統提供意見回饋，協助我們進一步支援反詐欺用途。
GeoIP GeoIP 的測試與部署時程的詳細資訊 Chrome 最近發布了詳細說明 GeoIP 計劃的新資訊。我們計劃在第 3 季發布更多有關部署時程的資訊。我們預計一開始會為一小部分流量推出「IP 保護」功能。我們瞭解這項提案可能會對公司有些重大變更，因此希望在擴大推出這項功能前，讓生態系統有時間適應並提供意見。
帳戶驗證 透過 Proxy 伺服器進行帳戶驗證的運作方式為何？ 我們預計在今夏稍晚發布更多帳戶驗證的詳細資訊，但目前已有一些初步考量。

跳轉追蹤因應措施

意見回饋主題 摘要 Chrome 回應
測試指南 如何測試跳轉追蹤因應措施 我們在 5 月時發布了一篇 網誌文章，進一步說明如何測試跳轉追蹤因應措施。
說明文件 跳轉追蹤提案中的明確性 目前的提案仍在開發階段，Chrome 會持續更新提案，為生態系統提供清楚明確的資訊。我們正在努力提供更多詳細資料，也歡迎你提供其他意見回饋。
Cookie 刪除 跳轉追蹤因應措施會刪除網域中的所有 Cookie 嗎？ 跳轉追蹤緩解 (BTM) 會清除所有儲存空間和所有快取，詳情請參閱這篇文章。
規避跳轉追蹤因應措施 您可以使用彈出式視窗或新分頁執行重新導向，略過跳轉追蹤程式分類。 「跳轉追蹤因應措施」規格仍在開發階段。目前，我們主要側重於同一分頁的重新導向，但未來也打算擴大處理彈出式視窗的相關事宜。歡迎按這裡提供更多意見。

隱私公開程度上限

意見回饋主題 摘要 Chrome 回應
指定鄰近目標 「隱私公開程度上限」可能會影響指定鄰近目標的用途。 我們已收到此問題的意見回饋，希望深入瞭解 YouTube 生態系統的潛在影響。

強化跨網站隱私界線

第一方集合

意見回饋主題 摘要 Chrome 回應
(同時回報於前幾季) 網域限制 要求增加相關網域的數量 Chrome 正在評估相關子集的適當數值上限，以兼顧隱私權和實用性，並兼顧已識別的用途。Chrome 從很一開始就表示，關聯子集的確切數量尚未定案。
嵌入式用途 支援需要第一方集合、CHIP 和共用儲存空間的內嵌用途 Chrome 已收到關於這個使用案例的意見回饋，該團隊正在調查，也歡迎您提供其他意見回饋。
存放區管理 在出現差異或忽視的情況下，從 GitHub 存放區移除第一方集合的政策相關資訊 Chrome 已收到關於這個用途的意見回饋。我們的團隊正在調查，也歡迎您提供其他意見回饋。
使用者教育 Chrome 應提升使用者對第一方集合的認識和瞭解，進而提升採用率。 Chrome 致力於向使用者說明第一方集合，並發布了關於此效果的 說明中心文章 (可透過 Chrome 使用者介面連結)。同時，Chrome 也持續投注心力，持續學習如何在適當的情境下，提供使用者最優質的教育環境。
第三方 Cookie 後 第三方 Cookie 淘汰後，第三方 Cookie 仍會保留在第一方集合中。 雖然 requestStorageAccess 和 requestStorageAccessFor 確實會針對特定用途再次提供第三方 Cookie，但現在這些 Cookie 需要由網站主動叫用，不再預設使用，就像在 Chrome 中第三方 Cookie 的目前狀態一樣。

雖然在單一集合中叫用此叫用時，不需要經過使用者核准，但使用者可以在「設定」中選擇拒絕此行為。

如需詳細資訊，請參閱說明中心文章 (透過 Chrome UI 連結)。隨著每秒影格數提高至 100%，我們預計將提供現有的開發人員指南擴充資料。
提交第一方集合 重新命名必要的 .well-known/first-party-set，加入 .json 副檔名。 我們做出這項變更，是為了確保 YouTube 支援特定的網站代管方案。
IANA 註冊 「first_party_sets.JSON」應向 IANA 註冊 我們正在考慮提案，歡迎按這裡查看其他意見回饋。

Fenced Frame API

意見回饋主題 摘要 Chrome 回應
廣告封鎖 Fenced Frame 較容易使廣告攔截器封鎖廣告。 擴充功能可以與圍欄頁框互動，類似於與 iframe 互動的方式。擴充功能也可查看 Fenced Frame 即將前往的實際網址，因此可以像在 iframe 中一樣，套用任何網址比對規則來封鎖使用者。單純封鎖所有 Fenced Frame，都可能會破壞非廣告的圍欄框架使用情境。

Shared Storage API

意見回饋主題 摘要 Chrome 回應
採用範圍較大 「共用儲存空間」是所有瀏覽器都能使用的業界標準。 我們誠摯歡迎您提供寶貴意見。Chrome 持續積極參與 W3C fora 計畫，以倡導這項提案、尋求意見回饋，並鼓勵採用。
輸出閘門 共用儲存空間輸出門檻太小。 我們正在考慮這些意見回饋，也歡迎其他生態系統的使用者提供意見，說明輸出閘過於限制的原因。
監管法規遵循 共用儲存空間會如何因應法規遵循要求，例如資料保留政策？ Shared Storage 提供靈活的實作及自訂邏輯，以控制任何儲存資料的生命週期和到期時間。廣告技術可以根據寫入時間戳記，更新或清除共用儲存空間資料。
A/B 測試 如何針對共用儲存空間和 Protected Audience API 進行 A/B 測試？ 我們正在努力針對這個問題發布更多指引，希望日後再分享更多詳細資訊。
共用儲存空間限制 達到共用儲存空間上限後會怎麼樣？ 達到上限時，系統不會儲存任何後續輸入內容。
同個網頁載入時有多個存取權 如果在同一網頁載入中多次存取共用儲存空間，會發生什麼情況？ 處理這種情況的最佳方式就是使用 window.sharedStorage.append(key, value) 函式。而不是更新每則廣告的值，如果有多個廣告，可能會導致衝突。附加函式會在現有值的尾端加上新的值。
iframe 功能 在第三方 Cookie 淘汰後，共用儲存空間仍可支援特定 iframe 功能嗎？ 第三方 Cookie 淘汰後， iframe 中的本機儲存空間將依頂層網站劃分，但不會封鎖 iframe 本身。iframe 本機儲存空間中的資料無法在多個頂層網站複製，但仍可在 iframe 內使用本機儲存空間。

CHIP

意見回饋主題 摘要 Chrome 回應
分區限制 每個分區網站 10 KiB 仍相當顯著，希望能降低。 Firefox 已表示在 CHIPS 上具有 正向位置。如需 Webkit 支援，我們建議開發人員直接針對 這個 GitHub 問題向 Apple 提供意見回饋，說明分區 Cookie 優先於分區儲存空間的用途。
已驗證的嵌入項目 CHIP 可能會影響目前的單一登入 (SSO) 登入流程，因為不同的分區會影響經過驗證的嵌入。 我們打算利用 Storage Access API (含使用者提示) 支援經過驗證的嵌入使用案例，而最近也傳送了 意圖對原型。
生命週期政策 潛在生命週期政策是否適用於第一方 Cookie？ 我們目前不打算對第一方 Cookie 實施效期限制。

FedCM

意見回饋主題 摘要 Chrome 回應
OAuth 授權支援 授權非設定檔 OAuth 範圍一致 在第三方 Cookie 淘汰後，我們現正積極尋求 Web Identity 社群的 W3C FedID CG 建議，以協助支援非基本驗證以外的授權。
支援 SAML 符合 SAML 支援的要求 在第三方 Cookie 淘汰後，相關研究與教育社群也積極尋求有關 SAML 支援需求 (除 OpenID-connect 支援) 的意見。

打擊垃圾內容與詐欺

Private State Token API (和其他 API)

意見回饋主題 摘要 Chrome 回應
探索新信號 許多合作夥伴對探索瀏覽器輔助的裝置完整性或使用者信任信號做出正面觀感。一般來說，他們也會留意新的專用信號，即使這些信號已足以維持目前的詐欺偵測程度，他們也同樣必須謹慎。 我們很高興能在反詐欺和網路安全社群中一起探索新提案，也認同和分享他們的疑慮。這正是「打擊垃圾內容和詐欺行為」的緣由。一直以來都是 Privacy Sandbox 的核心工作流程，而且我們強化了使用者隱私，因此會繼續優先加強保護網路安全。
對 PST 的正面評價 許多合作夥伴有意測試或將 PST 用於各種反詐騙或網路安全用途。 我們很高興聽到這方面的支援，並有興趣進一步探索採用 PST 的全新解決方案。歡迎前往 Chrome 開發人員網站取得相關資源和程式碼範例，也歡迎您提供寶貴意見。
詐欺與濫用行為 第三方 Cookie 淘汰後，停止支援廣告詐欺 / 評估指南。 我們導入了私密狀態權杖等工具，針對反詐欺用途，復原第三方 Cookie 遺失的部分信號，不過已導入新的隱私權控制項。我們目前正積極投入新的反詐欺和反濫用提案，以保留與其他 Privacy Sandbox 異動相關的功能。
核發者對來源資訊率 核發者之間的資訊率夠高，可以識別不重複使用者。 我們已更新規格，更清楚說明可以使用私密狀態權杖傳送哪些使用者資料。根據設計，一次最多可使用六個公開金鑰，可能代表「狀態」特定使用者存取權每組金鑰只能每 60 天更新一次 (必須在需要緊急輪替金鑰的情況下才更新，但這在極少數情況下，可能會拖慢加入其他使用者資料的可能性)。無論是使用新的網路 API，它所提供的公用程式和新使用者資訊能否得到平衡。根據我們的估計，PST 可在保護使用者隱私方面取得適當的平衡，同時支援因第三方 Cookie 退場影響的關鍵反詐騙用途。
擷取整合項目 fetch 整合功能複雜且非必要。 使用 fetch 有許多益處和缺點，我們希望在網路生態系統中實現進一步的標準化，但我們認為現在要進行這項改變還太早，直到我們清楚瞭解標準架構之後，才會如此。每當有標準出現，我們就會努力負責任地讓網頁開發人員符合這項標準。
儲存位置 私密狀態權杖的金鑰設定必須與 PrivacyPass 通訊協定的儲存位置相同。 在來源試用期間進行測試時，開發人員表示他們比較喜歡將金鑰儲存在一般網址，而非 .well-known 目錄中。PrivacyPass 中的金鑰使用承諾格式並不適合金鑰集允許隱含「公開中繼資料」的版本值。如果 PrivacyPass 的變化版本最終使用公開中繼資料 (如 POPRF、部分 RSA 盲或金鑰組) 完成標準化，我們可能會改用較新版本的 PST 來支援這種格式。
API 的標頭實作 關於 API 標頭實作的問題 隨著 API 經過標準化，且這個 API 的生態系統使用日漸成熟，我們應該可以同時支援這個 API 的標準非標頭版本，或者如果使用率過低，或有足夠的開發人員工具/支援建立將核發/兌換要求與其他資料建立關聯的標準方法，也許可以同時支援這個 API 的標準非標頭版本。我們正在在這裡討論問題。
註冊 讓發卡機構向瀏覽器廠商註冊是否可行？ 我們已更新規格，說明私密狀態權杖的核發者註冊程序。雖然這個程序採用獨立程序，但與 Privacy Sandbox 的其他工作註冊計畫類似，我們會要求核發機構針對他們打算如何使用 PST 發表公開聲明，並確認瞭解會保護使用者隱私的技術限制。