本指南將介紹一些最佳做法，說明如何實作，以便最佳化應用程式的效率和效能。
持續維護
如何確保應用程式運作不中斷：
更新 API 中心中的開發人員聯絡電子郵件地址。這是我們用來與您聯絡的別名。如果我們未能聯絡您確實遵守 API 條款及細則，可能會在您不知情的情況下撤銷 API 存取權。請避免使用與個人或未受監控帳戶相關聯的個人電子郵件地址。
歡迎訂閱我們的電子報
Google Ads API 團隊會定期監控論壇，是提出 API 相關問題的理想園地。
- 確保您的應用程式符合 Google Ads API 條款及細則規定。 如有必要，權杖審查和法規遵循團隊將會透過您的聯絡電子郵件與您聯絡。如果您對條款及細則有任何疑問或疑慮，可以在審查開發人員權杖申請時回覆審查團隊的電子郵件，與審查團隊聯絡。
最佳化
批次作業
向 API 發出要求需要許多固定費用，例如往返網路延遲、序列化與去序列化處理，以及對後端系統的呼叫。為了減少這些固定費用的影響並提高整體效能，API 中大多數的 Change 方法設計為接受一系列作業。將多項作業批次處理到每項要求中，即可減少送出的要求數及相關的固定費用。如果可以，請避免只透過一項作業發出要求。
舉例來說，假設您想在廣告活動內的多個廣告群組中加入 50,000 個關鍵字。與其分別提出 50,000 個請求，每個要求各含 1 個關鍵字，您可以提出 100 個請求，每個請求各包含 500 個關鍵字 (甚至有 10 個請求，每個要求各含 5,000 個關鍵字)。每項要求可包含的作業數量有限，因此您可能需要調整批次大小，才能達到最佳效能。
傳送 sparse 物件
將物件傳送至 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 進行開發，即使應用程式尚未經過審查也一樣。