確保 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。這些限制可用來大幅減少要執行的出價指令碼數量。
從鍵/值服務中篩除興趣群組
如果買方可以在即時受信任出價信號伺服器中，判斷特定興趣群組不應出價 (例如該廣告活動已停用、暫停或預算用盡，或不應對這個發布商出價)，就可以向瀏覽器指出信任的出價信號擷取 priorityVector 回應。如果產生的 priorityVector 和 prioritySignals 稀疏小積為負數，瀏覽器就會略過這個興趣群組的 generateBid() 叫用 generateBid()。若要進一步瞭解這項機制，請參閱說明的「篩選及排定興趣群組」一節。
重複使用 JavaScript 執行環境
瀏覽器必須先初始化新的 JavaScript 執行環境，才能執行 generateBid()。這可能需要大量時間，和執行最少 generateBid() 本身可能需要的時間。您可以使用「依來源分組」或「凍結結構定義」模式來節省這個時間。
如果興趣群組加入同一個來源，且可能不需要變更出價指令碼，group-by-origin 模式可以重複使用執行環境。詳情請參閱說明中的「group-by-origin 說明」。凍結模式可以重複使用所有可能的執行環境，但可能需要變更出價指令碼。詳情請參閱說明中的 frozen-context 說明。
重複使用出價指令碼
如果可以，請針對興趣群組使用相同的出價指令碼。這會讓瀏覽器不必下載、剖析及編譯多個指令碼，進而產生額外的網路要求。出價方仍可在使用相同指令碼時，根據興趣群組資訊 (例如 name 或 userBiddingSignals) 設定不同的出價。
重複使用 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 的討論。