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

意見回饋報告 - 2024 年第 1 季

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 的 1:1 利害關係人會議記錄、個別工程師收到的電子郵件、API 郵寄清單和公開意見回饋表單。接著，Google 會由所涉及各種外聯活動的團隊進行協調，判斷與每個 API 相關的新主題相對普遍程度。

Chrome 會回應意見回饋的原因，來自已發布的常見問題、實際對利害關係人所提出問題的實際回覆，以及針對這項公開報告練習的具體立場。反思目前的開發與測試重點、我們收到的針對 Topics、Protected Audience 和 Attribution Reporting API 相關的問題和意見回饋。

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

縮寫詞彙表

阿拉伯聯合大公國: Attribution Reporting API
CHIPS: 具有獨立分區狀態的 Cookie
DSP: 需求端平台
FedCM: Federated Credential Management
FPS: 第一方集合
IAB: 互動廣告局
IdP: 識別資訊提供者
網際網路工程任務組 (IETF): 網際網路工程任務組
IP: 網際網路通訊協定位址
openRTB: 即時出價
加時: 來源試用
PAT API: Protected Audience API (舊稱「FLEDGE」)
PatCG: 私人廣告技術社群團隊
RP: 信賴黨
回應式網頁設計: 相關網站集 (舊稱第一方集合)
賣方平台: 供應端平台
TEE: 受信任的執行環境
UA: 使用者代理程式字串
UA-CH: 使用者代理程式用戶端提示
W3C: 全球資訊網協會
建構中: 正視 IP 失明

一般意見回饋，不使用特定 API 或技術

意見回饋主題	摘要	Chrome 回應
管理	希望能在公開留言期內，瞭解 Privacy Sandbox 的管理異動事項。	我們願意收到關於 Privacy Sandbox 重要發展 (包括日後 Privacy Sandbox 的未來管理) 的利害關係人意見回饋。
測試	除了目前由 Chrome 協助進行的 1% 測試之外，另有額外 3PCD 測試階段。	我們並不打算在 1 月初提供目前啟用 1% 的 Chrome 流量外的 Chrome 協助測試。
Web to App	網頁和應用程式之間必須完全互通，才能在行動裝置上使用 3PCD 模式。	我們同意支援應用程式和網站互通性，並推出跨應用程式和網站歸因評估，並探索網站到應用程式指定目標解決方案。不過，我們並沒有計畫延後行動版網站的 3PCD 作業。我們並未在 3PCD 年底達到 100% 的涵蓋率目標。相反地，我們希望 Android 的跨應用程式和網站評估相容性達到 3PCD 等級，且會隨著使用者更新手機而增加。
瀏覽器的角色	Chrome 似乎牽涉到廣告伺服器或賣方平台。	Chrome 不會採用廣告伺服器或賣方平台的角色。運用 PA API，Chrome 就能為廣告伺服器、賣方平台、需求端平台和其他廣告技術提供容器，運用自己的出價和評分邏輯。
使用案例指南	針對 Privacy Sandbox API 支援哪些用途，提供更明確的指南。	Privacy Sandbox 專案初期，開發人員說明文件著重於讓開發人員進入所有提案的討論和意見回饋程序。這意味著，這類內容的架構通常著重於瞭解專案背後的動機和概念，接著詳細介紹各項提案的早期開發與測試細節。在 API 正式普及後，這個做法能有效促進生態系統的合作，但隨著 API 正式普及，現在的開發人員主要負責以 API 為基礎，而非近期開發基礎的開發人員。我們之後會繼續採用以案件為基礎的文件方法。
本機開發環境	當 Cookie 為 SameSite=Secure 且後端由 CDN 前面時，我們要如何在本機 http://localhost 上持續開發及測試前端？	我們將在這裡討論這個問題，也歡迎生態系統提供其他意見回饋。
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，因為廣告技術公司希望能在更多流量上訓練模型，不必增加 3PCD 的流量。如此一來，Chrome 就不會在 Standstill 結束前顯示 3PCD 版本，才能完成這項操作。
不支援的用途	我們目前不會考慮自助式 DSP 用途。	許多自助式需求端平台會定期針對 API 提供公開意見回饋，其中幾個已定期公開意見回饋的需求端平台也將自己列為測試人員。此外，Chrome 也積極參與常見的自助式需求端平台主題，例如影片和第三方廣告伺服器。最近的每週 PA API 呼叫說明瞭這些主題。
來源試用	申請為希望以更積極的方式擴大測試範圍，並擴大 3PCD 測試涵蓋範圍的網站。	Chrome 目前正在開發第一方 OT，此機制將允許來源選擇採用 3PC 的逐步停用行為。註冊這項試用測試和部署權杖的頂層來源，會因為使用者裝置已啟用追蹤防護功能，封鎖 3PC。在與 CMA 諮詢後的 3PC 之後，此 OT 將提供寶貴機會，讓網站針對 3PC 的長期替代方案進行更廣泛的測試。我們目前正致力完成最終的 OT 推出時間表。
IAB Tech Lab 報告	根據互動廣告協會科技實驗室報告 (IAB Tech Lab) 提供你對 Privacy Sandbox 的意見回饋。	我們已在這裡詳細說明互動廣告協會科技實驗室 (IAB Tech Lab) 的報告。我們也瞭解「這份報告提出內容涵蓋零碎文件、商業規定、第三方稽核、產業認證、擴充性、資訊公開和未來管理方面的問題，而我們將與生態系統互動，並據此更新公開常見問題。」我們處理先前內容過於零散的說明文件。我們已處理此處「資料保證」一節所述的商業規定，部分 Google 廣告產品已分享這些做法。請參閱這裡的「演算法完整性保證」部分，解決第三方稽核的問題。在認證方面，我們希望這些機構能夠繼續認證產品 (包括使用技術，而非單純使用技術)。在擴充性方面，我們持續接受開發人員提供問題資料。關於資訊公開和管理，我們持續在 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 存取權。您也可以透過其他措施 (例如 Storage Access API) 重新啟用 3PC。有些技術措施 (例如 hasStorageAccess()) 可讓網站偵測 3PC 是啟用或停用狀態。不過，Chrome 無法協助網站瞭解重新啟用的原因。
追蹤保護功能	Chrome 的追蹤保護使用者介面功能可以使用多久？	在 3PC 淘汰之後，網址列中的追蹤保護使用者介面仍會持續顯示。
(另於前幾季回報) 跨瀏覽器支援	採用 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 會確認檔案是否存在，語法也正確無誤，但 Google 不會驗證廣告技術中與認證語言相關的行為。
Private Aggregation API 註冊程序	我可以檢查 Private Aggregation API 註冊狀態嗎？	註冊通過驗證後，註冊支援團隊一律會以電子郵件通知所有通過核准的報名者。如果註冊者在過程中有任何問題，可以聯絡支援團隊 (他們會在提交註冊表單後接洽)。支援團隊會回覆及回答問題，並提供必要的額外指引。

顯示相關內容和廣告

主題

