最佳做法
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
ondemand_video
影片：觀看 2019 年研討會的最佳做法講座
本指南將介紹一些最佳做法，協助您提升應用程式的效率和效能。
維護中
為確保應用程式能持續運作，請採取下列措施：
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 進行開發，即使應用程式尚未接受審查也沒問題。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-27 (世界標準時間)。
[null,null,["上次更新時間：2025-08-27 (世界標準時間)。"],[[["\u003cp\u003eOptimize your app's performance by using batch operations and sending sparse objects to reduce API calls and processing time.\u003c/p\u003e\n"],["\u003cp\u003eMaintain uninterrupted app function by keeping your developer contact email current, subscribing to Google Ads communication channels, and ensuring API compliance.\u003c/p\u003e\n"],["\u003cp\u003eImplement robust error handling by distinguishing request sources and error types, proactively syncing data, logging errors comprehensively, and monitoring error trends.\u003c/p\u003e\n"],["\u003cp\u003eUtilize test accounts for development and experimentation to validate app functionality without affecting live campaigns.\u003c/p\u003e\n"]]],[],null,["# Best Practices\n\nondemand_video\n[Video: Check out the best practices talk from the 2019 workshop](https://www.youtube.com/watch?v=J9zVoWT7twk&list=None&start=None)\n\nThis guide covers some best practices you can implement to optimize\nthe efficiency and performance of your apps.\n\nOngoing maintenance\n-------------------\n\nTo ensure that your app runs uninterrupted:\n\n- Keep your developer contact email in the API center up to date.\n This is the alias we use to contact you. If we're unable to contact you\n regarding compliance with the API Terms and Conditions, your API access\n may be revoked without your prior knowledge. Avoid using a personal email\n address tied to an individual or unmonitored account. To view the API\n center, you must be logged in to your manager account.\n\n- To be informed of issues such as product changes, maintenance downtime,\n deprecation dates, and so on, subscribe to our\n\n - [Forum](//groups.google.com/g/adwords-api)\n - [API blog](//ads-developers.googleblog.com/search/label/google_ads_api)\n - [Product blog](//blog.google/products/ads-commerce/)\n\nThe forum is regularly monitored by the Google Ads API team, making it the ideal place\nto post API questions.\n\n- Keep your app compliant with the Google Ads API [Terms and Conditions](/google-ads/api/terms) (T\\&C). If required, the token review and compliance team will reach out to you using your contact email. If you have questions or concerns about the T\\&C, you can reach out to the review team by responding to the email they sent you when reviewing your developer token application.\n\nOptimization\n------------\n\nYou can optimize your app by running batch operations and, if appropriate,\nsending sparse objects.\n\n### Batch operations\n\nMaking a request to the API entails a number of fixed costs, such as\nround-trip network latency, serialization and deserialization processing, and\ncalls to back-end systems. To lessen the impact of these fixed costs and\nincrease overall performance, most mutate methods in the API are designed to\naccept an array of operations. By batching multiple operations into each\nrequest, you can reduce the number of requests you make and the associated\nfixed costs. If you can, avoid making requests with only one operation.\n\nFor example, suppose you're adding 50,000 keywords to a campaign across multiple\nad groups. Instead of making 50,000 requests with 1 keyword each,\nmake 100 requests with 500 keywords each, or even 10 requests with\n5,000 keywords each. There are limits on the number of operations\nallowed in a request, so you may need to adjust your batch size to achieve\noptimal performance.\n\n### Send sparse objects\n\nWhen objects are sent to the API, fields must be deserialized, validated,\nand stored in the database. Passing in full objects when you only want to update\na few fields can result in extra processing time and decreased performance.\nTo mitigate this, the Google Ads API supports sparse updates, allowing you\nto populate only the fields in an object that you need to change or that are\nrequired. Sparse updates process faster and are less likely to produce errors.\nFields that aren't in the update_mask (also known as `FieldMask`) are left\nunchanged.\n\nFor example, an app that updates keyword-level bids can benefit from using\nsparse updates, as only the ad group ID, criterion ID, and bids fields would\nneed to be populated.\n\nError handling and management\n-----------------------------\n\nDuring development, you're likely to encounter errors. This section describes\nconsiderations and strategies for building error management into your app.\nIn addition to this section, visit the [Troubleshooting\nguide](/google-ads/api/docs/best-practices/troubleshooting) for more information on managing\nerrors.\n\n### Distinguish request sources\n\nSome apps are primarily interactive, issuing API calls directly in response\nto user-initiated actions in a UI. Others work primarily offline, issuing\nAPI calls as part of a periodic back-end process. Many apps combine the two.\nWhen thinking about error management, it can be useful to distinguish these\ndifferent types of requests.\n\nFor user-initiated requests, your primary concern should be providing a good\nexperience for your users. Use the specific error that occurred to provide the\nuser with as much context as you can in the UI. Offer easy steps they can take\nto resolve the error (check out the suggestions below).\n\nFor requests initiated on the back end, implement handlers for the different\ntypes of errors your app may encounter. Always include a default handler to\naddress rare or previously unencountered errors. A good approach for a default\nhandler is to add the failed operation and error to a queue for a human operator\nto review and determine an appropriate resolution.\n\n### Distinguish error types\n\nKnowing the differences between error types in Google Ads API is crucial when\nbuilding robust error handling. Some of the most common error types are:\n\n1. [Authentication errors](/google-ads/api/docs/best-practices/error-types#authentication_errors)\n2. [Retryable errors](/google-ads/api/docs/best-practices/error-types#retryable_errors)\n3. [Validation errors](/google-ads/api/docs/best-practices/error-types#validation_errors)\n4. [Sync-related errors](/google-ads/api/docs/best-practices/error-types#sync-related_errors)\n\nRefer to [Error Types](/google-ads/api/docs/best-practices/error-types) and\n[Common Errors](/google-ads/api/docs/common-errors) for more details.\n\n### Sync back ends\n\nIf your app's users have manual access to Google Ads accounts, they may make\nchanges that your app is not aware of, causing your app's local database to go\nout of sync. As noted in our [Error Types](/google-ads/api/docs/best-practices/error-types) guide,\nyou can address sync-related errors reactively when they occur, but you can also\ntry to prevent them proactively. One proactive strategy is to run a nightly\nsync job on all your accounts, retrieving the Google Ads objects in your\naccounts and comparing against your local database.\n\n### Log errors\n\nAll errors should be logged to facilitate debugging and monitoring. At a\nminimum, log the request ID, the operations that caused the error, and the\nerror itself. Other information to log includes customer ID, API service,\nround-trip request latency, number of retries, and the raw request and response.\n\n### Monitor trends\n\nBe sure to monitor trends in API errors so that you can detect and address\nproblems with your app. Consider building your own solution or employing one\nof many available commercial tools that can use your logs to produce interactive\ndashboards and send automated alerts.\n\nDevelopment\n-----------\n\nUse test accounts during development.\n\n### Use test accounts\n\n[Test accounts](/google-ads/api/docs/best-practices/test-accounts) are Google Ads\naccounts that don't actually serve ads. You can use a test account to\nexperiment with the Google Ads API and test that your app's connectivity, campaign\nmanagement logic, or other processing are working as expected. Your developer\ntoken does not need to be approved to be used on a test account, so you can\nstart developing with the Google Ads API immediately after requesting a developer\ntoken, even before your app is reviewed."]]
