L'API Search Ads 360 Reporting precedente è stata ritirata. Ora puoi creare i report utilizzando la nuova API Search Ads 360 Reporting.
Tieni presente che i metodi get e getByCustomerId nell'API Search Ads 360 Conversion verranno ritirati nel terzo trimestre del 2025. Per continuare ad accedere ai dati sulle conversioni, devi creare un report utilizzando la risorsa conversion con la nuova API Search Ads 360 Reporting. Scopri di più qui.
Le restanti funzioni dell'API Search Ads 360 Conversion continueranno a essere supportate.
Report incrementali
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
La nuova API Search Ads 360 Reporting è ora disponibile. La nuova API offre maggiore flessibilità per la creazione di report personalizzati e l'integrazione dei dati nelle applicazioni e nei processi per la generazione di report. Scopri di più sulla migrazione alla
nuova API Search Ads 360 Reporting e su come utilizzarla.
Anziché ricevere un dump di tutti i dati ogni volta che richiedi un report, puoi richiedere periodicamente solo i dati che sono stati modificati dall'ultimo report. Questi report incrementali saranno probabilmente significativamente più piccoli di un report completo.
Se richiedi report incrementali, tieni presente quanto segue:
- È comunque una buona idea richiedere di tanto in tanto un report completo, nel caso in cui alcune modifiche incrementali vadano perse. Ad esempio, se richiedi report incrementali
settimanali nel mese di gennaio, alla fine di febbraio devi richiedere un report completo
per gennaio per assicurarti di ottenere tutti i dati di gennaio.
- Poiché non è sempre possibile determinare se alcune entità sono cambiate, un report incrementale conterrà un'entità se Search Ads 360 sospetta che l'entità sia cambiata. Ciò significa che i report incrementali potrebbero contenere dati che non sono
cambiati.
Per richiedere un report incrementale, specifica una delle seguenti proprietà Reports.request.timeRange
:
changedMetricsSinceTimestamp=timestampRichiede metriche che sono cambiate rispetto al timestamp specificato. Poiché le metriche vengono
archiviate con una granularità giornaliera e potrebbero cambiare per un giorno ma non per un altro, queste
richieste devono essere segmentate per giorno (la colonna date deve essere presente). Ad esempio, un report keyword con le colonne clicks, actions e date restituirà una riga per ogni parola chiave e data in cui il numero registrato di clic o azioni è cambiato dal timestamp specificato.
Il timestamp non deve risalire a otto giorni prima dell'ora della richiesta. Per acquisire tutte le metriche in evoluzione, assicurati di inviare una richiesta changedMetricsSinceTimestamp almeno una volta ogni 7 giorni e di creare un report completo per ogni data una volta che le metriche sono state liquidate (è più sicuro attendere almeno 7 giorni). Un pattern di esempio è la creazione di due report ogni giorno: un report incrementale per le metriche che sono cambiate nelle ultime 36 ore e un report completo per le metriche che si sono verificate 8 giorni prima.
changedAttributesSinceTimestamp=timestampAttributi delle richieste che sono cambiati dopo il timestamp specificato. Una richiesta changedAttributesSinceTimestamp può includere solo colonne di attributi (nessuna colonna di metrica o segmento) e non funziona per i report sugli eventi non elaborati, ad esempio i report conversion. Ad esempio, un report campaign con le colonne dailyBudget e campaignStartDate restituirebbe una riga per ogni campagna il cui budget giornaliero o la data di inizio sono cambiati rispetto al timestamp specificato.
Tieni presente che le modifiche agli attributi principali non vengono acquisite nei report changedAttributesSinceTimestamp. Ad esempio, una parola chiave può ereditare la strategia di offerta dal gruppo di annunci principale.
Anche se al gruppo di annunci è assegnata una nuova strategia di offerta, la parola chiave in questione potrebbe non essere visualizzata nel report. Le colonne degli attributi il cui valore dipende
dalle entità padre (e pertanto potrebbero cambiare senza essere rilevate
dai report changedAttributesSinceTimestamp) hanno in genere
il prefisso "effective", come effectiveLabelIds o
effectiveBidStartegy.
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2023-12-14 UTC.
[null,null,["Ultimo aggiornamento 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"]]
