本頁面由 Cloud Translation API 翻譯而成。

意見回饋報告 - 2024 年第 1 季
bookmark_border 透過集合功能整理內容你可以依據偏好儲存及分類內容。

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

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

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

縮寫詞彙表

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

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

意見回饋主題	摘要	Chrome 回應
管理	對 Privacy Sandbox 任何治理更新的公開意見徵詢期感興趣。	我們歡迎各方意見相關人士針對 Privacy Sandbox 的任何重大進展提供合理意見回饋，包括 Privacy Sandbox 的未來治理機制。
測試	除了目前 1% 的 Chrome 協助測試外，還可為 3PCD 新增其他測試階段。	我們不打算在目前 1% 的 Chrome 流量 (自 1 月初啟用) 以外，提供 Chrome 輔助測試。
Web to App	在網站和應用程式之間達成完全的相容性之前，請勿在行動裝置上使用 3PCD。	我們同意支援應用程式和網頁的互通性，並已推出跨應用程式和網頁歸因評估功能，同時也正在研究網頁至應用程式指定目標解決方案。不過，我們並未計劃延後行動版網站的 3PCD 功能。我們並未設定 3PCD 結束時的涵蓋率目標為 100%。相反地，我們預期 Android 跨應用程式和網站評估的相容性會在 3PCD 時達到相當高的水準，並隨著使用者更新手機而持續提升。
瀏覽器的角色	Chrome 似乎扮演廣告伺服器或賣方平台的角色。	Chrome 並未擔任廣告伺服器或 SSP 的角色。透過 PA API，Chrome 為廣告伺服器、賣方平台、需求方平台和其他廣告技術提供容器，讓這些服務提供自有的出價和評分邏輯。
用途指南	更清楚說明 Privacy Sandbox API 支援哪些用途。	在 Privacy Sandbox 專案初期，開發人員說明文件的主要重點是讓開發人員參與所有提案的討論和意見回饋程序。這表示內容的整體架構是圍繞著瞭解專案背後的動機和概念，接著說明各項提案的早期開發和測試細節。這有助於在開發提案時建立真正的生態系統合作關係，但隨著 API 逐漸推出一般版，我們也吸引了新的開發人員對象，他們主要目的是建構 API，而非協助開發。我們最近更新了 Privacy Sandbox 開發人員網站的導覽，以用例為重點，並採用與 IAB Tech Lab 在最近的 Privacy Sandbox 工作小組報告中類似的分類。我們會持續以用途為依據的文件編寫方式。
本機開發環境	當 Cookie 為 SameSite=Secure，且後端由 CDN 代管時，我們如何在本機上繼續開發及測試 http://localhost 的 frontend？	我們正在這裡討論這個問題，也歡迎生態系統提供更多意見回饋。
3PCD 因應措施	是否有程式輔助方式可用來瞭解 3PC 是否遭到封鎖，或何時啟用推論法？	在 Chrome 中，功能偵測和在 iframe 中呼叫的 document.hasStorageAccess 都會讓開發人員知道 iframe 中的來源是否有權存取 3PC。
影片測試	目前無法在 Privacy Sandbox 中測試影片廣告。	Chrome 已發布討論和示範內容，說明目前可透過 PA API 完成影片的幾種可能方式 (請參閱 GitHub 示範存放區中的 242 和 254)。請注意，這些並非廣告技術人員可以全面採用的範例程式碼，而是概念驗證和示範，說明如何透過 PA API 支援 VAST 影片算繪。在討論過程中，我們也發現，雖然目前已可進行影片算繪，但 Chrome 可以進行一些變更，簡化透過 PA API 實作的程序。舉例來說，我們已計劃根據第三方廣告驗證機構品牌安全用途的意見回饋，更新巨集替換功能 (詳見這篇文章)，並且也會針對影片用途的意見回饋進行更新，因為買方想知道在轉譯時要使用哪些賣方巨集。目前討論的內容大多著重於轉譯 VAST 影片廣告。原生廣告的算繪作業可以使用相同的方法，而且在許多方面都更簡單。目前原生廣告似乎比影片廣告獲得的關注度低，但這只是廣告技術產業的優先順序問題，並非實施時的任何技術障礙。
非廣告評估	3PCD 可能會影響非廣告相關的目標對象評估解決方案。	評估 API 不要求用途與廣告相關。雖然 ARA 更專門針對一般廣告歷程，私人匯總則是通用功能。這兩個構成要素可用於處理各種評估活動。
內容創作者	Privacy Sandbox 的架構旨在鼓勵內容創作者為 YouTube 製作更多內容，並減少在自有網站上發布內容。	Privacy Sandbox 計畫旨在保護使用者在開放且自由的網路環境中的活動隱私權。我們瞭解發布商需要透過廣告製作內容，並盡可能讓內容廣為流傳。廣告客戶協助使用者發掘可能感興趣的新產品或優惠。有了 Privacy Sandbox 功能，各種網站 (包括與內容創作者合作的網站) 都能根據使用者與不同方的活動，向使用者顯示實用的廣告，且不會向這些方透露使用者的身分。
更清晰的時間軸	提供更清晰、更詳細的 Privacy Sandbox 技術發布時程。	Privacy Sandbox API 說明文件包含 API 狀態和可用性頁面。這些頁面會列出即將推出的功能和相關時間表 (例如 PA API、 ARA)。您可以前往這個頁面查看這些狀態的集中檢視畫面。
機器學習	3PCD 必須超過 1%，廣告技術才能正確訓練機器學習模型。	將 3PCD 擴充至更多瀏覽器進行測試，並不能保證 API 的使用率會提高，而廣告技術人員為了進一步訓練機器學習模型，可能會尋求這類資訊。如果廣告技術人員不希望廣泛的廣告生態系統用於訓練機器學習模型，就沒有理由擴大 3PCD，因為廣告技術人員若想針對更多流量訓練模型，現在就能這麼做，無須增加 3PCD。這麼做時，Chrome 不會在 3PCD 結束前顯示為前進。
不支援的用途	我們目前不考慮推出自助式 DSP 用途。	有多個自助式 DSP 定期針對 API 提供公開意見回饋。其中幾家 DSP 定期提供公開意見回饋，並將自己列為測試人員。此外，Chrome 也積極參與影片和第三方廣告伺服器等典型的自助式需求端平台主題。最近一週的 PA API 呼叫已涵蓋這些主題。
來源試用	針對希望加快 3PCD 測試覆蓋率的網站，申請 OT。	Chrome 目前正在開發第一方 OT，讓來源選擇啟用 3PC 逐步淘汰行為。註冊這項試用方案的頂層來源和部署的符記，會封鎖 3PC，就像使用者裝置已啟用追蹤防護功能一樣。這個 OT 將為網站提供寶貴的機會，讓他們在與 CMA 諮商後，最終逐步淘汰 3PC 前，先對 3PC 的長期替代方案進行更廣泛的測試。我們仍在努力確定 OT 的推出時程。
IAB 技術實驗室報告	從 IAB Tech Lab 報告收到的 Privacy Sandbox 相關意見回饋。	我們已在這裡詳細回覆 IAB Tech Lab 的報告。我們也承認，「這份報告提出了有關零散文件、商業要求、第三方稽核、業界認證、可擴充性、透明度和未來治理的疑問，我們將與生態系統合作，並據此更新公開的常見問題。」我們先前討論過不連續的說明文件。我們在「資料保證」這裡說明商業規定，部分 Google Ads 產品也分享了相關做法。我們會在「演算法完整性保證」這裡說明第三方稽核。至於認證，我們希望這些機構繼續認證產品 (包括使用技術)，而非單獨認證技術。就擴充性而言，我們會持續接受開發人員提供的資料，以便瞭解問題。在資訊公開和治理方面，我們會繼續在 GitHub 和 W3C 等論壇上公開相關資訊，並在承諾下與 CMA 互動。
Google 登入	Google 登入功能可能會導致 Google 使用跨身分識別登入資料，違反承諾。	Google 帳戶登入功能不會讓 Google 使用違反承諾的資料。
相容性	您有哪些計畫，以支援 Privacy Sandbox API 和前向 / 回溯相容性？	一旦 Chrome 推出一般可用的功能，我們就會持續支援該功能。當然，我們無法保證永遠維持向後相容性，因此在這種情況下，我們會依照這篇文章所述，明確說明如何淘汰及移除現有功能。我們預計會持續為 Privacy Sandbox API 新增更多功能，以回應生態系統提供的意見回饋，讓使用者能透過更完善的支援服務，充分發揮這些功能的效益。在這種情況下，我們通常會加入某種功能偵測技術，讓有意嘗試新功能的廣告技術人員，可以直接向瀏覽器詢問是否支援該功能。這比要求開發人員檢查特定 Chrome 版本號碼更為理想，因為部分功能可能不會同時向所有 Chrome 使用者推出。舉例來說，您可以前往這個頁面，查看我們針對 PA API 進行的功能偵測工作。
伺服器實作	與其耦合至自身實作項目，Chrome 應指定可滿足信任信號伺服器、匯總伺服器和任何其他必要非瀏覽器元件的行為。這麼做可在可接受的隱私權範圍內推動創新。	我們樂見外部人士有創新的想法，我們希望所有 API 和服務都能為廣告技術提供彈性，讓他們能夠實作功能。舉例來說，我們允許廣告技術人員在設計競價邏輯時，使用機密的業務資訊。此外，我們會持續與廣告技術團隊互動，並在適當情況下將意見回饋納入設計。為了讓其他人能在信任執行環境中執行自己的程式碼，Privacy Sandbox 需要審查程式碼 (以及任何變更)，確認程式碼確實符合隱私權保證。這需要 Privacy Sandbox 團隊付出大量心力。因此，我們想瞭解利害關係人希望獲得哪些好處，而我們目前無法提供這些好處。
經驗法則	針對啟發法的長期計畫為何？	與其他瀏覽器所指出的一致，我們打算在替代解決方案廣泛使用後，最終淘汰這些啟發式規則，但仍需進一步進行可行性分析。我們已在這裡分享這項資訊。
測試音量	比較不同維度時，流量量會有所不同。	1% 實驗有排除條件，會導致不同 Chrome 用戶群體的實驗資格有所差異。舉例來說，實驗排除 Chrome Enterprise 使用者，因此週末時，帶有實驗標記的流量比例預期會較高。在不同資料切片 (例如地理位置、日期和平台) 中看到不同的流量百分比是正常現象，這與我們在 Chrome 資料中看到的情況一致。
手動重新啟用 3PC	在實施 3PCD 後，網站是否能得知有多少使用者 (以百分比表示) 手動重新啟用 Cookie？	如果使用者遇到問題，可以透過使用者略過功能，在網站層級重新啟用 3PC 存取權。3PC 也可能會透過其他措施 (例如 Storage Access API) 重新啟用。有許多技術措施 (例如 hasStorageAccess())，可讓網站偵測是否已啟用或停用 3PC。不過，Chrome 不會提供任何方式，讓網站得知重新啟用的原因。
追蹤保護功能	Chrome 的追蹤保護 UI 功能開放多久？	3PC 淘汰後，網址列中的追蹤防護 UI 預計仍會保留。
(也曾在先前幾季報告) 跨瀏覽器支援	其他採用 Privacy Sandbox API 的瀏覽器供應商。	Apple、Mozilla 和 Microsoft 等其他瀏覽器供應商，都是在討論隱私權原則和瀏覽器相關做法的公眾論壇中積極參與的一方。我們很高興看到論壇中進行的協作討論，例如最近的 W3C 年度 TPAC 會議和持續進行的 W3C PATCG 論壇，因為我們發現這些論壇有趨於一致的跡象。舉例來說，Microsoft Edge 最近宣布其計畫「旨在盡可能提高語法相容性」，並透過 PA API 和 ARA 提供額外功能給開發人員。
3PCD 後不相容嵌入項目的備用選項	提供 API 鉤子，用於偵測第三方 iframe / 嵌入內容是否符合 3PCD。	我們正在討論這項要求，詳情請見這裡。歡迎生態系統提供更多意見回饋。
測試	在受管理的 Chrome 例項中要求額外標記，以便暫時關閉自訂行為。	我們正在考慮針對 Chrome 受控執行個體提出這項要求，如果這類標記有用，歡迎生態系統提供更多意見。

