視商品目錄而定,您可能需要進行資料分割 (將動態饋給拆分為多個檔案)。
使用區塊處理的時機
動態饋給檔案大小超過 200 MB (經 gzip 壓縮後)。
- 範例:產生的可用性動態饋給為 1 GB。這應該會分割成 5 個以上的獨立檔案 (或分割)。
合作夥伴廣告空間分散在各個系統和/或區域,導致難以對帳廣告空間。
- 範例:合作夥伴擁有美國和歐盟的廣告空間,但位於不同的系統。動態饋給可能會使用 2 個檔案 (或分片) 產生,其中 1 個用於美國,1 個用於歐盟,且都使用相同的
nonce
和generation_timestamp
。
- 範例:合作夥伴擁有美國和歐盟的廣告空間,但位於不同的系統。動態饋給可能會使用 2 個檔案 (或分片) 產生,其中 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,在同一個動態饋給的所有分片中相同,但與其他動態饋給的值不同。nonce
必須為正整數 (uint64
)。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 個資料分片
請按照下列步驟確保動態饋給處理正確無誤:
- 決定上傳時間表,並設定每個廣告空間例項,以便按照時間表上傳。
- 為每個執行個體指派不重複的區塊編號 (例如美國 = 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" } ] } ] }