意見回饋報告 - 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 的個別利益相關者會議記錄、個別工程師收到的電子郵件、API 的電子郵件發送清單，以及公開意見回饋表。接著，Google 會協調參與這些各種外展活動的團隊，以便判斷與各個 API 相關的主題的相對普遍性。

我們根據已發布的常見問題、對利益相關者提出的問題的實際回應，以及專為這項公開報告作業而決定的立場，說明 Chrome 對意見回饋的回應。我們特別收到了與 Topics、Protected Audience 和 Attribution Reporting API 相關的問題和意見回饋，這些問題和意見回饋反映了我們目前的開發和測試重點。

在目前報表期間結束後收到的意見回饋，可能尚未收到 Chrome 回應。

CHIPS
具有獨立分區狀態的 Cookie
DSP
需求端平台
FedCM
Federated Credential Management
每秒影格數
第一方集合
IAB
互動廣告協會
IDP
Identity Provider
網際網路工程任務組 (IETF)
網際網路工程任務組
IP
網際網路通訊協定地址
openRTB
即時出價
延長賽
Origin 試用版
PatCG
Private Advertising Technology Community Group
RP
依賴方
SSP
供應端平台
TEE
受信任的執行環境
UA
使用者代理程式字串
UA-CH
使用者代理程式用戶端提示
W3C
全球資訊網協會
WIPB
故意隱藏 IP

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

意見回饋主題 摘要 Chrome 回應
資料管理與法規遵循 生態系統指南：如何遵守監管規定使用 Privacy Sandbox。 如同任何新技術，各家公司都必須負起責任，確保其使用 Privacy Sandbox 的方式符合法律規定；Google 無法提供法律建議。不過，我們瞭解這也是生態系統中的重要領域。我們已針對每個 API 發布詳細的技術文件，以提供必要的法律評估依據。我們也正努力提供額外資料，協助各公司遵守法規要求。
CMA 定量測試提案 進一步瞭解 CMA 定量測試提案 我們正與 CMA 合作設計實驗，以便瞭解淘汰第三方 Cookie 和導入 Privacy Sandbox 提案對生態系統的影響。4 月時，CMA 發布了概略指南，說明測試和試用期間的預期情況，並在 6 月發布詳細指南。如對 CMA 的定量測試提案有任何問題或意見，歡迎直接與 CMA 聯絡。
Chrome 協助測試模式 進一步說明測試時間表 我們在 5 月 18 日發布網誌文章，進一步說明 Chrome 協助進行的測試模式。這些詳細資料尚未定案，我們會在 2023 年第 3 季持續進展時，發布進一步的導入指南。
分割儲存空間 在 Chrome 協助測試期間，是否會使用分割儲存空間？ 在第三方 Cookie 淘汰實驗前，我們會先為所有使用者推出儲存空間分割功能。因此，系統會為實驗的所有組別啟用這項功能。網站可選擇啟用淘汰試用功能，在這段期間內取回未分割的儲存空間。
製作支援服務 Chrome 如何處理影響生態系統的 Privacy Sandbox 技術問題和升級問題？ Google 提供多種管道，方便廣告技術人員回報問題，並向上呈報必要的案件。
如要進一步瞭解意見回饋和提報功能的公開和私人論壇，請參閱意見回饋總覽。
註冊時程 目前的註冊時間太短 我們仍在評估實施期限，並希望能聽取生態系統的意見，瞭解哪個時間表較為合適。
鄧白氏環球編碼 進一步瞭解註冊和認證所需的鄧白氏環球編碼 參與者可以在鄧白氏集團網站上，查看取得鄧白氏環球編碼的相關規定。每個市場的規定各不相同，因此參與者請務必查看自己有興趣的特定市場網站。不過，一般來說，參與者必須提供商家的基本資訊，例如商家名稱、地址，以及商家業主或管理人的聯絡資訊。參與者也可能需要提供財務資訊，例如商家的年收入。申請完成後，鄧白氏集團會審查申請，並在申請獲得核准後核發鄧白氏環球編碼。
從來源試用版轉換為正式版 從來源試用版轉換為正式版，是否會影響目前的來源試用版測試人員？ 自 7 月起，測試人員就能使用一般版的相關性和評估 API。這樣一來，原始試用版和正式版的發布時間就會重疊。
AdExchanger 研究 進一步瞭解問卷調查方法 這項問卷調查要求受訪者估算商家的同步率和收益。受訪者可自行決定如何回答個別問題。
參數值 系統如何決定噪音等級、匿名門檻和隱私預算等參數值？ 這個 GitHub 說明文件列出 Privacy Sandbox API 背後的一般原則。許多值仍在確定階段，歡迎您提供相關意見。

顯示相關內容和廣告

主題

意見回饋主題 摘要 Chrome 回應
隱私權保護 研究評估 Topics API 的隱私權維護功能 我們積極與研究社群互動，在論文、報告和工作坊簡報中，呈現我們對 Topics API 隱私權屬性的研究成果。我們很高興看到更多研究社群的外部成員參與這個領域。

