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.

Targeting Group Considerations

Configuring Targeting Groups¶

To create a new Targeting Group, select Targeting Groups ‣ Add New Group
To edit or delete a Targeting Group, open the Targeting Groups page and select the relevant option beside the Targeting Group name.

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

Ad Context and Placement¶

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. The Require IFA checkbox blocks all bid requests without the device.ifa field when activated and can be applied to all or any device type. You can find details on the device.ifa field in the Device Object section.
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
Digital out of Home If your integration is set up to trade DOOH, you can enable it per Targeting Group
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

Commercial Context¶

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
Traffic Type Set the traffic types that you want to get, i.e. receive all traffic or only deals traffic.

In-App Targeting¶

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.

Example bundle List¶

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

Website Targeting¶

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

User Traffic Synced: To only receive bid requests from matched users and specific user ID sources of your choice, check the Only Synced Users option. 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 EID sources you want to target; to add a Custom EID Type, enter them into the field below.

You can find more details below in the Extended ID Provider Targeting block.
Declared App Source: 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.

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 whether you have selected All Traffic or Only Deals Traffic

All Traffic If there are no deals left in a request after the exclude list has been applied, then open auction requests will be passed to the Buyer that match the targeting criteria of the Targeting Group
Only Deals Traffic If 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 All Traffic or Only Deals Traffic

All Traffic If 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.
Only Deals Traffic If you set a include list of Deal IDs, only those requests which contain an included deal will be passed within the Targeting Group. There is also a few additional caveats around private deals inclusions.
- 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 Auction¶
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 Auction¶
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.