意見回饋主題	摘要	Chrome 回應
(另於前幾季回報) 分類器時間軸和說明文件	您必須透過某種形式接受分類審查的機制，或至少讓對於分類模式如何判定類別有更公開透明的機制。	與前幾季相比，我們採取的措施並無不同：「網站分類錯誤會使得 Topics 信號對整體信號的實用性稍微降低，但比起其他其他網站，這些錯誤的網站更不會再受到損害。這是因為無論網站分類錯誤為何，網站的競價隨時都能獲得網站情境資訊，以便與正確主題相互比較。歡迎按這裡針對這個主題提供意見。」
Google Ad Manager	大多數網站都已嵌入「Google Ad Manager」，與較少網站的競爭對手相比，使用者主題相關資訊也會更加廣泛。	這項觀察規定是為了確保 Topics API 不會與 API 要替換的技術 (包括 3PC) 共用使用者資料。其他產業解決方案 (例如 Prebid) 可與 1 萬個網站搭配運作，讓市場參與者能透過自家技術呼叫 Topics API。另外提醒您，每週最多 5 個熱門主題的上限也可能有相同效果，因為市場參與者可能會在許多網站上使用 3PC 學習超過 5 個同等主題。
(也適用於前季度的報表) 不同類型相關人士的實用性	對網站價值產生及分配的價值，取決於網站的流量層級或內容專業程度。	我們瞭解，比起一般興趣網域，專門網站往往能提供更多更精細的主題。不過，並非所有專業網站都會提供商業價值。此外，這些動態也反映了現況，完全獨立於 Chrome 對 3PC 的支援結束。另外，在目前的環境下，某些網站比 3PC 廣告關聯性系統中的網站更有價值。此外，專業網站的相關主題對於彼此互有助益，因為有不同的廣告客戶可以在不同的主題組合中執行廣告活動，而出價邏輯則能觀察到各種主題所帶來的價值。
主機名稱與完整網址	根據網站主機名稱進行分類是否足夠有效？與完整網址相比，此做法可降低隱私權風險嗎？	我們考量除了主機名稱之外，還考慮使用資訊網址或網頁標題，並認為對使用者隱私和安全性的風險，可能遠大於這些資訊的潛在效益。使用者隱私權風險的例子包括，根據使用者主題的網址或網頁標題將機密資訊分類。
以主題做為信號	向我們索取指引，瞭解如何結合 Topics 和其他信號，以及有哪些其他實用信號。	廣告技術解決方案結合了所有可用的工具，例如機器學習、保護隱私權的 API 提供的保護隱私權信號，以及比對內容資料、廣告素材資料和第一方資料，可帶來最佳成效。相關詳細指引請參閱這裡。

Protected Audience API (舊稱 FLEDGE)