註冊與認證

意見回饋主題	摘要	Chrome 回應
認證驗證	Google 如何確保認證的真實性？	所有註冊者在使用 API 時，都必須保留認證檔案。Google 會驗證檔案是否正確且語法正確，但不會驗證廣告技術與認證語言的行為。
Private Aggregation API 註冊程序	有辦法查看 Private Aggregation API 註冊狀態嗎？	註冊驗證完成後，所有已核准的註冊者都會收到註冊支援團隊發送的電子郵件通知。如果註冊者在註冊期間有任何疑問，可以與支援團隊聯絡 (他們會在註冊表單提交後與你聯絡)。支援團隊會回覆並解答問題，並提供任何必要的額外指引。

顯示相關內容和廣告

主題

意見回饋主題	摘要	Chrome 回應
(也曾在前幾季報告) 分類器時間表和說明文件	應提供某種機制，以便審查分類結果，或至少讓分類模式決定類別的方式更透明。	我們的回覆與先前幾季相同：「網站分類錯誤可能會讓『主題』信號的整體效用略微降低，但這對特定網站的影響與其他網站相同，這是因為網站的內容相關資訊一律會提供給網站上的競價，因此即使發生錯誤分類，也能提供與正確主題相符的資訊。歡迎前往這個頁面提供意見。」
Google Ad Manager	Google Ad Manager 已嵌入多數網站，因此比起只出現在少數網站的競爭對手，可提供更多使用者主題相關資訊。	觀察要求的目的，是確保 Topics API 不會導致使用者資料與 API 取代技術 (包括 3PC) 以外的實體共用。其他產業解決方案 (例如 Prebid) 則與數萬個網站合作，讓市場參與者透過其技術呼叫 Topics API。此外，值得注意的是，每週最多 5 個熱門主題的限制可能會產生均衡效果，因為許多網站上的市場參與者可能會透過 3PC 學習超過 5 個主題，但最多只能學習 5 個。
(也曾在前幾季報告中提及) 對不同類型的利害關係人是否實用	關於網站價值產生和分配的疑慮，這取決於網站的流量或內容專業程度。	我們瞭解，專門網站比一般興趣領域網站更有可能提供更精細的主題。不過，並非所有專門網站都提供具有商業價值的主題。此外，這項動態反映現況，與 Chrome 停止支援 3PC 無關。在目前的環境中，有些網站在以 3PC 為基礎的廣告關聯性系統中，比其他網站提供更高的價值。此外，不同專門網站的主題之間可以互惠互利，因為不同廣告客戶可針對不同主題組合放送廣告活動，而出價邏輯則可觀察各種主題的價值。
主機名稱與完整網址	以網站主機名稱進行分類是否足夠有效？與完整網址相比，這是否可降低隱私權風險？	除了主機名稱之外，我們也考慮使用資訊網址或網頁標題，但我們認為這會對使用者的隱私和安全性造成風險，因此不採用。使用者隱私權風險的例子包括將網址或網頁標題中的機密資訊歸類為使用者的主題。
主題做為信號	請教如何將主題與其他信號結合，以及其他可能有用的信號。	廣告技術解決方案可結合所有可用的工具 (例如機器學習和來自隱私權保護 API 的隱私權保護信號)，以及內容比對資料、廣告素材資料和第一方資料，以取得最佳成效。如需進一步指引，請參閱這篇文章。

Protected Audience API (舊稱 FLEDGE)

