大量下載和上傳
使用 大量服務 ，您可以在背景以非同步方式下載並上傳行銷活動設定。 建議使用大量服務來管理大規模資料，特別是當您需要在帳戶中的多個廣告群組或行銷活動之間新增或更新廣告和關鍵字時。 針對某些實體，您也可以下載申請建議和品質分數資料。 無論相同檔案中的其他記錄是否包含錯誤，都可以成功上傳每一筆記錄。 如需下載和上傳檔案所用架構的相關資訊，包括可用的實體、申請建議和品質分數資料的詳細資料，請參閱 大量檔案架構。
重要事項
新的記錄類型 (資料列) 和欄位 (資料行) 可以隨時新增，而且您不應該依賴大量下載或大量上傳結果檔案中的記錄或欄位順序。 同樣地，除非參考檔中另有說明，否則您不應該相依于每個欄位中傳回的固定值集。
如果您使用 .NET 語言、JAVA 或 Python，您應該使用 Bing 廣告 API 用戶端程式庫。 .NET、JAVA 和 Python SDK 會抽象化以下所述的低階詳細資料。 例如，您可以搭配BulkServiceManager類別使用一個方法，而不是呼叫DownloadCampaignsByAccountIds和GetBulkDownloadStatus來下載檔案。 如需搭配 SDK 使用大量下載和上傳的詳細資訊，請參閱大量Service Manager。
大量下載
若要下載帳戶的行銷活動資料，請呼叫 DownloadCampaignsByAccountIds 作業。 若要下載特定活動的資料，請呼叫 DownloadCampaignsByCampaignIds 作業。
下載大量檔案
您可以要求所有行銷活動的資料，或只要求自上次下載行銷活動資料以來已變更的資料。 針對任一下載作業，以下是要求設定和下載工作流程的概觀。
重要事項
您必須針對下載要求作業使用相同的使用者認證， (DownloadCampaignsByAccountIds 或 DownloadCampaignsByCampaignIds) 和 GetBulkDownloadStatus 輪詢作業。
設定要求的 DataScope 元素，並指定除了實體資料之外，是否要包含報價建議或品質分數資料。 如需可能值的清單，請參閱 DataScope 值集。
設定要求的 DownloadFileType 元素，以選取 Csv 或 Tsv 作為下載檔案的格式。
注意事項
下載的 Csv 或 Tsv 檔案會根據您指定的 CompressionType 進行 ZIP 或 GZIP 壓縮。 如果您未指定 CompressionType，則 ZIP 是預設值。
設定要求的 Entities 元素，以包含您的行銷活動、廣告群組、廣告和關鍵字實體。 您可以選擇性地在下載中包含其他實體，例如負關鍵字和目標。 如需您可能要求的實體清單，請參閱 DownloadEntity 值集。
將要求的 LastSyncTimeInUTC 元素設定為先前下載的時間戳記，只要求自上次下載後已更新或刪除的實體。
注意事項
如果這是您第一次要求下載指定的實體，請將要求的 LastSyncTimeInUTC 元素設定為 Null，以下載所有可用的實體。
使用 DownloadCampaignsByAccountIds 或 DownloadCampaignsByCampaignIds 作業提交下載要求。
下載要求會傳回您傳遞給 GetBulkDownloadStatus 作業的識別碼。 您會在迴圈中呼叫 GetBulkDownloadStatus 作業，直到下載完成或失敗為止。 下載完成所需的時間長度取決於一些變數，例如您要求的活動數目和佇列中已存在的要求數目。 由於這些變數，您使用的輪詢間隔可能會有所不同。 您有兩天的時間可以從提交下載要求開始下載檔案。 如果您尚未在這段時間內成功下載檔案，則會從下載網站中移除該檔案，而且您必須再次呼叫其中一個下載作業。
當 GetBulkDownloadStatus作業順利完成時，它會傳回下載檔案的 URL。 使用 URL 在本機複製下載檔案。 URL 必須在 GetBulkDownloadStatus 作業傳回 成功 狀態碼的五分鐘內使用。 如果您未在這段時間內開始下載，則必須再次呼叫 GetBulkDownloadStatus 以取得新的 URL。
下載檔案會以 zip 格式壓縮，因此您必須將檔案解壓縮以存取資料。 如需下載檔案所用架構的相關資訊，請參閱 大量檔案架構。
下載最佳做法
請遵循最佳做法，以確保您自己和所有 Microsoft Advertising 用戶端都能夠公平使用。
重要事項
雖然確切的並行下載和上傳限制可能會變更，但您提交的暫止要求數目有限。 如果您觀察到 4204 BulkServiceNoMoreCallsPermittedForTheTimePeriod 錯誤，您可以在等候最多 15 分鐘後重新提交要求，視您提交的要求頻率和大小而定。 如需詳細資訊，請 參閱大量 API 節流。
只要求您需要的大量下載實體。 新的記錄類型 (資料列) 和欄位 (資料行) 可以隨時新增，而且您不應該依賴大量下載或大量上傳結果檔案中的記錄或欄位順序。
只執行一次完整下載。 之後，請執行差異下載。 將 LastSyncTimeInUTC 設定為上次下載的時間戳記。 下載檔案包含在帳戶記錄的SyncTime資料行中下載的時間戳記。 每次執行完整下載並不會有任何好處，它會降低每個人的效能，包括您的效能。
以合理的間隔輪詢下載。 您比任何人都更瞭解您的資料。 如果您下載的帳戶小於一百萬個關鍵字，請考慮以 15 到 20 秒的間隔輪詢。 如果帳戶包含大約一百萬個關鍵字，請考慮在等候五分鐘後，每隔一分鐘輪詢一次。 對於具有大約 400 萬個關鍵字的帳戶，請考慮在等候 10 分鐘後，每隔一分鐘輪詢一次。
如果帳戶包含超過 400 萬個關鍵字，請呼叫 DownloadCampaignsByCampaignIds 作業。 使用包含超過四百萬個關鍵字的帳戶呼叫 DownloadCampaignsByAccountIds 作業將會失敗。
您可能想要在 DownloadCampaignsByCampaignIds 要求中包含較少的活動。 使用包含超過 8 百萬個關鍵字的帳戶呼叫 DownloadCampaignsByCampaignIds 作業將會失敗。 指定每個呼叫較少行銷活動的要求通常會比指定允許數目上限的呼叫更快完成。
大量上傳
您可以使用 HTTP POST 將大量上傳檔案提交至大量服務所提供的 URL。
注意事項
生產環境中上傳的檔案大小限制為 100 MB，最多 4 百萬個數據列。 針對 沙箱 ，限制為 2 萬個數據列。
如需您應該用於上傳檔案的架構相關資訊，請參閱 大量檔案架構。
上傳大量檔案
以下是要求設定和上傳工作流程的概觀。
重要事項
您必須在整個 GetBulkUploadUrl、HTTP POST 和 GetBulkUploadStatus 工作流程中使用相同的使用者認證。
將GetBulkUploadUrl要求的AccountId元素設定為對應至將上傳之資料的帳戶識別碼。
設定GetBulkUploadUrl要求的ResponseMode元素，以指定服務應該傳回錯誤及其對應的資料，還是只傳回結果檔中的錯誤。 如需詳細資訊，請參閱 ResponseMode。
使用隨 GetBulkUploadUrl回應傳回的UploadUrl，以使用 HTTP POST 提交大量上傳檔案。 內容類型必須是 multipart/form-data。 UTF-8 檔案必須包含 BOM) (位元組順序標記。 ZIP 壓縮的上傳應該包含一個格式為 Csv 或 Tsv 的檔案。 ZIP 檔案必須正確結構化，包括中央目錄記錄的結尾。
注意事項
不使用 HTTP 標準授權標頭。 若要驗證，您必須新增並設定 HTTP 用戶端的 Microsoft Advertising 自訂標頭元素，包括 DeveloperToken、 CustomerId和 CustomerAccountId 標頭。 您也必須透過 AuthenticationToken 標頭元素來設定使用者認證。 如需詳細資訊，請 參閱使用 OAuth 進行驗證 和 使用 API 認證的位置。
您必須在整個 GetBulkUploadUrl、HTTP POST 和 GetBulkUploadStatus 工作流程中使用相同的使用者認證。
範例如下。
POST <UploadUrl> HTTP/1.1 AuthenticationToken: <AuthenticationToken> DeveloperToken: <DeveloperToken> CustomerId: <CustomerId> AccountId: <AccountId> Content-Type: multipart/form-data;檢查 HTTP 回應狀態碼。 如果 HTTP 回應狀態碼為 200，則 Microsoft Advertising 已成功接收檔案。 如果 HTTP 回應狀態碼為 401，則驗證失敗，例如 AuthenticationToken 或 DeveloperToken 無效。 如果 HTTP 回應狀態碼為 400，則您也應該檢查 Bing 廣告 API 作業錯誤碼的 回應資料流程，例如，範圍為 3220 - 3227。
以下是 URL 已用來上傳大量檔案的範例錯誤回應訊息。
HTTP/1.1 400 Bad Request Cache-Control: private Content-Type: application/json; charset=utf-8 Server: Microsoft-IIS/8.0 X-AspNetMvc-Version: 3.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Tue, 12 Jan 2016 17:07:23 GMT Content-Length: 224 {"TrackingId":"16bd93cc-22fb-4d3c-94be-25adefd06fae","RequestId":"26c3fbf6-3e24-4569-ada3-d4e8b3d0aecc","Code":3224,"ErrorCode":"BulkServiceUrlAlreadyUsedForUpload","Message":"The URL has already been used for file upload."}GetBulkUploadUrl回應也包含您傳遞至GetBulkUploadStatus作業的RequestId。 當上傳擱置時，您可以在迴圈中呼叫 GetBulkUploadStatus 作業，直到上傳完成或失敗為止。 從提交上傳要求開始，您有 15 分鐘的時間可以下載上傳結果檔案。 如果您尚未在此期間內成功下載檔案，則會從下載網站中移除該檔案，而且可能無法擷取該檔案。 如果您錯過這個商機視窗，您可以呼叫其中一個下載作業來取得最新的實體資料。
當 GetBulkUploadStatus作業順利完成時，它會傳回上傳結果檔案的 URL。 使用 URL 在本機複製結果檔案。 URL 必須在 GetBulkUploadStatus 作業傳回 Completed 狀態回應 字串的 15 分鐘內使用。 如果您未在這段時間內開始下載，則必須再次呼叫 GetBulkUploadStatus 以取得新的 URL。
注意事項
上傳結果檔的格式會是 Csv 或 Tsv，且會符合您提交來上傳的檔案格式。
上傳最佳做法
請遵循最佳做法，以確保您自己和所有 Microsoft Advertising 用戶端都能夠公平使用。
重要事項
雖然確切的並行下載和上傳限制可能會變更，但您提交的暫止要求數目有限。 如果您觀察到 4204 BulkServiceNoMoreCallsPermittedForTheTimePeriod 錯誤，您可以在等候最多 15 分鐘後重新提交要求，視您提交的要求頻率和大小而定。 如需詳細資訊，請 參閱大量 API 節流。
大型檔案可能會降低上傳效能。 這是選擇性的，建議將檔案壓縮以上傳。 如果已壓縮，則必須使用對應的延伸模組將它格式化為 ZIP。 生產環境中上傳的檔案大小限制為 100 MB，最多 4 百萬個數據列。 針對 沙箱 ，限制為 2 萬個數據列。 如果您可以將每個客戶的並行上傳限制在 5 或 6 以下，請考慮分割檔案，而不是達到檔案大小限制。
將每個客戶的並行上傳限制為 5 或 6，以平行方式上傳檔案。 等候每個執行緒，直到處理上一個檔案為止，然後您可以重複使用執行緒上傳另一個檔案。 例如，一個執行緒可以上傳檔案，在上傳狀態為Completed、CompletedWithErrors或Failed之後，該執行緒可以上傳另一個檔案。
只上傳您要新增或更新的實體和欄位。 如果提供，則會忽略唯讀欄位，例如中標建議和品質分數資料。
每個檔案上傳一個實體類型，以將效能最大化。 有一些例外狀況，例如，建立新的行銷活動、廣告和關鍵字時，將它們與 參考金鑰一起上傳會更有效率。 另一個範例是，如果您只更新 10 個行銷活動、500 個廣告和 800 個關鍵字，則可以將它們包含在一個上傳中，而不是分割每個類型的上傳。
請考慮您是否需要在上傳結果檔案中 (ResponseMode = ErrorsAndResults) 要求錯誤和結果，還是只有 (ResponseMode = ErrorsOnly) 的錯誤才足夠。 請考慮是否應將結果與本機資料同步處理。 例如，如果您要更新實體，您可能只需要知道是否發生任何錯誤，而且在該情況下，您可以在GetBulkUploadUrl要求中指定ResponseMode = ErrorsOnly。 如果您要新增實體，則可以在GetBulkUploadUrl要求中指定ResponseMode = ErrorsAndResults，以接收產生的實體識別碼。
針對部分重試嘗試，如果只有記錄的子集產生錯誤，請勿上傳整個檔案。 只上傳您要重試的記錄。
在上傳狀態為Completed、CompletedWithErrors或Failed之前，請勿重試。 如果效能可能不符合預期，仍請等候結果。
以合理的間隔輪詢上傳結果。 一開始，您應該每上傳 10K 個數據列等候一分鐘。 在初始等候時間之後，請考慮以一分鐘間隔輪詢。