Add and Configure Endpoint

• Endpoints Table Overview
• Add an Endpoint
• Main Settings
• RTB
• VAST
• Prebid
• SDK
• Add BidSwitch Endpoint
• Shared Configurations for All Endpoints
  
• Inventory Filters
• Demand Rules
• Bid Floor
• Packages
• Endpoints Priority
  

Endpoints Table Overview

Under each SSP, you will find a list of its endpoints. An endpoint refers to a specific URL where the partner SSP sends bid requests. This tab displays key statistics, including Billed Impressions and Profit, to help you analyze performance effectively. The Billed Impressions and Profit columns feature interactive graphs on the right side, which provide data for the selected time period in the dropdown menu above the table. Hovering over the graphs allows you to view specific daily data points.

In addition to performance metrics, the Endpoints tab provides quick access options for editing, activating/pausing, and deleting endpoints, as well as linking them to various packages. The Endpoints table also includes a search option and filters for endpoint type, with active/paused endpoints and removed endpoints displayed in separate tabs.

The tab also contains several graphs to visualize data:  

• Valid vs Filtered Impression Opportunities: This graph illustrates Valid Impression Opportunities, calculated by subtracting Filtered Impression Opportunities from Total Impression Opportunities. It also details the reasons for the filtered impressions and displays their percentage relative to the total impression opportunities for the selected time period. 
• Bids vs Impressions: This section shows the total sum for Bids sent to the SSP and the Billed Impressions for the selected time period, with a graph for each. The area charts allow for a visual comparison over time, with data changes to the previous period displayed alongside (green for increase, red for decrease, or no percentage if there are no changes). 
• Profit vs Expenses: This graph shows the total sum for Profit and Expenses for the chosen time period, with individual graphs for each metric. Similar to the Bids vs Impressions graph, it also includes data changes to the previous period.

The Time Period dropdown menu allows you to select a specific period for data analysis, including options such as today, yesterday, the last 7 days, the last 30 days, last month, and this month. Data is split by hour for 'today' and 'yesterday', and by day for the other options, providing a comprehensive view of endpoint performance over time. 

Add an Endpoint

• On the SSPs tab select the desired SSP. 
  
• On the Endpoints tab click the 'New Endpoint' button in the upper right corner. 
  
• In the opened modal window, first fill in the Main Settings, then proceed to Inventory Filters, Demand Rules, Bid Floor, and Packages. 
  

Main Settings

Certain fields (Endpoint Name, State, and Type) are common across all endpoint types. Additional fields will appear based on the Type selected. The options for Type include RTB (default), VAST, Prebid, and SDK. Please note that the last three types - VAST, Prebid, and SDK - become available only after the corresponding module has been activated in the platform settings.

RTB Type:

• Endpoint Name (required): Enter a name for the endpoint.
• State: This toggle indicates the state of the endpoint. It can be Active, Paused, or Paused with the toggle disabled for paused SSPs.
• Type: RTB.
• Impressions Expiry Time (required): Set an expiration time for an impression. If an impression is registered after the specified time, it will be deemed as expired. The value entered can be either an integer or a fractional number that is greater than 0. By default, the Impressions Expiry Time is set to 1800 seconds.
  
• Impression Tracking Mechanism: Choose one of the following tracking methods for billed impressions, revenue, and expenses. Ensure the SSP partner uses the same method (for a deeper understanding of how SSP and DSP trackers are implemented, you can read more about the process in our guide on SSP and DSP Trackers Implementation):
• Ad markup Pixel: A small, transparent image embedded in an ad for tracking impressions. 
• nURL (notification URL): A callback method that notifies the bidder of an impression event.
• bURL (billing URL): A callback method that notifies the bidder when an impression is billed.
• Custom Latency: Adjust this setting to optimize communication with your SSP partner and minimize timeouts between servers. By default, the system attempts to ascertain the precise latency between your servers and those of your SSP partner. If this determination isn't feasible, a standard latency of 10ms is used. However, you can adjust this setting to optimize communication with your SSP partner: increasing the Custom Latency value can help minimize timeouts between servers. Note that this value should be greater than 0. The formula for determining the DSP's maximum time (dspTmax) is as follows: dspTmax = sspTmax - sspLatency - dspLatency - 10, where:
• sspTmax: Maximum time in milliseconds allowed by the SSP for receiving bids.
  
• sspLatency: The exact latency between servers, with a default of 10ms or the latency value set in the Custom Latency field.
  
• dspLatency: The exact latency between your servers and those of your DSP partner.
  
• 10: A constant value representing internal processing time.
• Endpoint URLs: These URLs will be available once the Endpoint is created and saved. Share the URLs with the SSP partner, selecting URLs of datacenters that are closer to your partner. 