Topics API 會讓使用者難以被大規模追蹤，進而保護使用者免受一般網站追蹤。這些論文顯示我們已成功透過 Topics API 達成這項目標。這類 Cookie 比第三方 Cookie 更能保障使用者隱私，同時支援使用者常造訪的網站。
主題分類不夠精細 廣泛主題分類不包含更精細的主題，包括地區特定主題。 為回應生態系統先前的意見回饋，我們於 6 月 15 日發布網誌文章，詳細說明全新的更新分類法，其中納入了許多根據生態系統意見回饋所做的改善。為了修訂分類法，我們與生態系統中的多家公司合作，例如 Raptive (前身為 CafeMedia) 和 Criteo。更新後的分類法則會移除我們認為較不實用的類別，並加入更符合廣告客戶興趣的類別，同時維持排除可能敏感主題的承諾。

我們鼓勵生態系統檢閱最新的分類法，並針對異動內容提供意見回饋。
分類和分類器更新程序 進一步瞭解主題分類和分類器的發布頻率，以及公司如何因應這類更新。 如同最近的網誌文章所述，我們預期分類法會隨著時間演進，並且最終將分類法治理權移交給代表業界各方利益相關者的外部機構。我們也在 topics-announce 群組中分享了逐步推出計畫。
對第一方信號的影響 近期分類更新中主題數量增加可能非常有價值，因此會降低其他第一方興趣信號的價值。 在 2023 年第 1 季報告中，CMA 表示：「據我們瞭解，Google 一直在與廣告技術供應鏈中的多個市場參與者討論新分類法。雖然部分大型發布商表示，增加主題的實用性會增加他們以第一方資料為基礎的解決方案面臨的競爭壓力，但我們初步認為，增加實用性對整體競爭環境更為有利，特別是對於小型發布商而言，在第三方 cookie 淘汰後，他們仍能繼續透過廣告空間營利。我們的觀點與 CMA 的這則評論一致。
對不同類型的利害關係人有用 擔任 SSP 和 DSP 的廣告技術，可能比其他生態系統參與者擁有明顯優勢。 我們的回應與先前幾季相同：

「Google 已向 CMA 承諾，在設計及實施 Privacy Sandbox 提案時，不會偏袒 Google 自家業務，導致競爭環境扭曲，並會考量數位廣告競爭環境、以及不論規模大小的發布商和廣告客戶所受的影響。我們會持續與 CMA 密切合作，確保我們的工作符合這些承諾。隨著 Privacy Sandbox 測試進展，我們將評估新技術在不同類型的利害關係人身上的表現，這也是其中一個重點問題。在這方面，意見回饋至關重要，尤其是具體且可行的意見回饋，可協助我們進一步改善技術設計。我們已與 CMA 合作，制定量化測試方法，並支持 CMA 發布實驗設計備忘錄，為市場參與者提供更多資訊，並讓他們有機會對建議的做法發表意見。」
子主題 主題選取條件是瀏覽器造訪頻率，區隔區塊分散的情況是否會導致子主題永遠無法成為熱門主題？ Chrome 目前正在評估其他排名方法，並探索其他可能有助於提升排名的信號。我們會適時向生態系統說明修訂後的計畫。
機密等級 Topics API 的目標應是確保從 Topics API 取得或衍生的使用者資訊，比起目前的追蹤方法，對個人隱私權的侵犯程度較低。 我們認為 Topics API 比目前的技術更能保障隱私權，可大幅限制使用者重新識別的情況，並可排除敏感主題。我們瞭解主題可與第一方資料建立關聯或結合，以建立機密類別，但我們認為 Topics API 是保護使用者隱私的一大進步，並致力於持續改善 API。
分類結構 在主題分類中新增 ID、版本和其他中繼資料結構 目前，我們會在 API 回應中加入分類 ID。為了長期管理，建議您審查 Topics 物件，並視需要納入版本設定的其他中繼資料。
發布商控制 發布者應可決定網站應歸類為哪些主題。 網站分類錯誤可能會讓 Topics 信號的整體效用略微降低，但這對特定網站的影響與其他網站相同。這是因為網站的內容相關資訊一律會提供給網站上的競價，因此即使發生錯誤分類，也能提供與正確主題相符的資訊。歡迎在這裡提供意見。

允許發布商控管分級類別存在風險。網站可能會刻意將網站歸類為錯誤類別，降低所有人的使用效益，或是在較不常見的主題中編碼敏感意義，損害使用者隱私。
Chrome 擴充功能 允許 Chrome 擴充功能管理及篩選主題，類似目前的 Cookie 管理擴充功能 如同 GitHub 討論的內容，這項功能應該已經可行，但我們歡迎生態系統提供更多意見回饋。
改用正式發布版 從來源試用版轉換為正式版時，Topics API 會受到任何影響嗎？ 使用者從 Origin 測試版轉換至正式版時，資料不會遺失。
隱私權 主機名稱可能含有私人資訊，Topics API 可能會揭露這些資訊 我們採取了多項措施來確保隱私權，詳情請參閱這篇文章。
詐欺與濫用 如何防止不實流量操縱「主題」 如要進一步瞭解緩解措施，請參閱本文。
主題分類器 網站是否可以要求變更「主題」分類？ 我們很想聽聽生態系統對這項主題的看法，歡迎在這裡提供意見。
Topics 供應商網站 將許多主題的內容託管網站指定為「特殊主題提供者網站」，並根據網頁提供的標記訓練分類器。 我們正在討論這項提案，也歡迎提供更多意見。