意見回饋主題	摘要	Chrome 回應
測試流量	測試人員回報參與付費 API 競價的出價回應量偏低。	1. 出價密度與參與 PA API 的生態系統息息相關，我們預計在 2024 年及未來將持續增加。廣告客戶、代理商和技術供應商最終有權決定廣告活動預算的分配方式。根據我們的預期，有些生態系統參與者可能會在 3PCD 之後，延後投資各種「無 Cookie」等各種「無 Cookie」解決方案。屆時，我們或許能提高廣告活動的預算分配比例。 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 可讓賣方根據顯示網址和主機名稱 (代表發布商的網域) 的組合擷取額外的即時信號。假設發布商想要強制執行這項規則，賣方可使用這項資訊來避免競爭品牌的廣告彼此重疊。
資訊有限	PA API 會減少發布商可用的資訊，例如廣告值、元件買方名稱、廣告主名稱、到達網頁網址、廣告素材大小、回應時間和出價率，以及出價落選。	我們已在這個頁面提出一些可能的解決方案，也歡迎這個生態系統提供其他意見回饋。
事件層級報表	事件層級報表 PA API 淘汰後，發布商就無法取得足夠的廣告放送相關資訊。	我們瞭解不同的報表用途，在事件層級報表停用後，我們必須繼續支援。因此，我們將事件層級報表的停用日期設定為 2026 年以前。從現在起，這段期間，我們會邀請積極參與的發展路徑，持續與生態系統互動，在保護隱私權的情況下納入新資訊以獲取資訊。
多個賣方平台	對於發布商來說，擁有多個賣方平台的附加價值會太低。	我們認為這是誤判，歡迎來自生態系統的其他意見回饋，瞭解此斷言的理由。
收錄活動	PA API 無法執行收錄活動。	我們已經收到意見回饋，表示賣方可以使用 PA API，向網路上的買方 (AKA 目標對象額外資訊) 顯示目標對象資訊。只要將 PA 的委派功能與業務協議搭配使用，我們相信今天就能達成這個目標。目前，我們正積極思考是否應考慮是否能進一步因應這類用途，以及該如何更妥善地因應。
買方選擇不採用	買方預設的拒絕選項可能會導致元件競價的結果降低。	無論是定義單一賣方還是多重賣方私下競價競價，賣方都必須在 AttributionConfig 的「interestGroupBuyers」欄位明確列出買方。這個數據是根據生態系統意見回饋，賣方與部分買方簽訂合約，而非其他買方，因此需要明確控管哪些買家能參與競價。歡迎前往 GitHub 進一步討論。
廣告化	無法根據 adsize 和 adSlotSize 進行預先篩選。	我們正在努力加入這項功能，詳情請參閱這裡。
支援排除 IG 指定	支援排除 IG 指定目標的 API：只在使用者不屬於 IG 時顯示廣告。	這個 GitHub 問題提議採用另一種執行排除指定目標的方式，讓瀏覽器直接告知廣告伺服器，特定廣告請求應套用哪些排除指定規則。雖然這看起來很有吸引力，但本提案的所有版本仍經過調查，都是讓伺服器能夠識別使用者身分。
《數位服務法》	發布商如何使用 Fenced Frame，並防止包含《數位服務法》所適用資訊的回應？	如同採用任何新技術，每家公司都有責任確保 Privacy Sandbox 的使用方式符合法律規定；Google 無法提供任何法律建議。我們針對各個 API 發布了內容豐富的技術說明文件，可協助您進行必要的法律評估。2026 年起，PA API 便不需要使用 Fenced Frame，讓相關人員有更多時間，確保自身使用這項技術時遵守所有相關法規。
說明文件	updateAdInterestGroups() 是臨時性的嗎？	我們尚未宣布要淘汰 updateAdInterestGroup，由於我們曾針對其他 IG 更新機制宣布過，因此日後可能會採用類似的隱私保護措施，例如同時使用 IP 位址和 Proxy 並在更新發生前增加一些延遲。
非 DSP 的買方中繼資料和邏輯擁有權支援	要求成為 DSP 的 Proxy。	我們發現這項來自非需求端平台區隔的意見回饋，正在考慮這項要求。我們也歡迎生態系統提供意見。
報告	要求為私人匯總報表中的信號值區 / 值新增自訂處理常式功能。	我們已經知道有這項功能要求，目前正等候進一步確認。歡迎到這裡提供更多對生態系統的意見回饋。
說明文件	是否可以提供連結，以便查看廣告客戶和 (委派) 擁有者網域需要設定的所有回應標頭？	我們預計會更新說明文件，以便釐清這個問題，歡迎生態系統提供其他意見回饋。
多重出價出價	透過架構 / 區塊圖提出工作流程說明 (訓練和推論)，說明多塔要如何在 PA API 環境中的理念。	感謝您提供寶貴意見。我們針對該主題有一些簡報，未來還應另外建立文件，
排除指定	Privacy Sandbox 可保護敏感目標對象和未成年人，避免他們看到不當廣告，例如賭博。	PA API 不會將顯示的廣告內容納入考量。使用 PA 的廣告技術開發人員可全權掌控。一般來說，發布商及其廣告技術供應商，可根據網頁的內容資訊和發布商規則組合，在 Protected Audience 競價中封鎖廣告素材。這反映了我們對於生態系統目前因應這些挑戰的方法。對買方來說，排除的 IG 指定功能可能也適用於某些法規遵循用途。
API 設計	Google 紛紛回退，希望廣告技術採用通用出價功能，藉此增加延遲時間，而非在不同 IG 中使用不同的 BiddingLogicURL。	在競價延遲期間，我們強調，如果對買家的所有 IG 重複使用相同的指令碼，會加快買方出價的執行速度。下文將詳細說明這裡的內容，以及其他改善 PA API 競價延遲的建議。
以客戶為主的行銷	針對以帳戶為基礎的行銷用途，PA API 並非簡潔的 API。	生態系統中，歡迎生態系統提供意見，說明他們認為無法實現的特定用途，並鼓勵生態系統參與者透過我們的公開 GitHub 存放區或每週通話繼續討論。
A/B 版本測試	在 GAM 中為發布商設定 PA API 後，目前所有廣告空間都必須啟用 PA API，或是完全不啟用。這會導致發布商無法執行 A/B 版本測試。	Google Ad Manager 提供的回應： Google Ad Manager (GAM) 中的 PA API 控制項會影響 GAM 的 API 使用資格 (前提是該 API 可供使用)。因此，發布商可以使用 Chrome 的權限政策功能執行 A/B 版本測試，禁止一部分流量使用 API 做為 A/B 測試的控制組。
機器學習	發布商需要進一步掌控 GAM 提議的機器學習技術使用方式。	Google Ad Manager 提供的回應：我們在 2024 年 1 月推出了控制項，讓發布商能停用機器學習節流器，並針對所有流量，與非 Google 賣方進行 PA API 競價。如要進一步瞭解這個控制項，請造訪說明中心。
(也適用於前季度報表) 頂層競價	可使用 Google 的發布商廣告伺服器，而不需要讓 GAM 控管頂層 PA API 競價。	Google Ad Manager 提供的回應：基於 Google 2023 年第 3 季報告所述，GAM 的 PA API 整合計畫，並未支援將 GAM 做為發布商廣告伺服器使用 GAM 的發布商，且無法掌控頂層競價。
資訊存取權	GAM 可存取競爭對手的重要資訊，包括內容相關競價價格、買方提供給 SSP 用於參與 PA API 競價的信號，以及來自賣方平台的設定參數。	Google Ad Manager 提供的回應：多年來，我們一直相當重視競價公平性，這包括我們承諾，發布商的任何無保證廣告來源價格 (包括無保證委刊項的價格) 都會在競價之前，先與其他買方分享，然後才針對法國競爭主管機關的承諾。針對私下競價 API 競價，在多重賣方競價結束競價之前，我們希望能維持我們的承諾，不會與其他競價參與者分享出價。明確來說，我們不會與任何元件競價 (包括我們自己的競價) 共同提供競價價格，詳情請參閱本次更新中所述。此外，我們不會在競價過程中使用元件競價設定的相關資訊，包括買方提供給賣方平台的信號。事實上，我們歡迎變更 PA API，讓元件賣家透過從頂層賣方模糊處理的方式指定元件競價設定。
組件競價	GAM 進行的是頂層競價，將控管哪些賣方平台為每個廣告商機執行元件競價。	Google Ad Manager 提供的回應： GAM 是發布商廣告伺服器，為賣方平台提供了輕量級 API。發布商可能與其合作，透過 Google 發布商廣告代碼 (GPT) API 指定元件競價設定。詳情請參閱這裡。如果賣方平台透過這個 API 提供元件競價設定，系統就會將這類設定納入該廣告空間的元件競價清單中。GAM 對包含的元件競價不做任何限制。任何想要執行元件競價的賣方平台都可以這麼做，前提是發布商允許他們在發布商網頁上執行必要程式碼。
組件競價	GAM 可以為每個元件競價得標出價套用特定未揭露的底價。	Google Ad Manager 提供的回應： GAM 多年來相當重視競價的公平性。為了維持公平的競價機會，我們不支援只對特定需求區隔套用的底價。這在 Google 產品中秉持一致的原則，日後參與競價 API 競價時也會如此。
第三方廣告伺服器	第三方廣告伺服器無法存取 Google 參與較高層級的競價，因此也無法在 PA API 環境中運用 Google 賣方平台廣告需求。	Google Ad Manager 提供的回應：目前 GAM 支援透過這裡所述的 API，與多個 GAM 賣方測試 PA API。目前不支援在其他頂層競價中以元件競價加入 GAM。
(另於前季記錄) 私下競價 API 競價的成效	測試人員回報參與競價 API 競價的延遲時間較長。	我們聽說過延遲時間的問題，因此我們在 PA API 中開發了多項功能，讓賣方平台能同時限制 DSP 的延遲時間，並做出改善，進而縮短延遲時間。我們最近更新了延遲最佳做法指南，進一步瞭解如何善用這些功能。我們也持續在開發新的延遲時間改善措施，部分訣竅請見此處。
(同時於前幾季回報) 影片顯示	支援使用 PA API 和 Fenced Frames 轉譯影片。	今年 1 月，我們發布了示範影片在私下競價競價中的運作方式，並詳細介紹替代做法。我們也看到生態系統中的玩家開始提議如何轉譯影片，適合與合作夥伴整合的合作夥伴，例如 GAM 的關於影片相容轉譯網址架構的提案，或是完整的 E2E 程序。此外，我們也傾聽大環境的意見回饋，瞭解如何提高採用率。GitHub 也提供了此類變更的詳細資訊。我們會持續積極與生態系統合作，找出在採用過程中遇到哪些障礙，並設法解決。
(另於前季報告) 資料處理政策	IG / PA API 的資料處理政策為何？	採用 PA API 設計時，IG 中儲存的所有資料或使用者的個人物品屬於 (i) 保留在裝置端，或者 (ii) 在受信任執行環境 (TEE) 內運作的出價和競價 (B&A) 服務中進行處理。無論是哪種情況，任一方都無法讀取相關資料，或是以任何方式在競價中出價。部分 Chrome 探索的隱私強化措施涉及與 Google 執行的 k-anonymity 伺服器互動。這項互動經過精心設計，可避免分享使用者相關資訊，並確保在 TEE 中運作，確保廣告生態系統中的資訊一致。 Google 承諾設計與導入 Privacy Sandbox 提案時，不會因自我偏好 Google 的業務而改變競爭情形，也會將對數位廣告以及發布商和廣告主的競爭影響納入考量。我們持續與 CMA 密切合作，確保我們的工作符合這些義務。
(另於前季報告) IG 生命週期	申請將 IG 壽命從 30 天延長至 90 天。	這類變更需要經過仔細評估，衡量該產業對 Chrome 使用者和其他利害關係人造成的影響。我們正在考慮這項要求，如有任何意見，歡迎按這裡。
(另於前幾季記錄) 模擬信號	除了模型訊號 (只能編碼多媒體和點擊資訊) 之外，也要求新增欄位。	我們已按這裡回應這項意見回饋。我們正積極與業界夥伴合作，希望能瞭解他們對我們的提案的看法，目前也正在衡量業界這項提案的效益，以及 Chrome 使用者和其他利害關係人受到的影響，
reportWin() 中的額外資料	根據 3PCD 之前的目前限制 (12 個)，在 reportWin() 中提供其他位元。	我們正在研究支援這個使用案例的方法。我們正在研究一些方法，協助確保我們制定長期的隱私權計畫，請花一些時間。
競價設計	每次競價都會傳回顯示網址和相應分數。	我們會考慮在單一私下競價競價中，分享多個顯示網址和相關分數，但基於隱私權考量，我們並沒有實行。我們瞭解，您希望能避免在單一頁面上多次向使用者顯示同一則廣告，並歡迎到 GitHub 進一步討論。
reportWin	reportWin() 函式中可記錄任意欄位。	這項調整已在今天的測試期間生效。Chrome 停止支援 3PC 後，for DebuggingOnly 版本的 API 會遷移，以啟用向下取樣偵錯功能 (詳情請參閱這裡)。
元件賣家	具備用來計算自家曝光和其他事件的獨立機制，且只能仰賴廣告技術的報表。	這項功能要求已排入佇列，以便進一步發掘。我們預計在 Chrome 促成的測試期間無法解決這個問題。
單次點擊出價計費	在私下競價 API 中實施單次點擊出價計費。	我們正在考慮這裡提出這項要求，而我們目前視這項要求提供建議，解釋如何搭配目前的 API 介面實作。
browserSignals	將 IncomingBidInSellerCurrency，用於回報賣方的 BrowserSignals 規格。	我們正在考慮這項要求，如有任何意見，歡迎按這裡。
非 DSP 的買方中繼資料和邏輯擁有權支援	目前的 API 設計可能會導致產品層級的指定舊訪客廣告活動出現大幅轉變，因此廣告活動必須遷移至同時以 DSP 和 DCO 供應商身分運作的平台。	我們會討論這個問題，歡迎點選這裡提供更多意見回饋。
非 DSP 的買方中繼資料和邏輯擁有權支援	舉出 DSP 不是 IG 擁有者的例子。	我們瞭解非出價者希望使用 IG 的部分功能，而非其他功能。我們正積極評估是否能解決這些用途，歡迎在這裡提供更多意見回饋。
逾時控制項	發布商應能指定 IG 可參與事件的數量，以及頂層逾時 / 全域逾時。	我們瞭解，希望能在頂層和元件賣方之間提供強化的逾時控制項和瀏覽權限，因此我們考慮了這項要求。
多種廣告大小	為多重廣告大小用途提供 PA API 支援。	我們正在考慮這項要求，也歡迎生態系統提供意見。
說明文件	是否有任何 IG 屬性受 k-anon 影響？	我們已經在這裡回覆這個問題。
偵錯	改善 PA API 的偵錯功能。	我們瞭解，健全的偵錯工具對使用 PA API 的開發人員來說至關重要。為了提升開發人員體驗，我們致力於探索如何以更有效的方式整合 .well-known 檔案擷取作業與開發人員工具。我們的目標是在開發環境中提供更廣的瀏覽權限和疑難排解功能。我們將在這裡進一步討論這個問題，如有任何意見，也歡迎提出。
標籤	模式 B 實驗組標籤的所有使用者是否均已啟用 Privacy Sandbox API？	Chrome 實驗群組指派作業是由隨機決定，且不受使用者設定的 Chrome 設定影響。雖然這些 API 可提供給特定實驗組 (例如 treatment_1.*) 的使用者使用，您也可以透過 Chrome 設定修改或停用這些功能。模式 B Control_2 群組：如果納入這個群組，其中的 Privacy Sandbox 關聯性和評估 API 就會停用，且使用者無法在 Chrome 設定中覆寫這項設定。
API 使用方法	呼叫 reportWin() 和廣告顯示時是平行還是依序進行？	系統會在 runAdAuction() 完成時直接呼叫 reportWin()。同時，當競價結果置於 iframe 或 Fenced Frame 中時，系統可能會開始顯示廣告程序。reportWin() 完成執行且廣告開始顯示後，系統就會擷取傳送至 sendReportTo() 的網址。
(另於前季度報告) A/B 測試支援	要求支援 PA API A/B 測試。	請按這裡討論這項要求，如有任何意見，也歡迎提出。
流量型態	由 Google 負責透過 KV 伺服器管理必要決策的提案沒有幫助，因為賣家無法與後端互動，導致流量塑造困難。	如 GitHub 問題中所述，揭露個別需求端平台是否有 IG 可能造成使用者數位指紋採集。我們針對這個問題提供了其他替代方案，並且願意提供更多建議。
流量型態	快取機制大幅增加複雜度，讓需求端平台無法得知要出價的實際流量型態。	單純提供的快取機製做為建議。廣告技術可以選擇採用這些建議與用途。如有需要，我們也歡迎您前往這裡查看更多相關討論。
標籤	在向買方和賣方信任伺服器提出的要求中，Chrome 應以參數的形式分享標籤。	這個要求似乎是合理的，因為要求範圍似乎廣泛，符合負責任的 IG 資料使用率目標。不過，我們正在考慮這項要求，並經過內部審查，並在討論的過程中針對這項案件提供公開更新資訊。
API 使用方法	在「給第三方測試的其他 CMA 指南」文件中清楚說明「control_1」群組。具體而言，某些疑慮可能會誤解，比如要求所有 Privacy Sandbox API 一律從 Control_1 中排除。	我們已經在這個 GitHub 執行緒中表達了看法。不過，我們無法與 CMA 協商，建議你直接向 CMA 提出有關檢測指引的解釋。
API 使用方法	重新導向至其他資源時，Chrome 是否允許在空白網頁上呼叫 joinAdInterestGroup() 嗎？	如果使用者造訪某些網站，網站擁有者可以將呼叫 joinAdInterestGroup 的功能委派給第三方。這項委派功能可讓第三方建構 IG，不必透過空白頁面新增任何重新導向方式。歡迎針對在重新導向的過程中建構 IG 的特定原因提供意見回饋，而非使用預期的委派機制。
API 使用方法	廣告交易平台應該要能將 IG 寫入與其合作的發布商所擁有的網頁，並將 IG 出價的權限委派給任何指定買方或需求端平台。	我們已收到意見回饋，正在評估這類要求是否可行。我們也歡迎生態系統提供意見。
API 使用方法	如果沒有人贏得 PA API 競價，系統就不會顯示偵錯損失通知。	Chrome 的 reportWin 和 reportResult 函式是專為競價 (PA) 系統中的事件層級勝出報表而設計。在私下競價競價期間所有出價遭拒的情況下，由於無法判定勝出者，因此預期不會叫用這些函式。 Chrome 近期更新或許能解釋為何傳遞至 forDebuggingOnly.reportAdAuctionLoss() 的網址，但開發人員工具並未顯示在開發人員工具的面板中。建議你使用 Chrome Canary 或開發人員版來驗證這項功能。
API 使用方法	從 generateBid 傳回的 adCost 是否為負數 (已隨機四捨五入為 2 位元組)？	AdCost 是指從 generateBid() 到 reportWin() 的廣告客戶點擊或轉換費用。這個值可以是空值或雙精度浮點值。系統會忽略並略過負值。傳遞後，值會以隨機四捨五入的方式進位。
API 改善	是否可以使用可信任且加密的執行伺服器 (而非 Chrome 瀏覽器) 處理指定目標 / 同類群組 / 歸因和競價？	建議您探索以 TEE 為基礎的元件與 PA API 中的選項 (例如 KV 伺服器和 B&A 服務)，以及以 TEE 為基礎的歸因報表與私人匯總元件 (例如「匯總服務」)。
API 改善	Privacy Sandbox 競價回應是否能做為出價回應 (例如標頭出價)，而非廣告回應 (例如廣告代碼)？	這類變更徹底改變了 PA API 的隱私權屬性，這並不是我們考慮的方向。
發布商控制項	發布商可以在自己的網頁上封鎖 PA API 廣告素材嗎？	Chrome 提議即時掃描廣告素材，但目前還未開放測試。雖然我們尚未推出這項功能，但我們發現多數賣方平台建立的解決方案來提供此功能。
API 使用方法	每個買家信號的大小限制為何？	在 Chrome 中，PerBuyerSignals 具有經典的尺寸限制。主要限制在於資料保持 JSON 序列化，不會造成過多記憶體消耗。不過請注意，如果每個買方信號非常複雜，可能會對成效造成負面影響。您也可以透過 directFromSellerSignalsHeaderAdSlot 傳送 PerBuyerSignals，這個方法會在標頭中傳輸 PerBuyerSignals，且整個標頭回應的大小上限為 10 KB。此外，個別伺服器可能會對標頭大小上限設下限制。
說明文件	必須變更 generateBid 中呼叫 RegisterAdBeacon 的說明文件。	這份說明文件已在 2 月 17 日更新。
API 使用方法	reportEvent 如何從多個註冊選項中選擇正確的信標網址？	每次競價都會產生個別的設定，因此會產生一份獨立的報表對應。個別競價 (及其產生的影格) 是完全獨立的，不會共用資料。如要進一步瞭解這個主題，「圍欄頁框廣告報表」一文將進一步說明。
Chrome 使用者介面	在 Chrome 開發人員工具的「應用程式」->「興趣群組」分頁中新增篩選器，即可按照 IG 擁有者 (或 IG 名稱) 進行篩選。	我們正在評估這項要求，歡迎生態系統提供意見。
無頭 Chrome	在無頭 Chrome 中支援 PA API	有一些與 Chrome 連結的 PA API 元件 (例如向 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-anonymity 系統中重複提交同一個物件的「Join」要求？	我們瞭解並感謝您持續討論瀏覽器 ID 導入 k-anonymity 系統的方式。我們瞭解，這類 ID 可能對隱私權造成的潛在影響，有所疑慮。雖然我們最初的導入方式採用了低熵 ID 做為反濫用機制，但我們正積極尋找其他做法 (例如匿名計算權杖)，在維持系統完整性的同時，顧及使用者隱私。我們致力於尋找解決方案，在負責任的資料使用方式與完善的隱私保護措施之間取得平衡，同時也歡迎研究社群持續與研究社群交流。我們對這個網頁進行討論，也歡迎您提出其他意見。
API 使用方法	AMP (Accelerated Mobile Pages) 支援 PA API。	AMP 目前不原生支援 PA API。如果 AMP 支援是優先要務，我們也歡迎生態系統提供意見。
API 改善	建議您從 k-anonymity 檢查中移除類型。	我們正在仔細評估這些意見回饋，或許能將 k-匿名性要求結構調整至最佳狀態。我們瞭解合併參數和可能整合類型的建議，以簡化程序。我們的目標是確保其效率及可維護性，同時在持續開發隱私權解決方案的同時，也會評估所有選項。我們會在這裡討論這個問題，如有任何意見，也歡迎提出。
Chrome 使用者介面	要求低技術人員輕鬆查看及管理屬於 IG 的機制，包括選擇退出的潛在網站層級控制項。	我們深知提供容易使用的實用工具，以便瞭解及管理 IG。我們仔細考慮了多種方法，發現透過加入這類機制的網站來識別 IG，可在明確性和隱私保護之間取得最佳平衡。目前 IG 的全域管理功能位於 Chrome 設定中。我們會持續探索各種方法，進一步提升這區域的使用者體驗。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
API 安全性	即使在 Fenced Frames 環境下，PA API 是否能透過廣告素材廣告互動來避免隱私權外洩？	我們瞭解透過複雜的廣告互動，有可能導致資訊外洩的可能性。我們正積極調查 Fenced Frames、PA API 和潛在攻擊媒介之間的交互作用。降低隱私風險是我們的首要之務，因此我們致力開發完善的解決方案，兼顧創新與使用者防護措施。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
延遲時間	買方出價邏輯的 50 毫秒逾時期限是否實際？	我們瞭解，開發人員對於規格與出價邏輯的網路要求時間，可能存在不一致的疑慮。我們正在積極審查這些規格，以確保其準確性，並調查最佳的預設逾時設定，藉此在效能和可行性之間取得平衡。我們會在這裡討論這個問題，如有任何意見，也歡迎提出。
說明文件	這項規格可能在一段時間內造成錯誤，網站可以推論出廣告是否未達到 k-anonymity 門檻，並可能影響跨網站追蹤。	我們瞭解你提出的問題與潛在時間外洩問題有關。我們已經確認規格不一致，並已採取相關措施，確保廣告在競價前能確定 k-anonymity 狀態，避免廣告外洩。我們非常重視這類疑慮，因此會更新規範來反映這些異動。我們會在這裡討論這個問題，如有任何意見，也歡迎提出。
API 使用方法	在 PA API 內導入賣方平台封鎖清單的方式。	我們瞭解，我們需要採用由賣方平台管理廣告限制的機制。我們鼓勵您探索合適的解決方案，優先評估裝置端評估作業，並使用現有的廣告中繼資料保護使用者隱私，同時兼顧彈性。我們致力於與開發人員合作，找出 PA API 中的最佳做法。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
API 使用方法	別人能否讓瀏覽器以無法偵測的方式假裝 PA API？	我們瞭解，在目前的表單中，網站有權停用 PA API。我們正積極開發更多出價、排除指定目標等功能，以及 Fenced Frames 顯示功能，以加強隱私保護，並努力提供無法偵測的選擇停用選項。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
模式 A/B 測試	資料中心流量假定可以治療 1.1。	Chrome 團隊已和 GAM 團隊確認，這類流量現在已從實驗中篩除。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
API 使用方法	在 PA API 中導入 interestGroupBuyers 的效率和公平性。	我們深知長期以來對「interestGroupBuyers」欄位在 PPA API 競價的效率和公平性進行討論。我們認同在效率、隱私權和市場公平性之間取得取捨。雖然賣方需要管理與買方的業務關係，但我們積極研究如何最佳化比對程序。其中可能包含根據即時資料和混合模式進行的動態調整。我們會持續努力尋找解決方案，以維護使用者隱私為優先，並維護競爭激烈的廣告生態。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
Chrome 使用者介面	Chrome 的 IG 相關潛在記憶體疑慮和使用者介面清晰度。	我們瞭解對於在開發人員工具中顯示 IG 的疑慮。雖然目前的檢視畫面呈現了所有用於歷史追蹤的 IG 事件，但我們相信這麼做的價值，在於能夠更清楚地掌握儲存的 IG 目前狀態。我們將探討最佳化調整項目和潛在的使用者介面改善項目，進一步強化開發人員的深入分析資訊。關於記憶體管理，IG 實作旨在防止記憶體流失，但我們會持續監控及最佳化資源用量。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
說明文件	原始張貼者嘗試直接在「joinAdInterestGroup」函式的「sizeGroup」欄位內使用已命名的廣告大小，就會發生錯誤。並想瞭解這是否是預期的行為。	我們識別出「joinAdInterestGroup」函式中的簡化廣告設定。我們正積極努力解決這項限制，並預計在未來的更新中啟用這項功能。我們致力為開發人員提供靈活且高效率的廣告管理工具，而這些改進措施與我們的承諾一致。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
由 Chrome 協助執行的測試標籤	要求取得模式 A 與 B 的直接資料，以及 sendReportTo 中確切的標籤，以便我們持續追蹤實驗。	請按這裡討論這項要求，如有任何意見，也歡迎提出。
說明文件	向賣家的信任伺服器發出的要求中，是否有賣家的網域名稱以進行驗證？	我們知悉 Protected Audience KV Server API 說明文件中遺漏主機名稱參數原本遺漏的情況。我們希望向開發人員保證，賣家的網域名稱會自動加入賣家信任伺服器發出的要求中。這項功能對於完善的廣告驗證程序至關重要。我們更新了相關說明文件來解決此問題，並會繼續優先確保開發人員社群清楚公開相關資訊。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
API 使用方法	在廣告曝光追蹤呼叫中加入 IG 名稱的可行方法，以便製作報表。	我們致力依使用者隱私權原則，在必要時提供完善的檢舉機制。在追蹤廣告曝光時，納入 IG 名稱必須遵循 k-匿名性保護措施，防止身分辨識。我們會持續探索創新的報表解決方案，因應這些隱私權限制。我們將在這裡討論這個問題，如有任何意見，也歡迎提出。
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 時，我們是以使用者隱私為首要考量。雖然基於跨網站追蹤風險，我們無法直接回報個別出價事件，但我們提供「共用儲存空間」和「私人匯總」等機制。這些解決方案能讓需求端平台取得出價活動的匯總深入分析資料，並維護使用者隱私。
API 使用方法	在 reportResult() 中，從 sendReportTo() 擷取出來的擷取時間，只限於使用 forDebuggingOnly.reportAdAuctionWin() 註冊的擷取作業的 94%。	即使兩者的時間不同，系統也可能同時擷取這兩個網址。在某些情況下，系統會直接處理元件賣家的工作，並必須重新載入才能執行 reportResult() 函式。不過，無論是擷取評分邏輯和重新載入工作小程式所需的時間，也都不會影響 reportResult() 的 50 毫秒逾時時間。請注意，在需要重新載入工作小程式時，Chrome 會使用快取標頭來定義擷取行為。如要進一步瞭解私下競價競價的階段，請按這裡。
K 匿名	要求確認 interestGroup 的名稱不會影響廣告放送的 k-anonymity。	Instagram 擁有者網址、出價指令碼網址、廣告素材網址和廣告大小的元組必須在過去一段時間 (w) 達到指定的門檻 (k)，才會被視為 k 匿名廣告素材。k-anonymity 狀態會定期更新 (p)。
Chrome 使用者介面	提議提供許多 MVC、ORM 等架構提供的「內部能見度」類型。舉例來說，一開始先將所選內部事件記錄在「開發人員工具」>「應用程式」>「應用程式」部分中的新面板	我們會在這裡討論提案內容，歡迎提供更多寶貴意見。
Chrome 使用者介面	彙整開發人員工具 IG 後不會顯示優先順序相關元素。	我們曾在這裡解決這個問題。
API 改善	建議您讓廣告素材廣告伺服器追蹤自己的事件。是否可以設定允許的追蹤網域清單？	我們已經在這裡分享提案，也歡迎您來自生態系統的其他意見回饋。
API 功能要求	PA API 可以擴充為支援非即時出價媒體交易，並維持廣告放送和多媒體廣告活動最佳化工具等重要用途嗎？	我們將在這裡討論問題，歡迎提供其他意見回饋。
發布商競價逾時	發布商必須掌控競價期間，以免錯失曝光，特別是在標頭出價設定中依序選擇廣告時。	我們瞭解讓發布商精確掌控廣告競價逾時的重要性。我們正在積極探索如何導入全域競價逾時機制，可能位於「auctionConfig」物件，並審慎考慮遇到的特殊情況。這項功能的目標是為發布商盡可能提高曝光供應率，而我們也會繼續與社群合作，尋找最合適的解決方案。我們將在這裡討論問題，歡迎提供其他意見回饋。
API 改善	目前 PA API 中的 IG 設計會導致因 displayURL 過長而產生大量的中繼資料。測試人員希望為這些網址壓縮來提高效率。	我們瞭解最佳化 Instagram 中繼資料大小非常重要，對於注重效益的廣告競價尤其重要。我們認為以範本為基礎的解決方案壓縮轉譯網址可以帶來顯著的潛力。我們會仔細評估建議的範本設計，並確保實作的解決方案包含強大的濫用防範機制，以維持瀏覽器穩定性。與網路標準社群合作制定出最佳方法，記住這些考量，仍是優先要務。我們將在這裡討論問題，歡迎提供其他意見回饋。
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 競價小程式會改為標準 Worklet 類型嗎？	由於隱私權和安全性相關規定各有不同，因此這些小程式與標準瀏覽器 Worklet 類型有極大差異，因此我們預計這些小程式很快就會成為 HTML 規格中的標準 Worklet 類型。我們致力於加強開發人員資源，針對競價工作小程式的實作和執行環境提供清楚的說明，讓 Privacy Sandbox 參與者更容易取得這些資訊。我們在這裡進一步討論了相關細節。
自備伺服器 (BYOS) 金鑰值 (KV) 伺服器	雙方或許可以透過 BYOS KV Service 設定中的 KV 服務查詢，學習使用者彙整的多個 IG (由同一擁有者拍攝)。	但當 KV 伺服器在 TEEs 中執行時，我們就無法這麼做，而我們可以確定這些伺服器符合已發布的信任模型。
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 和 GCP) 已設計並實施了緩解措施，以降低員工在內部存取的風險。如要進一步瞭解地端部署支援，請參閱下文。我們提到，執行雲端服務的費用比地端部署廣告技術資料中心高。我們無權評估這些陳述，但歡迎對成本提出其他意見，並繼續評估 TEE 支援方案以擴大服務規模。
TEE	支援非公用雲端環境中的 TEE	我們的回應方式與前季類似：除了公有雲式解決方案之外，我們會持續探索更多選項的支援，但我們目前並未打算支援地端部署 TEE。在這個階段，由於 Privacy Sandbox 安全性要求，以及地端部署部署項目帶來的重大挑戰，我們認為持續擴大及改善雲端式部署 (例如在 AWS 以外的上支援 Google Cloud) 對這個生態系統最有幫助。不過，當隱私權和安全性限制下，我們更歡迎您提出其他意見，說明為何在必要和可行情況下必須進行這類要求。
其他雲端服務供應商	支援其他雲端服務供應商	我們隨時樂意為其他雲端服務供應商提供建議，不過我們目前也至少計劃在強制執行 3PCD 的情況下，支援 GCP 和 AWS。詳情請參閱這份說明。
B&A 服務 API	Google 對 B&A Services API 的看法為何？和 Chrome 瀏覽器上的 Protected Audience 裝置競價優先順序會高於或低於嗎？	我們的回應方式與前幾季類似：我們會持續努力採用目前的裝置端出價設計。該公司提議採用 B&A 服務來探索可能的解決方案，以支援部分使用情境，這些情境可能包括裝置的運算能力或網路速度可能受限。
標準化	B&A 服務尚未經過標準化程序。	B&A 服務提案處於標準化程序的一個階段，我們十分熱衷於協助達成該目標。提案開始 (根據先前的提案) 公開發布，透過 W3C 廣泛公開討論，讓感興趣的開發人員開始試用並提供意見回饋。這是網路功能開發的常見模式，如這裡的網誌文章所述。
KV 伺服器	針對內容 / 內容相關廣告 / 網站指定，向買方的 KV 伺服器公開完整網址。	歡迎前往這裡討論這項要求，也歡迎生態系統提供其他意見回饋。
說明文件	GitHub 上所提供的「可信任/強制執行元件與選用元件」說明文件，可能會讓某些擁有自己一組部署映像檔和基礎架構的廣告技術產生混淆。	我們正在改進「可信任/強制實行的元件與選用元件」說明文件，並期待在需要優先處理哪些工作時，聽聽這個生態系統的意見。
API 改善	KV 伺服器呼叫的 HTTP 狀態碼也會在 ScoreAd() 函式中使用做為參數。	我們正在評估這項要求，歡迎生態系統提供意見。
說明文件	提供詳細資訊，說明系統如何在 UDF 執行作業中，精確處理 JS 和 WASM 工作負載。	我們正致力提供這項資訊，歡迎您前往這裡提供更多意見回饋。
說明文件	要求更新存放區名稱。	將存放區重新命名為「Protect-auction-key-value-service」。這與上述所屬服務的收集行為一致，其中也包含其他存放區，例如 Protected Audience Services 相關討論，以及 Protected Attribution Services 說明文件存放區。
說明文件	移除 Bidding_auction_services_gcp_guide.md 中 Cloud debugger API 的參照。	我們更新說明文件並移除參考資料。
API 使用方法	KV 查詢造成的延遲時間超過 50 毫秒。大約需要 100 毫秒。對於其他賣方成效良好的部分，Google 有沒有提供任何指引？您對如何評估逾時和時間有任何建議嗎？	KV 伺服器呼叫會在指令碼執行器的環境 (也就是 Chrome 瀏覽器中的特殊受保護環境) 內發生。這項功能的用途是保護這些指令碼執行器中的資訊，不受任何非 API 存取影響。詳情請參閱這裡的說明。
API 使用方法	KV 伺服器在特定時間內是否有回應？	賣方可以在競價設定中指定「perBuyerCumulativeTimeouts」欄位。這段逾時時間包含擷取受信任出價信號所需的時間。
延遲時間	Privacy Sandbox 團隊如何解決延遲問題？	如要瞭解相關策略，確保延遲時間未超過許可上限，請參閱這篇文章。