意見回饋主題	摘要	Chrome 回應
測試流量	測試人員回報，PA API 競價的出價回應量偏低。	1. 出價密度與 PA API 的生態系統參與度相關，我們預期這項指標在 2024 年及之後都會持續增加。廣告主、代理商和技術供應商最終決定如何分配廣告活動預算。我們預期部分生態系統參與者會延後投資各種「無 Cookie」解決方案 (包括 PA API)，等到 3PCD 後再投資。屆時，我們預期他們會將廣告活動預算分配給這類解決方案。 2. 在 PA API 競價中，出價請求的數量可能會受到 (1) 的影響，因為發布商和廣告技術供應商可能會在需求偏低時，決定不啟動 PA API 競價。發布商可自行決定更新網頁和參與計畫的優先順序。我們預期發布商可能會花點時間進行測試，並逐步增加流量。這份報表也包含 Google Ad Manager 對參與 PA API 的發布商控制項所做的回應。
(也曾在先前幾季回報) 詐欺 / 濫用	生態系統要如何降低風險，並防止不肖人士或買方將自己定位為理想的目標對象？	PA API 廣告的報表機制會保留目前用於區分人流和機器人流的資訊。此外，PA API 可使用目前的網域技術，納入或排除網域。詳情請參閱我們對 IAB Tech Lab 關於 Privacy Sandbox 的報告回應。
對 IG 擁有者和出價邏輯網址的相同來源限制	由於有相同來源的要求，IG 擁有者的端點將被迫透過相同的負載平衡器，這可能導致重新導向遭到拒絕。	載入指令碼時必須符合同源規定，這是重要的安全防護機制。這裡提出了一些詳細的解決方案，可平衡生態系統意見回饋和其他考量因素。
多個廣告位私下競價	我們可以利用雜訊，並與現行廣告做法更緊密整合，在隱私權範圍內允許多個廣告位元的私下競價。	我們正在考慮這項意見回饋，並評估多標籤競價功能的申請，以因應這項功能帶來的複雜度和隱私風險。我們在 PA API Web Incubator Community Group (WICG) 會議中進一步討論這個問題，會議記錄請見這裡。
頂層賣家	與發布商或元件賣家相比，PA API 目前的結構可為任何頂層賣家提供更多資料，並讓他們瞭解曝光次數的相對價值。	在多重賣方競價中，每位賣方都會擁有最佳出價。此外，我們從生態系統中瞭解到，發布商可能會在考量與各個合作賣家的最佳出價時，同時考慮直接銷售的需求。您必須檢視所有潛在的營利商機，才能決定要放送哪些廣告。在這種情況下，某些使用者必須看到完整的選項，才能選擇要放送的廣告，而這類情況早在 PA API 推出之前就存在。 PA API 旨在支援多賣方競價，以及發布商希望在直接銷售廣告活動旁考量各賣方的最佳出價 (如果適用的話)。也就是說，我們需要提供機制，讓創作者在眾多營利機會中做出選擇，就像目前的情況一樣。我們認為瀏覽器不應負責選擇要放送的廣告。因此，頂層賣家概念是從眾多可能的廣告中選出勝出廣告的必要條件。這個頂層賣方邏輯必須能夠考量發布商選擇合作的每個賣方提供的最佳出價。且賣家邏輯可能會選擇提供發布商直接售出廣告活動的相關資訊 (如有)。所有這類資訊都可以納入頂層廣告選擇邏輯。也就是說，頂層邏輯會查看 PA API 競價中最佳出價，並在適用情況下查看發布商的任何直接銷售廣告選項，以決定勝出者。 Google Ad Manager 在本報告的「資訊存取權」主題下，詳細說明瞭做為頂層賣方的 PA API 導入方式。
競爭性廣告分隔	要求競爭廣告分開顯示，例如避免競爭品牌的廣告同時顯示。	我們不清楚如何在現今的程式輔助、出價、多賣家數位廣告生態系統中，確保競爭分離。不過，PA API 可讓賣家根據呈現網址和主機名稱 (代表發布商的網域) 組合，擷取額外的即時信號，並在評分廣告素材時，在 scoreAd() 中使用這些信號。賣方可使用這項功能，避免競爭品牌的廣告同時顯示 (假設發布商想強制執行這項規則)。
提供的資訊有限	PA API 會減少發布商可用的資訊，例如廣告價值、元件買家名稱、廣告客戶名稱、到達網頁網址、廣告素材大小、回應時間、出價率和失敗出價。	我們已在這裡提出一些可能的解決方案，也歡迎生態系統提供更多意見回饋。
事件層級報表	事件層級報表 PA API 淘汰後，發布商無法取得足夠的廣告放送資訊。	我們瞭解，在停用事件層級報表後，我們必須繼續支援各種報表用途。因此，我們預計在 2026 年之前停用事件層級報表。在這個過渡期，我們會與生態系統合作，共同探索可持續發展的未來路徑，並提供新的想法，協助我們以保護隱私權的方式取得資訊。
多個賣方平台	使用多個 SSP 對發布商來說，附加價值太低。	我們認為這並非正確做法，也歡迎生態系統提供更多意見回饋，讓我們瞭解這項主張的依據。
收錄活動	無法使用 PA API 進行內容策展活動。	我們收到許多意見回饋，指出賣方可以使用 PA API 向網路上的買家提供目標對象資訊 (又稱為目標對象擴充資料)。我們認為，只要使用 PA 的委派功能搭配業務協議，就能實現這項功能。同時，我們也積極考慮如何更好地支援這類用途。
買方選擇不採用	買方預設選擇不採用的做法，可能會導致元件競價的成效降低。	無論是定義單一賣家還是多賣家 PA 競價，賣方都必須在 AuctionConfig 的 interestGroupBuyers 欄位中明確列出買方。這項功能是根據生態系統的意見回饋所開發，因為賣方與部分買方簽有合約，但與其他買方並無合約，因此需要明確控制要納入競價的買方。歡迎您在 GitHub 上進一步討論。
廣告尺寸	無法根據 adsize 和 adSlotSize 執行預先篩選。	我們正在努力新增這項功能，詳情請參閱這篇文章。
支援排除指定 Instagram	支援排除 Instagram 指定目標的 API：僅在使用者不屬於 Instagram 時顯示廣告。	這個 GitHub 問題提出了另一種導入負向指定目標的方式，在這種方式中，瀏覽器會直接告知廣告伺服器，應針對特定廣告請求啟用哪些負向指定目標規則。雖然這似乎是個不錯的方法，但我們調查的所有這類想法都會讓伺服器能夠獨立識別使用者。
《數位服務法》	發布商如何使用 Fenced Frames，同時避免含有《數位服務法》所規範資訊的回應顯示？	如同任何新技術，各家公司都必須負起責任，確保其使用 Privacy Sandbox 的方式符合法律規定；Google 無法提供法律建議。我們已針對每個 API 發布詳細的技術文件，這些文件應可提供必要的法律評估依據。在 2026 年之前，PA API 不必使用區隔框架，讓利益相關者有更多時間確保他們使用這項技術的方式符合所有相關法律。
說明文件	updateAdInterestGroups() 是否為暫時性功能？	我們尚未宣布淘汰 updateAdInterestGroup 的計畫。日後，我們可能會套用與其他 IG 更新機制相同的隱私權保護措施，例如使用 IP 位址代理程式，並在更新前增加一些延遲時間。
支援非需求端平台的買方中繼資料和邏輯擁有權	要求一種可充當 DSP 代理的做法。	我們已收到非數位廣告平台區隔的這項意見回饋，並正在考慮這項要求。歡迎生態系統提供更多意見回饋。
報表	要求在私人匯總報表中，為信號分桶 / 值新增自訂處理常式功能。	我們已知悉這項功能要求，並將其列入待開發的功能清單。歡迎生態系統提供更多意見回饋。
說明文件	是否有連結可供查看廣告客戶和 (委派) 擁有者網域需要設定的所有回應標頭？	我們正計畫更新說明文件，以便說明這項資訊，也歡迎生態系統提供更多意見回饋。
多塔出價	請透過架構 / 區塊圖表說明工作流程 (訓練和推論)，說明如何在 PA API 情境中採用多塔式方法。	感謝您提供寶貴意見。我們有幾份相關簡報，預計會根據這些簡報製作其他文件。
排除指定	Privacy Sandbox 可保護敏感目標對象和未成年人，不受不當廣告 (例如賭博廣告) 影響。	PA API 不會考量顯示的廣告內容。這項功能由使用 Protected Audience 的廣告技術開發人員控管。一般而言，發布商和廣告技術供應商可以使用網頁的內容資訊和發布商規則組合，在 Protected Audience 競價中封鎖廣告素材。這也反映了我們對生態系統目前處理這些挑戰的做法。對於買家而言，IG 排除指定功能也許可用於某些法規遵循用途。
API 設計	Google 正在推遲這項要求，希望廣告技術人員使用通用出價函式，藉此增加延遲時間，而非在不同 IG 中使用不同的 biddingLogicURL (允許使用)。	在討論競價延遲問題時，我們強調在所有買方 IG 中重複使用相同的腳本，可讓買方出價更快速。如要進一步瞭解這項功能，請參閱這篇文章，以及其他改善 PA API 競價延遲時間的最佳化建議。
以帳戶為基礎的行銷	PA API 並非用於帳戶行銷用途的純 API。	我們歡迎生態系統提供意見，說明他們認為無法實現的特定用途，並鼓勵生態系統參與者透過我們的公開 GitHub 存放區或每週的電話會議繼續討論。
A/B 版本測試	在 GAM 中為發布商設定 PA API 時，目前必須為所有廣告空間啟用，或完全不啟用。這會限制發布商執行可行 A/B 測試的能力。	Google Ad Manager 提供的回應： Google Ad Manager (GAM) 中的 PA API 控制項會影響 GAM 使用 API 的能力 (前提是 API 可供使用)。因此，發布商可以使用 Chrome 的權限政策功能，在部分流量中停用 API 使用權限，以做為 A/B 測試的控制組。
機器學習	發布者需要進一步控管 GAM 建議的機器學習用途。	Google Ad Manager 回覆：我們在 2024 年 1 月推出了控制項，方便發布商停用機器學習節流器，並在所有流量中啟用與非 Google 賣方的 PA API 競價。如要進一步瞭解這項控制選項，請前往說明中心。
(也列於前幾季報表) 頂層競價	可使用 Google 的發布商廣告伺服器，而無須將頂層 PA API 競價的控制權交給 GAM。	Google Ad Manager 提供的回覆：根據 Google 2023 年第 3 季報告所述，GAM 的 PA API 整合計畫並未納入支援使用 GAM 做為發布商廣告伺服器的發布商，因為這類發布商無法控制頂層競價。
資訊存取權	GAM 可存取競爭對手提供的寶貴資訊，包括比對內容競價價格、買方為 PA API 競價提供給 SSP 的信號，以及 SSP 提供的設定參數。	Google Ad Manager 回應：多年以來，我們一直非常重視競價公平性，包括承諾在其他買家出價前，不會將任何發布商無保證廣告來源的價格 (包括無保證委刊項價格) 與他們分享。我們後來在向法國競爭局承諾時也重申了這一點。對於 PA API 競價，我們會信守承諾，在多賣家競價結束前，不會將任何競價參與者的出價與其他競價參與者分享。在此說明，我們不會將內容相關廣告競價的價格提供給任何元件競價，包括我們自己的競價，如這篇更新文章所述。此外，我們不會將元件競價設定 (包括買方提供給 SSP 的信號) 的資訊用於自家競價。事實上，我們歡迎對 PA API 進行變更，讓元件賣家以不易讓頂層賣家察覺的方式指定元件競價設定。
元件競價	由於 GAM 是頂層競價，因此會控管哪些 SSP 針對每個廣告機會執行元件競價。	Google Ad Manager 提供的回覆： Google Ad Manager 是發布商廣告伺服器，可為發布商合作的賣方平台提供輕量 API，讓他們透過 Google 發布商代碼 (GPT) API 指定元件競價設定。如需詳細資訊，請參閱這篇文章。如果 SSP 透過這個 API 提供元件競價設定，就會納入該廣告機會的元件競價清單。GAM 不會對所包含的元件競價施加任何限制。只要發布商允許 SSP 在發布商的網頁上執行必要程式碼，任何 SSP 都能執行元件競價。
元件競價	GAM 可為每個元件競價勝出的出價套用特定的未公開底價。	Google Ad Manager 回應：多年以來，GAM 一直非常重視競價公平性。為了維持公平且透明的競價，我們不支援僅適用於特定需求區段的底價。這是我們產品一貫的原則，PA API 競價也會遵循這項原則。
第三方廣告伺服器	第三方廣告伺服器無法存取 Google 參與的較高層級競價，因此無法在 PA API 的情況下，從 Google SSP 廣告需求中獲益。	Google Ad Manager 提供的回應：目前，GAM 支援透過這裡所述的 API，在 GAM 上為多個賣方測試 PA API。目前不支援在其他頂層競價中，以 GAM 做為元件競價的形式參與競價。
(也已在先前的季度中報告) PA API 競價的成效	測試人員回報，PA API 競價的延遲時間過長。	我們瞭解延遲時間的問題，因此開發了許多 PA API 功能，讓 SSP 可以設定 DSP 延遲時間限制，並改善延遲時間。我們最近更新了延遲最佳做法指南，其中包含更多資訊，說明如何充分利用這些功能。我們也持續開發新的延遲改善功能，部分功能可在這裡查看。
(上個季度也有回報) 影片算繪	支援使用 PA API 和 Fenced Frames 進行影片轉譯。	我們在 1 月發布了示範影片，說明串流內影片可能如何在 PA 競價中運作，並進一步說明其他方法。我們也看到生態系統參與者開始提出影片算繪作業的運作方式，例如 GAM 針對影片相容的 renderURL 建構提出的建議，或是完整的 E2E 程序。此外，我們也聆聽生態系統的意見回饋，瞭解我們可以做出哪些調整來提高採用率，其中一個調整的詳細資訊已在 GitHub 上公布。我們會持續與生態系統保持密切合作，找出可能會影響採用率的其他因素，並及時加以解決。
(也曾在先前幾季提報) 資料處理政策	IGs / PA API 的資料處理政策為何？	在 PA API 設計中，儲存在 IG 中的所有資料，或關於使用者在哪些 IG 中的資料，都會 (i) 留在裝置上，或 (ii) 在信任執行環境 (TEE) 中執行的出價和競價 (B&A) 服務中處理。無論是哪種情況，其他方都無法讀取資料，也只能在競價中產生出價，無法以其他方式使用資料。 Chrome 正在研究的某些隱私權強化功能確實會與 Google 管理的 k 匿名性伺服器互動。這項互動功能經過精心設計，可避免分享使用者相關資訊，並在 TEE 中執行，確保廣告生態系統中的資訊一致性。 Google 已向 CMA 承諾，在設計及實施 Privacy Sandbox 提案時，不會偏袒 Google 自家業務，並考量對數位廣告競爭、發布商和廣告主造成的影響。我們會持續與 CMA 密切合作，確保我們的工作符合這些義務。
(也列於前幾季) IG 生命週期	要求將 IG 的效期從 30 天延長為 90 天。	這類變更需要經過審慎評估，權衡對業界的益處，以及對 Chrome 使用者和其他利害關係人的影響。我們正在審核這項要求，也歡迎您在這裡提供更多意見。
(也曾在前幾季回報) modelingSignals	除了只能對顯示和點擊資訊進行編碼的模擬信號，還可以要求新增欄位。	我們已針對這項意見回饋提出對應提案，請參閱這篇文章。我們正積極與業界互動，瞭解他們對這項提案的看法，並評估這項提案對業界的益處，以及對 Chrome 使用者和其他利害關係人的影響。
reportWin() 中的其他位元	在 3PCD 之前，在 reportWin() 中提供額外的位元 (目前限制為 12 位元)。	我們目前正在研究支援這類用途的方法。我們也正在尋找可確保長期隱私權計畫的做法，因此需要一些時間。
競價設計	要求單一競價，傳回轉譯網址及其對應分數。	我們曾考慮從單一 PA 競價中分享多個 renderURL 及其分數，但基於隱私權考量而未實施。我們瞭解您希望避免在單一網頁中向使用者多次顯示相同的廣告，並歡迎您在 GitHub 上進一步討論。
reportWin	在 reportWin() 函式中記錄任意欄位。	這項措施已在測試期間實施。當 Chrome 停止支援 3PC 後，forDebuggingOnly 版本的 API 就會遷移，以啟用降樣偵錯功能，相關資訊請參閱這裡。
元件賣家	具備獨立機制，可計算自身的曝光次數和其他事件，不必完全仰賴廣告技術的報表。	這項功能要求已排入待處理的佇列，以便進一步探索。我們預計不會在 Chrome 協助測試期間解決這個問題。
單次點擊出價帳單	在 PA API 中實作單次點擊出價計費。	我們正在考慮這項要求，目前認為這項要求是希望我們提供建議，說明如何透過目前的 API 介面實作。
browserSignals	將 incomingBidInSellerCurrency 新增至賣家報表的 browserSignals 規格。	我們正在審核這項要求，也歡迎您在這裡提供更多意見。
支援非需求端平台的買方中繼資料和邏輯擁有權	目前的 API 設計可能會導致產品層級再行銷廣告活動出現重大轉變，廣告活動可能需要遷移至同時提供 DSP 和 DCO 服務的平台。	我們正在討論這個問題，也歡迎您在這個頁面提供更多意見。
支援非需求端平台的買方中繼資料和邏輯擁有權	分享需求端平台不是 IG 擁有者的例子。	我們瞭解非出價者希望使用 IG 的部分功能，但不想使用其他功能。我們正積極評估解決這些用途的方法，歡迎前往這個頁面提供更多意見回饋。
逾時控制項	發布商應能指定可參與的 IG 數量，以及頂層超時 / 全域超時。	我們瞭解你希望強化頂層和元件賣家之間的超時控制項和顯示效果，並正在考慮這項要求。
多種廣告大小	PA API 支援多種廣告尺寸用途。	我們正在考慮這項要求，也歡迎生態系統提供其他意見。
說明文件	是否有一份 IG 屬性清單，列出需要採用 k-anon 的屬性？	我們已在這篇文章中回答這個問題。
偵錯	改善 PA API 的偵錯功能。	我們瞭解，對於使用 PA API 的開發人員來說，健全的偵錯工具十分重要。我們致力於改善開發人員體驗，因此正在研究如何將 .well-known 檔案擷取與開發人員工具整合。我們的目標是在開發環境中提供更完善的資訊和疑難排解功能。我們正在這裡進一步討論這個問題，也歡迎您提供更多意見。
標籤	模式 B 處理標籤中的所有使用者是否都已啟用 Privacy Sandbox API？	Chrome 實驗群組指派作業會隨機決定，不受使用者設定的 Chrome 設定影響。雖然這些 API 可能會提供給特定治療組 (例如 treatment_1.*) 的使用者，但使用者可以透過 Chrome 設定修改或停用這些 API 的功能。模式 B 控制組_2：加入這個群組會預設停用 Privacy Sandbox 相關性和評估 API，使用者無法在 Chrome 設定中覆寫這項設定。
API 使用方法	呼叫 reportWin() 和廣告算繪作業是否會同時進行，還是會依序進行？	在 runAdAuction() 完成後，系統會直接呼叫 reportWin()。與此同時，當競價結果放置在 iframe 或 Fenced Frame 中時，廣告算繪程序可能會開始。在 reportWin() 執行完畢且廣告開始算繪後，系統會擷取傳送至 sendReportTo() 的網址。
(也曾在先前幾季回報) A/B 版本測試支援	要求支援 PA API A/B 測試。	我們正在這裡討論這項要求，也歡迎您提供更多意見。
流量型態	Google 提案透過 KV 伺服器管理所需決策，這對賣家來說並無幫助，因為賣家無法與後端互動，因此難以調整流量。	如GitHub 問題所述，揭露個別 DSP 是否有 IG 可能會造成使用者指紋問題。我們已在問題中提出其他替代方案，也歡迎提供更多建議。
流量型態	快取機制會增加一層複雜度，導致 DSP 無法瞭解要出價的流量實際形態。	快取機制只是建議，廣告技術供應商可以選擇使用符合其用途的建議，歡迎前往這個頁面進一步討論。
標籤	Chrome 應在向買方和賣方信任伺服器提出要求時，將標籤做為參數共用。	這似乎是合理的要求，因為這與負責任使用 IG 資料的目標大致一致。不過，我們正在考慮這項要求，並會在內部審查後，針對此事提供公開更新。
API 使用方法	在「第三方測試的其他 CMA 指南」文件中，明確定義「control_1」組。具體來說，我們擔心文字變更可能會被誤解為要求從 control_1 排除所有 Privacy Sandbox API。	我們已在這個 GitHub 討論串中表達我們的看法。不過，我們無法代表 CMA 發言，建議您直接向 CMA 提出任何有關解讀測試指南的問題。
API 使用方法	Chrome 是否允許在空白網頁上呼叫 joinAdInterestGroup()，同時重新導向至其他資源？	如果使用者造訪某些網站，網站擁有者可以將呼叫 joinAdInterestGroup 的權限委派給第三方。這項委派作業可讓第三方建構 IG，而無須透過空白頁面新增任何類型的重新導向。歡迎您提供意見，說明在重新導向期間建構 IG 而非使用預定的委派機制的原因。
API 使用方法	廣告交易平台應能將 IG 寫入與其合作的發布商擁有的網頁，然後將對該 IG 出價的權限委派給任何買家或 DSP。	我們已收到意見回饋，目前正在評估是否能支援這類要求。歡迎生態系統提供更多意見回饋。
API 使用方法	如果沒有人勝出 PA API 競價，就不會收到偵錯失敗通知。	Chrome 的 reportWin 和 reportResult 函式專為在 Privacy Auction (PA) 系統中，回報事件層級的勝出報表而設計。如果在 PA 競價期間所有出價都遭到拒絕，由於沒有勝出者，這些函式不會叫用。 Chrome 近期的更新可能會說明為何在 DevTools 網路面板中，傳遞至 forDebuggingOnly.reportAdAuctionLoss() 的網址不會顯示。建議您使用 Canary 或開發人員版的 Chrome 進行功能驗證。
API 使用方法	透過 generateBid 傳回的 adCost 是否可以為負值 (已隨機四捨五入至 2 個位元組)？	AdCost 是廣告主從 generateBid() 傳遞至 reportWin() 的點擊或轉換成本。這個值可以是空值或雙精度浮點值。系統會忽略負值，不會傳遞。傳遞時，系統會隨機捨入該值。
API 改善	是否可以使用信任且經過加密的執行伺服器，而非 Chrome 瀏覽器，來處理指定目標 / 同類群組 / 歸因和競價？	建議您探索 PA API 中的 TEE 相關元件和選項 (例如 KV 伺服器和 B&A 服務)，以及歸因報表和私人匯總的 TEE 相關元件 (例如匯總服務)，以便解決這個問題。
API 改善	Privacy Sandbox 競價回應是否可以是出價回應 (例如標頭出價)，而不是廣告回應 (例如廣告代碼)？	這類變更會從根本上改變 PA API 的隱私權屬性，因此我們不考慮這類變更。
發布商控制項	發布商可以封鎖網頁上的 PA API 廣告素材嗎？	Chrome 提出了即時廣告素材掃描提案，但尚未開放測試。雖然這項功能尚未推出，但我們發現大多數的賣方平台都已建立相關解決方案。
API 使用方法	perBuyerSignals 的大小限制為何？	在傳統形式中，perBuyerSignals 在 Chrome 中沒有固有的大小限制。主要限制是資料必須可序列化為 JSON，且不會造成過度耗用記憶體。不過，請注意，如果 perBuyerSignal 過大或過於複雜，可能會對成效造成負面影響。您可以透過 directFromSellerSignalsHeaderAdSlot 傳遞 perBuyerSignals，這種做法會在標頭中傳送 perBuyerSignal，但整個標頭回應的大小上限為 10 KB。此外，個別伺服器可能會對標頭大小上限設定限制。
說明文件	請修改說明文件，說明如何從 generateBid 內呼叫 registerAdBeacon。	我們已在 2 月 17 日更新這份說明文件。
API 使用方法	reportEvent 如何從多個已登錄的選項中選擇正確的信標網址？	每個競價都會產生獨立的設定，進而產生獨立的報表對應項目。個別競價 (以及產生的廣告框) 彼此完全獨立，不會共用資料。「分隔廣告框廣告報表」說明文章會進一步說明這個主題。
Chrome UI	在 Chrome 開發人員工具中新增篩選器，並依「應用程式」>「興趣群組」分頁標籤篩選，以便依 IG 擁有者 (或 IG 名稱) 篩選。	我們正在評估這項要求，也歡迎生態系統提供更多意見。
無頭 Chrome	無頭 Chrome 中的 PA API 支援。	部分 PA API 元件與 Chrome 相關，例如對 Google 伺服器的 k-anon 呼叫，可能無法在「舊版」無頭 Chrome 中運作。我們認為，Chrome 112 發布的「新版」無頭 Chrome 可能可以解決這個問題。
API 使用方法	在使用 reportAdAuctionLoss 進行損失報表的情況下，我們在許多情況下都會看到「topLevelWinningBid=0」。這代表什麼意思？	topLevelWinningBid 值來自頂層賣方元件中的 scoreAd() 函式。這個值會影響最高層級競價的結果。根據說明，如果 topLevelWinningBid 值為零或任何負數，表示對應的廣告不符合競價勝出資格。舉例來說，您可以運用這項機制，篩除未超越內容指定候選項目的興趣群組指定廣告。雖然 topLevelWinningBid 值為零可能表示內容廣告競價已勝出，但 PA API 規格承認，其他因素也可能導致這個結果。
模式 A/B 測試	說明模式 B 和模式 A 的流量選取和停用提示。	模式 A 和模式 B 的納入條件相同。目標是讓群組代表一般 Chrome 流量，只要支援 Privacy Sandbox API 和標記方法即可，因為某些用戶端設定不相容。為了進行實驗，請務必只比較標記流量和其他標記流量。模式 B 的使用者已啟用追蹤防護功能，因此會收到有關該功能的通知。
API 改善	是否可以將「lifetimeMs」加入 joinAdInterestGroup 呼叫中，做為直接的資源，或是將其做為個別引數管理？	我們正在仔細考量網頁開發社群針對 PA API 提案中「joinAdInterestGroup」功能提出的意見回饋。討論重點是管理 IG 生命週期的最佳方法。我們正在評估為「lifetimeMs」參數提供個別引數的好處，因為這有助於提升彈性和適應性，以便日後對規格進行強化。我們正在這裡討論這個問題，也歡迎提供更多意見。
API 使用方法	由於與低熵瀏覽器 ID 發生衝突，PA API 架構中的誤判率可能會增加。	Chrome 團隊正積極參與 PA API 架構的持續精進作業。我們很高興討論到瀏覽器 ID 衝突可能導致的假陰性率。我們正在仔細評估這些意見回饋，並會努力確保更新後的分析結果全面反映所有相關因素。我們致力於提供可同時達成隱私權保護目標和維持準確性與可靠性的解決方案。我們正在這裡討論這個問題，也歡迎您提供更多意見。
API 使用方法	是否需要使用低熵瀏覽器 ID，以免用戶端在 k 匿名系統中針對同一項物件重複提交「Join」要求？	我們瞭解並感謝大家持續討論在 k 匿名系統中使用瀏覽器 ID 的做法。我們瞭解大家對這類 ID 可能對隱私權造成的影響有疑慮。雖然我們最初的實作方式是使用低隨機性 ID 做為反濫用機制，但我們正積極探索其他技術 (例如匿名計數權杖)，以便在維持系統完整性的同時，優先保護使用者隱私。我們致力於尋找平衡負責任使用資料與嚴格隱私權保護的解決方案，並歡迎與研究社群持續對話。我們正在討論這個問題，也歡迎您提供更多意見。
API 使用方法	AMP (Accelerated Mobile Pages) 是否支援 PA API。	AMP 目前不支援 PA API。如果 AMP 支援功能是優先考量，歡迎生態系統提供更多意見回饋。
API 改善	建議從 k-anonymity 檢查中移除類型。	我們正在仔細考量如何最佳化 k 匿名度要求結構的意見回饋。我們瞭解您建議整合參數，並可能統一類型，以便簡化程序。我們的目標是確保效率和可維護性，我們會在持續開發隱私權解決方案的過程中評估所有選項。我們正在這裡討論這個問題，也歡迎提供更多意見。
Chrome UI	要求提供機制，讓技術程度較低的使用者輕鬆查看及管理所屬的 IG，包括可用於選擇退出的網站層級控制項。	我們瞭解提供易於使用的工具，協助使用者瞭解及管理 IG 的重要性。我們經過仔細考量各種方法，發現以加入 IG 的網站來識別 IG 最能兼顧清楚明瞭和隱私權保護。目前，IG 的全球管理功能位於 Chrome 設定中。我們會持續探索如何進一步改善這方面的使用者體驗。我們正在這裡討論這個問題，也歡迎您提供更多意見。
API 安全性	即使在 Fenced Frames 的情況下，PA API 是否仍可能因廣告素材互動而洩漏隱私資訊？	我們瞭解複雜的廣告互動可能會導致資訊外洩。我們正積極調查 Fenced Frames、PA API 和潛在攻擊向量的相互關係。降低隱私風險是我們的首要任務，我們致力開發完善的解決方案，在創新與使用者保護之間取得平衡。我們正在這裡討論這個問題，也歡迎您提供更多意見。
延遲時間	買方出價邏輯的預設逾時時間 (50 毫秒) 是否合理？	我們瞭解您對規格與出價邏輯網路要求時間不一致的疑慮。我們正積極審查規格，確保其準確性，並研究最佳的預設逾時設定，以平衡效能和可行性。我們正在這裡討論這個問題，也歡迎提供更多意見。
說明文件	規格中可能會發生時間外洩，導致網站推斷廣告是否未達 k-anonymity 門檻，並對跨網站追蹤產生潛在影響。	我們瞭解您提出的潛在時間流失問題。我們已確認規格有差異，並採取措施確保廣告的 k-匿名性狀態是在競價前決定，以免發生資料外洩。我們非常重視這些疑慮，並會根據這些變更更新規格。我們正在這裡討論這個問題，也歡迎提供更多意見。
API 使用方法	在 PA API 中實作 SSP 封鎖清單的方式。	我們認為，需要提供機制來管理廣告平台的廣告限制。我們建議您探索優先採用裝置端評估，並利用現有廣告中繼資料保護使用者隱私，同時提供彈性運用的解決方案。我們致力於與開發人員合作，找出 PA API 中最佳的做法。我們正在這裡討論這個問題，也歡迎您提供更多意見。
API 使用方法	有人可以讓瀏覽器假裝執行 PA API，讓網站無法偵測嗎？	我們瞭解，在目前的形式下，網站可以偵測到選擇不採用 PA API 的情況。我們正積極開發額外出價和剔除指定目標等功能，以及柵欄框架算繪功能，以提升隱私權並提供無法偵測的選擇不採用選項。我們正在這裡討論這個問題，也歡迎您提供更多意見。
模式 A/B 測試	資料中心流量聲稱為處理方式 1.1。	Chrome 團隊已與 GAM 團隊確認，這類流量現已從實驗中篩除。我們正在這裡討論這個問題，也歡迎您提供更多意見。
API 使用方法	PA API 中 interestGroupBuyers 實作項目的效率和公平性。	我們瞭解大家持續討論 PA API 競價中「interestGroupBuyers」欄位的效率和公平性。我們瞭解效率、隱私權和市場公平性之間的取捨。雖然賣方需要管理與買方的業務關係，但我們正在研究如何改善配對流程。這可能包括根據即時資料和混合型模型進行的動態調整。我們持續致力於尋找以使用者隱私為優先，並能支援競爭力強大的廣告生態的解決方案。我們正在這裡討論這個問題，也歡迎您提供更多意見。
Chrome UI	在 Chrome 中，與 IG 相關的潛在記憶體問題和 UI 清晰度。	我們瞭解您對在開發人員工具中顯示 IG 有疑慮。雖然目前的檢視畫面會顯示所有 IG 事件的歷來追蹤記錄，但我們也瞭解，提供更清晰的儲存 IG 目前狀態資訊，將有助於提升使用者體驗。我們將探討最佳化和潛在的 UI 改善方式，以提升開發人員洞察資料。就記憶體管理而言，IG 實作方式旨在防止記憶體耗盡，但我們會持續監控及改善資源用量。我們正在這裡討論這個問題，也歡迎您提供更多意見。
說明文件	原始發布者嘗試直接在「joinAdInterestGroup」函式的「sizeGroup」欄位中使用命名廣告大小時，發生錯誤。他們想知道這是預期的行為嗎？	我們瞭解在「joinAdInterestGroup」函式中簡化廣告設定的價值。我們正積極解決這項限制，並預計在日後的更新中啟用這項功能。這項增強功能符合我們提供彈性且高效的廣告管理工具給開發人員的承諾。我們正在這裡討論這個問題，也歡迎您提供更多意見。
Chrome 協助測試標籤	請要求在 sendReportTo 中提供關於模式 A 與 B 的直接資料和確切標籤，以便我們持續追蹤實驗。	我們正在這裡討論這項要求，也歡迎您提供更多意見
說明文件	向賣方信任的伺服器提出要求時，是否會在要求中加入賣方的網域名稱，以便進行驗證？	我們承認在 Protected Audience KV Server API 說明文件中，一開始沒有提供主機名稱參數。我們想向開發人員保證，系統會自動將賣方的網域名稱納入對賣方信任伺服器的要求中。這項功能對於健全的廣告驗證程序至關重要。我們已更新說明文件，以解決這項疏失，並會持續以開發人員社群的資訊清楚度和透明度為優先。我們正在這裡討論這個問題，也歡迎您提供更多意見。
API 使用方法	為了製作報表，在廣告曝光追蹤呼叫中加入 IG 名稱的潛在方法。	我們致力於在完善的報表機制和使用者隱私權的基本原則之間取得平衡。在廣告曝光追蹤中加入 IG 名稱時，我們會採用 k-anonymity 保護措施，避免識別個人身分。我們會持續在這些隱私權限制下，探索創新的報表解決方案。我們正在這裡討論這個問題，也歡迎您提供更多意見。
API 功能	要求買方信任的伺服器接收用戶端提示 HTTP 標頭。	我們正在追蹤這項功能要求，詳情請參閱這篇文章。
API 使用方法	委派檔案是否應要求載入「Access-Control-Allow-Origin」標頭，因為該標頭會決定瀏覽器的 IG 會員行為？	我們致力於遵循網路安全性最佳做法。委派檔案的「Access-Control-Allow-Origin」標頭規定可確保符合 CORS 原則，並防止機密資訊遭到非預期揭露。我們正在研究如何在維持強大安全防護機制的前提下，改善這項程序。我們正在這裡討論這個問題，也歡迎您提供更多意見。
API 使用方法	讓廣告伺服器在 PA API 架構中為廣告素材進行個人化設定。	我們瞭解廣告伺服器在廣告素材個人化功能中扮演的角色。我們正積極探索解決方案，以便在 PA API 中強化廣告伺服器功能，例如可結合出價和廣告素材選擇邏輯的「共同 IG」模式。我們的目標是在提供強大的廣告素材功能和保護使用者隱私之間取得平衡。歡迎您前往這個頁面，進一步合作並提供意見，協助我們改進 API，滿足所有利害關係人的需求。
隱私權疑慮	是否有其他 ID (例如 RampID、ID5) 可能會促進跨網站資料收集，進而破壞 PA API 的隱私權目標。	我們瞭解跨網站 ID 與 PA API 的隱私權目標之間可能存在衝突，雖然發布商可以選擇分享這類 ID，但 PA API 的設計目的在於將廣告選擇與跨網站追蹤的需求分開。我們致力於打造以隱私權為重點的廣告生態系統，並鼓勵開發人員優先採用 PA API 做法。我們正在這裡討論這個問題，也歡迎您提供更多意見。
快取	有辦法避免在多個競價中重複使用出價指令碼嗎？	我們瞭解在 PA API 架構中，出價指令碼的快取行為。雖然系統支援標準 HTTP 快取機制，但由於裝置暫停行為和出價執行工具的設計，指令碼仍有可能在競價中重複使用。團隊正在研究解決方案，讓買方能更有效地控管指令碼快取，以便有效管理出價策略。我們正在這裡討論這個問題，也歡迎您提供更多意見。
API 使用方法	在尊重使用者隱私權的情況下，集中記錄所有需求端平台的 IG 出價活動。	我們在設計 PA API 時，會優先考量使用者隱私權。雖然由於跨網站追蹤風險，無法直接回報個別出價事件，但我們提供共用儲存空間和私人匯總等機制。這可讓 DSP 以保護使用者隱私的方式，取得有關出價活動的匯總洞察資料。
API 使用方法	相較於透過 forDebuggingOnly.reportAdAuctionWin() 註冊的擷取作業，在 reportResult() 中透過 sendReportTo() 執行的擷取作業只會發生 94%。	雖然兩者可能不會在同一時間，但兩個網址都可能會同時擷取。在某些情況下，元件賣家的 worklet 會遭到處置，因此需要重新載入，才能執行 reportResult() 函式。不過，無論是擷取評分邏輯所需的時間，還是工作區塊重新載入所需的時間，都不會影響 reportResult() 的 50 毫秒逾時時間。請注意，如果需要重新載入工作區塊，Chrome 會使用快取標頭來定義擷取行為。如要進一步瞭解 PA 競價的各個階段，請參閱這篇文章。
K-anonymity	要求確認「興趣群組」名稱不會影響廣告放送的 k-anonymity。	廣告素材必須在過去一段時間 (w) 內，以 IG 擁有者網址、出價指令碼網址、廣告素材網址和廣告大小組成的元組，達到指定的 k 匿名門檻。系統會定期更新 k-anonymity 狀態 (p)。
Chrome UI	提案提供許多 MVC、ORM 等架構提供的「內部可見度」類型。例如，您可以先在「開發人員工具」-->「應用程式」-->「應用程式」部分，將所選內部事件記錄到新的面板	我們正在這裡討論提案，歡迎提供更多意見回饋。
Chrome UI	開發人員工具 IG 加入功能不會顯示優先順序相關元素。	我們已在這裡解決這個問題。
API 改善	建議您允許廣告素材廣告伺服器追蹤自己的事件。是否可以設定允許追蹤的網域清單？	我們已在這裡分享提案，歡迎生態系統提供更多意見回饋。
API 功能要求	是否可以擴充 PA API，以支援非 RTB 媒體交易，並維持廣告放送和 DCO 等重要用途？	我們正在這裡討論這個問題，也歡迎你提供更多意見。
發布商競價逾時	發布商需要控制競價期間，以免錯失曝光，尤其是在廣告會依序選取的標頭出價設定中。	我們瞭解，讓發布商能精細控管廣告競價逾時時間的重要性。我們正積極探索如何實作全域競價逾時機制，可能會在「auctionConfig」物件中實作，同時仔細考量極端情況。這項功能旨在為發布商最佳化曝光填充率，我們將持續與社群合作，找出最佳解決方案。我們正在這裡討論這個問題，也歡迎你提供更多意見。
API 改善	由於 renderURL 過長，導致 PA API 中 IG 目前的設計會產生大量中繼資料。測試人員希望能壓縮這些網址，提高效率。	我們瞭解最佳化 IG 中繼資料大小的重要性，特別是對於效率敏感的廣告競價而言。我們認為，以範本為基礎的壓縮 renderURL 解決方案具有極大潛力。我們會仔細評估提出的範本設計，確保任何導入的解決方案都包含完善的濫用防範機制，以維持瀏覽器的穩定性。我們仍會優先考量這些因素，與網路標準社群合作，開發最佳做法。我們正在這裡討論這個問題，也歡迎你提供更多意見。
API 使用方法	負責處理原生廣告格式的測試人員希望在單一呼叫中擷取多個廣告結果，藉此改善 Privacy Sandbox 競價程序，以減少網路負載並提升廣告顯示速度。	我們瞭解在 Privacy Sandbox 中顯示原生廣告時，會出現成效問題。我們致力於在效率與嚴格的使用者隱私保護機制之間取得平衡。雖然傳回多則分數滿分的廣告會侵害隱私權，但我們正積極探索如何改善競價程序。我們致力於強化 PA API 對原生廣告格式的支援，並研究其他機制，以便在 Privacy Sandbox 的嚴格隱私權限制下提高效率。我們正在這裡討論這個問題，也歡迎你提供更多意見。
API 使用方法	在 Privacy Sandbox 中，廣告出價的評分和排序方式可彈性調整，特別是用於表示優先順序或私人交易市場規則。	我們瞭解您需要在 Privacy Sandbox 中對廣告評分和排序進行精細控管，特別是在複雜的出價情境中。我們瞭解提出的解決方案使用元組和數學函式，可在不犧牲使用者隱私的情況下，達成多維度評分。雖然這些做法可能會增加開發人員的複雜度，但可提供必要的表現力。我們致力於探索各種方法，以便簡化這些程序 (可能透過輔助函式或指南)，確保能妥善運用 Privacy Sandbox 功能，實現進階競價邏輯。我們正在這裡討論這個問題，也歡迎您提供更多意見。
reportEvent()	新增可在瀏覽器初始化含有廣告素材的框架時觸發的新保留事件 (可能是自動信標)。	我們正在這裡討論這項要求，也歡迎您提供更多意見。
adCost	允許 adCost 細目。	每個成本值都是傳送有限資訊到競價之外的機會。允許整個 N 個費用清單，即可傳送完整的使用者 ID，進而啟用跨網站追蹤功能。我們正在這裡討論這個問題，也歡迎您提供更多意見。
resolveToConfig	是否應從頂層繼承 resolveToConfig，並在 browserSignals 中公開？	我們正在這裡討論這項要求，也歡迎您提供更多意見。
更好用的工具	是否有類似 chrome://topics-internals 的 PA API？	沒有任何完全相同的內容。不過，PA API 有許多開發人員工具。
標籤	Chrome 可以使用標籤來識別 20% 的 k-anon 人口嗎？	我們正在考慮這項要求，也歡迎生態系統提供其他意見。
說明文件	Privacy Sandbox 競價工作項是否會成為標準工作項類型？	由於隱私權和安全性要求各有不同，這些工作項與標準瀏覽器工作項類型有顯著差異，因此我們不認為這些工作項很快會成為 HTML 規格中的標準工作項類型。我們致力於強化開發人員資源，清楚說明競價工作項的導入和執行環境，讓 Privacy Sandbox 參與者更容易取得這類資訊。我們已在這篇文章中進一步討論這項問題。
自備伺服器 (BYOS) 鍵值 (KV) 伺服器	在 BYOS KV 服務設定中，各方可能會透過 KV 服務查詢，瞭解使用者加入的多個 IG (來自同一位擁有者)。	當 KV 伺服器在 TEE 中執行時，就無法再這樣做，我們可以確保這些伺服器遵守已發布的信任模型。
userBiddingSignals	更新部分「userBiddingSignals」，同時保留其他信號。	這項功能已可使用，且無須對 API 進行任何變更。
API 使用方法	在 Privacy Sandbox 中為多個 IG 實作展示頻率上限，可能會使用 KV 伺服器或經修改的「prevWinsMs」資料。	我們瞭解您希望在 Privacy Sandbox 中使用進階展示頻率上限功能。我們瞭解，目前在 IG 之間共用資料的限制可能會導致實施這些策略時遇到困難。雖然 KV 伺服器提供潛在機制，可提供適當的隱私權保護，但我們仍鼓勵開發人員在單一 IG 模型中探索解決方案。我們正在這裡討論這個問題，也歡迎您提供更多意見。
API 使用方法	元件賣家 (參與 Privacy Sandbox 內巢狀競價的賣家) 需要掌握頂層競價逾時時間，才能改善自身設定並避免不必要的延遲。	我們瞭解需要改善 Privacy Sandbox 中頂層賣家和元件賣家之間的超時協調機制。我們正積極研究新增的逾時機制，包括可能的整場競價逾時機制，以及如何將頂層逾時機制套用至元件競價。我們的目標是提升 Privacy Sandbox 競價程序的效率和可預測性，讓所有參與者都能受惠。我們正在這裡討論這個問題，也歡迎您提供更多意見。

