確保 Protected Audience API 運作效率良好，對所有人都好：
- 瀏覽網路的使用者希望網站能快速載入。也就是說，開發人員應有效率地使用 Protected Audience API 建構內容，避免過度使用有限的裝置資源 (例如運算或網路資源)，這些資源是載入網站和內嵌廣告的必要條件。
- 發布商希望網站能快速載入，為使用者提供有效率且回應迅速的體驗。發布商也希望透過有效的廣告，盡可能提高收益。
- 廣告主和廣告技術供應商希望廣告能快速顯示，盡可能發揮效用。
本文將說明導入 Protected Audience API 的最佳做法，確保網站以最高效率運作。
買方 (出價方) 最佳做法
如要確保您盡可能提升 Protected Audience API 競價效率，請遵循下列最佳做法。
興趣群組擁有者較少
為保護 Protected Audience API 出價者，瀏覽器會使用網站隔離功能保護網路上不同來源，並使用昂貴的資源 (例如作業系統程序) 保護個別興趣群組擁有者。
為盡量減少這些非常昂貴的資源支出，請務必盡可能減少興趣群組擁有者數量。請避免不同子網域擁有不同的興趣群組。舉例來說，如果 cats.adtech.example 和 dogs.adtech.example 擁有興趣群組，瀏覽器可能會使用兩個不同的程序來執行出價指令碼。adtech.example
出價的興趣群組較少
瀏覽器必須先完成大量設定和準備工作，才能叫用買家的 generateBid() 指令碼，例如設定新的乾淨 JavaScript 執行環境，以及剖析和載入 generateBid() 程式碼。
- 如果興趣群組代表的使用者並非目前有效廣告活動的目標對象，廣告素材清單應為空白。這樣一來，如果興趣群組沒有相關廣告，Protected Audience API 就不會執行
generateBid()。 - 合併類似的興趣群組可減少必須執行的
generateBid()次數。興趣群組的userBiddingSignals屬性可用來儲存使用者的其他中繼資料，因此興趣群組數量較少不一定代表目標對象指定效果較差。 - Protected Audience API 支援賣方指定的興趣群組數量限制，以及供買方指定興趣群組相對優先順序的 API。這些限制可大幅減少要執行的競價指令碼數量。
在鍵/值服務中，從出價中篩除興趣群組
如果買方可在即時可信出價信號伺服器中判斷特定興趣群組不應出價 (例如廣告活動已停用、暫停或超出預算，或不應對這個特定發布商出價)，則可透過對可信出價信號擷取的 priorityVector 回應，向瀏覽器指出這點。如果 priorityVector 和 prioritySignals 的稀疏點積結果為負數，瀏覽器就會略過這個興趣群組的 generateBid() 呼叫。如要進一步瞭解這項機制，請參閱說明文件的「篩選及設定興趣群組優先順序」一節。
重複使用 JavaScript 執行環境
瀏覽器必須先初始化新的 JavaScript 執行環境，才能執行 generateBid()。這可能需要大量時間，與執行最少 generateBid() 本身所需的時間相當。使用依來源分組或凍結情境執行模式，即可節省這段時間。
如果興趣群組是在相同來源中加入，group-by-origin 模式可以重複使用執行環境，而且可能不需要變更出價指令碼；如要瞭解詳情，請參閱說明文件中的group-by-origin說明。凍結環境模式可能會重複使用所有執行環境，但可能需要變更出價指令碼；如要瞭解詳情，請參閱解說畫面中的frozen-context說明。
重複使用出價指令碼
請盡可能為興趣群組使用相同的競價指令碼。這樣一來，瀏覽器就不必下載、剖析及編譯多個指令碼 (這會產生額外的網路要求)。出價者仍可使用相同指令碼，根據興趣群組資訊 (例如 name 或 userBiddingSignals) 區分出價。
如果沒有 HTTP 快取控制項標頭，系統就不會快取出價指令碼。請指定適當的標頭，確保系統不會不必要地擷取指令碼。如果網頁上有多個競價並行執行，且記憶體中已有相同出價者的出價指令碼，系統會重複使用該指令碼，並忽略快取語意。如果競價是依序執行，瀏覽器就會遵守 HTTP 快取機制。
請注意，瀏覽器會在出價期間 (適用於 generateBid()) 和報表期間 (適用於 reportWin()) 載入出價指令碼。如果未設定快取控制標頭，瀏覽器會擷取相同的指令碼兩次，每個時間範圍各一次。
因此，建議您在所有指令碼中設定快取控制標頭。
重複使用 trustedBiddingSignalsUrls
網路延遲和資源用量可能非常顯著。減少擷取即時可信出價信號的次數，有助於縮短延遲時間。
如果多個興趣群組共用 trustedBiddingSignalsUrl，即可合併擷取信任的出價信號。盡可能為所有興趣群組使用相同的 trustedBiddingSignalsUrl。
指定適當的 HTTP 快取控制標頭，確保特定網頁上廣告空間的受信任出價信號擷取作業會快取。請避免將 trustedBiddingSignalsSlotSizeMode 設為 slot-size，因為當廣告空間大小不同時，要求的網址也會不同，這樣會導致廣告空間無法快取。
減少擷取可信的即時出價信號
網路延遲時間可能非常長，而這會直接受到擷取即時信任出價信號期間傳輸的資料量影響。
建議您將廣告或興趣群組專屬資料儲存在興趣群組中，而非即時受信任的出價信號服務。僅為真正即時的信號保留即時受信任的出價信號資料，例如廣告活動預算或終止開關。
任何可每天或更長時間更新的信號，都應儲存在興趣群組中，並使用每日更新功能更新。
如「在鍵/值服務中篩除興趣群組，避免參與出價」一節所述，請勿針對已篩除的興趣群組傳回受信任的出價信號。
優先顯示興趣群組
賣家會使用逾時來限制發布商網頁上瀏覽器資源的使用量。perBuyerCumulativeTimeouts可用於限制買家擷取信任出價信號和執行出價指令碼的時間長度，因此買家務必優先處理興趣群組，確保最有可能贏得競價的群組優先執行。舉例來說，如果 perBuyerCumulativeTimeouts 設為 100 毫秒，出價者的可信出價信號擷取作業耗時 50 毫秒，且每次叫用 generateBid() 耗時 10 毫秒，裝置上又有 10 個興趣群組，那麼只有一半的興趣群組有機會計算出價。在這個範例中，買方應依據最有可能贏得競價到最不可能贏得競價的順序，為興趣群組設定優先順序。
興趣群組可包含以 priority 欄位定義的靜態優先順序。興趣群組也可以使用動態優先順序，這類優先順序可在受信任的出價信號服務中計算，並透過 priorityVector 回應傳回瀏覽器，以擷取受信任的出價信號。
請注意，瀏覽器會依優先順序從高到低執行興趣群組，這可能會穿插來自不同加入來源的興趣群組，進而影響 group-by-origin 最佳化。
賣家最佳做法
請務必監控並盡量提高 Protected Audience API 競價效率。
平行處理競價
現代網路連線和多核心處理器可同時執行多項活動，瀏覽器可與其他活動並行執行 Protected Audience 競價。建議盡早呼叫 runAdAuction()，由於部分 runAdAuction() 輸入內容可能無法在初期提供 (例如在脈絡回應中傳回瀏覽器的內容)，因此瀏覽器允許在這些輸入內容可用之前呼叫 runAdAution()，並在稍後使用 JavaScript Promise 提供這些輸入內容。如要盡可能降低競價延遲時間，請在得知 interestGroupBuyers 輸入內容時呼叫 runAdAuction()。這樣一來，系統就能立即開始競價的許多環節，包括擷取競價者的即時出價信號。
監控競價
收集競價指標。瀏覽器可以回報per-buyer延遲指標給賣家，讓他們深入瞭解賣家競價所花費的時間。賣家可以運用這些指標尋找最佳化競價的方法，包括瞭解如何最有效地設定逾時。賣家可以與買家分享特定買家的延遲指標，協助他們進一步最佳化。
出價者可以深入瞭解自家興趣群組的出價成效，但可能無法與其他出價者比較。比較不同出價者的相對勝率和出價遭拒率，有助於找出因興趣群組從未產生可行的出價，或使用未獲核准的廣告素材過度出價，而導致出價運算資源浪費的情況。
防範出價指令碼執行緩慢
如果出價指令碼耗費過多時間，所有參與者都會受到影響，導致 Protected Audience API 競價速度變慢。使用逾時可防止競價速度緩慢，同時在競價速度緩慢時仍可回收收益。
賣家應使用 perBuyerCumulativeTimeouts 避免競價速度緩慢，並在競價速度緩慢且達到逾時時，仍接受出價。相較於使用 perBuyerTimeouts 和 perBuyerGroupLimits，建議使用 perBuyerCumulativeTimeouts，因為 perBuyerCumulativeTimeouts 不會對興趣群組數量或 generateBid() 速度做出任何判斷 (例如，出價速度快的興趣群組數量較多，出價速度慢的興趣群組數量較少，兩者都可以在逾時前完成)。
建議使用競價設定 signal 欄位實作整體競價逾時，以防在擷取可信評分信號和執行 scoreAd() 耗費過多時間時，競價時間過長。
後續步驟
我們希望與您一起討論，確保我們打造出適合所有人的 API。
討論 API
如同其他 Privacy Sandbox API，這個 API 會記錄並公開討論。
使用 API 進行實驗
您可以實驗並參與 Protected Audience API 的討論。