評估數位廣告

Attribution Reporting (和其他 API)

意見回饋主題	摘要	Chrome 回應
手動廣告活動最佳化	ARA 不支援手動廣告活動最佳化。	我們與廣告技術討論這個情境，並展示了 ARA 如何用於手動廣告活動最佳化。ARA 可讓您自訂廣告技術，並能靈活調整，以解決各種廣告技術用途。我們根據不同的彈性事件層級設定，提供了一些建議；此外，他們也使用事件層級報表搭配摘要報表，減少雜訊造成的影響，並滿足手動和自動最佳化的需求。對於 ARA 設定的自訂功能與彈性，我們也歡迎其他生態系統意見回饋。
轉換類型	Google 只允許使用八種轉換類型，	我們已導入大部分的彈性事件層級報表，讓廣告技術人員可以靈活調整報表回溯期數量、歸因報表數量，以及可使用的少量觸發事件資料。廣告技術可以選擇設定，以便評估最多 32 種轉換類型。
可匯總報表事件限制	每份可匯總報表必須至少有 20 個轉換事件數，不適用於預算有限的廣告客戶。	每份可匯總報表所需的轉換事件沒有數量下限。此外，還有幾項設計決策可為小型廣告主提供最佳的可匯總報表，例如變更追蹤的主要結構 / 維度、測試不同程度的分析頻率、測試更長的批次批次作業頻率，以及測試不同評估目標之間不同貢獻的預算摘要。
即時資料	根據需求端平台提供即時資料 (例如點擊、工作階段和轉換)，需求端平台用來調整出價策略並提高廣告活動成效，反而會取代現有功能。	即使有 ARA，點擊和工作階段仍會保持即時，而且就算有 3 個點擊，轉換仍會保持不變。
遺漏欄位	「完整彈性事件推出作業」缺少規定：i)「貨幣」欄位和「ii) 訂單 ID / 交易 ID」欄位。	在完整的彈性事件層級報表中，我們並不打算支援「貨幣」欄位或「訂單 ID」/「交易 ID」欄位，因為目前已有方法透過目前的事件層級報表進行這項操作。我們願意對這些欄位提供其他意見，日後如果還有其他用途需要用到，我們也會重新考慮。如何使用 ARA 目前的設計來測量貨幣和訂單 ID 類型資訊： 1.根據意見回饋，貨幣則取決於使用者的地理區域，這個地理區域可新增為 source_event_id 的一部分，做為系統使用的貨幣。 2.根據反饋，我們需要「Order 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 使用方法	有機會統整歸因事件與所有參與者分享，對賣方平台、需求端平台等有益的參與者。	我們計劃與廣告技術人員同步，進一步瞭解他們的意見回饋及遇到的任何限制。
測試流量	所有 Chrome 穩定版的測試流量 B 是否都穩定？	加入實驗的群組不會受到 Chrome 設定影響，不受 Chrome 設定影響。
說明文件	支援像素 ARA。	我們已發布相關資訊，說明如何支援這項用途，並歡迎這個生態系統提供其他意見回饋。
API 使用方法	如未以最後一次接觸點完成轉換，ARA 可能無法將 ARA 歸入電子商務平台上的第三方賣方來源。	公司可以使用篩選器，避免歸因錯誤發生 (因為系統沒有產生任何轉換報表)。此外，我們也正在開發一個預先歸因篩選提案的提案，以協助這一使用情境。
瀏覽器支援	不同的瀏覽器是否支援 ARA？	歡迎其他瀏覽器採用 Privacy Sandbox API，並持續花時間討論我們在 W3C 開放的方式。我們明確指出互通性是運送 ARA 和 ARA 的設計目標，是確保在瀏覽器不受瀏覽器限制，並為具有不同隱私權立場的供應商提供彈性的供應商指定值。其他瀏覽器，在提供數位 ID 和跨網站 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 值，根據自身用途找出轉折點並提供意見回饋。如果 Epsilon 的值範圍有任何變更，我們一定會事先告知廣告技術人員。
API 改善	支援以下用途：廣告客戶可在 trigger_data 欄位中插入 ID，以便與外部客戶關係管理資料進行比對，以便廣告客戶驗證轉換品質。	我們正在討論這項要求，如有其他意見，歡迎按這裡。
API 使用方法	如何將重新導向網址視為到達網頁網址。	廣告技術可以採取下列任一做法： 1. 在目的地欄位中輸入最終到達網頁網址； 2. [目的地] 欄位最多允許 3 個網址，您可在欄位中輸入多個網址。這兩種選項都需要知道最終到達網頁網址。我們在這裡進一步討論了相關細節。

