本指南將說明一些最佳做法，協助您提升應用程式的效率和效能。
持續維護
如要確保應用程式能持續執行，請按照下列步驟操作：
請務必更新 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 進行開發，甚至在應用程式經過審查前即可開始。