本指南將介紹一些最佳做法，協助您提升應用程式的效率和效能。
維護中
為確保應用程式能持續運作，請採取下列措施：
確保 API 中心內的開發人員聯絡電子郵件地址符合現況。 這是我們用來連絡您的別名。如果我們無法與您聯絡，確認您是否遵守 API《條款及細則》，我們可能會在您不知情的情況下撤銷您的 API 存取權。請勿使用與個人或未受監控帳戶相關聯的個人電子郵件地址。如要查看 API 中心，請登入管理員帳戶。
如要掌握產品異動、維護停機時間、淘汰日期等問題，請訂閱我們的
Google Ads API 團隊會定期監控論壇，因此是發布 API 問題的理想場所。
- 確保應用程式遵守 Google Ads API《條款及細則》。如有需要，權杖審查和法規遵循團隊會透過您的聯絡電子郵件與您聯絡。如果您對條款及細則有任何疑問或疑慮，請回覆審查團隊在審查開發人員權杖申請時傳送的電子郵件，與他們聯絡。
最佳化
您可以執行批次作業，並視情況傳送稀疏物件，藉此最佳化應用程式。
批次作業
向 API 發出要求會產生許多固定費用，例如網路來回延遲、序列化和還原序列化處理，以及對後端系統的呼叫。為減少這些固定成本的影響並提升整體成效，API 中的大多數變動方法都設計為接受一系列作業。將多項作業批次處理到每個要求中，即可減少提出的要求數量和相關固定費用。如果可以，請避免只含一項作業的要求。
舉例來說，假設您要為廣告活動新增 50,000 個關鍵字，並將這些關鍵字分配到多個廣告群組。與其提出 50,000 個要求 (每個要求包含 1 個關鍵字)，不如提出 100 個要求 (每個要求包含 500 個關鍵字)，甚至提出 10 個要求 (每個要求包含 5,000 個關鍵字)。要求中允許的作業數量有限，因此您可能需要調整批次大小，才能達到最佳效能。
傳送稀疏物件
將物件傳送至 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 Ads API 進行開發，即使應用程式尚未接受審查也沒問題。