Browse the help center

Block demand and inventory (pre-targeting blocks)

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.

How-to network manager publisher Account → Publishers → site → zone → placement → Banners probability

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. 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

  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

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 asRule typeWhat stops serving
BannerBlocked Bannersthat one creative; the campaign’s other banners keep serving
CampaignBlocked Campaignsevery banner in that campaign
AdvertiserBlocked Advertisersevery 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.

OnRule is written onRows createdReach
Placementthe placement1this placement only
Sitethe site the placement belongs to1every placement under that site, including ones added later
All sitesevery site your account can currently seeone per sitethose 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

  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.

RuleOwned byShown as Blocking onShown as is Blocked by onRemoved from
Blocked Banners / Campaigns / Advertisers, scope Placementthe placementthe placementthe entity it names, and everything under it — an advertiser block also surfaces on each of that advertiser’s campaigns and bannersthe placement’s Pre-targeting card
Blocked Banners / Campaigns / Advertisers, scope Site or All sitesthe site (one row per site)the site — and every placement under itsame as aboveeach site’s Pre-targeting card
Blocked Sitesthe banner or campaignthat banner or campaignthe named site, and its zones and placementsthe banner’s/campaign’s Targeting card, or Unblock site in analytics
Blocked Placementsthe banner or campaignthat banner or campaignthe named placement onlythe 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)

ControlOptionsWhat it does
Header—Reads Block <name>, where the name is the row’s name at the current grouping level — not necessarily the entity you are about to block
Block asBanner, Campaign, AdvertiserChooses the rule type. Only the grouping level and the levels above it are offered
OnPlacement, Site, All sitesChooses 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)

ButtonAppears whenWhat it does
Block site / Unblock siteBlocked Sites enabled, report grouped by Site and by Campaign or BannerAdds/removes a Blocked Sites rule on the row’s banner (or campaign)
Block placement / Unblock placementBlocked Placements enabled, report grouped by Placement and by Campaign or BannerAdds/removes a Blocked Placements rule the same way
Block channelChannel targeting enabled, report grouped by Banner and ChannelAdds a Channel exclude rule — a dimension rule, not a named block
Set banners OFFBanner-status permissions, report grouped by BannerDeactivates the banner; unrelated to blocking
ClearalwaysClears the selection

Groups in the Targeting / Pre-targeting card

HeadingContainsChips
Excluded: Blocking (N)blocks this entity holds, plus blocks inherited from its site or campaignremovable, with Clear all for the group
Excluded: is Blocked by (N)blocks other entities hold against this oneremovable 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 pages

Please disable Adblock
Are you using adblock? Disable it and reload the page to proceed to the destination page.

A registration has already been submitted from this page. Please try again in 10 minutes.