Protected Audience API (舊稱 FLEDGE)

意見回饋主題 摘要 Chrome 回應
流量型態 為提升每秒查詢次數 (QPS) 負載，使用 SSP 篩選功能對效能造成的影響 我們花了相當長的時間思考流量塑造問題，因此建議 SSP 善用快取功能。
測試音量 賣方平台和交易平台難以取得大量流量，因此無法測試 Protected Audience。 我們會持續與 SSP 和 DSP 合作夥伴合作，採用並測試 Protected Audiences。我們已開始提供一般版，相信啟用 PA 的流量百分比，將有助於合作夥伴進行測試。
複雜度 導入 Protected Audience 解決方案需要付出大量心力和成本。 我們瞭解新技術 (包括 Privacy Sandbox) 難以導入。Privacy Sandbox 團隊正與眾多利益相關者密切合作，提供相關教育訓練和支援，並持續評估其他加速器，以利推動生態系統採用。
受信任的執行環境 在非公開雲端環境中支援受信任的執行環境 (TEE) 雖然我們正在探索可能支援的雲端以外解決方案，但由於內部安全性限制，目前無法支援內部 TEE，因為這需要花費大量時間評估 Privacy Sandbox。考量到 Privacy Sandbox 的安全性規定，以及內部部署作業所面臨的重大挑戰，我們認為持續擴大及改善雲端部署作業 (例如除了 AWS 外，也支援 GCP) 對生態系統最為有利。不過，我們歡迎您提供額外意見回饋，說明為何需要這項規定。
成本結構 與用戶端模式相比，出價與競價服務提案會增加廣告技術的成本和複雜度。 我們目前正在製作指南，說明如何估算在「出價和競價」伺服器中支援出價和競價工作流程的成本，這項成本將與廣告技術使用量相關，以實現我們的設計目標之一。
K-Anon 時間軸 何時會在 `renderUrl` 上強制執行已規劃的 k-anonymity 限制？ 我們正在製作說明，說明違規政策的實施時程，並會盡快發布。
runAdAuction 限制 Chrome 是否可以限制 runAdAuction 只能從頂層頁面呼叫？ 雖然我們的設計完全支援 runAdAuction 可從頂層網頁呼叫，但我們認為，如果發布商限制只能從頂層網域呼叫，對發布商來說會更有害。

我們特別聽取生態系統的意見，認為 Privacy Sandbox 需要盡量減輕發布商和廣告客戶的負擔。這項意見與網頁開發的一般原則一致，網站擁有者可以使用第三方工具來管理網站。Privacy Sandbox 的目標一直是鼓勵建立健康的生態系統，而無須規定發布商和廣告技術的運作方式。

我們允許發布商選擇在網站上呼叫 runAdAuction 的方式和對象，讓發布商彈性運用最符合需求的做法。
導入支援 Chrome 可以建構或貢獻多重賣方競價的開放原始碼實作嗎？ Privacy Sandbox 旨在開發不依賴第三方 Cookie 或其他跨網站 ID 的隱私權保護技術。我們希望能維護健全的廣告生態，但不需規定廣告技術應如何運作。

我們已發布有關 API 在 GitHub 存放區中運作方式的指南，並願意與業界合作探索解決方案。

我們不打算建立任何特定實作項目，因為我們的核心職責是建構平台技術，而非規定使用這些技術的策略。我們的技術可協助廣告技術公司為客戶提供最佳服務，並為消費者提供適當的隱私權防護機制。
多賣家競價 Chrome 是否會強制將「內容相關」得標廣告與元件競價分享？ Protected Audience API 可讓發起多賣方競價的一方將資訊傳遞至元件競價 (注意：僅限在發起競價之前)。

不過，我們無法讓瀏覽器判斷資訊是否為情境贏家，因此無法強制封鎖或要求特定資訊。
同意聲明追蹤的使用者偏好設定 Adtech 詢問 PA 如何正確實作使用者同意聲明追蹤功能 我們的回覆包含第 1 題的內容：
「針對特定廣告，相關廣告技術供應商最適合提供廣告素材顯示方式或選取方式的控管功能。」

