本指南將介紹一些最佳做法，協助您提升應用程式的效率和效能。
維護中
為確保應用程式能持續運作，請採取下列行動：
請確認 Google Cloud 專案的系統管理員和擁有者清單為最新狀態。如有任何緊急情況或與 API《條款及細則》法規遵循相關的主題，我們會與這些使用者聯絡。如果我們無法就 API《條款及細則》的遵循情況與您聯絡，您的 API 存取權可能會遭到降級或撤銷。
如要掌握產品異動、維護停機時間和淘汰日期等問題，請訂閱我們的
確保應用程式符合 Google Ads API 條款及細則。如有需要，API 法規遵循團隊會與 Google Cloud 專案的管理員和擁有者聯絡，瞭解 API 存取權。如果您對條款及細則有任何疑問或疑慮，請回覆 API 存取權申請審查時收到的電子郵件，與法規遵循團隊聯絡。
最佳化
您可以執行批次作業，並視需要傳送稀疏物件，藉此最佳化應用程式。
批次作業
向 API 提出要求會產生多項固定費用，例如網路來回延遲時間、序列化和還原序列化處理，以及對後端系統的呼叫。為減少這些固定成本的影響並提升整體成效，API 中的大多數變動方法都設計為接受一系列作業。將多項作業批次處理到每個要求中，即可減少提出的要求數量和相關固定費用。如果可以，請避免只包含一項作業的要求。
舉例來說，假設您要為廣告活動新增 50,000 個關鍵字，並將這些關鍵字分配到多個廣告群組。與其為每個關鍵字提出 1 次要求，不如為每 500 個關鍵字提出 1 次要求，或為每 5,000 個關鍵字提出 1 次要求。要求中允許的作業數量設有限制，因此您可能需要調整批量大小，才能達到最佳效能。
傳送稀疏物件
將物件傳送至 API 時，必須將欄位還原序列化、驗證，並儲存在資料庫中。如果您只想更新幾個欄位，但卻傳遞完整物件，可能會導致額外的處理時間和效能下降。為減輕這類情況，Google Ads API 支援稀疏更新，讓您只填入需要變更或必填的物件欄位。稀疏更新的處理速度較快，且較不容易產生錯誤。不在 update_mask (也稱為 FieldMask) 中的欄位不會變更。
舉例來說，如果應用程式會更新關鍵字層級的出價，就很適合使用稀疏更新，因為只需要填入廣告群組 ID、條件 ID 和出價欄位。
錯誤處理和管理
開發期間可能會遇到錯誤。本節說明在應用程式中建構錯誤管理機制時，需要考量的事項和策略。除了本節內容，您也可以參閱疑難排解指南，進一步瞭解如何管理錯誤。
區分要求來源
部分應用程式主要用於互動，會直接發出 API 呼叫，以回應 UI 中使用者啟動的動作。其他應用程式則主要離線運作，並在定期後端程序中發出 API 呼叫。許多應用程式會結合這兩項功能。思考錯誤管理時，區分這些不同類型的要求會很有幫助。
如果是使用者發出的要求，首要考量應是為使用者提供良好的體驗。請使用發生的具體錯誤，在 UI 中盡可能向使用者提供脈絡資訊。提供簡單的步驟，協助他們解決錯誤 (請參閱下方的建議)。
如果是從後端發出的要求，請為應用程式可能遇到的不同類型錯誤實作處理常式。請務必加入預設處理常式，以解決罕見或先前未遇到的錯誤。預設處理常式的良好做法是將失敗的作業和錯誤新增至佇列，供人工操作員審查並判斷適當的解決方式。
區分錯誤類型
建構完善的錯誤處理機制時，瞭解 Google Ads API 中的錯誤類型差異至關重要。常見的錯誤類型包括：
同步後端
如果應用程式使用者可手動存取 Google Ads 帳戶，他們可能會進行應用程式未知的變更，導致應用程式的本機資料庫失去同步。如錯誤類型指南所述，您可以主動嘗試防止發生同步相關錯誤，也可以在發生錯誤時被動解決。其中一項積極主動的策略，是在所有帳戶上執行夜間同步作業，擷取帳戶中的 Google Ads 物件，並與本機資料庫進行比較。
記錄檔錯誤
所有錯誤都應記錄下來，方便進行偵錯和監控。至少要記錄要求 ID、導致錯誤的作業，以及錯誤本身。要記錄的其他資訊包括客戶 ID、API 服務、往返要求延遲時間、重試次數，以及原始要求和回應。
監控趨勢
請務必監控 API 錯誤趨勢，以便偵測及解決應用程式問題。您可以自行建構解決方案，或採用其中一種市售工具，這些工具可使用記錄檔產生互動式資訊主頁，並傳送自動快訊。
開發
在開發期間使用測試帳戶。
使用測試帳戶
測試帳戶是 Google Ads 帳戶，但不會實際放送廣告。您可以使用測試帳戶試用 Google Ads API，並測試應用程式的連線能力、廣告活動管理邏輯或其他處理程序是否正常運作。在測試帳戶中，Google Cloud 專案只需要「測試帳戶」存取層級，因此您可以在等待 Google 審查應用程式，以取得較高的 API 存取層級時，立即開始使用 Google Ads API 進行開發。