匯總服務

意見回饋主題	摘要	Chrome 回應
主要探索機制	要求金鑰探索機制	我們提出了關鍵探索提案，也歡迎業界對這項提案提出意見回饋。
API 使用方法	匯總服務觀測能力的藍圖	我們正在推行相關選項來協助提升觀測能力。歡迎按這裡查看來自生態系統的意見。
API 改善	要求可重新查詢報表。	匯總服務正在規劃重查詢提案，由廣告技術人員為每份報表分配轉換策略。這可能會為每項查詢產生更多雜訊，但可讓廣告技術重新查詢內容並維護隱私權。
API 改善	要將多個來源與同一個 AWS ID 建立關聯。	匯總服務現在可讓多個網站使用同一個雲端帳戶 (GCP 或 AWS) 啟用。如此一來，廣告技術人員就能使用相同的匯總服務區域，處理來自相同網站的多個網站和多個來源的報表。
API 使用方法	可匯總批次失敗時，請確認預算是否已用完，以及能否重新處理該批次。如果匯總服務發生重複報表的預算錯誤，其餘報表會遺失。如何盡量降低損失？	一般情況下，如果整個工作失敗，預算就不會使用。萬一預算用盡的情況發生罕見錯誤，廣告技術就可以要求恢復預算。如果廣告技術經常發生工作失敗和預算用盡錯誤，應確認批次處理策略。如要瞭解如何正確批次處理及避免重複製作報表，請參閱這篇文章。歡迎前往這裡，針對預算復原功能提出意見回饋。
API 使用方法	如果使用 Private Aggregation API 搭配這篇文章所述的觸發條件，系統會在每次競價產生可匯總報表。匯總服務的資源調度功能為何？	匯總服務本身並未限制批次或報告的鍵數量，而是由於需要的記憶體容量，因此目前無法限定 10^14 份報表和 10^12 組鍵的數量。我們的規模調整指南指出已經過測試的範圍，並會針對預期負載和支援的雲端 VM 執行個體類型，建議可以發揮最佳效能。
資料處理	如果加密資料含有個人資訊，向匯總服務提供加密資料的法律協議為何？您能指出是否保證協調者不會存取加密資料？	匯總服務不會與協調者共用已加密 / 使用者資料。匯總服務使用協調器進行金鑰管理和會計作業。如需協調者的詳細資訊，請參閱這篇文章。針對會計，匯總服務只會與 PBS 共用共用 ID 和報表來源，以便評估預算。我們推出多個網站後，會將來源替換為網站。請注意，匯總服務是在 TEE 中執行，因此只有 TEE 才能解密用戶端的報表。在 TEE 中執行的程式碼是由外部方開放原始碼及稽核，詳情請參閱這個頁面。