Endpoint URL obtained from the Edit Endpoint window will have the following pattern:

https://your-adx-domain/rtb?client=[CLIENT_OID]&endpoint=[ENDPOINT_ID]&ssp=[SSP_ID]

In this pattern:

• CLIENT_OID: A unique identifier for your RTB Stack platform, distinguishing it from others.
• SSP_ID: A unique identifier for the Supply-Side Platform.
• ENDPOINT_ID: A unique identifier specifying where requests from the site should be directed.

Endpoint URLs are used to specify the location where the SSP (Supply-Side Platform) should send ad requests. When a user visits a webpage and triggers an ad request, the SSP packages the details of this ad opportunity into a bid request. For more details on how the bid request is structured, please refer to the article on OpenRTB SSP Integration. This bid request is then sent to the Endpoint URL, which serves as the address of the ad exchange participating in the auction.

The ad exchange receives this bid request via the Endpoint URL, evaluates the ad opportunity, and if it's interested, responds with a bid. This bid response is then sent back to the SSP through another connection.

VAST Type:

• Endpoint Name (required): Enter a name for the endpoint.
• State: This toggle indicates the state of the endpoint. It can be Active, Paused, or Paused with the toggle disabled for paused SSPs.
• Type: VAST.
• Impressions Expiry Time (required): Set an expiration time for an impression. If an impression is registered after the specified time, it will be deemed as expired. The value entered can be either an integer or a fractional number that is greater than 0. By default, the Impressions Expiry Time is set to 1800 seconds.
• Impression Tracking Mechanism: To track billed impressions, revenue, and expenses accurately, it is essential to select a tracking method and ensure that your SSP partner uses the same approach. For a deeper understanding of how SSP and DSP trackers are implemented, you can refer to our detailed guide on SSP and DSP Trackers Implementation). Currently, the following tracking method is available:
• Ad markup Pixel: This method involves a small, transparent image embedded within an ad to track impressions.
• Fixed Event Price: Enter a CPM (in USD only), which will be used to calculate the price of Impressions for this VAST.
• VAST URLs: These will be available once the Endpoint is created and saved. Share the URLs with the SSP partner, selecting URLs of datacenters that are closer to your partner.  

VAST URL obtained from the Edit Endpoint window will have the following pattern:

https://your-adx-domain/vast?client=[CLIENT_OID]&endpoint=[ENDPOINT_ID]&ssp=[SSP_ID]&...&[OTHER_PARAMETERS]

In this pattern:

• [CLIENT_OID], [ENDPOINT_ID], and [SSP_ID] are placeholders for the unique identifiers of the client, endpoint, and SSP respectively.
• [OTHER_PARAMETERS] represents other potential parameters that could be included in the URL, each of which would be replaced by actual values at the time of the ad request. Each parameter in the URL is followed by an equal sign and a macro enclosed in square brackets. These macros act as placeholders that get replaced with actual values when the ad is served. For example, the macro [OS] would be replaced with the actual operating system of the user's device, [PAGE] would be replaced with the URL of the page where the ad will be displayed, and so on. It is essential to include certain mandatory parameters such as domain/bundle, IP and user agent to prevent the rejection of requests. The list of the platform-supported VAST macros can be found below. 

For detailed information on how to correctly compose a VAST URL, please refer to this article. 

When a video player sends an ad request using the VAST URL, it includes specific information about the user and the context of the ad request. The SSP or ad server takes this information and replaces the macros in the VAST URL with the actual values.

The response to the video player will contain a VAST XML document with the video file, some companion assets, tracking pixels, and instructions on how and when to display the ad. The video player then parses the XML and displays the ad. As the ad is displayed, the tracking pixels in the VAST XML are triggered, sending data back to the ad server about the impression. This data can include information like whether the ad was viewed, how long it was viewed for, and whether the user interacted with the ad.

Prebid Type:

• Endpoint Name (required): Enter a name for the endpoint.
• State: This toggle indicates the state of the endpoint. It can be Active, Paused, or Paused with the toggle disabled for paused SSPs.
• Type: Prebid.
• Impressions Expiry Time (required): Set an expiration time for an impression. If an impression is registered after the specified time, it will be deemed as expired. The value entered can be either an integer or a fractional number that is greater than 0. By default, the Impressions Expiry Time is set to 1800 seconds.
• Impression Tracking Mechanism: To track billed impressions, revenue, and expenses accurately, it is essential to select a tracking method and ensure that your SSP partner uses the same approach. For a deeper understanding of how SSP and DSP trackers are implemented, you can refer to our detailed guide on SSP and DSP Trackers Implementation). Currently, the following tracking method is available:
• Ad markup Pixel: This method involves a small, transparent image embedded within an ad to track impressions.
• Bidder URLs: This field allows you to enter up to three URLs, depending on the connected datacenters. The options include EU (European Union), US (United States), and APAC (Asia-Pacific). These URLs will become available once the Endpoint is created and saved. You should share these URLs with the SSP partner, choosing the URLs of datacenters that are geographically closer to your partner. When setting up the adapter, the SSP will need to select one of these URLs to ensure proper communication and integration between the publisher site and your platform. For more detailed information, you can visit the provided page.

