使用 Data Manager API 時，請留意下列最佳做法。
傳送所有使用者 ID
無論是使用 UserData 傳送目標對象成員或事件，請盡可能加入多個 user_identifiers，包括傳送多個相同類型的 ID。
舉例來說，如果使用者有多個電子郵件地址，請為每個電子郵件地址加入個別的 UserIdentifier。同樣地，如果您有使用者的不同類型 ID，例如電子郵件地址、電話號碼和地址，請為每個 ID 分別新增 UserIdentifier，最多可達ID 數量上限。
最佳化要求
為降低超過每日要求上限的可能性，請盡可能在每項要求中批次處理多個項目，最多不超過單次要求限制。
舉例來說，如要將 10,000 名目標對象成員加入目標對象，請在一個 IngestAudienceMembersRequest 的 audience_members 清單中加入所有 10,000 名成員。在單一要求中批次處理所有 10,000 名成員，比為每位目標對象成員分別傳送要求更有效率。
傳送並行要求
如要縮短擷取資料所需的整體時間，請同時傳送並行要求至 IngestionService。建議您同時傳送最多 10 個要求，降低超出每分鐘要求限制的可能性。
即使要求具有相同的 destinations，您也可以傳送並行要求。
在用戶端驗證資料
Data Manager API 採用快速失敗模式。如果要求中的任何記錄未通過同步驗證，整個要求就會失敗，且不會處理任何記錄。此外，API 會依序驗證要求，因此修正某個錯誤後，可能會發現後續驗證層的錯誤。
為避免重複來回和要求遭拒，請先驗證及清理資料，再傳送資料：
在雜湊前移除空值：在計算 SHA-256 雜湊前，請檢查
email_address和phone_number等欄位，確認是否有空字串或僅含空白字元的字串。對空字串進行雜湊處理會產生有效的雜湊，雖然能通過語法檢查，但會降低媒合率。捨棄不完整的複合式物件：請先確認複合式物件包含所有必要欄位，再新增至記錄。舉例來說，如果
AddressInfo物件缺少四個必要欄位 (given_name、family_name、region_code或postal_code) 的任一項，請捨棄整個address識別碼，以免發生REQUIRED_FIELD_MISSING錯誤。驗證編碼和明文欄位：確認雜湊欄位與宣告的
encoding相符，而非傳送原始明文，並確保必須保持明文的欄位 (例如mobile_ids) 未經雜湊處理。篩除超出範圍的時間戳記：確認時間戳記並非未來時間，或早於目的地的轉換回溯期。
如果使用 JSON 傳送要求，請確保時間戳記字串採用 RFC 3339 格式，並包含時區偏移。
清理電話號碼：確認電話號碼包含國家/地區代碼，並在雜湊前使用 E.164 格式。
刪除空白或過大的記錄：將
user_identifiers限制在每筆記錄上限 (10 個 ID)，捨棄空白的自訂參數，並省略不含有效 ID 的記錄。確認用途需求：確認每個事件都包含目的地和用途的所有必要欄位 (例如 Google Ads 線上轉換的
transaction_id)。如需各用途的必填欄位完整清單，請參閱事件總覽中目的地的傳送事件指南。使用
validateOnly測試要求：傳送要求時，將validateOnly設為true，即可擷取快速失敗錯誤，而不必擷取或移除資料。即使僅限驗證要求成功，也不保證非同步處理期間不會發生錯誤，因此傳送一般要求後，請繼續檢查要求狀態和診斷資訊。
如需詳細的正規化和雜湊規則，請參閱「設定使用者資料格式」。
查看要求狀態和診斷資訊
擷取並收集每個 IngestAudienceMembersResponse 或 IngestEventsResponse 的 request_id，並使用要求 ID 檢查要求狀態和診斷。
監控配額並設定快訊
為避免要求意外遭拒，請在 Google Cloud 控制台中設定配額警告和監控功能。監控配額用量有助於追蹤用量模式，並在應用程式達到每日或每分鐘限制前，最佳化要求批次處理。
部署至正式環境
從本機測試轉換至正式環境工作負載時，請使用應用程式預設憑證，並附加服務帳戶或 Workload Identity Federation，以非互動方式安全地進行驗證。
如要進一步瞭解如何為不同正式環境設定驗證，請參閱「部署至正式環境」。