BidSwitch Targeting Groups¶

BidSwitch Targeting Groups allow you to set targeting configurations for the traffic you receive from BidSwitch. At the very minimum, a default Targeting Group will be applied to your traffic, which you can configure as you wish and use as a basis when creating other Targeting Groups.

The concept of Targeting Groups differs from how BidStream Settings previously worked, which was one default set of targeting settings or else a specific set of targeting settings per Supplier. Targeting Groups allows for greater flexibility by supporting many targeting sets which can be applied to one or more of your Suppliers.

Using Targeting Groups¶

Targeting Groups enables you to create a multitude of traffic filtering setups. While this flexibility allows you to target different niche traffic sources and apply those settings to various Suppliers, any overlapping or contradicting settings could result in some confusing outcomes. Taking the following fictional settings as examples:

Targeting Group 1, which targets first-price auction, Spanish language video inventory in the US, CA, and MX can be applied to traffic from SSP 1, SSP 4, and SSP 7
Targeting Group 2, which targets all traffic types and auction types, and video, display, and native inventory in the US and UK across all languages can be applied to traffic from SSP 1, SSP 2, and SSP 5
Targeting Group 3, which targets 2nd-price open-auction video, display, and native inventory in the US and UK but has an exclude list of website domains and app bundles can be applied to traffic from SSP 1, SSP 2, and SSP 7

Taking Targeting Group 2 and 3 above, the exclude list of website domains and app bundles will be applied by #3 but such traffic might be a positive match for #2, therefore you might see domains or app bundles from certain Suppliers which you thought excluded at SSP 1 and SSP 2

Taking Targeting Group 1 and 2 above, this could mean that while Spanish video is targeted only in the given countries, you may also see English videos available from any overlapping settings, in this case from SSP 1 in the US. The following interactive diagram aims to further outline the considerations necessary when configuring your Targeting Groups.

Regarding Targeting Groups interaction with QPS, please note the following:

Targeting Groups enable you to create a multitude of traffic filtering setups. While this flexibility allows you to target different niche traffic sources and apply those settings to various Suppliers, any overlapping or contradicting settings could result in some confusing outcomes. This is because Targeting Groups share the QPS you’ve set in your Data Center settings.
Targeting Group 2, which targets all traffic types and auction types, and video, display, and native inventory in the US and UK across all languages can be applied to traffic from Supplier 1, Supplier 2, and Supplier 5. Moreover, if Supplier 1 has QPS that exceeds your QPS limits, you may not receive much Spanish-language video requests from Targeting Group 1 because there is enough display and native traffic coming from Targeting Group 2 to hit the QPS limit.

Additional Example

Configuring Targeting Groups¶

To create a new Targeting Group, select Targeting Groups from the left-hand menu and click the Create Targeting Group button
To edit a Targeting Group, click on the name of the Targeting Group to be taken to the edit page
To pause a Targeting Group, click on the pause button on the far right
To delete a Targeting Group, you must first pause it. Once paused, click the three dot button and choose delete

When configuring a Targeting Group you can set each option individually or you can inherit settings from the Default Group by using the Copy Section from Default Group option. Either way, the following options can be configured per Targeting Group. You can also find a video tutorial explaining Targeting Groups configuration here, Targeting Groups Video Tutorial

Commercial Context¶

Traffic Type Set the traffic types that you want to get, i.e. receive open exchange / open deals / private deals traffic or any combination of them.
Auction Type Filter bid requests based on the auction type. The auction types available are First-price and Non First-price auctions, Non First-price auctions include 2nd price, fixed-price, and any other type. These are identified using the at field in bid requests. Auction Type Targeting means you will only receive bid requests from BidSwitch for the auction type you want.
Supply Partners Specify the Suppliers to whom you wish to apply the Targeting Group settings, you may select certain Suppliers or All current and future

Targeting¶

