Open RTB Supply Integration FAQ Change Log

Current Guide Version

V2

  

Admin

Multi-bid, Multi-imp, and Dynamic Podding

  • Clarified that FreeWheel also supports single imp requests.

Historic Change Log

v1

  

Admin



Table of Contents


General Integration Questions

What is the OpenRTB Supply Integration (ORTB-S)?

The OpenRTB Supply Integration, short as ORTB-S, is an integration type alternative to VAST that allows publishers that have inventory upstream third party ad servers to transact inventory with Freewheel using the ORTB-S Specification.

The ORTB-S specification is built upon the IAB ORTB specification with additional items to cover the requirements for the integration to work with Freewheel systems.

How is ORTB-S different than VAST or other integrations?

  • ORTB-S typically requires a server to server to connect, while VAST can originate from the endpoint/player itself

  • ORTB-S is built upon the IAB ORTB Specification thus uses attributes, formatting, and language that is standardized between SSPs and DSPs.

  • ORTB-S integrations can only be activated or used once the the upstream third party ad server and Freewheel have validated the integration.

What are the benefits of ORTB-S? Are there any cons?

  • ORTB-S has additional features like Multi-Bid, Multi-Imp, and Dynamic Podding which can create large efficiencies in the usage of computational resource and a increase the amount of diverse ads delivered upstream.

  • ORTB-S since it is majority based off the IAB ORTB spec, external transactions are done using the same attributes, formatting, and language that are used industry wide. This leads to more consistent sharing and understanding of metadata for advertisers to bid with.

  • When an ORTB-S integration is established between an upstream ad sever and FreeWheel there is no longer the need for custom VAST tags and extended setup. Freewheel can share critical values to the publisher to setup ORTB-S integrations in the upstream ad server, typically easily via their UI.

What's an acceptable tmax or TTL?

500 ms is recommended for the maximum amount of time available for Freewheel to respond with ads

For the net price - how does the client/I know what values to input on their end in 3P ad server UI?

The client's/publisher's Account Manager will provide the bid floors that will be inputed upstream.


Specification Support 

What IAB ORTB spec does ORTB-S support?

See the specification support table at the beginning of the OpenRTB Supply Integration Guide

What IAB Content Category Taxonomy does ORTB-S support?

See the specification support table at the beginning of the OpenRTB Supply Integration Guide

I do not see a specification or standard taxonomy listed as supported, their support is considered necessary for my business, we can I do?

Please reach out to your Account Manager or Partnerships contact to raise the request.

Do you plan on moving to Content Cat v3? If we receive a request that contains content cat v2 or v3 how would you like us to handle that in the request to FW?

We currently only support IAB Content Category Taxonomy v1. Please raise to your account manager is v2/v3 support is needed. In terms of handling those requests, send them along regardless, any thing we don't support will be ignored so it should have no impact.

Critical Items Outside of the Normal OpenRTB Spec

What are critical items that are not used in other OpenRTB integrations such as the SFX one?

  • Network ID
  • Site Section ID
  • Profile ID

In this case where I am an ad server that servers multiple clients accessing Freewheel SSP, what items need to be configurable for our clients when setting up ORTB-S placements/bidders?

Clients need to be able configure a ORTB-S bidder/placement with the following:
  • Endpoint Prefix
  • Network ID
  • Site Section ID
  • Profile ID
The reason behind this is that each client gets their own network with a linked endpoint prefix, profile ids, and site sections so it has to be configurable per ORTB-S placement/bidder.

Endpoint Prefix 

What is the endpoint prefix?

The endpoint prefix is a clients network id in hexadecimal format and designated to be an endpoint for the client to send their ORTB-S bid requests.

The prefix is located here in the target endpoint url: https://prefix.v.fwmrm.net/ortb/ssp

An example: https://12345A.v.fwmrm.net/ortb/ssp

Will I have to pass multiple endpoint prefixes? Does it have to be dynamic like other critical items?

Depending on your situation, if you host multiple publishers/clients then endpoint prefixes will need to be dynamically passed as each publisher will have their own prefix. If you also own your ad server chances are you will only have one network thus only one prefix.

Network ID

What is a network id?

A network id is the numerical id that tied to a publisher's instance or "network' in Freewheel.

How is this different than a SFX PX

A SFX Private Exchange is essentially the same concept as a Freewheel Network

Is the Network ID associated with the upstream ad server as a seller or is there a Network ID per publisher working with the upstream ad server?

It depends on the upstream ad server relationship with the inventory:
  • If the upstream ad server is hosting multiple publishers/clients then the network id will be mostly likely associated to each individual publisher/client
  • If the upstream ad server is owned by a singular publisher then there will be likely only one network id as the ad server and the publisher are the same

What is the recommended attribute to pass network id?

If possible, we recommend using ext.network_id from the 5.1.2 Network ID table in the OpenRTB Supply Integration Guide. If the network id value is passed via multiple of the options in the table we will use the key value with the highest priority.

Site Sections

What is a Site Section ID? How is it used? 

Site Section IDs are associated to Site Sections which in a network make up different ways how a client's/publishers inventory is broken out and targeted by demand sources in Freewheel. Depending on how the network is designed via these site sections along with other larger network items certain kinds of inventory will flow to specific site sections. 

How are site sections different than a Zone in SFX?

SFX Zones are a combination of both a network item (what breaks out the inventory in the clients instance) and an ad unit, which is why there was multiple zones to represent the same inventory broken out by ad unit type (typically pre-roll, mid-roll, and post-roll). Site sections do away with that therefore being flexible in what sort of ad units are being received, thus you up needing less site sections to cover the same amount of inventory.