Protected Audience 服務

意見回饋主題	摘要	Chrome 回應
受信任的執行環境 (TEE)	在公用雲端執行 TEE 的費用是否比在自家廣告技術資料中心執行更高？	我們的回應與前幾季類似：我們目前的 TEE 安全性模型可從公有雲端導入的做法中受益。特別是，目前的硬體 TEE 無法防範所有實體攻擊。我們目前支援的公開雲端服務供應商 AWS 和 Google Cloud 已設計並實施了物理存取風險的因應措施，包括針對員工的風險。請參閱以下有關內部支援服務的詳細資訊。廣告技術人員曾提到，執行雲端服務的費用比內部部署廣告技術資料中心的費用高。雖然我們無法評估這些陳述，但歡迎您提供更多有關成本的意見回饋，我們也會持續評估擴大 TEE 支援服務的選項。
TEEs	支援非公開雲端環境中的 TEE	我們的回應與先前幾季類似：雖然我們持續探索支援公有雲端解決方案以外的選項，但目前沒有支援內部部署 TEE 的計畫。在這個階段，考量 Privacy Sandbox 的安全性要求，以及在內部部署時遇到的重大挑戰，我們認為持續擴大及改善雲端部署 (例如除了 AWS 外，也支援 Google Cloud) 對生態系統最為有利。不過，我們歡迎您提供更多意見回饋，說明為何在隱私權和安全性限制下，這項規定是必要且可行的。
其他雲端服務供應商	支援其他雲端服務供應商	我們隨時歡迎其他雲端服務供應商提出建議，但至少在 3PCD 生效時，我們會支援 Google Cloud 和 AWS。詳情請參閱這篇說明文章。
B&A Services API	Google 對 B&A Services API 的方向為何？在裝置競價中，Chrome 瀏覽器 Protected Audience 的優先順序會高於還是低於裝置？	我們的回應與先前幾季類似：我們仍致力於現有的 Protected Audience 裝置端出價設計。我們提出 B&A 服務，是為了探索可能的解決方案，以支援在裝置的運算能力或網路速度可能受限的情況下，可支援的部分用途。
標準化	B&A 服務尚未經過標準化程序。	B&A Services 提案目前正處於標準化程序的某個階段，我們歡迎更多人參與，協助達成這個目標。這項提案起源於先前的提案，目前正透過 W3C 的公開討論進行公開孵育，有興趣的開發人員可以開始進行實驗並提供意見回饋。這是開發網頁功能的常見模式，如這篇網誌文章所述。
KV 伺服器	向買方的 KV 伺服器公開完整網址，以便進行內容 / 內容比對 / 網站指定。	我們正在這裡討論這項要求，也歡迎生態系統提供更多意見回饋。
說明文件	GitHub 上的「信任/強制執行元件與選用元件」說明文件，會讓擁有自訂部署映像檔和基礎架構的部分廣告技術人員感到困惑。	我們正致力改善「信任/強制執行元件與選用元件」的說明文件，也想瞭解生態系統是否需要優先處理這項工作。
API 改善	KV 伺服器呼叫的 HTTP 狀態碼也應可供 scoreAd() 函式做為參數使用。	我們正在評估這項要求，也歡迎生態系統提供更多意見。
說明文件	進一步說明如何透過 UDF 執行作業來處理 JS 和 WASM 工作負載。	我們正在研究如何提供這項資訊，也歡迎您在這個頁面提供更多意見回饋。
說明文件	要求更新存放區名稱。	我們已將儲存庫重新命名為「protected-auction-key-value-service」。這與其所屬服務集合的名稱相符，該集合還有其他儲存庫，例如 Protected Audience Services 討論和 Protected Auction Services 說明文件儲存庫。
說明文件	在 bidding_auction_services_gcp_guide.md 中移除對 Cloud Debugger API 的參照。	我們已更新說明文件並移除參考資料。
API 使用方法	KV 查詢所造成的延遲時間超過 50 毫秒。耗時將近 100 毫秒。請問其他賣家有哪些做法成效良好？您是否有任何建議，可以評估逾時和時間？	KV 伺服器呼叫會在 Script Runners 的背景中發生，也就是 Chrome 瀏覽器內的特殊受保護環境。目的是讓這些指令碼執行程式中的資訊免於遭到任何非 API 存取。如需詳細說明，請參閱這篇文章。
API 使用方法	KV 伺服器是否有在特定時間內回應的逾時限制？	賣家可以在競價設定中指定「perBuyerCumulativeTimeouts」欄位。這段逾時時間包含擷取受信任出價信號所需的時間。
延遲時間	Privacy Sandbox 團隊如何解決延遲問題？	如要瞭解我們正在研究的策略，確保延遲時間不會超過許可上限，請參閱這篇文章。

