增加的報表
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
您可以定期要求只要求自上次報告以來有所變更的資料，而非在每次要求報表時接收所有資料。這些增量報表可能會遠低於完整報表。
如要索取增量報表，請注意下列事項：
- 我們仍建議您每隔一段時間就索取一次完整報表，以免有遺漏某些增量變更。舉例來說，如果您在 1 月要求每週增加報表，則應在 2 月底索取 1 月份的完整報表，以確保取得 1 月的所有資料。
- 由於系統有時無法判斷部分實體是否已變更，因此即使 Search Ads 360 的認為該實體已變更，也會在後續報表中納入一個實體。也就是說，增量報表可能包含的資料維持不變。
如要索取增量報表，請指定下列其中一項 Reports.request.timeRange
屬性：
changedMetricsSinceTimestamp=timestamp要求指標在指定時間戳記後有所變更。由於指標以每日精細程度儲存，且可能會持續一天，但必須按日區隔，因此這類要求必須按日區隔 (必須顯示 date 資料欄)。舉例來說，如果 keyword 報表包含 clicks、actions 和 date 資料欄，系統會針對每個關鍵字和日期傳回一列，其中記錄的點擊次數或操作次數自指定時間戳記起發生變化。
時間戳記不得早於要求時間的前 8 天。如要擷取所有變更的指標，請務必至少每 7 天提出 changedMetricsSinceTimestamp 要求一次，並在指標確定後為每個日期製作完整的報表 (比較安全，至少等待 7 天)。其中一個模式就是每天建立兩份報表：針對過去 36 小時內變更的指標建立增量報表，以及為 8 天前發生的指標建立完整報表。
changedAttributesSinceTimestamp=timestamp要求的屬性在指定時間戳記後有所變更。changedAttributesSinceTimestamp 要求只能包含屬性欄 (不含指標或區隔欄)，且不適用於原始事件報表 (例如 conversion 報表)。舉例來說，如果 campaign 報表包含 dailyBudget 和 campaignStartDate 欄，系統就會根據指定時間戳記後，針對每個廣告活動傳回一個資料列。
請注意，changedAttributesSinceTimestamp 報表不會擷取父項屬性的變更。舉例來說，某個關鍵字可能會沿用上層廣告群組的出價策略。即使廣告群組獲派新的出價策略，這個關鍵字也可能不會顯示在報表中。值取決於父項實體的屬性欄 (因此可能會因 changedAttributesSinceTimestamp 報表未擷取而可能變更) 前置字串為「有效」，例如 effectiveLabelIds 或 effectiveBidStartegy。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2023-12-14 (世界標準時間)。
[null,null,["上次更新時間：2023-12-14 (世界標準時間)。"],[[["\u003cp\u003eThe new Search Ads 360 Reporting API offers increased flexibility for creating custom reports and integrating data into your workflows.\u003c/p\u003e\n"],["\u003cp\u003eIncremental reports allow you to retrieve only the data that has changed since your last request, making reports smaller and more efficient.\u003c/p\u003e\n"],["\u003cp\u003eIt is recommended to periodically request full reports in addition to incremental reports to ensure all data is captured.\u003c/p\u003e\n"],["\u003cp\u003eIncremental reports can be requested based on either changed metrics or changed attributes using specific time range properties.\u003c/p\u003e\n"],["\u003cp\u003eWhile \u003ccode\u003echangedAttributesSinceTimestamp\u003c/code\u003e requests provide efficient updates for attributes, changes to parent attributes might not be reflected, necessitating awareness of potential data discrepancies.\u003c/p\u003e\n"]]],["The new Search Ads 360 Reporting API allows users to build custom reports and integrate data into their applications. It offers incremental reports, which retrieve only data that has changed since the last request, reducing report size. Users can request changes in metrics (`changedMetricsSinceTimestamp`) or attributes (`changedAttributesSinceTimestamp`). Full reports are still recommended periodically to ensure no data is missed. For `changedMetricsSinceTimestamp`, data must be segmented by day and should be requested every seven days. Changed attributes only report changes to the attribute itself, not inherited changes from parent.\n"],null,["# Incremental Reports\n\nThe new Search Ads 360 Reporting API is now available. The new API provides enhanced flexibility to build custom reports and integrate the data into your reporting applications and processes. Learn more about migrating to and using the [new Search Ads 360 Reporting\nAPI](https://developers.google.com/search-ads/reporting/overview).\nInstead of receiving a dump of all data every time you request a report, you can\nperiodically request only the data that has changed since your last report. These\nincremental reports will likely be significantly smaller than a full report.\n\nIf you request incremental reports, you should be aware of the following:\n\n- It's still a good idea to request a full report every once in a while, just in case some incremental changes are lost. For example, if you request weekly incremental reports during January, at the end of February you should request a full report for January to make sure you get all of the January data.\n- Since it isn't always possible to determine if some entities have changed, an incremental report will contain an entity if Search Ads 360 even *suspects* that the entity has changed. This means that incremental reports might contain data that hasn't changed.\n\n\nTo request an incremental report, specify one of the following ` `[Reports.request.timeRange](/search-ads/v2/reference/reports#request.timeRange)`\n` properties:\n\n`changedMetricsSinceTimestamp=`*timestamp*\n\n: Requests metrics that have changed since the specified timestamp. Because metrics are\n stored at a daily granularity and might change for one day but not another, such\n requests must be segmented by day (the `date` column must be present). For\n example, a `keyword` report with the columns\n `clicks`, `actions`, and `date`, would\n return a row for each keyword and date in which the recorded number of\n clicks or actions has changed since the given timestamp.\n\n\n The timestamp must be no earlier than 8 days before the time of request. To capture\n all of the changing metrics, be sure to make a `changedMetricsSinceTimestamp`\n request at least once every 7 days, and make a full report for each date\n once the metrics have settled (it is safer to wait at least 7 days). An\n example pattern is to create two reports every day: an incremental\n report for metrics that have changed in the last 36 hours, and a full\n report for metrics that occurred 8 days ago.\n\n`changedAttributesSinceTimestamp=`*timestamp*\n\n: Requests attributes that have changed since the given timestamp. A\n `changedAttributesSinceTimestamp` request can only include\n attribute columns (no metric or segment columns), and does not work for\n raw event reports such as\n [`conversion`](/search-ads/v2/report-types/conversion) reports. For example, a\n `campaign` report with the columns `dailyBudget`\n and `campaignStartDate` would return a row for each campaign\n whose daily budget or start date has changed since the given timestamp.\n\n\n Note that changes to parent attributes are not captured in `changedAttributesSinceTimestamp` reports. For example a keyword may inherit its bid strategy from the parent ad group. Even if the ad group is assigned a new bid strategy, this keyword might not appear in the report. Attribute columns whose value depends on parent entities (and therefore could change without getting picked up by `changedAttributesSinceTimestamp` reports) usually have the prefix \"effective\", such as `effectiveLabelIds` or `effectiveBidStartegy`.\n\n \u003cbr /\u003e"]]
