Before Starting
The following information is important to know regarding Demand Side Analytics.Asynchronous Workflow
Reports are requested and retrieved using asynchronous endpoints.Report Date Range
The report date range supports a maximum window of 100 days, with data retained for up to 3 years.Report Row Limits
Reports are limited to 10 million rows. If a report reaches this limit, the data may be incomplete due to truncation. To avoid this, consider reviewing the following parameters for bulk requests:- Number of campaign or line item IDs
- Start and end date range
- Number of dimensions and metrics selected
Report Attribution
- Report attribution windows and time-zones are fully configurable.
- Data is processed and batched hourly. Same-day data may be partially available.
- While reports with an end date of today or yesterday are cached for 1 hour, reports with an end date older than yesterday are cached for 24 hours.
- The exact expiration time is provided in the
expiresAtfield of the /status response.
Rate Limits
You can find more details about rate limits on this page.OAuth Method | Rate limit | Rate limit applies at level |
|---|---|---|
250 callsper minute for default endpoints 40 callsper minute for reporting endpoints | Application level | |
10 callsper minute | Account |
Data Latency
Please refer to our troubleshooting guide for more data latency details.Different types of activity and attribution data become available at different times after the event or sale:
- Onsite activity data is typically available within 6–8 hours of the event.
- Offsite activity data is typically available within 24 hours of the event.
- Initial attribution data is available within 7–9 hours of the sale.
- Final attribution data is processed and posted within 74 hours after the sale.
- Please note that potential minor updates can occur up to 120 hours before finalization
Learn more about our Attribution Rules in the Commerce Max Help Center.
What changed in this version
Previous versions exposed three aggregation-level endpoints —POST /reports/campaigns, POST /reports/line-items, and POST /reports/accounts — together with a reportType field that selected a preset report shape (summary, keyword, pageType, capout, attributedTransactions, and so on). That model has been replaced by a smaller, explicit, and more predictable set of endpoints.
What is different from the previous model:
- One performance endpoint instead of three.
/reports/campaigns,/reports/line-items, and/reports/accountsare all replaced byPOST /reports/performance. You choose the scope by which ID array you pass underfilters, and the output granularity by the dimensions you select. reportTypeis gone. You now always specifymetricsanddimensionsexplicitly. The preset report types (keyword,pageType,productCategory,product,servedCategory,environment, …) are reproduced simply by adding the corresponding dimension to your request.- Scope moved into a
filtersobject. Instead of top-levelaccountId/campaignId/lineItemId, provide exactly one offilters.accountIds[],filters.campaignIds[], orfilters.lineItemIds[]. startDate,endDate,filters,metrics, anddimensionsare all required on the new endpoints.- Two purpose-built use cases are split into their own endpoints.
capoutandattributedTransactionsare no longerreportTypevalues — they are dedicated endpoints, each with a few field/metric renames documented on its own page.
Migrating from the legacy reporting API
Map your existing calls to the new endpoints using the table below. In every case you also need to update the request shape as described above: move the scope into afilters object, add explicit metrics and dimensions, and remove reportType.
Endpoint-specific rename details live on each endpoint page: see Missed Opportunities Report and Attributed Transactions Report.