為確保 Protected Audience API 運作順暢，請務必遵守以下最佳做法：
- 使用者瀏覽網站時，希望網站能快速載入。也就是說，開發人員應使用 Protected Audience API 有效建構，以免過度使用裝置資源 (例如運算或網路資源)，這些資源是載入網站及其嵌入式廣告所需的資源。
- 發布商希望網站能快速載入，為使用者提供高效且即時的使用體驗。發布商也希望能透過有效的廣告，將收益最大化。
- 廣告客戶和廣告技術人員希望廣告能快速顯示，以提供最佳效益。
本文將概述 Protected Audience API 導入作業的部分最佳做法，確保網站能以最高效率運作。
買家 (出價方) 最佳做法
如要確保您針對 Protected Audience API 競價效率進行最佳化調整，請遵循下列最佳做法。
興趣群組擁有者較少
為了保護 Protected Audience API 出價方，瀏覽器會使用大量資源 (例如作業系統程序) 來保護個別興趣群組擁有者，這與瀏覽器使用網站隔離功能保護網路上不同來源的方式相同。
為了盡量減少這些昂貴資源的支出，您必須盡可能減少興趣群組擁有者的數量。避免讓不同子網域擁有不同的興趣群組。舉例來說，如果 adtech.example 有由 cats.adtech.example 和 dogs.adtech.example 擁有的興趣群組，瀏覽器可能會使用兩個獨立程序來執行出價指令碼。
較少興趣群組出價
瀏覽器必須在叫用買方的 generateBid() 指令碼前，進行重要的設定和準備工作，例如設定新的清除 JavaScript 執行環境，以及剖析及載入 generateBid() 程式碼。
- 代表非目前有效廣告活動目標對象的興趣群組，應包含空白廣告素材清單。這可避免 Protected Audience API 為沒有相關廣告的興趣群組執行
generateBid()。 - 合併類似的興趣群組，可減少必須執行
generateBid()的次數。興趣群組的userBiddingSignals屬性可用於儲存使用者的其他中繼資料，因此興趣群組數量較少，不一定代表指定目標的效果較低。 - Protected Audience API 支援賣方指定的興趣群組數量限制，以及買方指定興趣群組相對優先順序的 API。這些限制可用來大幅減少要執行的出價指令碼數量。
在 Key/Value 服務中篩除出價的興趣群組
如果買方可在即時信任出價信號伺服器中判斷某些興趣群組不應出價 (例如廣告活動已停用、暫停或超出預算，或是不應對特定發布商出價)，則可透過 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 避免競價速度變慢，並在競價速度變慢且達到逾時期限時，仍能接受出價。建議使用 perBuyerCumulativeTimeouts 而非 perBuyerTimeouts 和 perBuyerGroupLimits，因為 perBuyerCumulativeTimeouts 不會針對興趣群組數量或 generateBid() 的速度做出任何假設 (例如，許多快速出價的興趣群組和少數慢速出價的興趣群組，都能在逾時前完成)。
建議您使用競價設定 signal 欄位實作整體競價逾時，以免在可信度評分信號擷取和執行 scoreAd() 的時間過長時，導致競價時間過長。
後續步驟
我們希望與您一起討論，確保我們打造出適合所有人的 API。
討論 API
如同其他 Privacy Sandbox API，這個 API 會記錄並公開討論。
使用 API 進行實驗
您可以實驗並參與 Protected Audience API 的討論。