Privacy Sandbox 關聯性和評估 API 常見問題的解答。
Topics 與賣方定義目標對象 (SDA) 有何差異？
Topics 和 SDA 都提供互補的資訊類型，發布商可全權掌控。我們相信他們不會彼此競爭。而是可同時或交互運作，或在不同的情境中運作，盡可能增加購買機會。透過程式輔助方式評估曝光時，買方會考量和使用許多信號，因此我們預期 Topics 會是其中一個考量因素。賣方先前並未在公開競價競價中納入目標對象區隔，因此會使用 Topics 的可能性。相反地，賣方將目標對象提供給廣告客戶、代理商或需求端平台的交易，並提供程式輔助交易。在這種情況下，賣方和買方會故意透過 SDA 交易。在這種情況下，主題可能用於下列一或多項情況：
- 銷售員運用 Topics 擴充目標對象定義
- 買方使用 Topics 做為出價信號
- 買方使用 Topics 驗證 SDA 是否正確
Protected Audience 是否讓 Google 掌控目標對象建立程序？
否。網站可以繼續在 Privacy Sandbox 內外建立自己的目標對象。網站在 Privacy Sandbox 中建立目標對象時，網站擁有者或選用的 Proxy 會決定誰可以建立目標對象、目標對象為何、這些目標對象的更新方式、這些目標對象的出價方式，以及是否要從目標對像中移除使用者。
Protected Audience 是否支援發布商建立的興趣群組？
需要。我們瞭解發布商擔心目標對象會加入採用 OpenRTB 的競價，因為擔心資料外洩。發布商可立即在 Protected Audience 中建立目標對象，讓出價者不必跨網站檢視個別發布商的使用者。我們很高興能繼續探索發布商可如何利用 Protected Audience 減少的資料外洩環境。
Protected Audience 競價如何強制執行廣告品質規則？
Protected Audience 競價有多種執行廣告品質規則的方式。每個項目都類似於目前賣方平台強制執行廣告品質規則的方式。其中一種方法是讓包含不明廣告素材的競價觸發廣告素材排入掃描佇列。我們已經收到許多意見回饋，表示賣方平台希望針對這個用途提供更完善的支援，並且正在設計一個機制，用來建立 renderUrls 的動態饋給，方便賣方平台稽核從頻外稽核，然後將資訊儲存在其鍵/值伺服器中。另一種方法是要求預先註冊廣告。和上一個情況一樣，廣告素材掃描完畢後，結果就會連結至鍵/值伺服器。之後當買方對該廣告素材出價時 (由廣告素材 ID 表示廣告素材 ID 可能採用與 OpenRTB 相同的格式)，賣方的評分邏輯就能在鍵/值伺服器中執行查詢，據此決定分數的方式。
Protected Audience 是否支援影片廣告？
需要。VAST 網址可傳入及傳出 Protected Audience。產生 VAST 網址後，賣方技術就可以協調如何包裝買方的 VAST 網址，再將網址傳送至播放器。在規定移至Fenced Frame (2026 年前) 並進一步加強使用者隱私保護措施之前，我們預計生態系統將參與設計討論，其中確實包含影片。
Protected Audience 是否支援原生廣告？
需要。JSON 網址可傳入和傳出 Protected Audience。當 JSON 網址傳送至轉譯程式碼時，賣方技術可以協調新增任何所需事件的方式，然後再將最終的 JSON 傳遞至轉譯程式碼。在需要移至 Fenced Frame (2026 年前) 的相關規定之前 (2026 年內)，我們預計生態系統會參與設計討論，其中可能包含原生技術。
Protected Audience 廣告顯示會對創新造成乾擾嗎？
不可以。顯示廣告的功能一直仰賴瀏覽器技術。這一點不會改變。 這可能是特別關注於日後需要搭配使用 Fenced Frames 與 Protected Audience 的計畫。這些計畫「在未來」的一部分，是因為我們希望 Fenced Frames 技術能夠支援生態系統革新，並在廣告顯示方面提供差異化優勢。感興趣的開發人員和公司仍有時間可以衡量 Fenced Frames 的方向，包括我們如何支援原生廣告。
Protected Audience 是否能在現今的傳統競價中，以精細的方式調整使用速度和出價評估做法？
Protected Audience 可讓買方即時選項，瞭解廣告活動的配速和預算。從廣告空間的角度來看，賣方可以提供有關網頁情境和其他資訊的競價信號給買方。如果賣方選擇傳送內容相關出價要求，買方也可以透過該機制取得廣告空間，並透過 perBuyerSignals 提供可用於產生 Protected Audience 出價的比對內容信號。早期採用者已經將機器學習系統連結至 Protected Audience。我們瞭解調整這些系統需要花時間，以便在 Protected Audience 環境中出價，但值得注意的是，您可以進行調整且相關作業已經執行。
OpenRTB 標準適用於 Protected Audience 嗎？
需要。這項工作將在 IAB Tech Lab 進行，由優秀的代表性需求端平台和賣方平台參與開發。我們似乎會將一部分的 OpenRTB 通訊協定，當做 Protected Audience 競價內的通訊標準，而我們也注意到早期採用者已著手打造這類機制。
Protected Audience 是否要求公司維持兩個不同的廣告放送架構？
否。Protected Audience 不需要維護兩個不同的架構。架構選擇由你自己決定線上廣告近幾年來不斷進步 系統運作的系統複雜也越來越複雜。讓使用者享有更安全的上網環境 不僅複雜，且需要運作廣告技術公司可以選擇維護兩個不同的架構，或將 Protected Audience 建構為搭配傳統競價的合併架構。
一旦有更多廣告技術公司支援 Protected Audience，傳統競價會發生什麼情況？
我們預期內容相關競價仍取決於各種原因，包括交易、非第一方目標對象廣告活動，以及許多其他比對內容情境。此外，如果沒有興趣群組，或 Protected Audience 中的出價未能達到底價或遵守廣告品質規則，這些事件也非常實用。
Protected Audience 競價是否與生態系統供應路徑最佳化 (SPO) 相輔相成，以減少廣告客戶與發布商之間的中介總數，以及/或重複特定廣告商機的重複交易？
不會。在 Protected Audience 中，勝出的廣告會在最多兩個賣方實體 (例如供應端平台 (SSP) 和發布商廣告伺服器) 傳遞；如果買方與發布商建立直接整合，則幾乎不會傳遞任何實體。
發布者仍可選擇使用多個中繼來複製同一個要求。Protected Audience 不應以這種方式互相影響。
為了不會洩漏跨網站使用者資料，Protected Audience 競價是在當今的伺服器對伺服器即時系統外進行。有些人可能會說這與廣告請求重複。要實現在技術層面上展現隱私 確實需要做一些取捨不過，長遠來看，生態系統可能決定在不使用傳統伺服器端競價的情況下使用 Protected Audience。這麼做有機會打造更優異的供應路徑。
Protected Audience 是否會降低現有流量型態基礎架構的價值？
據我們所知，每秒查詢數的異動在於，許多賣方平台會使用跨網站 ID 來判斷是否要傳送 DSP 請求。因此，跨網站 ID 的減少便會影響現有的流量型態技術。無論發布商是否想要執行 Protected Audience 競價，結果都一樣。
我們運用許多賣方平台探討流量型態，並找到多種解決方案，包括快取和依據內容進行篩選。我們預期開發人員將能透過私人匯總功能進一步掌握 DSP 出價的偏好設定，並據此進行篩選。
最終，部分依據跨網站 ID 建立的舊有基礎架構將不再有用。
Protected Audience 競價所產生的新要求是否會限制賣方平台的數量？
有些賣方平台向我們反應，容量並非問題，或從整合的角度來看，SSP 價值主張的重點內容並非問題。對於那些對於競價程序中的新呼叫有疑慮的賣方平台，我們已註意到這些公司已協助賣方平台，且有能力疑慮，並希望擴充這些服務來支援 Protected Audience。如果您希望我們協助您與其中一間公司聯絡，請告訴我們。
瀏覽器中有競爭資源時，Protected Audience 中的優先順序如何解決？
Protected Audience 一般遵循建構控制項的標準模式，可讓賣家決定出價工具可使用的時間和資源，並建構工具讓買家決定如何以最佳方式運用可用資源。目前這些控制項和工具已可供使用，但買方和賣方採用後將可徹底發揮效益。此外，Chrome 也持續努力改善競價速度 (例如 crrev.com/1190815、crrev.com/1199839、crrev.com/1201837、crrev.com/1198337、319.com)。
Protected Audience 如何解決延遲問題的疑慮？
過去，在 Protected Audience 之前，在伺服器發生即時出價的賣方會明確針對買方回應指定嚴格的逾時時間，以保持檢查延遲時間。我們為 Protected Audience 新增了各種非常類似的賣家指定的逾時控制項 (請參閱 perBuyerCumulativeTimeouts、perBuyerTimeouts、sellerTimeout 的說明文件)，以達到保持檢查延遲的相同目標。此外，這些控制項也能鼓勵競價參與者將邏輯最佳化，確保資源發揮最大效率，支援廣告技術生態系統和優質的使用者體驗。
此外，Chrome 也持續努力改善各種基礎架構，藉此改善競價速度 (例如 crrev.com/1190815、crrev.com/1199839、crrev.com/1201837、crrev.com/1198339、crrev.com/1198339)。我們會邀請意見回饋，針對這兩個部分的延遲處理效率提供寶貴意見：買方和賣家認為其他實用工具，以及 Chrome 工程師應調查的瓶頸問題報告。
在有出價和競價服務 (B&A) 的環境中，建構裝置端 Protected Audience 是否耗費大量心力？
否，裝置端足以滿足廣告技術用途的需求。當廣告技術想要投資在瀏覽器允許的出價運算資源時，出價和競價服務是選用的水平縮放解決方案。裝置端開發是很好的投資，因為即使開發人員之後決定加入出價和競價服務環境，大多數工作都可供重複使用。大部分管道和建構的基礎架構仍然以類似方式運作。
對於 Protected Audience 推送企業，這是否會影響雲端型受信任的執行環境 (TEE) 要求？
Privacy Sandbox 設計的 API 以提供強大的隱私權和安全性防護機制，而我們目前在設計方面，並未做出任何可造福 Google Cloud 的決策。我們開始支援採用 AWS 的雲端服務供應商，因為我們知道有多少廣告技術供應商選擇 Amazon。除了 AWS 和 Google Cloud 之外，我們預計未來還會支援其他雲端服務供應商，並樂於獲得其他雲端服務供應商的建議。如果擔心延遲問題，雲端平台會提供客戶的位置選項，讓您縮短與其他雲端服務供應商間的距離。
Privacy Sandbox 是否允許信任的執行環境 (TEE) 在非公開雲端資料中心中執行？
可稽核的受信任的執行環境 (TEE) 是我們的隱私權和安全性模型的一部分。我們一開始先使用公有雲供應商提供的 TEEs，採取嚴格的安全性措施明確來說，短期內唯一需要使用 Trusted Execution 環境的 API 是 Attribution Reporting API 和 Private Aggregation API，而且這兩個 API 都不在競價設定中即時呼叫 TEE。除了公有雲解決方案外，我們仍會繼續探索各種支援服務。
比起地端部署的廣告技術資料中心，在公有雲上執行受信任的執行環境是否更加昂貴？
目前的 TEE 隱私權模型受益於公有雲實作的安全性做法，並會擔心在內部部署環境中運作受信任執行環境所需的成本較低。以下是這些做法的部分費用考量：
公用雲端服務供應商必須遵循極高的安全性標準。舉例來說，AWS 是信譽良好的雲端供應商，他們採用了既定安全性做法。尤其是 AWS Nitro 提供了記錄過的安全模型，可確保 Nitro Enclave 禁止操作人員存取在集中處理的資料，而受保護的資源 (例如解密金鑰) 僅供在 Enclave 中執行的授權程式碼使用。我們也會考量實際操作AWS 已針對實體存取風險 (包括 Amazon 員工) 設計並執行緩解措施。現有的硬體式 TEE 可能無法防禦所有專門用於公有雲的實體攻擊。此外，Amazon 最近與獨立研究公司 NCC Group 合作審查他們的 Nitro 設計，著重在與內部員工存取相關的安全聲明。公開報告會指出 AWS 設計符合其憑證附加資訊。
長期投入這些做法，需要投入資金、獲得支援和改善。由於公有雲遍及全球，且可廣泛使用，因此這些費用會分散在廣大客戶群。
Privacy Sandbox 會改變計費方式嗎？
不行。廣告技術公司和其他 API 呼叫端可以繼續查看網頁內容是否已轉譯完畢，以及相關價格。
Privacy Sandbox 是否可以設定展示頻率上限？
Protected Audience 透過 prevWinsMs 物件，支援同一個興趣群組內的跨網站展示頻率上限。在 Protected Audience 競價中，買方的 generateBid() 函式可建立邏輯，以便根據同一瀏覽器先前的廣告曝光結果通知出價策略。
有幾項解決方案可在 Protected Audience 以外使用展示頻率上限，但這些解決方案並未完全對應至廣告技術使用第三方 Cookie 的跨網站技術。
- 第一方 Cookie：廣告技術可以使用自己的第一方資料，設定自家網站的展示頻率上限
- CHIP：廣告技術可使用分區 Cookie 管理每個網站層級的展示頻率上限
- 共用儲存空間
SelectURL()：廣告技術贏得競價且在顯示廣告素材之前，可以呼叫 Shared Storage 存取跨網站資料，並透過「選取網址輸出門檻」根據頻率選擇正確的廣告素材。
以隱私權為重的非 Protected Audience 展示頻率上限解決方案，提供有意義的廣告技術公用程式，雖然有挑戰性，原因如下：
- 目前我們無法根據廣告技術的意見回饋，判斷頻率信號是否容許雜訊。
- 我們一直以來都收到一項廣告技術意見回饋，表示在競價期間，必須在競價期間提供跨網站頻率信號，因此這類信號必須在任何廣告競價中使用無雜訊的跨網站信號。這可能洩漏使用者在各網站上的大量活動資訊，進而實現 Privacy Sandbox 的隱私權目標。
- 我們對於導入延遲的情況十分敏感，並會利用裝置端解決方案提供這個信號，可能會造成延遲及中斷競價環境。
- 解決方案可能需要是新的 API，且必須完成 W3C 提案程序。
因此，在 Protected Audience 以外的地方建構展示頻率上限解決方案並不在我們的即時藍圖中，但我們會提供意見回饋，詢問是否能解決這項用途。
請問 Privacy Sandbox 未涵蓋的用途是什麼？
Privacy Sandbox API 提供隱私權保護廣告的重要基礎，可讓開發人員靈活決定兩者的合作方式。這些構成要素可讓企業推動創新和開發解決方案，為客戶創造價值。這不是 Privacy Sandbox 的用意，而是為所有用途提供端對端解決方案。我們認為這樣會讓結果不愉快開發人員和企業會繼續採用多項技術，包括整合至自家解決方案的 Privacy Sandbox API，藉此實現自己的想法。