評估數位廣告成效

歸因報表 (和其他 API)

意見回饋主題	摘要	Chrome 回應
手動廣告活動最佳化	ARA 不支援手動廣告活動最佳化。	我們已與廣告技術團隊討論過這種情況，並說明如何使用 ARA 支援手動廣告活動最佳化。ARA 的設計方式可讓廣告技術自訂，並靈活解決各種廣告技術用途。我們提供的幾項建議包括使用不同的彈性事件層級設定，以及搭配摘要報表使用事件層級報表，以減少雜訊影響，並滿足手動和自動最佳化需求。歡迎您針對 ARA 設定的可自訂性和彈性提供更多生態系統意見回饋。
轉換類型	Google 只允許八種轉換類型，限制太多。	我們已實作大部分的彈性事件層級報表，讓廣告技術人員在報表回溯期數、歸因報表數量，以及可用的觸發事件資料位元方面，享有更大的彈性。廣告技術人員可以選擇設定，最多可評估 32 種不同的轉換類型。
可匯總報表事件限制	每份可匯總報表的轉換事件數量下限為 20 次，這對預算有限的小型廣告客戶來說並不實用。	每份可匯總報表都不需要設定轉換事件的最低數量。此外，您還可以採取多項設計決策，為小型廣告主最佳化可匯總報表，例如變更追蹤的主要結構 / 維度、測試不同程度的ε值、測試更長的批次頻率，以及測試評估目標之間的不同貢獻預算分配。小型廣告技術人員也可以嘗試結合事件層級報表和摘要報表，以減少雜訊的影響。
即時資料	不提供即時資料 (例如點擊、工作階段和轉換) 給數位廣告交易平台，因為數位廣告交易平台會根據這些資料調整出價策略，以提高廣告活動成效，這違反了維持現有功能的承諾。	即使啟用 ARA，點擊和工作階段仍會以即時方式記錄，轉換則會在事後記錄 (即使啟用 3PC 也是如此)。
遺漏欄位	在推出全方位彈性事件時，缺少以下規定：i) 幣別欄位，以及 ii) orderID / TransactionID 欄位。	我們目前不打算在完全彈性的事件層級中支援「貨幣」欄位或「訂單 ID / 交易 ID」欄位，因為目前的事件層級報表已經提供這類欄位。我們歡迎您針對這些欄位提供更多意見回饋，並會重新考慮是否有其他使用情境需要這些欄位。使用現行 ARA 設計評估幣別和訂單 ID 類型資訊的方式： 1. 根據這項意見回饋，系統會根據使用者的地理位置決定幣別，並將該資訊加入 source_event_id，以便判斷所使用的幣別。 2. 根據意見回饋，我們需要使用去重複鍵的訂單 ID 欄位，確保轉換和價值不會因誤判而重複計算。
隱私預算	ARA 隱私預算會限制跨多個維度的評估功能	ARA 的設計目的，就是讓廣告技術人員自訂 ARA 設定，涵蓋各種歸因情境。在現行 ARA 設計中，廣告技術供應商必須思考，要評估哪些維度最關鍵，以及雜訊對資料的影響。根據評估維度的細緻度，為資料加入雜訊，對於隱私權來說至關重要。我們歡迎生態系統提供更多意見回饋，針對跨不同維度評估的功能提出建議，但需要先瞭解這類用途。
更新規格	雖然 Google 表示已從固定事件回報時間範圍改為彈性時間範圍，但這項資訊並未反映在 Google 的技術規格中，目前仍維持一小時的最低時間範圍。	目前的彈性事件層級報表可讓廣告技術人員變更每個來源事件的歸因報表數量、觸發資料位元數，以及報表回溯期數/長度。ARA 仍會針對事件層級報表保留 1 小時的最低回報時間，這對維護隱私權和減輕特定類型的歷史資料重建攻擊十分重要。由於摘要報表會以匯總方式提供資訊，廣告技術人員可以選擇立即接收匯總報表，無需延遲 (視用途而定)。
API 設計	擔心減少轉換報表中的資訊和增加雜訊，會對生態系統造成比 Google 更嚴重的影響。	Google 已向 CMA 承諾，在設計及實施 Privacy Sandbox 提案時，不會偏袒 Google 自家業務，導致競爭環境失衡，並會考量數位廣告競爭環境、以及各種規模的發布商和廣告客戶受到的影響。
歸因修正	ARA 不允許技術供應商控制及驗證正確的歸因。	ARA 內有許多可用的驗證功能： 1. 廣告技術人員可以驗證 ARA 行為是否符合預期： – ARA 用戶端程式碼是開放原始碼。 – ARA 伺服器端程式碼也是開放原始碼，協調器會確保只有允許的匯總服務版本才能解密及處理可匯總報表。 2. Chrome 為廣告技術提供模擬資料庫，以便驗證歸因行為，廣告技術可以測試 ARA 在模擬環境中如何執行歸因。 3. ARA 支援多種偵錯信號，可協助您驗證預期的處理作業是否發生，以及為何未發生。
(上季也有回報) 噪音	意見回饋指出雜訊過多，影響報表的實用性。	我們曾與提供相同意見的廣告技術人員進行討論，並找出如何自訂 ARA 以便更適合他們的用途，即使有雜訊干擾也能正常運作。我們提供開發人員說明文件，其中包含與廣告技術人員討論過的大部分設計決策和自訂選項。 ARA 的設計目的，就是讓廣告技術人員自訂 ARA 設定，涵蓋各種歸因情境。不過，廣告技術人員必須考量，哪些維度對他們來說最為重要，以及雜訊對資料的影響。我們歡迎各位提供有關雜訊影響的額外生態系統意見回饋，並提供更多關於 ARA 槓桿的相關指南，協助您改變雜訊的影響。
跨網域歸因	如何追蹤跨網域歸因？	廣告技術可重新導向至不同的報表網址，以解決這個用途。歡迎針對 ARA 的這項設計提供更多生態系統意見回饋。
API 改善	定期變更註冊 ARA 摘要報表歸因時使用的縮放因子。	根據 GitHub 上的討論，在匯總服務中處理多個縮放因子，似乎會導致摘要報表的雜訊量增加，相較於目前的功能。我們歡迎您針對匯總報表中是否需要納入縮放因子提供更多意見回饋，但也想提醒您，這可能會導致雜訊量增加。我們也正在評估其他未來的 ARA 功能是否也能解決這個用途。
API 使用方法	統一歸因事件與所有參與者的分享方式，這對 SSP、DSP 等都很有幫助。	我們計劃與廣告技術團隊保持同步，進一步瞭解他們的意見和遇到的任何限制。
測試流量	所有 Chrome 穩定版的模式 B 測試流量是否相同？	加入實驗組不會受到 Chrome 設定影響 (與 Chrome 設定無關)。
說明文件	支援 Pixel 的 ARA。	我們已發布資訊，說明如何支援這類用途，也歡迎生態系統提供更多意見回饋。
API 使用方法	如果轉換不是由最終接觸點完成，則 ARA 可能不會歸因於電子商務平台上的第三方賣家正確來源。	公司可以使用篩選器避免歸因錯誤 (也就是不會產生轉換報表)。我們也正在研究歸因前篩選功能的提案，以便支援這類用途。
瀏覽器支援	不同瀏覽器是否支援 ARA？	我們歡迎其他瀏覽器採用 Privacy Sandbox API，並持續撥出時間，在 W3C 公開討論我們的做法。我們明確表示互通性是推出 ARA 的目標，而 ARA 的設計旨在不受瀏覽器限制，並為不同隱私權立場的供應商提供彈性供應商指定值。其他瀏覽器會自行決定是否要提供可支援內容和服務數位生態系統的跨網站 ID 可行替代方案。我們很高興 Microsoft Edge 表示將支援 ARA。
API 使用方法	針對 registerAdBeacon/reportEvent (以及 navigation_start/commit 自動信標) 的 ARA 來源註冊，預期的來源類型為何？	這取決於這些信標是自動或手動： - 保留。*自動事件的類型為導覽來源。 - 手動觸發的事件為事件來源類型。
API 使用方法	每個來源的匯總報表數量上限為 20 份，是否代表每個來源事件？上限是全球還是每日？是否有提高上限的計畫？	每個來源可匯總報表數量上限為 20 份，這是全球限制，也就是說，您只能為每個來源建立 20 份可匯總報表。此限制由瀏覽器設定，無法調整。這項限制的目的，是避免有人濫用空值報表來保護實際歸因報表。我們已在這篇文章中進一步討論這項問題。
API 使用方法	支援使用 ARA 進行電子郵件行銷。	目前 ARA 並未直接支援這個用途 (如果您無法控制電子郵件代管網站)。我們正在這裡討論這個問題，也歡迎您提供更多意見。
Epsilon	Aggregate API 的 epsilon 值何時會決定？	廣告技術可以設定目前的 epsilon 值，但不得超過 Privacy Sandbox 定義的預設門檻 (目前為 64)。建議您測試不同的 epsilon 值，並找出自身用途的轉折點，然後提供意見回饋。我們會在變更小數值範圍前，先通知廣告技術人員。
API 改善	支援廣告客戶可在 trigger_data 欄位中插入 ID，以便與外部客戶關係管理 (CRM) 資料比對，驗證轉換品質的用途。	我們正在討論這項要求，歡迎前往這個頁面提供更多意見。
API 使用方法	如何將重新導向網址設為到達網址。	廣告技術人員可以採取下列任一做法： 1. 將最終到達網址放入到達網址欄位； 2. 到達網頁欄位最多可輸入 3 個網址，因此您可以將多個網址放入該欄位。兩種選項都需要知道最終到達網址。我們已在這裡進一步討論這個問題。