我們在 5 月的 WICG Protected Audience Meeting 中討論了許多與此問題相關的情況，並歡迎您提供更多意見回饋和討論。
自訂目標對象 Protected Audience API 是否支援與建立自訂目標對象相關的 SSP 用途？ Protected Audience API 可讓賣方平台和其他廣告技術供應商擁有及管理自訂目標對象。我們正在研擬進一步的指南，說明賣方平台如何整合 PA API，並提供給賣方平台和其他廣告技術供應商，協助他們進行整合。
格式 Protected Audience API 是否支援影片？ 影片廣告可透過兩種方式放送：VAST XML 或 HTML (串流外廣告最終可能也會將 VAST XML 載入至影片播放器)。買方可以透過 renderURL 傳回任一格式。我們最近更新 VAST 規格，以支援 Attribution Reporting API。放送影片廣告的網站必須準備好透過 Protected Audience API 放送廣告的方式。也就是說，您必須確保刊登位置代碼能將 Protected Audience iframe 的網址傳送至影片播放器。針對 Fenced Frames，我們會在 2026 年前，先解決影片需求。
使用速度 Pacing 用途如何與 Protected Audience API 搭配運作？ 感謝你提供寶貴的意見回饋。我們希望看到更多 SSP 合作夥伴提供更多這類要求的例子，因為這項問題目前大多是 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，因此目前沒有可採取行動的意見回饋，至少要等到正式版發布後才會有。
幣別 請勿使用浮點數表示貨幣金額。 我們已在這篇文章中詳細說明這個問題。
非需求端平台廣告選取功能 在 Protected Audience API 競價中，廣告伺服器扮演什麼角色？ 我們知道廣告伺服器要求繼續提供出價後廣告選擇 / 動態廣告素材最佳化服務。我們目前正在評估現有 Protected Audience API 與這些要求之間的差距。
GenerateBid 支援 Google Ads 提案，從 generateBid 傳回每個廣告興趣群組的候選廣告，並在 `scoreAd` 中為這些候選廣告評分。 我們目前正在評估這項功能。歡迎在這裡提供更多意見。
競價訂單 是否必須先執行 Protected Audience API 競價，才能從所有其他競價的結果取得輸入內容？ 系統不會要求 Protected Audience API 最後執行。
非使用者啟動的導覽 公開非使用者啟動的導覽 我們正在審查這項要求，並在這裡討論 。歡迎提供更多意見。
快取 如果使用者狀態有所變更，SSP 就不得從快取建立特定 DSP 的 perBuyerSignal。 我們瞭解快取功能不適用於每個 perBuyer 信號用途，因此正在評估其他選項。歡迎生態系統提供更多意見回饋，說明快取功能是否適用於他們的用途。
歸因報表和 Protected Audience Attribution Reporting API 和 Protected Audience API 如何搭配運作？ 目前 Attribution Reporting API 的兩種模式 (事件層級和摘要報表) 都支援 Protected Audience API 整合。我們已在 6 月 1 日分享更多資訊，說明如何改善 Protected Audience API 與 Attribution Reporting API 的整合。如要瞭解相關資訊，請參閱這篇文章。
伺服器端點 在最終設計中，伺服器端點會是信任的匯總伺服器嗎？ 伺服器端點是廣告技術維護的端點，與用於處理已收集及轉換的報表的「可信賴的匯總伺服器」無關。目前我們沒有任何報表端點異動計畫。目前的設計旨在確保可匯總的報表本身 (含加密酬載) 不會洩漏跨網站資料，因此不需要信任端點。另外，不同廣告技術可能會有不同的所需批次處理策略，這也增加了複雜度。歡迎在這裡提供更多意見。
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};
}

外部貢獻 要求支援 Key/Value Server GitHub 程式碼集的協力貢獻。 我們正著手更新相關程序，以便支援外部人員對 GitHub 程式碼做出貢獻。
興趣群組大小 IG 支援的鍵數上限為何？ 目前的限制是每個 IG 的大小上限為 50 KB，其中鍵值也算在內。歡迎進一步討論大小上限。
批次處理 如何減少 K/V 伺服器呼叫次數？ 您可以使用 HTTP Cache-Control 標頭減少 K/V 呼叫次數。舉例來說，您可以在元件競價和單一網頁上的廣告版位中快取。
版本管控 支援多個版本的廣告技術程式碼 出價和競價服務將支援多個版本的廣告技術程式碼。在「出價和競價」API 中，SelectAd 要求可以指定用於競價要求 (即出價 / 競價和報表) 的程式碼版本。
共用儲存空間 支援在出價和競價服務中寫入共用儲存空間。 目前，出價和競價服務不支援共用儲存空間，但我們歡迎您提供更多意見回饋，說明為何這類用途對生態系統至關重要。
網頁到應用程式 支援將興趣群組從網頁分享到應用程式。 目前，Chrome 和 Android 的 Protected Audience API 部署作業並未納入網頁到應用程式用途，但我們很想瞭解生態系統對這個用途的重視程度。
K-匿名 如何處理 K-匿名 (k-anonymity) 備用項 我們正在討論這個問題，也歡迎你提供更多意見。

評估數位廣告成效

歸因報表 (和其他 API)

