---
title: "Block demand and inventory (pre-targeting blocks)"
description: "Block a named advertiser, campaign or banner on your inventory — or a named site or placement on your demand — then find, remove and audit the rules that result."
type: "howto"
audience: [network-manager, publisher]
keywords: [block, blocked advertisers, blocked campaigns, blocked banners, blocked sites, blocked placements, pre-targeting, unblock, blocked by, banners probability]
ui_path: "Account → Publishers → site → zone → placement → Banners probability"
---

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.

# Block demand and inventory (pre-targeting blocks)

Besides dimension rules (browser, operating system, day of week…), the two sides of the
platform can refuse each other **by name**:

- **Inventory blocks demand** — a placement or site refuses a named banner, campaign or
  advertiser.
- **Demand blocks inventory** — a banner or campaign refuses a named site or placement.

Both are stored as ordinary targeting rules, in five dedicated rule types: *Blocked Banners*,
*Blocked Campaigns*, *Blocked Advertisers*, *Blocked Placements* and *Blocked Sites*. They
never appear in the add-rule picker on the Targeting card, whatever your permissions: blocks
come only from the two flows below.

## Who this is for

- **Publishers and network managers** refusing a named advertiser, campaign or banner on their
  own inventory, from the **Banners probability** grid on a placement.
- **Advertisers and network managers** refusing a named site or placement from their demand,
  from an analytics report.