匯總服務

意見回饋主題	摘要	Chrome 回應
鍵盤探索機制	要求金鑰探索機制	我們提出了索引鍵探索功能的提案，歡迎生態系統提供意見回饋。
API 使用方法	Aggregation Service 監控功能的路線圖	我們正在評估各種選項，以便提供更完善的可觀察性，並歡迎生態系統提供意見回饋。
API 改善	要求能夠重新查詢報表。	匯總服務正在處理要求提案，讓廣告技術人員可以為每份報表分割自己的ε值。這可能會導致每個查詢產生更多雜訊，但可讓廣告技術人員重新查詢並維持隱私權。
API 改善	希望能夠將多個來源連結至同一個 AWS ID。	匯集服務現在可讓多個網站在同一個雲端帳戶 (Google Cloud 或 AWS) 中完成新手上路程序。這可讓廣告技術人員使用相同的匯總服務特區，處理來自多個網站的報表，以及來自同一網站的多個來源。
API 使用方法	當可匯總批次失敗時，不確定預算是否已用盡，也不知道是否可以重新處理批次。匯總服務在處理重複報表時遇到預算錯誤，其他報表就會遺失。如何盡量減少這項損失？	在一般情況下，如果整個工作失敗，系統就不會使用預算。如果預算用罄時發生罕見的失敗情況，廣告技術人員可以要求恢復預算。如果廣告技術人員經常遇到工作失敗，並出現預算用罄錯誤，則應確認其批次處理策略。如要瞭解如何正確批次處理並避免重複報表和錯誤，請參閱這篇文章。歡迎您前往這個頁面提供預算回收功能的意見回饋。
API 使用方法	使用 Private Aggregation API 搭配這裡所述的觸發條件，即可為每次競價產生可匯總的報表。匯總服務的資源調度功能為何？	匯總服務本身並未對批次中的鍵或報表數量設下上限，但由於需要的記憶體量，目前不支援 10^14 份報表和 10^12 個鍵的規模。我們的大小設定指南會指出我們已測試的範圍，並根據預期負載和支援的雲端 VM 執行個體類型，提供最佳效能的建議。
資料處理	如果加密資料含有個人資訊，向匯總服務提供加密資料的法律安排為何？請問您能否說明，協調程是否保證不會存取加密資料？	匯總服務不會將加密 / 使用者資料提供給協調器。匯總服務會使用協調器來管理及記錄金鑰。如要進一步瞭解協調器，請參閱這篇文章。在會計方面，匯總服務只會將共用 ID 和報表來源提供給 PBS，以便追蹤預算支出。推出多網站後，我們會將來源替換為網站。請注意，匯總服務會在 TEE 中執行，這是唯一可解密用戶端回報的地方。在 TEE 中執行的程式碼為開放原始碼，並由外部單位進行稽核，詳情請參閱這篇文章。