意見回饋主題 摘要 Chrome 回應
其他 VTC 事件層級報表設定 針對替代事件層級報表設定提供意見 我們收到一些意見回饋，指出目前的事件層級設定不夠理想，因此想請您提供最佳全域設定的意見回饋。我們歡迎您提供更多意見回饋，並認為彈性事件層級說明文件也能解決這個問題。
彈性事件層級設定 彈性事件層級設定功能的狀態為何？ 我們已分享彈性事件層級設定的說明文件。這項功能仍在提案階段，我們希望能收集更多意見回饋，瞭解這項功能對生態系統是否有價值。
彈性事件層級設定 如何調解不同單位的報告不一致？ 大多數報表情境都會使用匯總報表，而彈性事件層級設定提案則是專門針對事件層級報表提供額外彈性，這類報表最常用於最佳化用途。歡迎您針對此情況提供其他生態系統意見/回饋。
來源登錄 如果觸發事件註冊後才註冊來源，會發生什麼情況？ 目前，如果觸發事件登錄後才進行來源登錄，來源和觸發事件就無法彼此歸因。這似乎是特殊情況。歡迎您提供更多意見回饋，如果許多廣告技術人員都遇到這個問題，我們會設法解決。
與多家廣告代理商合作 如果廣告客戶與多家廣告代理商合作，需求端平台如何使用 Attribution Reporting API？ 這個 API 支援重新導向，因此即使廣告主與多個廣告代理商合作，也能使用這個 API。此外，為了確保 API 能提升隱私權，我們對重新導向設下了一些限制。我們也針對廣告技術提出的特定情境，找出可能的解決方法，利用 Shared Storage API 歡迎您針對這個情況提供其他意見，我們會根據這些意見持續改進。
目的地限制 自動重新整理廣告的用途可能會受到目的地限制的影響。 我們在 5 月 1 日的 WICG 會議中討論了這個問題，並希望能收到有關合理限制的意見回饋。我們已在歸因報表 (含事件層級報表) 說明中新增說明，指出瀏覽器可限制來源網站代表的「目的地」eTLD+1 數量。(請參閱「提取要求」)。
歸因報表和 Protected Audience Attribution Reporting API 和 Protected Audience API 如何搭配運作？ 目前 Attribution Reporting API 的兩種模式 (事件層級和摘要報表) 都支援 Protected Audience API 整合。我們已在 6 月 1 日分享更多資訊，說明如何改善 Protected Audience API 與 Attribution Reporting API 的整合。如要瞭解相關資訊，請參閱這篇文章。
彈性事件層級設定 分享噪音模擬的最佳做法，因為現在可以設定參數。 我們已在 GitHub 上提供程式碼，任何人都可以使用這項工具，針對想測試的任何彈性事件層級設定評估資訊增益和雜訊影響。我們很想聽聽選擇使用程式碼進行測試，並希望分享意見的使用者意見。
跨應用程式和網站歸因評估 何時可以使用跨應用程式和網站歸因評估功能？ 我們在 5 月 9 日宣布，透過 Attribution Reporting API 進行跨應用程式和網頁歸因評估的實驗。雖然關聯性和評估 API 預計在 Chrome 115 正式推出，但跨應用程式和網站歸因評估功能目前並未規劃在 Chrome 115 正式推出。
重複計算轉換 獨立成效評估解決方案如何與 ARA 達成一致？ 如同目前的標準做法，廣告主會與第三方獨立評估服務供應商合作，以便移除重複的轉換報表。我們提供相關資源，說明如何去除重複的轉換，以便製作事件層級報表。
歸因報表資料庫更新時資料遺失 根據公告，Chrome 更新歸因報表資料庫時，是否會遺失任何資料？ 自 Chrome 穩定版 115 起，我們將開始預設為部分 Chrome 使用者啟用相關性和評估 API。我們會監控潛在問題，並逐步擴大正式發布版的供應範圍。目標是在 2023 年第 3 季前，讓 100% 的內容在幾週內皆可供使用。這項變更與相關性和評估來源試用方案的結束時間一致。自 7 月起，測試人員就能註冊以便存取這些 API 的正式版。這樣一來，註冊後的試用版和正式版就會重疊。您的原始試用權杖有效期限至 9 月 19 日，但建議您在到期前註冊 API，以便順利結束原始試用，且不會中斷任何進行中的測試。

如這篇公告所述，更新後不會遷移舊版 (M113 以下) 註冊的資料，因此可能會發生資料遺失的情況。這項資料遺失情況不會顯示在偵錯報表中，我們會盡量避免在 114 至 115 之間發生資料遺失。
帳單 使用歸因報表來查看單次轉換費用 如這篇文章所述，由於事件層級和摘要報表會加入雜訊，因此 Attribution Reporting API 可能不適合按轉換費用計費。我們鼓勵生態系統參與者在 GitHub 上分享意見，說明 Attribution Reporting API 對各種結帳模式的影響。

匯總服務

