Rapports incrémentiels
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
La nouvelle API Search Ads 360 Reporting est désormais disponible. La nouvelle API vous offre davantage de flexibilité pour créer des rapports personnalisés et intégrer les données dans vos applications et processus de reporting. En savoir plus sur la migration vers et l'utilisation de la
nouvelle API Search Ads 360 ReportingAu lieu de recevoir un vidage de toutes les données chaque fois que vous demandez un rapport, vous pouvez demander régulièrement uniquement les données qui ont été modifiées depuis votre dernier rapport. Ces rapports incrémentiels seront probablement beaucoup plus petits qu'un rapport complet.
Si vous demandez des rapports incrémentiels, tenez compte des points suivants:
- Nous vous recommandons de demander un rapport complet de temps en temps, au cas où des modifications incrémentielles seraient perdues. Par exemple, si vous demandez des rapports incrémentiels hebdomadaires en janvier, vous devez demander un rapport complet pour janvier afin d'être sûr d'obtenir toutes les données de janvier à la fin du mois de février.
- Étant donné qu'il n'est pas toujours possible de déterminer si certaines entités ont été modifiées, un rapport incrémentiel contient une entité si Search Ads 360 suppose qu'elle a changé. Cela signifie que les rapports incrémentiels peuvent contenir des données qui n'ont pas changé.
Pour demander un rapport incrémentiel, spécifiez l'une des propriétés Reports.request.timeRange
suivantes:
changedMetricsSinceTimestamp=timestampDemande les métriques qui ont changé depuis le code temporel spécifié. Étant donné que les métriques sont stockées quotidiennement et peuvent changer pour un jour, mais pas un autre, ces requêtes doivent être segmentées par jour (la colonne date doit être présente). Par exemple, un rapport keyword contenant les colonnes clicks, actions et date affiche une ligne pour chaque mot clé et date à laquelle le nombre de clics ou d'actions enregistré a changé depuis le code temporel donné.
Le code temporel ne doit pas être antérieur de huit jours à l'heure de la demande. Pour capturer toutes les métriques changeantes, assurez-vous d'envoyer une requête changedMetricsSinceTimestamp au moins une fois tous les sept jours et de créer un rapport complet pour chaque date une fois les métriques établies (il est plus sûr d'attendre au moins sept jours). Par exemple, vous pouvez créer deux rapports par jour: un rapport incrémentiel pour les métriques qui ont changé au cours des dernières 36 heures et un rapport complet pour les métriques enregistrées il y a huit jours.
changedAttributesSinceTimestamp=timestampDemande les attributs qui ont été modifiés depuis le code temporel donné. Une requête changedAttributesSinceTimestamp ne peut inclure que des colonnes d'attributs (pas de colonnes de métriques ni de segments) et ne fonctionne pas pour les rapports sur les événements bruts tels que les rapports conversion. Par exemple, un rapport campaign contenant les colonnes dailyBudget et campaignStartDate affiche une ligne pour chaque campagne dont le budget quotidien ou la date de début a changé depuis le code temporel donné.
Notez que les modifications apportées aux attributs parents ne sont pas prises en compte dans les rapports changedAttributesSinceTimestamp. Par exemple, un mot clé peut hériter de la stratégie d'enchères du groupe d'annonces parent.
Même si une nouvelle stratégie d'enchères est attribuée au groupe d'annonces, il est possible que ce mot clé n'apparaisse pas dans le rapport. Les colonnes d'attributs dont la valeur dépend des entités parentes (et peuvent donc changer sans être récupérées par les rapports changedAttributesSinceTimestamp) présentent généralement le préfixe "effective" (effectif), tel que effectiveLabelIds ou effectiveBidStartegy.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2023/12/14 (UTC).
[null,null,["Dernière mise à jour le 2023/12/14 (UTC)."],[[["\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"]]
