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