意見回饋主題 摘要 Chrome 回應
可匯總報表延遲變更 對根據生態系統意見回饋，將可匯集報表延遲時間從 [10-60 分鐘] 變更為 [0-10 分鐘] 的提案持正面看法 我們很高興看到大家對提案變更的正面反應，也鼓勵生態系統持續針對我們的提案提供意見回饋。
地端部署解決方案 匯總服務是否可部署在內部部署資料中心？ 雖然我們正在探索可能支援的雲端以外解決方案，但由於內部安全性限制，目前無法支援內部 TEE，因為這需要花費大量時間評估 Privacy Sandbox。考量到 Privacy Sandbox 的安全性規定，以及內部部署作業所面臨的重大挑戰，我們認為持續擴大及改善雲端部署作業 (例如除了 AWS 外，也支援 GCP) 對生態系統最為有利。不過，我們歡迎您提供額外意見回饋，說明為何需要這項規定。
重新處理不同時間範圍的報表 可針對不同時間範圍重新處理報表 我們也收到類似的要求，希望能將批次依不同的日期範圍分割。其中一個建議是允許使用廣告技術定義的標籤擴充共用 ID，以便將報表分成不同的批次。我們目前正評估這項程序，並會隨著提案進展，向生態系統提供最新資訊。
受信任的執行環境對隱私權的影響 對受信任的執行環境隱私權影響的正面態度 我們很高興看到生態系統對我們的提案有正面反應，並歡迎大家繼續提供意見，協助我們持續改良及開發。
服務條款 接受匯總服務條款的期限為何？ 雖然我們尚未指定接受條款及細則的期限，但我們建議生態系統公司盡快接受條款及細則，以免註冊程序延遲。如有任何問題，歡迎與我們聯絡。
探索金鑰 索引鍵探索功能可讓測試人員查詢匯總報表，無須明確列出可能的索引鍵組合，即可處理跨聯播網歸因的摘要報表，進而提升效能和準確度。 我們目前正在研究可能的解決方案和因應措施，也歡迎生態系統提供更多意見回饋。

私密匯總 API

意見回饋主題 摘要 Chrome 回應
檢舉來源 如何定義報表來源？ 報表來源一律是私人匯總呼叫端的腳本來源。
128 位元金鑰空間 明確說明 128 位元鍵空間限制 我們會進一步說明這個鍵空間限制，並解決各頁面之間的不一致性。建議您使用雜湊法策略，確保不會超出這個鍵值空間。
每份報表的貢獻上限 目前每份報表的貢獻數量上限為 20 個，這項限制太低。 我們不打算增加貢獻次數上限，但會考慮分割報表，而非在達上限時截斷報表。我們會在這個提案演進的過程中與生態系統互動。
觸及報表 請求跨平台/跨裝置觸及報表。觸及數是品牌廣告的基本指標。廣告主會依據跨平台/跨裝置的觸及數和展示頻率報表，分析廣告活動並分配支出。觸及模型會使用第三方 Cookie 做為信號，用於評估在第三方環境中顯示的廣告，因此廣告技術人員在第三方 Cookie 淘汰後，要求提供其他解決方案。
 Privacy Sandbox 團隊正在研究可在第三方 Cookie 淘汰後支援跨網域觸及率方法的功能。
歡迎生態系統提供更多意見回饋。

限制隱密追蹤

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

意見回饋主題 摘要 Chrome 回應
(也將於 2023 年第 1 季回報) 其他板型規格的提示 要求使用者代理程式用戶端提示 (UA-CH)，以提供其他板型規格，例如電視、VR 我們仍在著手處理一些重要的設計決策 (例如是否提供「TV」等單一值，或是一長串板型功能)，但仍有興趣開發這個概念的原型。
隱私預算 隱私權預算限制可能會導致 UA-CH 要求在傳送過多要求時變得不確定。 我們目前沒有隱私權預算提案的最新消息，但我們承諾在第三方 Cookie 淘汰前，不會限制使用者代理程式提示的請求。
網站相容性 網站使用 UA-CH 品牌，限制特定瀏覽器存取網站。 品牌清單有其有效用途，其中之一就是相容性。獲取新客可以自由選擇多個品牌來解決這些問題。

IP 保護 (原稱 Gnatcatcher)

意見回饋主題 摘要 Chrome 回應
詐欺與濫用 企業如何透過 IP 保護機制設定防詐措施？ 我們瞭解防詐騙應用程式的重要性，以及這些應用程式可能受到的影響。我們預計在今年夏季稍晚公布更多有關支援防詐功能的詳細資訊。我們希望能收到生態系統的意見回饋，瞭解如何更好地支援防詐使用情境。
GeoIP 進一步瞭解 GeoIP 的測試和部署時間表 Chrome 最近發布了新資訊，詳細說明我們的地理位置 IP 計畫。我們預計在第 3 季發布更多有關部署時程的資訊。我們預計在初期將 IP 保護功能推出給少數流量，讓使用者選擇是否採用。這是因為我們瞭解這項提案可能會對公司造成重大變動，因此希望在功能大規模推出前，先讓生態系統有時間調整並提供意見回饋。
帳戶驗證 帳戶與 Proxy 伺服器的驗證機制具體運作方式為何？ 我們預計在今年夏季稍晚發布更多帳戶驗證相關資訊，不過我們已分享一些初步考量。

跳轉追蹤因應措施

意見回饋主題 摘要 Chrome 回應
測試指南 如何測試跳轉追蹤因應措施 我們在 5 月發布了一篇 網誌文章，進一步說明如何測試跳轉追蹤因應措施。
說明文件 跳轉追蹤提案中的明確資訊 目前的提案仍在開發中，Chrome 會持續更新提案，為生態系統提供明確資訊。我們正在努力提供更多詳細資訊，也歡迎您提供其他意見。
刪除 Cookie 是否會刪除網域中的所有 Cookie？ 跳出率追蹤緩解 (BTM) 會清除所有儲存空間和快取，如這篇文章所述。
規避跳轉追蹤因應措施 使用彈出式視窗或新分頁執行重新導向，可能會略過跳出追蹤器分類。 跳轉追蹤因應措施規格仍在開發中。我們目前主要著重於同一個分頁的重新導向，但日後也打算著手處理彈出式流程。歡迎在這裡提供更多意見。

