---
title: "Header bidding reports and targeting"
description: "What the Header Bidding report, the Traffic Source dimension and the win-rate figures say about header-bidding traffic, and how a Traffic Source targeting rule aims demand at it or keeps it off."
type: "reference"
audience: [network-manager, admin]
keywords: [header bidding report, fill source, fill rate, fills, unfilled, traffic source, HEADER_BIDDING, win rate, opportunities, lost opportunities, advanced report, impressions log, clicks log, targeting, pre-targeting]
ui_path: "Account → Analytics"
---

Fetch the complete documentation index at: https://epom.com/ad-server/docs/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version.

# Header bidding reports and targeting

Once a tag is live, two reports show what header bidding brought in, and a targeting rule aims
demand at that traffic or keeps it off. This page covers both; to set a tag up, start from
[Header bidding](https://epom.com/ad-server/docs/guides/inventory/header-bidding.md).

## Who this is for

Network managers and admins who read **Analytics** or set targeting rules. The Header Bidding
report type, the Traffic Source dimension and the Traffic Source targeting rule each need a
permission of their own — see [Permissions](https://epom.com/ad-server/docs/guides/inventory/header-bidding.md#permissions).

## Reporting

Two reports read header bidding, and they answer different questions. The **Header Bidding**
report says who filled each slot the page auctioned — us, Google, a partner, nobody. The **Traffic
Source** dimension on the Advanced and log reports tells the impressions and clicks we won through
header bidding apart from the same placement's ordinary ad-tag traffic. Each needs its own
permission — see [Permissions](https://epom.com/ad-server/docs/guides/inventory/header-bidding.md#permissions).

### The Header Bidding report

**Account → Analytics**, report type **Header Bidding**. It is its own table, filled by a beacon the
page tag fires for every render outcome, so it reports rounds and fills rather than impressions —
and a fill Google made never touches placement limits, pacing or publisher payouts.

Group by any of **Fill Source**, **Country**, **Placement**, **Zone**, **Site**, with a time
breakdown from hour to year. Fill Source takes these values:

| Fill Source | What filled the slot |
| --- | --- |
| Direct campaigns | A campaign booked on this platform won the round — our own bid |
| Ad server (GAM) | A line item in the publisher's Google Ad Manager filled it |
| AdX / AdSense | Google's own demand filled it — backfill with no line item, the "Google outbid us" case |
| *a partner's name* | A bidder you added under Other bidders won; an alias shows as the alias |
| Unfilled | Nobody took the round. Without it the shares of the others mean nothing |

Columns: **Fills**, **Unfilled**, **Fill Rate**, **Gross** and **eCPM Gross** — the last two only
with the ordinary Gross column grants. A price is recorded for our own fills and for a partner's, at
the CPM that won; an Ad Manager or AdX / AdSense fill carries 0, because Google never exposes a
price. The report has no channel filter and no advertiser tree: it is supply-side and records
neither. The site, zone and placement pickers and the country filter apply, and a **Fill Source**
filter of its own narrows it to one or more sources. That filter lists only sources that have
actually been recorded — a partner nobody has filled for yet is not in it — and, unless the role
holds Inventory *View* at All, only the ones recorded on sites shared with the viewer, so one
network's demand partners are not shown to another's users. The report is a console feature: the
REST report endpoints do not support the Header Bidding type. For a Google Ad Manager publisher
this table is the whole story of the integration: *Direct campaigns* is what the deal line item is
winning, the two Google rows are what Google keeps, and *Unfilled* is what neither side had.

### Traffic Source on the Advanced and log reports

Impressions and clicks won through header bidding are tagged as their own source. Report on them in
**Account → Analytics → Advanced**, grouping by **Traffic Source**. The header-bidding row is
labelled `HEADER_BIDDING`; the blank row is everything that arrived through an ordinary ad tag,
which is deliberately left unmarked so no historical figure moves. The same dimension is a filter,
and a column and filter on the **Impressions Log** and **Clicks Log** raw reports. It is absent
from the **General** report on purpose: the marker lives only in the ad-server logs the Advanced
and raw-log reports read, not in the aggregated tables General is built on. Those report types are
granted on the Admin roles page — see [Permissions](https://epom.com/ad-server/docs/guides/inventory/header-bidding.md#permissions). Reference:
[Analytics dimensions](https://epom.com/ad-server/docs/reference/analytics-dimensions.md).

### Win rate

Every slot header bidding is asked to price is recorded, whether it produced a bid or not, so group
by Traffic Source and read **Opportunities** (slots we bid on), **Direct requests** (bids plus
no-bids) and **Deliveries** (bids that won and rendered): win rate is Deliveries ÷ Opportunities,
and the report also gives it directly as *Lost opportunities, %*. That figure is Opportunities minus
Deliveries plus any *Rejected impressions*, over Opportunities, so it is 100% minus the win rate
only while nothing was rejected.

These are ad-request records, so they follow the same switch as every other ad-request record: a
network that does not log the ad-request event for Advanced reporting gets deliveries and no requests, and a win
rate computed from that row reads **100%**. That is the event being switched off, not a real figure.

## Targeting header-bidding traffic

Header bidding is also a **targeting** dimension, so demand can be aimed at it or kept off it. Add
a **Traffic Source** rule on an advertiser, campaign or banner and tick **Header Bidding**: *include*
runs the entity only on header-bidding traffic, *exclude* keeps it off. The same rule exists on the
supply side — site, zone, placement — as pre-targeting, so a placement can refuse or reserve its
header-bidding rounds. It is added the way every other rule is: see
[Add targeting](https://epom.com/ad-server/docs/guides/targeting/add-targeting.md) and the
[targeting dimensions reference](https://epom.com/ad-server/docs/reference/targeting-dimensions.md).

Because an ordinary ad tag carries no traffic source, *include Header Bidding* refuses tag traffic
and *exclude Header Bidding* lets it through. Today the only value is Header Bidding, so the two
read as "header bidding only" and "everything but header bidding". Without the **Traffic Source**
permission (one for the supply side, one for the demand side) the dimension is not offered in the
rule picker.

## Related

- [Header bidding](https://epom.com/ad-server/docs/guides/inventory/header-bidding.md)
- [Header bidding tag settings and slots](https://epom.com/ad-server/docs/guides/inventory/header-bidding-settings.md)
- [Header bidding with Google Ad Manager](https://epom.com/ad-server/docs/guides/inventory/header-bidding-gam.md)
- [Header bidding on a site that runs its own Prebid.js](https://epom.com/ad-server/docs/guides/inventory/header-bidding-own-prebid-js.md)
- [Header bidding through a Prebid Server](https://epom.com/ad-server/docs/guides/inventory/header-bidding-prebid-server.md)
- [Header bidding in an app with Prebid Mobile](https://epom.com/ad-server/docs/guides/inventory/header-bidding-prebid-mobile.md)
- [Analytics dimensions reference](https://epom.com/ad-server/docs/reference/analytics-dimensions.md)
- [Targeting dimensions reference](https://epom.com/ad-server/docs/reference/targeting-dimensions.md)
- [Manage users, roles and permissions](https://epom.com/ad-server/docs/guides/admin/users-and-roles.md)