私密匯總 API

意見回饋主題	摘要	Chrome 回應
API 使用方法	元件供應商可將報表傳送至 TEE 中的多個匯總伺服器。	目前的 Private Aggregation API 狀態不支援這項功能。我們已在這裡進一步討論這個問題。
說明文件	Google 試驗中使用的 epsilon 值為何？	就私人匯總 API 而言，匯總服務查詢中指定的 ε 值會對應至 L1 貢獻預算 2^16，且會以 10 分鐘的滾動方式強制執行。此外，系統也會以 24 小時滾動方式，強制執行 2^20 的「備用」L1 貢獻預算。因此，隱私權參數基本上是 10 分鐘滾動式 ε，24 小時滾動式則是 16ε (而非 144ε)。匯總服務目前支援的 ε 測試範圍為 1 到 64，可用於測試不同的匯總策略，並針對 Private Aggregation 和其他 API 的不同隱私權參數，提供系統實用性的意見回饋。我們會持續收集測試人員的意見回饋，並新增可更有效運用隱私預算的功能，以便日後重新檢討最大許可的ε值。

限制隱密追蹤

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

本季未收到任何意見回饋。

IP 保護 (原稱 Gnatcatcher)

意見回饋主題	摘要	Chrome 回應
解析 ID	Privacy Sandbox 需要更積極向媒體宣傳，指出以 IP 建構的解析 ID 對廣告主而言並不永續。	Privacy Sandbox 已明確指出，我們的目標是減少跨網站追蹤。我們在 privacysandbox.com 和 GitHub 上公開的公開計畫，涵蓋的範圍超越 Cookie。我們致力減少跨網站追蹤，包括根據 IP 位址進行的追蹤。不過，最終決定是否主動啟用跨網站追蹤功能，仍取決於個別網站。在法規遵循度日益嚴格的時代，個別公司應謹慎瞭解服務供應商採用的做法。
Chromecast	IP 保護功能是否會影響 Chromecast 或其他 Chrome 裝置？	我們目前沒有將 IP 保護功能套用至 Chromecast 裝置的計畫。
IP 保護清單	是否會公布第三方名單，指出哪些第三方可能會使用 IP 位址進行全網跨網站追蹤？	如這篇文章所述，我們會在確定後發布這份清單。