私密匯總 API

意見回饋主題	摘要	Chrome 回應
API 使用方法	可元件銷售人員將報表傳送到 TEE 中的多個匯總伺服器。	目前的 Private Aggregation API 狀態不支援這項功能。我們已在這裡進一步討論這個問題。
說明文件	Google 試用期使用的 epsilon 值是多少？	對於 Private Aggregation API，匯總服務查詢中指定的 ε 值會對應 2^16 的 L1 貢獻預算，系統以累計 10 分鐘為單位強制執行。此外，還有 2^20 的「backstop」 L1 貢獻預算是以連續 24 小時強制執行。基本上，Privacy 參數會以 10 分鐘為基準，目前為 16 網際網路應用程式，時間為 24 小時至 144 小時。匯總服務目前支援測試作業範圍 (最多 64)，以利系統運用不同的匯總策略，針對私人匯總策略和其他相關 API API 提供意見回饋。我們會持續收集測試人員的意見回饋，並新增相關功能，改善隱私預算的運用效率，因此計畫未來會重新審視可允許的最大價值。

限制惡意追蹤

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

本季沒有收到任何意見回饋。

IP Protection (原稱 Gnatcatcher)

意見回饋主題	摘要	Chrome 回應
解決方案 ID	Privacy Sandbox 需要更發聲，才能確保廣告主通常無法透過 IP 建構的解決方案 ID。	Privacy Sandbox 明確指出，我們的目標是減少跨網站追蹤。我們的公開計畫延伸到 Cookie 之外，已在 privacysandbox.com 和 GitHub 上公開。我們致力於減少跨網站追蹤，包括根據 IP 位址判斷。然而，是否要主動啟用跨網站追蹤，完全取決於個別網站。這個時代更嚴謹地審查法規遵循，讓個別公司瞭解服務供應商採取的做法。
Chromecast	IP 保護功能會影響 Chromecast 或其他 Chrome 裝置嗎？	目前沒有 Chromecast 裝置的 IP 保護計畫。
IP 保護清單	如果有第三方判定為可能使用 IP 位址進行網站跨網站追蹤的第三方名單，是否會發布這份名單？	清單一經敲定，就會發布。如這篇文章所述。