Ads.txt status Set the ads.txt statuses that you want the Targeting Group to send to you, e.g. direct, reseller, unauthorized, unknown. Unauthorized trading is currently allowed only for CTV inventory
Ad Type Set the media types that you want the Targeting Group to send to you, e.g. video, native, display, audio. The Require Video Placement Fields checkbox restricts the Targeting Group traffic to bid requests that include video.placement (Video Object, RTB 2.5) or video.plcmt (Video Object, RTB 2.6).
Device Type Set the device types for which the Targeting Group will send you traffic, e.g. mobile, tablet, CTV, Desktop.
Display Sizes Set the display format sizes that you want the Targeting Group to send to you, e.g. 320x50. Note: Only relevant for Display ad type
Geography Set the countries from which the Targeting Group will send you traffic, e.g. US, CA. You can also target Regions within countries, regions may have different names depending on the country such as States (USA e.g. Texas, Germany e.g. Berlin), Departments (France e.g. Île-de-France), or Prefecture (Japan e.g. Aichi).
Languages Set the languages for which the Targeting Group will send you traffic, e.g. en, fr.
Send Interstitial Traffic Enable or disable receiving requests for Interstitial ads.
Supply Chain Object Set whether you want to receive requests with a complete Supply Chain Object only.
Only Send Rewarded Traffic Set whether you want to only receive requests for rewarded impressions. These are usually video, but sometimes for display, and are indicated by the imp.rwdd field in Open RTB 2.6 and by video.ext.rewarded as an extension field in BidSwitch Buyer Protocol 5.3
Deals Filtering: Set whether you want to enable an exclude or include filtration list for deals. Find more details about deals filtering below.

Digital Out Of Home¶

If your integration is set up to trade DOOH, you can enable it per Targeting Group. If unsure, please verify with your account manager before enabling.

In-App Settings¶

If you enable In-App targeting, you can configure the following settings.

Location Data: By enabling the Send Only Bid Requests with Location Data option you will only receive bid requests for devices which have shared their location data. To enable this, select the Location Data option and save your changes.
Declared App Source: You can also block traffic that does not contain an application bundle or domain in the bid request by selecting the Declared app source checkbox. See the App Object section for the details of these fields.
Exclude or Include Lists: You can create include or exclude lists for Application Bundles. An exclude list means that you do not wish to bid on the given applications, and an include list means you only want to bid on those particular applications. All lists must be uploaded in a text file, with each item on a single row, like the following Example bundle List. The limit is 5,000 entries.
The Require IFA checkbox blocks all bid requests without the device.ifa field when activated. You can find details on the device.ifa field in the Device Object section.

Example bundle List¶

com.rovio.angrybirds
com.king.candycrushsaga
533173905
343200656

Website Settings¶

If you enable website targeting, you can configure the following settings.

Addressability: To only receive bid requests from matched users and specific user ID sources of your choice, check the Addressable Requests option and select Addressable Requests from the dropdown list. You can find detailed information on passing multiple user IDs in the Extended Identifiers section.

To select EID Sources for targeting, use the dropdown list and mark the checkboxes against the addressable sources you want to target; to add a Custom EID Type, enter them into the field below. You can find more details below

You can find more details below in the Extended ID Provider Targeting block.
Declared Website Domain: You can also block traffic that does not contain a site domain in the bid request by selecting the Declared app source checkbox. See the Site Object section for the details of these fields.
Exclude or Include Lists You can create exclude or include lists for domains on which you wish to bid or avoid. An exclude list means that you do not wish to bid on the given domains, and an include list means you only want to bid on those particular domains. You can block (or target) traffic down to the subdomain level, but not below that level, i.e. individual pages.
- Blocking a domain blocks all of its subdomains, but not vice versa, e.g. example.com also blocks sub.example.com
- Similarly including a domain also includes its subdomains, i.e. example.com also includes sub.example.com. To specifically include only certain subdomains, ensure that the main domain is not on the include list.
All lists must be uploaded in a text file, with each item on a single row, like the following Example Domain List. The limit is 5,000 entries.

Example Domain List¶

example.com
subdomain.website.com

Extended ID Provider Targeting¶

The option to target specific providers of extended user IDs was implemented as part of preparing for the cookie-less future with both Suppliers and Buyers matching users by their IDs which come from different providers and are not cookie-based. The feature allows Buyers to target specific sets of user IDs in addition to the standard matched traffic while filtering out traffic from users without such IDs - for example, you can set up targeting all matched users plus all users with the liveintent.com identifier. Extended ID provider targeting adds more flexibility to Buyers’ ability to define which ID sources to target, preventing the loss of traffic from non-cookie based IDs. It also allows Buyers to find and target extended IDs for which they have better performance or isolate certain IDs in order to test their suitability for certain audiences.

If you’d like to participate in the Protected Audiences API, select PAAPI as an addressable source in order to receive bid requests with the imp.ext.ae field. For more information, please see our Protected Audience API page

Deals Filtering¶

You can use a list to include or exclude Deal IDs within each Targeting Group. This list can contain IDs for any kind of deal: open, private, preferred, guaranteed, etc. BidSwitch only needs the Deal ID for traffic routing purposes. When combined with Private Deals QPS controls, this allows for efficient routing of deals, particularly when trying to manage large volumes of Always-on Deals interspersed with lower volume guaranteed deals traffic. To further improve deals filtering, you could also enable SmartSwitch for Private Deals.

