對於使用 Display & Video 360 API 的任何應用程式,配額最佳化功能都是必要的。最佳化配額用量可簡化 API 要求,並避免超出設定的頻率限制時傳回錯誤,進而提升效能。
本頁面詳細說明一般最佳做法,並強調 Display & Video 360 API 中的輔助功能,協助您減少配額使用量。
針對多位廣告主提出並行要求
Display & Video 360 API 中的大多數方法會在網址中指定廣告主。除了專案整體配額之外,在呼叫指定相同廣告主的呼叫時,這些方法會強制執行更嚴格的「每個專案的廣告主」費率限制。
如要針對這項配額進行最佳化,請將並行要求限制為指定不同廣告主的請求。
使用 pageSize
、filter
和 orderBy
參數
擷取多個資源時,請使用 list
方法,而非 get
方法。由於頁面大小有限制,list
呼叫仍可能會耗用大量配額。
將 pageSize
參數設為最大可接受值,藉此最佳化所有 list
要求。方法的預設頁面大小 (在未設定參數時使用) 可能會小於允許的最大值,因此需要更多要求才能擷取完整的資源清單。
如果您只需要擷取完整清單回應的一部分,可以利用選用的 filter
和 orderBy
參數,改善配額的使用情形。
您可以使用 filter
參數,將 list
呼叫擷取的資源限制為屬性符合指定運算式的資源。嘗試擷取下列項目時,這個參數就非常實用:
- 特定資源,其 ID 不明但屬性已知。如果要搜尋特定資源,您可以依據所需資源的已知屬性篩選傳回的清單。例如,您可以依據已知的
displayName
篩選委刊項、依據預期的creativeType
篩選廣告素材,以及依據相關的exchange
篩選廣告空間來源。 - 相關聯的資源。Display & Video 360 中的資源通常會彼此關聯。您可以使用篩選器,將傳回的資源限制為與其他資源有特定關係的資源。例如擷取特定
campaignId
下方的所有廣告訂單,以及指派給委刊項的所有廣告素材。 - 只有具有可操作屬性的資源。您可以利用 API 功能輕鬆檢查資源狀態,並以程式輔助方式做出回應。您可以使用篩選器,透過
list
呼叫只取得需要執行動作的資源。例如擷取顯示特定可操作lineItemWarningMessage
的所有委刊項、自指定日期時間起更新的所有廣告訂單,或是有失敗approvalStatus
的所有廣告素材。
您可以使用 orderBy
參數,依特定屬性 (遞增或遞減) 排序擷取的資源。orderBy
特別適合與 filter
搭配使用,可用於限制在找到特定資源前,需要遍歷的網頁數量。您也可以輕鬆取得資源清單的上限和下限。舉例來說,您可以依 updateTime
排序,快速找出廣告客戶最近更新的委刊項或廣告訂單。
使用大量操作和資源層級函式
Display & Video 360 API 提供多項大量操作和資源層級函式,可透過單一要求執行多項操作。這類函式的例子包括:
- 大量編輯屬於單一頻道的網站。頻道可指派數千個網站。您可以使用單一
bulkEdit
或replace
要求,分別新增及移除多個網站,或取代頻道的整個內容,而非使用個別的create
或delete
要求來管理頻道的網站清單。 - 管理廣告主的整個指定目標套件。資源的指定套件會指派給多個指定類型。資源層級指定目標函式 (例如
advertisers
服務中的listAssignedTargetingOptions
和editAssignedTargetingOptions
) 可讓您在單一要求中擷取、建立及移除多種指定類型的指定目標。這樣一來,廣告客戶將指定目標套件設為單一要求的配額成本就會降低。 - 為多個委刊項設定相同的指定目標限制。如果您需要一次對多個委刊項進行相同的指定目標變更,可以使用單一
advertisers.lineItems.bulkEditAssignedTargetingOptions
要求執行這項操作。 - 啟用或暫停多個委刊項。委刊項必須先啟用,才能開始放送。如果您要快速依序建立多個委刊項,可以透過單一
advertisers.lineItems.bulkUpdate
要求啟用所有委刊項。您可以使用相同的方法暫停多個委刊項,停止放送這些委刊項。
快取及檢查常用的 ID
Display & Video 360 API 中的許多作業都需要使用透過 API 本身擷取的資源 ID,包括指定選項 ID、Google 目標對象 ID 等等。為避免每次使用時都從 API 擷取 ID,建議您在本機儲存這些 ID。
不過,部分資源可能會淘汰、刪除,或以其他方式無法使用。嘗試使用這些資源的 ID 可能會傳回錯誤。因此,建議您每週使用適當的 get
或篩選的 list
方法檢查所有快取 ID,確認 ID 仍可擷取且具有預期狀態。
為長時間執行的作業實作指數輪詢
在輪詢是否已完成長時間執行的作業 (例如 SDF 下載工作) 時,請使用指數輪詢策略來減少傳送的要求頻率和總數。
指數輪詢是網路應用程式的標準錯誤處理策略,讓用戶端可以定期重試要求,並逐漸增加重試次數。在正確的使用之下,指數輪詢可以提升頻寬使用的效率,減少取得成功回應所需的要求數,並最大化並行環境中的要求總處理量。
您可以在 SDF 下載程式碼範例中,找到用戶端程式庫實作的指數輪詢策略。實作簡單指數輪詢的逐步流程如下:
- 向 API 提出
sdfdownloadtasks.operations.get
要求。 - 擷取作業物件。
- 如果
done
欄位不是 true,表示您應重試要求。 - 等待 5 秒鐘加上隨機幾毫秒的時間,然後重試要求。
- 如果
- 擷取作業物件。
- 如果
done
欄位不是 true,表示您應重試要求。 - 等待 10 秒加上隨機幾毫秒的時間,再重試要求。
- 如果
- 擷取作業物件。
- 如果
done
欄位不是 true,表示您應重試要求。 - 等待 20 秒加上隨機幾毫秒的時間,然後重試要求。
- 如果
- 擷取作業物件。
- 如果
done
欄位不是 true,表示您應重試要求。 - 等待 40 秒加上隨機幾毫秒的時間,然後重試要求。
- 如果
- 擷取作業物件。
- 如果
done
欄位不是 true,表示您應重試要求。 - 等待 80 秒鐘 + 隨機數毫秒,然後重試要求。
- 如果
- 持續執行這個模式,直到查詢物件更新或已過的時間達到上限為止。