Restricting what Advertisers can Run

Publishers can restrict eligible bidders for a specific adrequest using key information that DSPs pass back in their bid responses.

The following sections list the primary data segments that publishers use to evaluate and restrict bids.

Publishers may restrict a given adrequest to specific buyers (for example, DSP platforms) or seats (for example, accounts within a DSP platform).

Publishers may restrict a given adrequest to specific campaigns or creatives identified by the IDs provided by a DSP platform.

Publishers may restrict a given adrequest to prevent bids as identified by:

  • adomain – This value generally represents a campaign landing page, such as landingpage1.com or landingpage2.co.uk.
  • bundle – This value represents a mobile app identifier, such as co.intersection.link.wifi, which a DSP platform provides to identify the specific application when a campaign targets a mobile app.

Publishers may restrict a given adrequest to prevent bids as identified by bcat (IAB category for a creative, as confirmed by Place Exchange PubOps).

Note: Blocking a parent category will block the child categories. For example, registering Tier-1 IAB1 will block all Tier-2 sub-categories IAB1-*.

Publishers may restrict a given adrequest to prevent bids as identified by battr (OpenRTB Creative Attribute).

Publishers can pass values that are either defined by OpenRTB specs or are custom blocked attributes. These restrictions can be set on the AdUnit level as well.

Note: Place Exchange does not pass custom battr IDs to Demand-Side Platforms (DSPs) in bid requests because some DSPs lack the capability to process them. Publishers, however, may continue to pass custom battr IDs for future use. We will continue to send standard OpenRTB battr IDs to DSPs.

OpenRTB Restricted Values

  • AUDIO_AUTO_PLAY = 1
  • AUDIO_USER_INITIATED = 2
  • EXPANDABLE_AUTOMATIC = 3
  • EXPANDABLE_CLICK_INITIATED = 4
  • EXPANDABLE_ROLLOVER_INITIATED = 5
  • VIDEO_IN_BANNER_AUTO_PLAY = 6
  • VIDEO_IN_BANNER_USER_INITIATED = 7
  • POP = 8 (Eg: Over, Under, or upon Exit )
  • PROVOCATIVE_OR_SUGGESTIVE = 9
  • ANNOYING = 10 (Defined as Shaky, Flashing, Flickering, Extreme Animation, Smileys)
  • SURVEYS = 11
  • TEXT_ONLY = 12
  • USER_INTERACTIVE = 13 (Eg: embedded games )
  • WINDOWS_DIALOG_OR_ALERT_STYLE = 14
  • HAS_AUDIO_ON_OFF_BUTTON = 15
  • AD_CAN_BE_SKIPPED = 16
  • FLASH = 17

Place Exchange Custom Restricted Values

  • AESTHETIC_PROBLEMS = 500
  • BLURRY_PIXELATED = 501
  • CLICK_HERE_CTA = 502
  • ERROR_RENDERING = 503
  • ILLEGIBLE = 504
  • GIF = 505
  • IMAGE_FALLBACK = 506
  • IMAGE_SCREENSHOT = 507

Publishers may restrict a given adrequest to specific languages that are defined in the wlang field.

Publishers can pass values that are defined in https://www.loc.gov/standards/iso639-2/php/code_list.php column named ISO 639-1 Code. These restrictions can be set on the AdUnit level as well.

Publishers may restrict a given adrequest to a specific btype (OpentRTB Banner Ad Type).

Publishers can pass the following values. These restrictions can be set on the AdUnit and Network level as well.

  • XHTML Text Ad (usually mobile) = 1
  • XHTML Banner Ad. (usually mobile) = 2
  • JavaScript Ad; must be valid XHTML that is, Script Tags Included) = 3
  • iframe = 4

Keywords allow publishers to tag ad creatives with custom labels during the review process. The system can then match these keywords against restrictions configured on your inventory, so ads tagged with a restricted keyword are automatically filtered out at auction time.

This gives publishers a flexible, custom taxonomy for blocking ads that goes beyond standard IAB categories or advertiser domain restrictions.

The restrictions feature has two parts that work together: