Challenges using Adobe Reporting API 2.0

Question

Hello everyone,We are implementing Adobe Reporting API 2.0, since version 1.4 will be deprecated in August 2026. During implementation, we encountered a limitation in the API design that affects our use case.In Reporting API 2.0, data retrieval is based on dimensions (descriptive attributes such as customer ID, date, page) and metrics (calculated measures such as pageviews and visits). The API always returns aggregated results based on the dimensions provided.Our requirement is to ingest historical data at the lowest possible granularity (near event-level) and/or perform daily loads. To achieve this, we would need to include multiple dimensions (e.g., date, customer ID, page). However, the API processes breakdowns by sending separate requests for each combination of dimensions if we want all dimensions and metrics in a single table.Example:	50 days			30 customers			10 pages	This would result in 50 × 30 × 10 = 15,000 API requests.Given this structure, the API appears not scalable for historical ingestion, and daily loads would also be challenging. The nested dimension logic significantly increases processing time, complexity, and the risk of hitting API limits.We would greatly appreciate any recommendations or best practices for:	Efficiently ingesting historical data at near-event granularity			Managing large-scale daily loads without creating excessive API requests	We have heard about Adobe Data Feeds and are waiting for a response from our Adobe team, but we would also like to know if anyone is using Adobe Analytics 2.0 for daily workloads involving multiple dimensions and metrics in a single table.Thank you in advance for your guidance!

manpreetkaur27 · Accepted Answer

For the requirements you described, you can try this:

1. Historical data at near-event granularity
If the goal is to ingest data at the lowest practical granularity, the better option is Adobe Analytics Data Feeds rather than Reporting API 2.0.

Data Feeds are intended for raw data export and provide:

Hit-level output
Hourly or daily delivery
Delivery to supported cloud destinations for downstream ingestion into your data lake or warehouse

This is typically the best option when you need to preserve detailed behavioral data and avoid the explosion of API requests caused by dimension-by-dimension breakdown logic.

2. Large-scale daily loads
For recurring daily or hourly ingestion, Data Feeds are again the preferred option when you need detailed data.

If instead the need is for large flat aggregated tables at a daily grain, such as combinations of date + customer + page + metrics, then Data Warehouse is generally a better fit than Reporting API 2.0. Data Warehouse is built for large tabular exports and avoids the same staged request pattern required by the Reporting API.

Jennifer_Dungan · Answer

Yeah, I don’t actually like API 2.0 as much as I liked API 1.4

For simple requests, 2.0 is fine… but as you said, the new API isn’t scalable!

Data Feeds are good, but a very different way to pull data… first off, they are full raw data… so you will have to process the exclusions (exclude_hit), the User and Visit calculations… You will have to map the “backend numerical event references” to the correct events, etc.

Some key pointers… make sure you are using “post_***” values where ever possible… any data that gets processed in your system via Processing Rules or Vista Rules will be set correctly only in the post_ version.

Also note, there is no specific “Page View” event, this is calculated by there being a post_page_url or post_page_name value.

The raw data will provide a table export of every hit, and the columns you specify… but all the calculations will be on you.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded