視庫存情況而定，您可能需要分割資料 (或將動態饋給拆分為多個檔案)。
資料分割的使用時機
1 個檔案的動態饋給大小超過 200 MB (gzip 壓縮後)。
- 範例：產生的供應情形動態饋給為 1 GB。請將這個檔案分割為超過 5 個不同的檔案 (或資料分割)。
合作夥伴目錄分散於不同的系統和/或區域，導致難以協調庫存。
- 範例：合作夥伴有分別位於不同系統的美國和歐盟商品目錄。這則動態饋給可能會包含 2 個檔案 (或資料分割)、1 (適用於美國) 和 1 個 (歐盟地區) 含有相同的
nonce和generation_timestamp檔案。
- 範例：合作夥伴有分別位於不同系統的美國和歐盟商品目錄。這則動態饋給可能會包含 2 個檔案 (或資料分割)、1 (適用於美國) 和 1 個 (歐盟地區) 含有相同的
一般規則
- 1 個檔案 (在 gzip 壓縮後) 的每個資料分割不得超過 200 MB。
- 每個動態饋給的資料分割數量不應超過 20 個。如果您有需要超過該金額的正當業務理由，請與支援團隊聯絡來取得進一步的操作說明。
-
個別記錄 (例如一個
Merchant物件) 必須以一個資料分割中傳送，且不能跨至多個資料分割。不過，不使用相同shard_number的資料分割也能傳送，以供日後的動態饋給使用。 - 為提高效能，請將資料平均分配給資料分片，讓所有資料分割檔案的大小都相似。
如何分割動態饋給
將每個檔案 (或資料分割) 的 FeedMetadata 設為以下內容：
processing_instruction設定為PROCESS_AS_COMPLETE。shard_number已設為動態饋給目前的資料分割 (從 0 至total_shards開始，1 不中斷)- 將
total_shards設為動態饋給資料分割總數 (從 1 開始)。 nonce設為不重複的 ID，在「同一個」動態饋給的所有資料分割中都相同，但與其他動態饋給的值不同。generation_timestamp是 Unix 和 EPOCH 格式的時間戳記。動態饋給的所有資料分割都應相同。
建議選項：設定每個檔案 (或資料分割) 的檔案名稱來表示動態饋給類型、時間戳記、資料分割數量和資料分割總數。資料分割的大小應大致相同，且會在所有資料分割上傳完畢後進行處理。
Example:“availability_feed_1574117613_001_of_002.json.gz”
資料分割供應情形動態饋給範例
資料分割 0
{
"metadata": {
"processing_instruction": "PROCESS_AS_COMPLETE",
"shard_number": 0,
"total_shards": 3,
"nonce": "111111",
"generation_timestamp": 1524606581
},
"service_availability": [
{
"availability": [
{
"spots_total": 1,
"spots_open": 1,
"duration_sec": 3600,
"service_id": "1000",
"start_sec": 1577275200,
"merchant_id": "merchant1",
"confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
}
]
}
]
}
資料分割 1
{
"metadata": {
"processing_instruction": "PROCESS_AS_COMPLETE",
"shard_number": 1,
"total_shards": 3,
"nonce": "111111",
"generation_timestamp": 1524606581
},
"service_availability": [
{
"availability": [
{
"spots_total": 1,
"spots_open": 1,
"duration_sec": 3600,
"service_id": "1000",
"start_sec": 1577620800,
"merchant_id": "merchant2",
"confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
}
]
}
]
}
資料分割 2
{
"metadata": {
"processing_instruction": "PROCESS_AS_COMPLETE",
"shard_number": 2,
"total_shards": 3,
"nonce": "111111",
"generation_timestamp": 1524606581
},
"service_availability": [
{
"availability": [
{
"spots_total": 1,
"spots_open": 1,
"duration_sec": 3600,
"service_id": "1000",
"start_sec": 1576670400,
"merchant_id": "merchant3",
"confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
}
]
}
]
}
針對合作夥伴分散式廣告空間使用資料分割
合作夥伴很難將分散在多個系統和區域的商品目錄合併為單一動態饋給。資料分割可用於解決對帳難題，方法是將每個資料分割設為符合各分散式系統的庫存組合。
舉例來說，假設合作夥伴的商品目錄資料分為 2 個區域 (美國和歐盟商品目錄)，且這些區域分別位於 2 個不同的系統中。
合作夥伴可將每個動態饋給分成 2 個檔案 (或多個資料分割)：
- 商家動態饋給：1 個資料資料分割 (適用於美國)，1 個資料分割代表歐盟
- 服務動態饋給：1 個資料資料分割 (美國)、1 個資料分割 (歐盟)
- 供應情形動態饋給：1 個資料分割用於美國，1 個資料分割代表歐盟
請按照下列步驟操作，確保系統能正確處理動態饋給：
- 決定上傳時間表，並將每個商品目錄執行個體設為按照時間表進行。
- 為各個執行個體指派不重複的資料分割號碼 (例如 US = N, EU = N + 1)。將
total_shards設為資料分割總數。 - 在每個排定的上傳時間，決定
generation_timestamp和nonce。在FeedMetadata中，將所有例項設為這兩個欄位的相同值。generation_timestamp應為目前或過去的日期 (最好是合作夥伴的讀取時資料庫時間戳記)
- 所有資料分割上傳完畢後，Google 會透過
generation_timestamp和nonce將資料分割分組。
即使每個資料分割都代表合作夥伴商品目錄的不同區域，且可在一天的不同時段上傳，只要所有資料分割的 generation_timestamp 都相同，Google 仍會將動態饋給視為一個來處理。
按區域劃分的供應情形動態饋給範例
資料分割 0 - 美國商品目錄
{
"metadata": {
"processing_instruction": "PROCESS_AS_COMPLETE",
"shard_number": 0,
"total_shards": 2,
"nonce": "111111",
"generation_timestamp": 1524606581
},
"service_availability": [
{
"availability": [
{
"spots_total": 1,
"spots_open": 1,
"duration_sec": 3600,
"service_id": "1000",
"start_sec": 1577275200,
"merchant_id": "US_merchant_1",
"confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
}
]
}
]
}
資料分割 1 - 歐盟廣告空間
{
"metadata": {
"processing_instruction": "PROCESS_AS_COMPLETE",
"shard_number": 1,
"total_shards": 2,
"nonce": "111111",
"generation_timestamp": 1524606581
},
"service_availability": [
{
"availability": [
{
"spots_total": 1,
"spots_open": 1,
"duration_sec": 3600,
"service_id": "1000",
"start_sec": 1577620800,
"merchant_id": "EU_merchant_1",
"confirmation_mode": "CONFIRMATION_MODE_SYNCHRONOUS"
}
]
}
]
}