> For the complete documentation index, see [llms.txt](https://docs.relevant-digital.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.relevant-digital.com/hb-analytics/reporting-and-metrics/how-to-use-hb-historical-reports-dimensions-and-metrics.md).

# How to Use HB Historical Reports - Dimensions and Metrics

This article outlines the features and limitations of HB Historical Reports, focusing on historical data, available dimensions and metrics, and their comparison with real-time data from HB Analytics Reports.

**HB Historical Reports** focus on reporting historical data, enabling users to look back in time (e.g., a month or a year) with a focused set of available dimensions and metrics that are stored permanently. **HB Analytics Reports** concentrate on real-time data with a few more available dimensions and metrics but the data is stored for the last 30 days.

### Available Dimensions in HB Historical Reports:

* **Time Period**: Defines the granularity with which you would like the report to be broken down.
* **Placement**: The placement where the auction occurred.
* **Publisher**: The Publisher (Account) for which the auction occurred.
* **Site**: The site where the auction occurred.
* **Prebid Configuration**: This dimension shows the name of your Prebid configurations and automatically includes any child configurations you have created.
* **Bidder**: The SSP or source returning a bid through your Prebid configuration.

### Available Metrics in HB Historical Reports:

* **Revenue**: Gross revenue is the accumulated value of the winning bids used by the Prebid. Any winning bids that were overridden by the Ad server are included here. Thus, gross revenue represents what is generated by the Prebid setup.
* **Impressions**: The number of sold impressions used by the Prebid.
* **Bid Responses**: The number of bids that received a response.
* **No Bid Responses**: The number of bids that did not receive a response.
* **Timed Out Bids**: Bids that never received a response. This can depend on various factors, but it is usually due to slow loading times or a specified cut-off point for when to stop waiting for a response.
* **Bid Requests**: The number of bid requests sent from the auctions. Please note that an auction can contain many Ad Unit requests, and each Ad Unit request typically contains one bid per SSP/source connected. Some SSPs use one bid request per dimension per Ad Unit request, leading to multiple bids per Ad Unit request in order to traffic all the dimensions.
* **Ad Unit Requests**: The total number of Ad Unit requests. An auction can contain multiple Ad Unit requests as multiple placements (Ad Units) are requested in the same auction.
* **eCPM**: The eCPM is the average CPM of all impressions (both won and used bids).
* **Fill Rate %**: The percentage value of the number of impressions compared to the number of Ad Unit requests.
* **Timed Out Bids %**: The percentage of bids that timed out.
* **Ad Unit eCPM**: The average CPM of all Ad Unit requests.
* **Bid Rate %**: The percentage of bid requests that were answered with a bid response.

{% hint style="info" %}
**Note**: This metric is not compliant with the following dimensions:

* Bid Range
* Creative Size
* Media Type
* Revenue Type

Using Bid Rate % in combination with these dimensions will always result in a 100% Bid Rate %.
{% endhint %}

* **Bid Density %**: This is calculated as Bid Responses / Ad Requests (how many bid responses per request, which can be greater than 100%) due to some SSPs delivering more than one response.
* **Win Rate %**: Calculated as Impressions / Bid Responses.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.relevant-digital.com/hb-analytics/reporting-and-metrics/how-to-use-hb-historical-reports-dimensions-and-metrics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.