視您的商品目錄而定,您可能必須分割資料 (或將動態饋給分割為多個檔案)。
資料分割功能的使用時機
1 個檔案 (超過 gzip 壓縮後) 的動態饋給大小超過 200 MB。
- 範例:產生的有空與否動態饋給為 1 GB。這應分割為 5 個以上的檔案 (或資料分割)。
合作夥伴廣告空間會分散到多個系統和/或區域,導致對帳不容易。
- 範例:合作夥伴擁有的美國和歐盟廣告空間位於不同的系統中。動態饋給可能會產生 2 個檔案 (或資料分割),1 個代表美國,1 個則含有相同
nonce
和generation_timestamp
。
- 範例:合作夥伴擁有的美國和歐盟廣告空間位於不同的系統中。動態饋給可能會產生 2 個檔案 (或資料分割),1 個代表美國,1 個則含有相同
一般規則
- 每個檔案在 1zip 檔案中壓縮後不得超過 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,歐盟 = 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" } ] } ] }