The Bidder URL obtained from the Edit Endpoint window will have the following pattern: 

 https://your-adx-domain/prebid?client=[CLIEND_OID]&ssp=[SSP_ID]&endpoint=[ENDPOINT_ID], where:

• CLIEND_OID: A unique identifier for your RTB Stack platform, distinguishing it from others.
• SSP_ID: A unique identifier for the Supply-Side Platform.
• ENDPOINT_ID: A unique identifier specifying where requests from the site should be directed.

Prebid.JS adapters are software components that enable communication between SSPs, DSPs, and ad exchanges. They translate bid requests and responses into a common format that can be understood by all parties involved in the bidding process. The Bidder URLs are crucial for this communication process. By setting these URLs correctly, the SSP can ensure that ad requests from publisher sites are correctly routed to your platform, and that bid responses from your platform are correctly routed back to the publisher sites. 

SDK Type:

• Endpoint Name (required): Enter a name for the endpoint.
• State: This toggle indicates the state of the endpoint. It can be Active, Paused, or Paused with the toggle disabled for paused SSPs.
• Type: SDK.
• Impressions Expiry Time (required): Set an expiration time for an impression. If an impression is registered after the specified time, it will be deemed as expired. The value entered can be either an integer or a fractional number that is greater than 0. By default, the Impressions Expiry Time is set to 1800 seconds.
• Impression Tracking Mechanism: Choose one of the following tracking methods for billed impressions, revenue, and expenses. Ensure the SSP partner uses the same method (for a deeper understanding of how SSP and DSP trackers are implemented, you can read more about the process in our guide on SSP and DSP Trackers Implementation):
• Ad markup Pixel: A small, transparent image embedded in an ad for tracking impressions. 
• Confirmed View: A tracking option where impressions are confirmed based on viewability criteria.
• Endpoint Request URLs: This field allows you to enter up to three URLs, depending on the connected datacenters. The options include EU (European Union), US (United States), and APAC (Asia-Pacific). These URLs will become available once the Endpoint is created and saved. You should share these URLs with the SSP partner, choosing the URLs of datacenters that are geographically closer to your partner. The value should be set for the 'RequestBaseUrl' when configuring the SDK using 'setRequestBaseUrl()'. For more detailed information on configuring SDK, you can visit the provided page.
  

The Endpoint Request URL obtained from the Edit Endpoint window will have the following pattern: 

 https://your-adx-domain/sdk?client=[CLIEND_OID]&ssp=[SSP_ID]&endpoint=[ENDPOINT_ID], where:

• CLIEND_OID: A unique identifier for your RTB Stack platform, distinguishing it from others.
• SSP_ID: A unique identifier for the Supply-Side Platform.
• ENDPOINT_ID: A unique identifier specifying where requests from the site should be directed.

After completing all fields, be sure to click the Save button or continue to configure additional settings shared between the Platform's and BidSwitch endpoints, such as Inventory Filters, Demand Rules, Bid Floor settings, and Packages.

Shared Configurations for All Endpoints

Inventory Filters

Inventory filters allow you to refine the traffic that the platform processes. These filters use various logical operations, including boolean functions and the use of blacklists or whitelists. With the latter, you have the option to upload a pre-prepared file for use across the platform.
By filtering incoming inventory, you can efficiently avoid processing non-performing requests, thereby optimizing server capacity for high-performing inventory.
For a detailed breakdown of each filter and its related logic, please visit the appropriate page.

Demand Rules

In situations where specific demand should not be delivered to the Endpoint, it's necessary to set up demand rules. These rules employ various logical operations, including boolean functions and the use of blacklists or whitelists. With the latter, you have the option to upload a pre-prepared file for use across the platform.
For a more in-depth understanding of each rule and its associated logic, please refer to the corresponding page.

Bid Floor

Below are examples illustrating how the system decides which bid floor to apply by comparing the incoming and Custom Bid Floors.

Examples:

1. Incoming Bid Floor: $1

   • Custom Bid Floor: $2
   • DSP Bid Floor: $2 + Commission
   • Explanation: The incoming Bid Floor is lower than the Custom Bid Floor, so the Custom Bid Floor is applied.

