視廣告空間而定，資料分割 (或將動態饋給拆分為多個項目) 檔案)。
使用資料分割的時機
1 個檔案的動態饋給大小超過 200 MB (gzip 壓縮後)。
- 示例：產生的供應情形動態饋給為 1 GB。這應該是 已分割至超過 5 個不同的檔案 (或資料分割)。
合作夥伴廣告空間分佈於各個系統和/或區域 導致無法協調廣告空間
- 範例：合作夥伴有美國和歐盟廣告空間，並分別在不同的平台中販售
有些人會將 Cloud Storage 視為檔案系統
但實際上不是動態饋給可以產生 2 個檔案 (或多個資料分割)、1 代表美國、
1 則代表使用相同
nonce和 1 的歐盟generation_timestamp。
- 範例：合作夥伴有美國和歐盟廣告空間，並分別在不同的平台中販售
有些人會將 Cloud Storage 視為檔案系統
但實際上不是動態饋給可以產生 2 個檔案 (或多個資料分割)、1 代表美國、
1 則代表使用相同
通則
- 每個資料分割不得超過 200 MB，適用於 1 個檔案 (gzip 壓縮後)。
- 每個動態饋給的建議資料分割不超過 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 個檔案 (或資料分割)：
- 商家動態饋給：1 個資料代表美國，1 個資料分割為歐盟
- 服務動態饋給：1 個資料分割為美國，1 個資料分割為歐盟
- 供應情形動態饋給：1 個資料代表美國，1 個資料分割為歐盟
如要確保系統能正確處理動態饋給，請按照下列步驟操作：
- 決定上傳時間表，並將各個廣告空間例項設為 按照時間表進行
- 為每個執行個體指派不重複的資料分割編號，例如 US = N、EU = N + 1。
將
total_shards設為資料分割總數。 - 在每個排定的上傳時間
《
generation_timestamp》和《nonce》。在FeedMetadata，將所有例項設為 這兩個欄位- 「
generation_timestamp」必須是目前日期或近期的日期 (最好使用合作夥伴的讀取資料庫時間戳記)
- 「
- 上傳所有資料分割後，Google 會透過
《
generation_timestamp》和《nonce》。
Google 會將動態饋給視為一項處理，即使每個資料分割都代表
合作夥伴的廣告空間不同區域，並可透過
不同的時段 (只要generation_timestamp
所有資料分割都相同。
各區域的資料分割供應情形動態饋給範例
資料分割 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"
}
]
}
]
}