Deals Exclusion Lists

If you set an exclude list for a Targeting Group, this will remove the given Deals from requests, but any other Deals present will be passed through. The difference in how other traffic is passed within the Targeting Group depends on the selected traffic type or a combination of them aka Open Exchange, Open Deals or Private Deals

Open Exchange, Open Deals, Private Deals If all the traffic types are selected and there are no deals left in a request after the exclude list has been applied, then open auction requests will be passed to the Buyers that match the targeting criteria of the Targeting Group
Open Deals, Private Deals If one or both these traffic types are selected and there are no Deals left in a request after exclude list filtering has been applied, then no request will be passed through for this Targeting Group

Deals Inclusion Lists

If you set an include list of Deal IDs, only those requests which contain an included deal will be passed within the Targeting Group. Note If requests also contain non-included Open Deal IDs these will not be removed from the request. The difference in how other traffic is passed within the Targeting Group depends on whether you have selected Open Exchange, Open Deals, Private Deals, or a combination of them.

Open Exchange, Open Deals, Private Deals If all the traffic types are selected and there are no deals left in a request after the include list has been applied, then open auction requests will be passed to the Buyer that match the targeting criteria of the Targeting Group.
Open Deals, Private Deals If one or both these traffic types are selected and you set an include list of Deal IDs, only those requests which contain any included deal will be passed within the Targeting Group. There is also a few additional caveats around private deals inclusions in case both deal types are selected.
- If a request also contains non-included open Deals these are not removed from the request.
- If a request also contains non-included private Deals, these are removed from the request
- If a Supplier cannot support specifying the pmp.deals.wseat field in a bid request to correctly route the private deal to the Buyer, a deals include list can be used. If BidSwitch sees a private deal included for a particular Buyer, it will route this deal to the Buyer even without a pmp.deals.wseat value being set.

Deals Filtering Private Deals¶
Deals in Request	Exclude: Deal 1 Deal 2	Include: Deal 1 Deal 2
Deal 1, Deal 2, Deal 3	Deal 3 passed to DSP. 1 and 2 stripped from request.	Deal 1 and Deal 2 passed to DSP. Deal 3 stripped from request.
Deal 1, Deal 2	Request dropped.	Request passed as is.
Deal 1	Request dropped.	Request passed as is.
Deal 2, Deal 3	Deal 3 passed to DSP, Deal 2 stripped from request.	Deal 2 passed to DSP, Deal 3 stripped from request.
Deal 3	Request passed as is.	Request dropped.

Deals Filtering Open Deals¶
Deals in Request	Exclude: Deal 1 Deal 2	Include: Deal 1 Deal 2
Deal 1, Deal 2, Deal 3	Deal 3 passed to DSP. 1 and 2 stripped from request.	Request passed as is.
Deal 1, Deal 2	Deal 1 and Deal 2 stripped from request, and request sent without deal details	Request passed as is.
Deal 1	Deal 1 stripped from request, and request sent without deal details	Request passed as is.
Deal 3	Request passed as is.	Deal 3 stripped from request, and request sent without deal details.

Distribution Pricing¶

If Distribution Pricing has been enabled on your BidSwitch integration, you can configure a Targeting Group to use it. As part of the configuration process, you will see a Trading Settings option as the final step. This allows you to apply Distribution Pricing to the traffic which matches the Targeting Group and set the amount of QPS you want dedicated to the it. To set this up, use the following steps.

Turn on Distribution Pricing from Targeting Groups -> (Your tgroup) ‣ Trading settings -> Distribution Pricing. Optionally, you may enable or disable SmartSwitch
Set the Queries per Second (QPS) you want allocated to this Targeting Group per Data Centre

To learn more about Distribution Pricing, see the Distribution Pricing section or to understand QPS, see the QPS Overview and Controls section.

Targeting Groups Reporting¶

There will be a difference between reported traffic numbers and billing numbers when compared to Targeting Groups reporting. This is because any traffic that matches at least one of your Targeting Groups will be sent to you as usual, i.e 1 request from a Supplier to BidSwitch means 1 request to you, but because Targeting Groups may contain overlapping settings such traffic will be reported as matching multiple Targeting Groups.

Each bid request contains a list of the Targeting Groups that it matched, ext.tgroup, see the Ext Object section for details.

For example, multiple Targeting Groups may include display traffic in US, CA. In such cases any matching traffic will be recorded as a positive match for each relevant Targeting Group.