隱私預算

意見回饋主題 摘要 Chrome 回應
指定鄰近目標 隱私預算可能會影響到鄰近指定目標的用途。 我們收到了有關這個問題的意見回饋，並且想進一步瞭解生態系統的潛在影響。

強化跨網站隱私界線

第一方集合

意見回饋主題 摘要 Chrome 回應
(也曾在前幾季回報) 網域限制 要求擴充相關網域數量 Chrome 正在評估相關聯子集的適當數值限制，以便在已識別的用途中取得隱私權和實用性的平衡。從一開始，Chrome 就已說明相關聯子集的確切數字尚未確定。
嵌入式用途 支援需要第一方集合、CHIP 和共用儲存空間的嵌入式用途 Chrome 已收到有關此用途的意見回饋，團隊正在進行調查，並歡迎提供更多意見回饋。
存放區管理 當 GitHub 存放區出現差異或疏失時，我們會依據政策從中移除第一方集合 Chrome 已收到有關此使用情境的意見回饋。團隊正在進行調查，歡迎提供其他意見回饋。
使用者教育 Chrome 應提高使用者對第一方集合的認知和理解，以促進採用率。 Chrome 致力於向使用者說明 First-Party Sets，並已發布 說明中心文章 (透過 Chrome UI 連結) 說明相關資訊。Chrome 也持續投入研究，瞭解如何在適當情境下，向使用者提供最適當的說明。
貼文 3PCD 第三方 Cookie 淘汰後，第三方 Cookie 仍會保留在第一方 Cookie 集合中。 雖然 requestStorageAccess 和 requestStorageAccessFor 確實可讓第三方 Cookie 再次用於特定且明確定義的用途，但現在必須由網站主動叫用，而非預設可用，就像 Chrome 中第三方 Cookie 目前的狀態一樣。

雖然在單一集合內的這個叫用作業不需要使用者核准，但使用者可以在設定中選擇停用這項行為，以免發生這種情況。

如要進一步瞭解相關資訊，請參閱說明中心文章 (連結可從 Chrome UI 取得)。隨著 FPS 提升至 100%，我們預計擴充現有的開發人員指南。
First-Party Sets 提交 重新命名必要的 .well-known/first-party-set，以便加入 .json 副檔名。 我們做出這項變更，是為了確保支援特定的網站代管方案。
IANA 註冊 first_party_sets.JSON 應向 IANA 註冊 我們正在考慮這項提案，歡迎在這裡提供更多意見回饋。

Fenced Frames API

意見回饋主題 摘要 Chrome 回應
廣告封鎖 使用 Fenced Frames 後，廣告攔截器可能會更容易封鎖廣告。 擴充功能可以與 Fenced Frame 互動，類似於與 iframe 互動的方式。擴充功能也會看到要導向的實際網址，因此可以套用任何網址比對規則來封鎖，就像在 iframe 中一樣。只要無條件封鎖所有圍欄框架，就可能會破壞圍欄框架的非廣告用途。

Shared Storage API

意見回饋主題 摘要 Chrome 回應
更廣泛的採用 共用儲存空間應是業界標準，可供各瀏覽器使用。 我們非常重視並樂於接受這項意見回饋。Chrome 會持續積極參與 W3C 論壇，推廣這項提案、尋求意見回饋，並推動採用。
輸出閘門 共用儲存空間輸出閘門過於受限。 我們正在考慮這項意見回饋，也歡迎您針對輸出閘道過於受限的原因提供更多生態系統意見。
監管法規遵循 Shared Storage 如何處理資料保留政策等法規遵循事項？ 共用儲存空間可讓您靈活實作及自訂邏輯，以便控制任何儲存資料的生命週期和到期日。廣告技術人員可以根據寫入時間戳記更新或清除共用儲存空間資料。
A/B 測試 如何進行 Shared Storage 和 Protected Audience API 的 A/B 版本測試？ 我們正在努力針對這個問題發布更多指南，希望日後能提供更多詳細資訊。
共用儲存空間上限 達到共用儲存空間上限後會發生什麼事？ 達到上限後，系統就不會再儲存其他輸入內容。
在同一網頁載入中多次存取 在同一個網頁載入期間多次存取共用儲存空間會發生什麼情況？ 處理這個問題的最佳方式是使用 window.sharedStorage.append(key, value) 函式。請不要更新每則廣告的值，因為這可能會在有多則廣告時造成衝突。附加函式只會將新值新增至現有值的結尾。
iframe 功能 第三方 Cookie 淘汰後，Shared Storage 是否會支援特定 iframe 功能？ 在淘汰第三方 Cookie 後，iframe 中的本機儲存空間會由頂層網站分區，但 iframe 本身不會遭到封鎖。iframe 本機儲存空間中的資料無法跨多個頂層網站複製，但本機儲存空間仍可在 iframe 中使用。

CHIPs

意見回饋主題 摘要 Chrome 回應
分區限制 每個分割網站 10 千位元組的大小仍然太大，希望能縮小。 Firefox 已在 CHIPS 中表示 贊成。針對 Webkit 支援，我們建議開發人員直接針對 這個 GitHub 問題提供意見回饋，說明在哪些情況下，他們偏好使用分割 Cookie 而非分割儲存空間。
已驗證的嵌入內容 由於不同分割區會影響經過驗證的嵌入內容，CHIP 可能會影響目前的 SSO 登入流程。 我們打算利用 Storage Access API (搭配使用者提示) 支援經過驗證的內嵌用途，並最近傳送了 意圖至原型。
終身政策 是否會將潛在的有效期限政策套用至第一方 Cookie？ 我們目前並未計劃對第一方 Cookie 實施有效期限限制。

FedCM

意見回饋主題 摘要 Chrome 回應
支援 OAuth 授權 針對授權非設定檔 OAuth 範圍進行調整 我們正透過 W3C FedID CG 積極尋求 Web Identity 社群的意見回饋，瞭解在淘汰第三方 Cookie 後，除了基本驗證之外，還有哪些最佳做法可支援授權。
支援 SAML 符合 SAML 支援規定 在第三方 Cookie 淘汰後，團隊正積極向研究和教育社群徵詢 SAML 支援需求 (除了 OpenID Connect 支援)。

打擊垃圾內容和詐欺

Private State Token API (和其他 API)

意見回饋主題 摘要 Chrome 回應
探索新信號 多位合作夥伴都對探索瀏覽器提供的裝置完整性或使用者信任信號表示樂觀。一般來說，他們也會謹慎評估新信號是否足以維持目前的詐欺偵測水準。 我們很高興能與反詐騙和網頁安全社群共同探討新的提案，並瞭解及分享他們的疑慮。這正是「對抗垃圾內容和詐騙」一直是 Privacy Sandbox 核心工作流程的原因，也是我們持續優先投資於保護網頁安全，並改善使用者隱私權的原因。
對 PST 的正面評價 多位合作夥伴表示有意測試或利用 PST 進行各種防詐或網路安全用途。 很高興得知你有意進一步探索使用 PST 的新解決方案，您可以透過 Chrome 開發人員網站取得資源和程式碼範例，歡迎提供更多意見回饋。
詐欺與濫用 在第三方 Cookie 淘汰後，當 ID 無法使用時，評估廣告詐欺防範 / 偵測的相關指南。 我們推出了私人狀態權杖等工具，有助於復原第三方 Cookie 因防詐目的緣故而遺失的部分信號，但同時也設有新的隱私權控制項。我們正積極投入新的防詐和反濫用提案，以便在其他 Privacy Sandbox 變更時保留功能。
發證機構到原始資訊費率 發出者與來源資訊比率高，足以識別不重複使用者。 我們已更新規格，更清楚說明可透過 Private State Tokens 傳送的使用者資料。根據設計，一次最多可使用六個公開金鑰，這些金鑰可能代表特定使用者的「狀態」。這些鍵組只能每 60 天更新一次 (除了在極少數情況下需要進行緊急鍵輪替)，因此可能會延緩與其他使用者資料的彙整速度。對於任何新的網路 API，都必須在提供的實用性和提供的新使用者資訊之間取得平衡。我們認為 PST 可在保護使用者隱私的同時，支援受第三方 Cookie 淘汰影響的防詐行為主要用途。
擷取整合 fetch 整合作業相當複雜，且不必要。 使用 fetch 有優點也有缺點，我們希望在網路生態系統中進一步推行標準化，但在我們對標準的樣貌有更明確的認識之前，我們認為現在還不宜做出這項變更。一旦標準出現，我們也會盡責地協助網頁程式開發人員轉換至該標準。
儲存位置 私密狀態權杖金鑰設定應儲存在與 PrivacyPass 通訊協定相同的位置。 在 Origin Trial 測試期間，開發人員表示，他們偏好將金鑰靈活地儲存在一般網址中，而非 .well-known 目錄中。PrivacyPass 中的金鑰承諾格式並不適合用於金鑰組允許隱含「公開中繼資料」值的版本。如果 PrivacyPass 的變化版本最終採用公開中繼資料標準 (可做為 POPRF、部分 RSA 遮蔽或鍵組)，我們可能會改用日後推出的 PST 來支援。
API 的標頭實作 關於 API 標頭實作方式的問題 隨著 API 標準化，且這個 API 的使用生態系統日趨成熟，我們希望能同時支援這個 API 的標準非標頭版本，並在使用率低到一定程度，或有足夠的開發人員工具/支援，可透過標準方式將核發/兌換要求與其他資料建立關聯時，最終淘汰標頭版本。我們正在討論這個問題。
註冊 要求發證機構向瀏覽器供應商註冊是否可行？ 我們已更新規格，說明Private State Tokens 的發出者註冊程序。雖然這項計畫採用專屬程序，但與其他 Privacy Sandbox 計畫的註冊計畫類似，我們會要求發證機構公開聲明他們打算如何使用 PST，並承認保護使用者隱私權的技術限制。