2. Incoming Bid Floor: $1

   • Custom Bid Floor: $0.5
   • DSP Bid Floor: $1 + Commission
   • Explanation: The incoming Bid Floor is higher, so it is used, and the Custom Bid Floor is not applied.

3. Incoming Bid Floor: $1

   • Custom Bid Floor: $1
   • DSP Bid Floor: $1 + Commission
   • Explanation: The incoming Bid Floor matches the Custom Bid Floor, so the incoming Bid Floor is used.

For more details on commission logic, please refer to the following article.

Users can add an unlimited number of bid floors, but each must be added individually. During this process, users specify which Demand Side Platforms (DSPs) and profiles the bid floor applies to, along with various parameters. These parameters help refine the bid floor's application to specific impression opportunities. The parameters include:

• Advanced Filters:
• Rewarded Only: Apply bid floor to rewarded traffic only.
• Full Chain Only: Apply bid floor to requests with a complete supply chain.
• Interstitial Only: Apply bid floor to interstitial ad requests.
• Only Skippable Video: Apply bid floor to skippable video requests.
• Direct Dial: Apply bid floor to specific deal IDs entered as comma-separated values.
• Connection Type: Apply bid floor based on network connection type (e.g., Wi-Fi, 4G).
• Device ID: Apply bid floor to specific device IDs entered as comma-separated values.
• Device Type: Apply bid floor based on device type (e.g., mobile, desktop).
• Domain or Bundle: Apply bid floor to specific domains or bundles entered as comma-separated values.
• Environment: Apply bid floor to either Web or In-App environments.
• External Publisher ID: Apply bid floor to specific publisher IDs entered as comma-separated values.
• Geo location: Apply bid floor to specific countries, regions, or cities.
• Impression Type: Apply bid floor to specific impression types (Banner, Native, Audio, Video).
• Inventory Content Category: Apply bid floor to specific content categories.
• IP: Apply bid floor to specific IP addresses entered as comma-separated values.
• Operating System: Apply bid floor to specific operating systems.
• Language: Apply bid floor to specific languages.
• Size: Apply bid floor to specific ad sizes.

Adding different bid floors in combination with various parameters helps cover a wide range of scenarios. For instance, a user can set a bid floor of USD 0.5 for Banner requests and USD 0.7 for Video and Audio requests, or set different bid floors depending on geographical location.

User Tip: If a request matches several rules, one will be chosen at random. To avoid this, try not to overlap parameters. For example, avoid setting multiple bid floors for the same parameter, like Mobile requests or the same Language.

Rules for Bid Floor Value:

• The value should be greater than 0 and less than 101 (acceptable range is 0.01 - 100).
• Only a dot is allowed as a decimal separator (commas are not allowed).
• The value can have only up to 2 decimal places.
• The currency is USD only. The value sent to DSP will be converted according to the DSP currency.

Packages

To enable access to Endpoints at the Profile level, they need to be included in at least one Package. A Package is a collection of Endpoints grouped according to specific business logic, such as differentiating between Premium sources and those of lower quality. For more information about Packages, please visit this page.
To associate an Endpoint with a particular Package (or multiple Packages), simply find it (you can use the search function), select the checkboxes, and click Save.  

For linking a group of endpoints to a specific Package, please utilize the Endpoints setting on the Package level.

Endpoints Priority

Reorder endpoints by dragging and dropping them, placing higher-priority endpoints at the top. The drag-and-drop feature is disabled if there is only one endpoint or when the search field contains a value.

When processing HTTP requests from an SSP that is not of the standard type, such as BidSwitch SSP, the system uses endpoint priorities to determine where requests should be routed. Endpoints for SSPs without individual URLs rely heavily on priority logic to allocate inventory effectively based on business needs.

Logic:

• SSP Matching: Upon receiving a request, the system identifies the appropriate SSP using the BidRequest.ext.ssp parameter. It searches for the first SSP with a matching type (e.g., BidSwitch) and SSP ID. If no match is found, the request is filtered, and the corresponding reason is logged (e.g.,"No matched SSP (BS SSP"). [add HC URL here]
  
• Endpoint Matching: Once an SSP is identified, the system matches the request to an endpoint. It prioritizes endpoints based on their set priority levels, starting with the highest and moving sequentially to the next until a match is found. If no endpoint is matched, the request is filtered, and the corresponding reason is logged (e.g., "No matched Endpoint (BS SSP)"). [add HC URL here]

This priority mechanism is crucial for efficiently managing inventory allocation and ensuring that requests are processed according to business strategies.