報表最佳做法

先在使用者介面中建立新報表

報表必須遵守與報表類型、篩選器、維度和指標相關的多項限制和規定。這些限制會在 API 中執行，並傳回 HTTP 400 錯誤。為了避免在建立報表時發生錯誤，建議您先透過 Display & Video 360 UI 建構新報表。

建立報表後，按一下參考文件頁面上的「試用這個 API」功能，執行 Query 資源的 queries.get。您可以使用傳回的 JSON 建構未來的報表。

使用報表類型專屬的指標和篩選器

部分指標和篩選器值僅適用於特定報表類型。除了先在 UI 中建構報表，您還可以透過 Bid Manager API 值，找出特定 ReportType 值的指標和篩選器。

以下提供一些方法，讓您找出相關的 Bid Manager API 篩選器和指標值。下表並未完整列出可用於這些類型的報表。並非所有值都可用於一份報表中。

ReportType	相關篩選器和指標
INVENTORY_AVAILABILITY	前置字串為 FILTER_TRUEVIEW_IAR 的篩選器。
YOUTUBE	含有 FILTER_TRUEVIEW 前置字串的篩選器，不包括前置字串 FILTER_TRUEVIEW_IAR 的篩選器。 前置字串為 METRIC_TRUEVIEW 的指標。
GRP	前置字串為 METRIC_GRP 的指標。
YOUTUBE_PROGRAMMATIC_GUARANTEED	前置字串為 FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED 的篩選器。 前置字串為 METRIC_PROGRAMMATIC_GUARANTEED 的指標。
REACH	前置字串為 METRIC_UNIQUE_REACH 的指標。
UNIQUE_REACH_AUDIENCE	前置字串為 METRIC_UNIQUE_REACH 的指標。

儲存並重複使用報表

建議您為經常執行的查詢建立並儲存報表，因為插入及刪除同一份報表會浪費資源。在 dataRange 欄位中使用已設定的 Range 值 (例如 PREVIOUS_DAY 或 LAST_7_DAYS)，可讓報表更容易重複使用。

排定報表

臨時或一次性報表可能會浪費資源，因為會單獨執行，且可能會對不完整的資料集執行。排定報表可充分運用報表資源，因為這些資源可以大量執行，且保證在前一天的資料處理完畢之前都不會執行。詳情請參閱可用的排程欄位。

合併類似報表

如果您會定期為不同的廣告客戶或合作夥伴產生採用相同指標和日期範圍的報表，建議您合併這些報表，以達到最佳報表量。

您可以將所有報表的篩選器附加到所有報表的篩選器，並將所有篩選器類型新增為維度，藉此合併類似的報表。產生報表後，您可以依據原始篩選器值分割產生的報表資料列，以產生原始報表。

考慮回報配額

您必須透過下列產品的用量配額，強制使用 Display & Video 360 報表功能。

每天臨時執行報表

限制使用者在 24 小時內可執行的臨時報表數量。 如何確保用量不超過這項配額：

• 合併類似報表以減少報表量。
• 安排週期性臨時報表，專門降低臨時報表用量。
• 停用不必要的 API 指令碼。

有效定期報表

限制使用者在指定時間可主動排定的報表數量。如何確保用量不超過這項配額：

• 合併類似的定期報表，以減少已排定的報表總數。
• 停用不必要的定期報表。
• 停用不必要的 API 指令碼。

並行報表

限制使用者可同時執行的報表數量。如何確保用量不超過這項配額：

• 排定定期執行報表。
• 停用不必要的 API 指令碼。
• 使用指數輪詢邏輯進行輪詢，追蹤完成報表的時間。

如果您已將報表導入作業最佳化，但發現配額仍然超出配額，請透過聯絡表單與 Display & Video 360 支援團隊聯絡。

輪詢報表狀態時使用指數輪詢

您無法預測報表需花費多久時間。時間長度從幾秒到數小時不等，具體取決於許多因素，例如日期範圍和要處理的資料量。報表執行時間和報表傳回的資料列數沒有關聯。因此，您需要定期使用 queries.reports.get 方法擷取報表資源，並檢查資源的 metadata.status.state 欄位是否已更新為 DONE 或 FAILED，以判斷該資源是否已執行完畢。這項程序稱為「輪詢」。

雖然需要進行輪詢，但效率低落的實作可能會在進行長時間執行的報表時快速耗盡配額。因此，建議您採用指數輪詢策略來限制重試次數並節省配額。

指數輪詢

指數輪詢是網路應用程式的標準錯誤處理策略，用戶端可透過這種策略，以增加的時間定期重試要求。在正確使用的情況下，指數輪詢可以提升頻寬用量的效率、減少取得成功回應所需的要求數量，並最大化並行環境中的要求處理量。

下列是簡單的指數輪詢實作流程：

1. 向 API 發出 queries.reports.get 要求。
2. 擷取報表物件。如果 metadata.status.state 欄位不是 DONE 或 FAILED，表示報表尚未執行完畢，應該繼續輪詢。
3. 等待 5 秒鐘 + 隨機幾毫秒，然後重試要求。
4. 擷取報表物件。如果 metadata.status.state 欄位不是 DONE 或 FAILED，表示報表尚未執行完畢，應該繼續輪詢。
5. 等待 10 秒鐘 + 隨機幾毫秒，然後重試要求。
6. 擷取報表物件。如果 metadata.status.state 欄位不是 DONE 或 FAILED，表示報表尚未執行完畢，應該繼續輪詢。
7. 等待 20 秒 + 隨機幾毫秒，然後重試要求。
8. 擷取報表物件。如果 metadata.status.state 欄位不是 DONE 或 FAILED，表示報表尚未執行完畢，應該繼續輪詢。
9. 等待 40 秒 + 隨機幾毫秒，然後重試要求。
10. 擷取報表物件。如果 metadata.status.state 欄位不是 DONE 或 FAILED，表示報表尚未執行完畢，應該繼續輪詢。
11. 等待 80 秒 + 隨機幾毫秒，然後重試要求。
12. 繼續執行這個模式，直到報表物件更新或到達時間上限為止。

如果報表執行完畢並處於 DONE 狀態，您可以在 metadata.googleCloudStoragePath 欄位中指定的路徑，從 Google Cloud Storage 擷取產生的報表檔案。