Rapports incrémentiels

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 Reporting

Au 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=timestamp

Demande 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=timestamp

Demande 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.