What is the recommended attribute to pass site section information?

If possible, we recommend using ext.custom_site_section_id from the 5.1.1 Site Section ID table in the OpenRTB Supply Integration Guide. If the site section value is passed via multiple of the options in the table we will use the key value with the highest priority.

Profile 

What is Profile ID? How is the Profile ID used by FW?

A Profile ID is a string that is tied to a specific player profile. Player profiles are packages of parameters and settings that represent the endpoints upstream. These parameters and settings have all sorts functions in respect to how demand is returned upstream. GDPR, CCPA, and other compliance types in the transaction are also governed by the player profiles thus its important that the player profile id gets passed.

What format should the Profile ID be passed as?

The profile id should be passed as (network id):(profile name) or just the profile name.Example:12345:fw_profile_nameorfw_profile_name

What is the recommended attribute to pass profile id?

If possible, we recommend using ext.profile_id from the 5.1.3 Network ID table in the OpenRTB Supply Integration Guide. If the profile id value is passed via multiple of the options in the table we will use the key value with the highest priority.

Testing and Validation Questions for Ad Servers

Does FreeWheel have any testing endpoints? If so how can I get access to it?


Yes, we have a network instance that can be used for testing and validating the initial elements of the ORTB-S integration with a specific upstream ad server. 

For further information on how to obtain access to the testing instance please reach out to your Account Manager or Partnerships representative.


Are there any traffic limitations to using the test environment?

Yes please only send up to 1000 requests per day once you are granted access. This will be a requirement repeated to you before the start of testing.

Does the test network return demand? Will I always get demand returned?


  1. Yes there demand returned, however, it is fake/dummy demand that is just used to validate the integration connection.
  2. Demand will not always be returned as our system has throttling enabled to assure machine resources are not being overtly spent



After I finish developing towards the ORTB-S Integration what is next? How and when do we establish a "Business as usual" ORTB-S integration connection?

  1. There will be initial validation of the integration done with the testing network, please coordinate with your FreeWheel representative

  2. After initial validation is confirmed and there are no blockers a coordinated validation plan will take place with live inventory. This will be scheduled with Freewheel resources.

  3. After validation with live inventory the integration will be considered "BAU" and ready to be used with other publishers/clients the upstream adserver represents or more inventory.

How long does a ad server validation take?

After initial validation is done with the test network and a live traffic validation is started depending on the features that will be enabled we can expect 2-4 weeks if there are no major blockers.

Endpoints 

Will we need to set up an endpoint per pub or can we have all traffic flow through a single endpoint?

Each client/publisher will have their own endpoint as each will have their own network.

Multi-Bid, Multi-Imp, and Dynamic Podding

Do we need to use Multi-imp, Multi-bid, or 2.6 Dynamic Podding?

No - FreeWheel also supports ORTB 2.5 standard single imp requests and single bid responses. However, we do recommend that Multi-bid, Multi-imp, or  Dynamic Podding be used if the 3P Ad server supports these features to improve efficiency and performance.

What is the difference between Multi-Bid, Multi-Imp (Structured Podding), and Dynamic Podding?


  • Multi-Bid
    • When available, multiple bids (up to 5) will be returned in the ad response against each individual impression opportunity. It offers more demand diversity and more demand for the 3p Upstream ADS to choose from.
    • If one impression opportunity were sent in an ad request we will send up to 5 bids in the ad response depending on how much demand is available and valid.
    • If Multi-Imp is being used and we will return up to 5 bids per impression opportunity.
      • Examples
        • 3 imp opportunities can have up to 15 bids in the ad response. 3x5=15.
        • 5 imp opportunities can have up to 25 bids in the ad response. 5x5=25
  • Multi-Imp (Structured Podding)
  • Dynamic Podding
    • Depending on the size of the the dynamic pod called out in the ad request's poddur and maxseq attributes we will return a diverse set of ads depending on what demand is available to fill the entire pod. These ads can be of different sizes and chosen dynamically to assure enough demand is available to fill the pod.
    • This is to resolve the dyanmic pod case in section 7.6 of the oRTB 2.6 spec: https://iabtechlab.com/wp-content/uploads/2022/04/OpenRTB-2-6_FINAL.pdf
    • A dynamic pod's slots sizes are determined dynamically based on podur value passed in the ad request and what the upstream ad server's ad decisioning determines what to use.



Can you use Multi-Bid, Multi-Imp (Structured Podding), and Dynamic Podding all at the same time?

  • Multi-Bid and Multi-Imp can be enabled at the same time

  • At this time Dynamic Podding can only be enabled on its own

i.e

  • If Multi-bid is enabled, Multi-Imp can be enabled, but not Dynamic Podding

  • If Multi-Imp is enabled, Multi-Bid can be enabled, but not Dynamic Podding

  • If Dynamic Podding is enabled, both Multi-Imp and Bid cannot be enabled

How do we decide which combination of features (i.e. dynamic podding, multi-imp, multi-bid) will work for us (the client)?

During the live traffic validation testing, depending on what the upstream ad server can support, we will test the different features to determine which is one most suited for the client/publisher.

How does Inventory Type Impact the Integration?

Given that we will have predominantly App inventory, what is the preferred method to pass the Site Section ID?

ext.custom_site_section_id is the preferred method. Its agnostic of inventory type and a clearer name for the site section id troubleshooting.

We do not support ext.custom_site_section_id how do I passed the site section id? Does my inventory type impact that?

You can use app.id for app inventory or site.id for web inventory to pass site section id in the cases where the extension is not supported.


You are evaluating Refined.