> **Before you start:** blocking by name is switched **off for all three roles as shipped** — on
> both sides. The Banners probability grid is there, and reports run as usual, but the **Block**
> buttons are not drawn until your network administrator turns the scope you need on for your role. See
> [Per-role notes](#per-role-notes). Read the rest of this page to know what to ask for: each
> scope — this placement, this site, all sites — is switched on separately, as is being able to
> see *who blocked me*.

## Prerequisites

- The placement is saved, and the banners you want to block are eligible to serve on it — the
  Banners probability grid is a live simulation, so it only lists demand that could win right
  now.
- For the analytics flow, a report that has run and returned rows, grouped so that the
  buttons appear (see the table under *Options & fields*).

## Steps — block an advertiser, campaign or banner on your inventory

1. Go to **Account → Publishers → site → zone → placement** and scroll to **Banners
   probability**. The grid lists every eligible banner with its computed share of the
   placement's traffic.
2. Optionally narrow it: the **Search** box matches advertiser, campaign and banner names, and
   **Grouping** (Banner / Campaign / Advertiser) collapses the grid to that level.
3. On the row you want, click the **Block** button at the end of the row (a circle-with-slash
   icon). A popover opens headed **Block
   *<row name>*** with two choices:
   - **Block as** — *Banner*, *Campaign* or *Advertiser*. Only the current grouping level and
     the levels above it are offered, so grouping by Advertiser leaves *Advertiser* as the
     only choice.
   - **On** — *Placement*, *Site* or *All sites*. A control with a single option renders as
     plain text rather than a segmented button.

   ![Placement edit page with the block popover open on a Banners probability row](https://epom.com/docs-images/ad-server/pretargeting-blocking/block-from-probability.webp)

4. Click **Block**. A confirmation dialog asks *"Block advertiser on site?"* (the wording
   follows your two choices). Click **Confirm**.
5. On success a green toast reads *"Successfully blocked advertiser on the specified scope"*
   and the grid reloads.
6. Open the **Pre-targeting** card of the entity you wrote the rule to — the placement for a
   *Placement* scope, the site for *Site* and *All sites*. The new rule sits under
   **Excluded: Blocking**, as a chip such as `Advertiser: Northwind Media`.

   ![Pre-targeting card showing a Blocking group and the always-applies warning](https://epom.com/docs-images/ad-server/pretargeting-blocking/blocked-groups-in-card.webp)

> **Note:** the rule is saved immediately, but the Banners probability grid reads the
> ad-server's in-memory cache. The blocked row can survive the reload that follows the toast
> and disappear only after the next cache refresh.

### What each choice actually writes

**Block as** decides which entity the rule names, and therefore how much demand it removes.

| Block as | Rule type | What stops serving |
|---|---|---|
| Banner | Blocked Banners | that one creative; the campaign's other banners keep serving |
| Campaign | Blocked Campaigns | every banner in that campaign |
| Advertiser | Blocked Advertisers | every campaign the advertiser has — including campaigns created *after* you set the block, because the ad server resolves the advertiser's campaign list at request time |

**On** decides where the rule is stored, and therefore how much inventory it covers.

| On | Rule is written on | Rows created | Reach |
|---|---|---|---|
| Placement | the placement | 1 | this placement only |
| Site | the site the placement belongs to | 1 | every placement under that site, including ones added later |
| All sites | every site your account can currently see | one per site | those sites only — **a site created afterwards is not covered**, because the fan-out is a snapshot taken when you click Block |

> **Corner case:** *All sites* is not a switch, it is a bulk write. For a banner-level block
> the fan-out covers the sites shared with you plus any site the banner is already linked to;
> for campaign and advertiser levels it covers the sites shared with you. Each resulting row
> is independent, so undoing it means removing the chip on every site one at a time — there is
> no "unblock everywhere" action.

## Steps — block a site or placement from your demand

This is the mirror direction: the rule is written on a **banner** or **campaign** and names a
site or placement.

1. Go to **Account → Analytics** and build a report that groups by **Site** (or **Placement**)
   *together with* **Banner** or **Campaign** — the buttons only appear for those combinations.
2. Click **Run report** and wait for the results grid.
3. Tick the rows whose traffic you want to cut off. A highlighted selection bar appears above
   the grid reading *"N selected"*.
4. Click **Block site** or **Block placement**.

   ![Analytics report with a row selected and the Block site button in the selection bar](https://epom.com/docs-images/ad-server/pretargeting-blocking/block-from-analytics.webp)

5. A toast reads *"Records have been blocked"*. The rule is written to each selected row's
   **banner** if the report groups by Banner, otherwise to its **campaign**.
6. To undo, select the same rows and click **Unblock site** / **Unblock placement**, or open
   the banner's (or campaign's) **Targeting** card and remove the chip from
   **Excluded: Blocking**.

> **Warning:** the analytics toast is not evidence. The buttons report *"Records have been
> blocked"* whether the server accepted the write, refused it for permissions, or matched
> nothing at all. After a bulk block or unblock, confirm on the banner's or campaign's
> **Targeting** card that the chips are what you expect.

## Where a block appears, and where to remove it

A block is one row, shown from both ends. The side that owns it sees it under **Blocking**;
the side it was aimed at sees it under **is Blocked by** — and that second group exists only
for users who hold **Blocked by**.

| Rule | Owned by | Shown as **Blocking** on | Shown as **is Blocked by** on | Removed from |
|---|---|---|---|---|
| Blocked Banners / Campaigns / Advertisers, scope *Placement* | the placement | the placement | the entity it names, and everything under it — an advertiser block also surfaces on each of that advertiser's campaigns and banners | the placement's Pre-targeting card |
| Blocked Banners / Campaigns / Advertisers, scope *Site* or *All sites* | the site (one row per site) | the site — **and every placement under it** | same as above | each site's Pre-targeting card |
| Blocked Sites | the banner or campaign | that banner or campaign | the named site, and its zones and placements | the banner's/campaign's Targeting card, or **Unblock site** in analytics |
| Blocked Placements | the banner or campaign | that banner or campaign | the named placement only | the banner's/campaign's Targeting card, or **Unblock placement** in analytics |

> **Corner case:** a placement's Pre-targeting card lists its **site's** blocks inside its own
> **Blocking** group, with nothing to mark them as inherited (a banner does the same with its
> campaign's blocks). The chip's ✕ deletes the original rule at the site or campaign, for
> every placement or banner under it — not a local copy. Before removing a chip you did not
> create, check the site's own card to see whether it lives there.

> **Corner case:** the same entity blocked at both placement and site level produces two chips
> with identical text in the placement's Blocking group. Removing one leaves the other in
> force.

**Unblocking is direction-specific.** The analytics **Unblock site** / **Unblock placement**
buttons only remove *Blocked Sites* and *Blocked Placements* rows from a banner or campaign.
They cannot touch a
publisher's block on their inventory, and nothing in analytics can — those come off the
placement's or site's own Pre-targeting card.

## What the blocked advertiser sees

Nothing, by default. A blocked banner simply stops being selected; there is no notice, no
status change, and no entry on the campaign — the traffic just stops. The ad server files the
drop under the same generic *targeting* exclusion it uses for any rule that did not match, so
even a troubleshooting trace does not separate "the publisher blocked this creative" from "it
failed the country rule".

The one place it does surface is the entity's own **Targeting** card, under **is Blocked by**,
with a chip like `By Site: Harbour Gazette` or
`By Site: Harbour Gazette > Zone: Homepage > Placement: Article MPU`. That group is added only
for users holding **Blocked by** — so two people can open the same banner and only one of them
learns that a publisher has blocked it. It aggregates upwards too: a banner shows blocks aimed
at its campaign and its advertiser, not only at itself.

> **Corner case:** a name in these chips is masked when you cannot view that advertiser or site,
> and — if your account has **Mask Campaigns** or **Mask Inventory** — also when you do not own it.
> The masking applies on every targeting card, supply and demand. The masked text is built from
> the id (`ADVERTISER_9`, `SITE_4`), except on a masked **blocked-advertiser** chip, which can
> show the bare type token `BLOCKED_ADVERTISERS` instead of any label.

> **Corner case:** an **is Blocked by** chip for a *banner*-level block on a site, zone or
> placement card ends in a stray fragment of HTML —
> `… > Banner: Northwind MPU 300x250 <a href="/account/advertisers/banner-preview.do?…"></a>`.
> Ignore the tail; the part before it is the real value.

## Options and fields

**Block popover** (Banners probability grid)

| Control | Options | What it does |
|---|---|---|
| Header | — | Reads **Block *&lt;name&gt;***, where the name is the row's name **at the current grouping level** — not necessarily the entity you are about to block |
| Block as | Banner, Campaign, Advertiser | Chooses the rule type. Only the grouping level and the levels above it are offered |
| On | Placement, Site, All sites | Chooses where the rule is written. One option per **Block … on …** permission you hold |
| Block | — | Opens the confirm dialog (**Confirm** / **Cancel**) |

**Analytics selection bar** (appears once at least one result row is ticked)

| Button | Appears when | What it does |
|---|---|---|
| Block site / Unblock site | **Blocked Sites** enabled, report grouped by Site **and** by Campaign or Banner | Adds/removes a *Blocked Sites* rule on the row's banner (or campaign) |
| Block placement / Unblock placement | **Blocked Placements** enabled, report grouped by Placement **and** by Campaign or Banner | Adds/removes a *Blocked Placements* rule the same way |
| Block channel | **Channel** targeting enabled, report grouped by Banner **and** Channel | Adds a Channel *exclude* rule — a dimension rule, not a named block |
| Set banners OFF | Banner-status permissions, report grouped by Banner | Deactivates the banner; unrelated to blocking |
| Clear | always | Clears the selection |

**Groups in the Targeting / Pre-targeting card**

| Heading | Contains | Chips |
|---|---|---|
| **Excluded: Blocking (N)** | blocks this entity holds, plus blocks inherited from its site or campaign | removable, with **Clear all** for the group |
| **Excluded: is Blocked by (N)** | blocks other entities hold against this one | removable unless your **Blocked by** grant is read-only |

Blocked rules are always *exclude* rules — the server rejects anything else with *"Please use
only Exclude rule."* — so both groups only ever render an **Excluded:** block, never an
**Included:** one.

## Corner cases and gotchas

> **Corner case:** blocks keep working when targeting is switched off, but you cannot see
> them. The ad server loads blocked-entity rules regardless of an entity's targeting switch,
> so turning **Pre-targeting** off does not release anything you blocked. The card, however,
> refuses to open while its switch is off and never fetches the rule list — so a placement
> with blocks and targeting off shows an empty, un-expandable card while quietly rejecting
> demand. Switch targeting back on to see, or remove, what is there.

> **Corner case:** creating a block silently switches targeting **on** for the entity that
> receives the rule, because the write path enables it. Any positive rules that entity already
> had — and that you had deliberately parked by switching the card off — start applying again
> at the same moment. The page does not repaint the switch, so it still reads *off* until you
> reload the page; reload after blocking to see the real state.

> **Corner case:** setting an entity's rule-type operator to **OR** can stop its blocks being
> applied. Rule types are evaluated in order with blocked types last, and OR stops at the
> first type that passes — so a placement with any passing dimension rule never reaches its
> blocked list. Leave entities that block on the default **AND**.

> **Corner case:** the popover header and the confirmation dialog can both name the wrong
> thing. With **Grouping** on *Banner* and **Block as** on *Advertiser*, the header still
> reads *"Block Northwind Leaderboard 728x90"* and the dialog only says *"Block advertiser on
> site?"* — neither names the advertiser you are about to remove from the placement. Read the
> **Block as** control, not the header.

> **Corner case:** the ✕ on a blocked chip is drawn for anyone who can manage the card, even
> without the blocked-type permission. Without **Show Blocked Banners** the click comes back
> as *"You do not have permission to delete target for this Zone"* and the chip stays. The toast
> says "Zone" whichever entity the card is on — its wording is fixed in the card.

> **Corner case:** blocking from analytics writes one rule per selected row, in sequence. A
> failure part-way through leaves the earlier rows blocked and the rest untouched — and the
> success toast still appears.

> **Corner case:** a block that points at a deleted entity is kept but hidden
> from the card, so restoring a deleted banner or site also restores every block that named
> it.

> **Corner case:** the REST API covers the blocks only in part. It can create *Blocked Sites* and
> *Blocked Placements* on an advertiser, a campaign or a banner
> (`POST /rest-api/{advertiser|campaign|banner}/{id}/targeting/{site|placement}/create.do`), and it
> can block advertisers on a placement
> (`POST /rest-api/placement/{placementId}/targeting/advertiser/create.do?advertiserIds=…&rule=…`,
> which needs **Block Advertiser/Campaign/Banner on Placement**). It cannot block a campaign or a
> banner on a placement, or anything on a site or a zone — those come only from the Banners
> probability grid. `GET /rest-api/blocked/entities.do` lists the blocked advertisers and placements
> visible to the caller. The placement endpoint does not restrict `rule` to Exclude the way the
> console does (*"Please use only Exclude rule."*); send `EXCLUDE`.

## Per-role notes

- **Publisher** — blocks from the **Banners probability** card on a placement. Each scope
  (placement, site, all sites) is switched on separately, so you may block on one placement but
  not site-wide.
- **Advertiser** — blocks from an analytics report; **Block site** and **Block placement** are
  switched on independently.
- **Network manager** — both entry points, once your network administrator switches them on.
- **Shared-entity viewer** — on a **Can View** share, blocked chips have no ✕ or **Clear all**
  and no Block button appears; blocking needs **Can Edit** or **Is Owner**.

## Related

- [Targeting and pre-targeting overview](https://epom.com/ad-server/docs/guides/targeting.md)
- [Add, edit, and remove targeting rules](https://epom.com/ad-server/docs/guides/targeting/add-targeting.md)
- [Targeting dimension reference](https://epom.com/ad-server/docs/reference/targeting-dimensions.md)
- [Run a report](https://epom.com/ad-server/docs/guides/analytics/run-report.md)
- [Keep unwanted ad categories off your inventory](https://epom.com/ad-server/docs/guides/targeting/block-ad-categories-on-inventory.md) — block by category instead of by name
- [Attach matching rules to an entity](https://epom.com/ad-server/docs/guides/targeting/entity-matching-rules.md)
- [Brand safety controls](https://epom.com/ad-server/docs/use-cases/brand-safety-controls.md)