跳轉追蹤因應措施

意見回饋主題	摘要	Chrome 回應
單一登入 (SSO) 豁免	跳轉追蹤因應措施 (BTM) 如何驗證單一登入 (SSO) 用途是否符合豁免資格？	BTM 將由 Chrome 經驗法則停用。詳情請參閱這篇文章。
淘汰試用期	3PC 淘汰試用計畫的網站是否啟用 BTM？	不可以，BTM 遵循淘汰試用計畫所建立的 Cookie 例外狀況，詳情請參閱這篇文章。

隱私預算

如同 GitHub 說明和開發人員網站所述，Privacy Sandbox 提案不再主動考慮隱私預算。

強化跨網站隱私權界線

意見回饋主題	摘要	Chrome 回應
功能建議	系統會自動允許透過 RWS 存取 CHIP 和 / 或儲存空間分區，不需要 Storage Access API 和使用者互動。	我們正在考量某些功能可執行這項功能的優點和可行性，其中一項考量是跨瀏覽器互通性可能存在的缺口，也就是利用 Storage Access API 的 RWS 地址。其他瀏覽器目前尚未支援這項要求的功能。我們鼓勵開發人員針對這個問題提交用途，以利討論這個頁面。
移除不符規定的集合	從存放區中移除不符合規定集的程序為何？	我們正在製定相關程序，一旦有最新消息，就會立即通知您。
「違規處置流程」	不清楚 Google 在 RWS 違規處置過程中的主觀角色。	RWS 目前屬於進行中的專案，我們也持續收到新提交內容，因此我們正在嚴謹評估相關程序和標準。Google 同意，在提交規範中完整擬定了提交規範十分重要，日後我們會在提交指南中提供更多詳細資訊，以免混淆不清，造成混淆。我們致力將提交程序視為盡可能提高技術性，進而逐步淘汰人為介入處理，並完全仰賴自動化檢查。像這項 PR 需要更人為互動，因為其中包含我們預期不到的行為，但這些 PR 能讓我們找出更多自動化作業領域，並幫助我們修正規範，避免日後發生上述問題。
分享資料	要求網域擁有者在徵得使用者同意的情況下，要求第三方一併分享 RWS 資料的功能。	要求的功能已可透過 FedCM 等 API 和 Storage Access API 取得，使用者接受權限提示後，就能存取經過驗證的身分。生態系統中對於自己認為無法實現的特定用途，歡迎你提供意見。
其他儲存方法	儲存在本機儲存空間或工作階段儲存空間的資訊，是否也會被解讀為 3PC？	自 115 版起，在第三方環境中使用時，本機儲存空間、工作階段儲存空間及其他形式的非 Cookie 儲存空間已經在 Chrome 中分區。詳情請參閱這篇網誌文章。
相關集合限制	如果機構提交超過 5 個網域，卻「最多只能建立 5 個關聯網站」，會發生什麼情況？	這些組合可以透過 GitHub 程序接受，但瀏覽器 (Chrome) 只會將 Storage Access API 自動授權規則套用到前 5 個網域，並忽略其餘網域，如這裡所述。
find_robots_txt	find_robots_txt 檢查無法用於重新導向。	已在這裡提交修正方法。
使用者手勢	移除 accessStorage() 的使用者手勢要求。	這項要求的起源於與 requestStorageAccess API 的所有主要瀏覽器類似。歡迎您在這個 GitHub 問題中提供更多意見回饋和應用實例，協助我們排定這項要求的優先順序，並開放跨瀏覽器討論。
使用者手勢	在 Chrome 或 OS 重新啟動後，是否需要使用者手勢才能授予第三方儲存空間存取權？	可以，但我們歡迎生態系統提出其他意見，告訴我們是否應變更這項行為。