跳轉追蹤因應措施

意見回饋主題	摘要	Chrome 回應
單一登入 (SSO) 豁免	Bounce Tracking Mitigation (BTM) 如何驗證免除追蹤功能的單一登入 (SSO) 使用情形？	Chrome 會使用推論法停用 BTM。詳情請參閱說明文章。
淘汰試用計畫	在 3PC 淘汰試驗中，網站是否已啟用 BTM？	否，BTM 會遵循淘汰前測試期間建立的 Cookie 例外狀況，詳情請參閱這篇文章。

隱私預算

如GitHub 說明文件和開發人員網站所述，我們已不再積極將隱私公開程度上限納入 Privacy Sandbox 提案。

強化跨網站隱私界線

意見回饋主題	摘要	Chrome 回應
功能建議	系統會自動允許在 RWS 中存取 CHIP 和 / 或儲存空間分割區，無須使用 Storage Access API 或使用者互動。	我們正在評估這項功能的效益和可行性。其中一個考量因素是跨瀏覽器互通性可能出現的差異，RWS 會運用 Storage Access API 來解決這個問題。目前其他瀏覽器不支援這項功能，我們鼓勵開發人員提交這項問題的用途，以利討論，請前往這個頁面。
移除不符規定的組合	從存放區移除不符規定的集合，該如何進行？	我們正在制定相關程序，一旦有最新消息，就會立即與你分享。
違規處置流程	Google 在 RWS 違規處置流程中的角色不明確。	由於 RWS 是持續進行的專案，我們會持續收到新的提交內容，因此程序和標準仍在不斷調整中。我們同意提交指南應充分說明提交規定，並會在日後的提交指南中加入更多細節，避免產生模糊和混淆的情況。我們的目標是讓提交流程盡可能以技術為主，以便逐步減少人為介入，並完全依賴自動檢查。這類提交的修訂要求需要更多人為互動，因為其中包含我們未預期的行為，但這類提交的修訂要求可讓我們找出更多可自動化的領域，並修正指南，以便日後避免發生這些問題。
分享資料	要求提供功能，讓網域擁有者可在取得使用者同意後，要求第三方也分享 RWS 資料。	使用者在接受權限提示後，即可透過 FedCM 和 Storage Access API 等 API 存取已提供的功能，存取已驗證的 ID。歡迎生態系統提供意見，指出他們認為無法實現的特定用途。
其他儲存方法	儲存在本機儲存空間或工作階段儲存空間的資訊是否也會解讀為 3PC？	自 Chrome 第 115 版起，在第三方情境中使用本機儲存空間、工作階段儲存空間和其他形式的非 Cookie 儲存空間時，這些儲存空間會在 Chrome 中分區。詳情請參閱這篇網誌文章。
關聯集合上限	如果機構提交的網域超過 5 個 (「最多 5 個相關網站」)，會發生什麼情況？	這些集合會透過 GitHub 程序接受，但瀏覽器 (Chrome) 只會將 Storage Access API 自動授權規則套用至前 5 個網域，並忽略其餘網域，如這裡所述。
find_robots_txt	find_robots_txt 檢查不適用於重新導向。	我們已提交修正程式，以解決這個問題。請參閱這篇文章。
使用者手勢	移除 accessStorage() 的使用者手勢要求。	這項規定是根據所有主要瀏覽器的 requestStorageAccess API 所採用的類似設計而制定。歡迎在這個 GitHub 問題中提供更多意見回饋和使用情境，協助我們優先處理這項要求，並啟用跨瀏覽器討論。
使用者手勢	在 Chrome 或作業系統重新啟動後，是否需要使用者手勢才能授予第三方存放區存取權？	是的，但我們歡迎生態系統提供更多意見，讓我們知道是否要變更這項行為。請按這裡提供意見。

Fenced Frames API

意見回饋主題	摘要	Chrome 回應
adComponent	使用 AdComponents 搭配 Fenced Frames 時，缺乏說明文件和彈性。	我們會提供更多與此使用情境相關的說明文件。此外，在使用 getNestedConfigs() 的圍欄邊框中，廣告元件也受到支援，相關規格說明請參閱這裡。
(也已在先前幾季回報) 算繪 adComponent	請提供如何在 Fenced Frame 中算繪 adComponents 的程式碼範例。	我們正在這裡分享一些範例程式碼。
第三方廣告驗證	第三方廣告驗證在 Fenced Frames 情境中的角色需要進一步說明，尤其是在內容/品牌安全方面。	目前，Fenced Frames 廣告報表可讓 DSP 將曝光和競價事件層級資料傳送給第三方廣告驗證機構，以便進行轉譯後品牌安全性檢查和結算。
可展開式廣告	要求支援展開式廣告。	如果廣告需要在兩個顯示比例相同的大小之間切換，且兩者之間沒有功能差異 (僅限大小)，嵌入者可以使用第二個廣告大小調整柵欄式框架大小，瀏覽器也會相應調整柵欄式框架元素。
(上季也有提及) 支援影片和原生廣告空間	Fenced Frames 是否支援影片和原生廣告空間？	我們的回應與前幾季類似： PA API 支援使用依賴 iframe 的機制來轉譯影片。不過，我們尚未設計出可與 Fenced Frames 相容的影片和原生廣告算繪解決方案，這也是我們決定將 Fenced Frames 實施日期延後至 2026 年的原因之一。也就是說，如果合作夥伴決定立即強制實施「封閉式框架」，就無法支援影片和原生廣告。
顧問委員會	要求建立原生廣告供應商的顧問委員會，確保 Fenced Frames 導入作業符合業界標準。	在 2026 年之前，您不必在 PA API 中使用區隔框架。我們會利用這段額外時間，繼續與業界合作，設計及實施更廣泛的關鍵用途支援功能。我們先前曾表示，會在 Fenced Frames 要求前，先改進 Fenced Frames，以便透過 PA API 支援影片和原生廣告。根據我們的承諾，我們會與 CMA 互動並告知對方任何這類變更，並在要求使用 Fenced Frames 之前，持續與生態系統互動並收集意見回饋。我們在 W3C 和互動廣告局科技實驗室 (IAB Tech Lab) 等廣告標準組織的參與生態系統模式，可讓各類業界專家在設計需求出現前提供指導。
(上個季度也有回報) 不同平台的尺寸差異	回報在電腦和智慧型手機上，Fenced Frame 顯示的內容大小看起來不同。	這是已知的 Chromium 問題，我們正在調查中。歡迎在這個頁面提供更多意見。
API 改善	是否將 Fenced Frames 規定推遲至 2025 年，以便在 Privacy Sandbox 中支援原生廣告？	如同我們在公開公告中所述，我們將在 2026 年前實施「圍欄式廣告框」政策，因為我們發現許多人「積極配合」這項政策。當然，其中一個是原生廣告，但這不是唯一的因素。這項措施旨在讓生態系統有更多時間準備，以便支援主要用途，包括原生廣告，但不限於此。

Shared Storage API

意見回饋主題	摘要	Chrome 回應
成效	在工作單元外部，共用儲存空間的傳回時間似乎取決於工作單元中的活動。	我們正在這裡討論這項測試結果。
更廣泛的採用	共用儲存空間應是業界標準，可供各瀏覽器使用。	我們非常重視並樂於接受這項意見回饋。Chrome 會持續積極參與 W3C 論壇，包括 WICG，以支持提案、尋求意見回饋，並推動採用。
出價小程式	是否可以在 generateBid (已在 worklet 中執行) 中讀取 Shared Storage，根據跨網站資訊套用廣告決策 / 業務邏輯 (例如展示頻率上限)，並選取部分廣告？	否，出價工作片段無法讀取共用儲存空間。

CHIPS

意見回饋主題	摘要	Chrome 回應
分區容量	說明超過分區容量時的行為。	達到容量上限時，系統會從最近最少存取的 Cookie 中移除最舊的 Cookie，釋出記憶體，直到不再超出上限為止。開發人員會在後續要求中看到更新的 Cookie 標頭。
第三方 iFrame 存取權	嵌入的第三方 iFrame 內容會開啟相同第三方網站的新分頁/視窗，應與開啟者使用相同的分割 Cookie。	我們正在討論這個用途，歡迎您前往這個頁面提供更多意見回饋。
重複的 Cookie	如果有名稱相同的區隔 Cookie 和未區隔 Cookie，瀏覽器會決定傳送哪個鍵值？	如果有兩個名稱相同的 Cookie (一個已分割，另一個未分割)，您會收到兩個 Cookie，但很遺憾，無法區分兩者。相關的 RFC 規格可在這裡找到，其中說明不應依賴 Cookie 傳送順序。
功能建議	選擇啟用原點分割 Cookie。	我們正在審核這項要求，歡迎生態系統提供更多意見回饋。

FedCM