Fenced Frame API

意見回饋主題	摘要	Chrome 回應
adComponent	缺乏搭配 Fenced Frames 使用 AdComponents 的說明文件和彈性。	我們希望提供更多與這個使用案例相關的文件。此外，我們也支援使用 getNestedConfigs() 在 Fenced Frames 中加入廣告元件，詳情請參閱這裡的規格說明。
(另於前幾季回報) 顯示 adComponent	要求取得如何在 Fenced Frame 中顯示 adComponents 的程式碼範例。	如有需要，你可以在這裡提供部分程式碼範例。
第三方廣告驗證	根據 Fenced Frames 進行第三方廣告驗證時，扮演的角色需要更詳細的資料，特別是在內容相關/品牌安全方面。	目前，Fenced Frames 廣告報表允許需求端平台將曝光和競價事件層級資料傳送給第三方廣告驗證器，進行算繪後的品牌安全檢查和帳單。
可展開式廣告	要求支援可展開式廣告。	如果廣告需要在兩個顯示比例相同的情況下切換，且兩者之間沒有功能差異，嵌入程式可以使用第二個廣告大小調整 Fenced Frame，然後瀏覽器據此調整 Fenced Frame 元素。
(也適用於前季度報表) 支援影片和原生廣告空間	Fenced Frames 是否支援影片和原生廣告空間？	我們也提供了類似前幾季的回應： PA API 透過依賴 iframe 的機制顯示影片。然而，我們尚未設計解決方案來支援與 Fenced Frames 相容的影片和原生廣告，這也是我們決定將 Fenced Frames 違規處置延至 2026 的原因之一。換句話說，如果合作夥伴決定立即強制執行 Fenced Frame，該合作夥伴將缺少對影片和原生廣告的支援。
諮詢委員會	申請原生廣告供應商顧問委員會，確保導入的 Fenced Frames 符合業界標準。	自 2026 年起，PA API 便不需要使用 Fenced Frame。多出時間讓我們能繼續與業界合作，針對更多關鍵用途設計和實作支援服務。如同先前所述，我們會提前更新 Fenced Frame，其內容將持續支援透過 PA API 放送影片和原生廣告。根據我們承諾，如有任何這類異動，我們會與 CMA 合作並通知他們。在要求 Fenced Frames 之前，我們會持續與生態系統的意見回饋互動。透過 W3C 採用的生態系統參與模型和互動廣告協會科技實驗室 (IAB Tech Lab) 等廣告標準機構，各類產業專家都能在設計需要前做好準備。
(也於前季度回報) 各平台的大小差異	回報 Fenced Frame 中顯示的內容大小在電腦和智慧型手機上有所不同。	我們正在調查這項已知的 Chromium 問題。歡迎按這裡提供更多意見回饋。
API 改善	Fenced Frames 規定是否延後到 2025 年，讓 Privacy Sandbox 現可支援原生廣告？	如我們在 2026 年前發布的關於 Fenced Frames 違規處置公告所述，我們已瞭解到許多「配合 Fenced Frames 這個設計有多大的努力」。值得注意的是，其中一個是原生廣告，但不是唯一的因素。這項目標是為了提供更多時間，確保生態系統準備好支援重要用途，包括但不限於原生用途。

Shared Storage API

意見回饋主題	摘要	Chrome 回應
效能	工作小程式外的共用儲存空間回歸時間，似乎會因工作小程式中的活動而異。	我們會在這裡討論這項測試結果。
採用	共用儲存空間應是適用於各種瀏覽器的業界標準標準。	我們歡迎並確認這項意見。Chrome 會持續參與 W3C 架構 (包括 WICG)，藉此推動這項提案、徵求意見回饋並提升採用率。
出價小程式	是否能在 generateBid (已在工作資料夾中執行) 的 Shared Storage 中讀取共用儲存空間，以便根據跨網站資訊套用廣告決策 / 商業邏輯 (例如展示頻率上限)，並選擇一部分的廣告？	不可以，您無法在出價工作程式中讀取共用儲存空間的資料。

CHIPS

意見回饋主題	摘要	Chrome 回應
分區容量	說明超出分區容量的行為。	容量達到上限時，最舊的 Cookie 會從最近存取的 Cookie 中排除，直到記憶體用量超過上限。開發人員會在後續要求中看到新版 Cookie 標頭。
第三方 iframe 存取權	開啟新分頁/視窗的第三方 iframe 內容開啟新分頁/視窗後，應能存取與開啟程式相同的分區 Cookie。	我們會討論這個使用情況，也歡迎按這裡提供來自生態系統的其他意見回饋。
Cookie 重複	如果有分區 Cookie 和同名未分區 Cookie，瀏覽器決定要傳送哪個鍵/值？	要是有兩個 Cookie 使用相同名稱 (一個分區，另一個則否)，您就會收到這兩個 Cookie，可惜的是，您無法區分哪一個 Cookie。您可以前往這裡查看 RFC 規格，其中說明瞭 Cookie 的傳送順序。
功能建議	選擇啟用來源分區 Cookie。	我們正在考慮這項要求，也歡迎你前往這裡收到來自生態系統的其他意見回饋。

FedCM