FAQ Change Log

Current Guide Version

Guide VersionDateAuthorChanges/Description
V6

 

Admin
  • Minor corrections

Historic Change Log

VersionDateAuthorChanges/Description
V5

 

Admin
  • Several new items added explain how more features work including: ads.txt, sellers.JSON, Programmatic Guaranteed, restrictions, net and floor price settings and cookie sync
  • Updates to include feedback from ENG
V4

 

Admin
  • updated 'What is a Site Section ID? How is it used?' row
V3

  

Admin
  • How do we decide which combination of features (i.e. dynamic podding, multi-imp, multi-bid) will work for us (the client)?
    • Updates done to the answer section in response to the above question due to recent updates in logic
V2

  

Admin

Multi-bid, Multi-imp, and Dynamic Podding

  • Clarified that FreeWheel also supports single imp requests.
v1

  

Admin



Table of Contents



OpenRTB Supply Integration (ORTB-S)

Question

Answer

Where is the ORTB-S Integration Guide? 

See here OpenRTB Supply Integration Guide

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.


Critical Items Outside of the Normal OpenRTB Spec

Question

Answer


What are mandatory items needed to be passed that might be unique to FW SSP? 


  • 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
  • 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.


Video Ad Serving Template Integration (VAST)

Question

Answer

Where is the VAST Integration Guide?

See here: VAST Integration Guide

What is a VAST Integration?

A Video Ad Server Template (VAST) integration is one of the most common integration types as it uses an industry standard XML format managed by the IAB to serve ads. VAST Integrations use "VAST Tags" which is a plug and play URL that contains parameters that describe inventory and requirements.

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

It is likely the easiest to deploy. Once you have a complete VAST tag you can essentially plug it into whatever upstream ad server you use as its the most common integration type. Complication lies in making sure that you are passing values in the right macros, but beyond that its usually copy and pasting the tag.

What are the benefits of VAST? Are there any cons?

VAST Benefits (Server-Side Integration)

VAST Drawbacks (Server-Side Integration)

Flexibility and Accessibility

  • VAST can originate directly from the endpoint/player itself, unlike ORTB-S or Prebid Server which typically requires a server-to-server connection
  • Supports a wide range of implementation scenarios including both client-to-server and server-to-server setups
  • Well-established industry standard with broad compatibility across various video players and ad servers

Implementation Simplicity

  • Uses straightforward HTTP GET requests with parameters, making it relatively easy to implement
  • Extensive documentation and support available due to its widespread industry adoption
  • Compatible with numerous third-party ad servers and platforms (SpringServe, Publica, GAM, etc.)

Technical Advantages

  • Supports custom site section tags, allowing for flexible inventory organization
  • Established user syncing mechanisms for better audience targeting and frequency capping
  • Familiar format for many publishers already using VAST in their existing setups

Limited Advanced Features

  • Lacks advanced features available in ORTB-S such as Multi-Bid, Multi-Imp, and Dynamic Podding
  • Cannot leverage the computational resource efficiencies that ORTB-S provides
  • Less efficient for podded ad requests compared to ORTB-S options

Technical Limitations

  • Strict parameter formatting requirements - parameters must be in the correct section of the tag with proper separators (semicolons)
  • More complex troubleshooting when issues arise compared to standardized ORTB formats
  • Currently only supports custom site section tags (not numeric site section IDs) for certain integration types like Prebid.js

Integration Challenges

  • Requires careful attention to tag taxonomy and parameter formatting
  • May need separate tags for different inventory types (live vs. on-demand)
  • Less standardized metadata sharing compared to ORTB-S, which uses industry-standard attributes


Prebid Server Integration

Question

Answer

Where is the Prebid Server Integration Guide?

See here Prebid Server Integration Guide

What is a Prebid Server Integration?

Prebid Server is an advanced ad serving technology that facilitates server-side header bidding. It acts as a bridge between publishers and demand sources (DSPs, ad exchanges, or SSPs), enabling efficient ad auction processes by translating bid requests and responses into standardized formats. Our fwssp Prebid Server Adapter, adapts Prebid ORTB ad requests into OpenRTB Supply Integration ad requests and OpenRTB Supply Integration ad responses back to Prebid ORTB ad responses. See Prebid Server Integration Guide for more information.  Key Prebid Server features:

  • Adapter Integration: Prebid Server uses adapters (like FreeWheel's fwssp adapter) to integrate demand sources, by translating bid requests and responses between different systems
  • OpenRTB Supply Integration Compatibility: Supports the OpenRTB Supply Integration API built to make it possible to deploy and maintain an effective OpenRTB supply integration with Freewheel to pass inventory to downstream demand sources to obtain incremental demand. Please refer to the OpenRTB Supply Integration Guide for more on specifications supported and other items
  • Media Type Support: Can handle various media types

Prebid Server Integration-Specific Considerations for FreeWheel

  • Requires PBS-Go implementation (PBS-Java not supported) 
  • Uses OpenRTB Supply Integration API
  • Cookie syncing available


What are the pros and cons of Prebid Server vs prebid JS?


Prebid Server Benefits (Server-Side Integration)

Prebid Server Drawbacks (Server-Side Integration)

Technical Advantages

  • Reduced Page Load Impact: Moves bidding processes off the user's browser, improving page performance
  • Centralized Cookie Syncing: More efficient user syncing with a single server-to-server sync
  • Better Mobile Performance: Particularly beneficial for mobile environments with limited processing power
  • Bypass Browser Limitations: Less affected by browser restrictions and ad blockers

Scalability Benefits

  • Better Performance with Many Bidders: Can handle more bidders efficiently without impacting user experience
  • Reduced Timeout Issues: Server environments typically have better network connectivity, reducing timeout problems

Advanced Features

  • Support for Complex Auction Types: Better handling of multi-impression requests and dynamic podding for video
  • Extended Feature Support: FreeWheel's implementation supports features like multi-bid responses and structured podding

Technical Limitations

  • More Complex Setup: Requires server infrastructure and configuration (PBS-Go implementation for FreeWheel)
  • Additional Network Hop: Introduces an extra server call that can add latency
  • Limited User Data Access: Less direct access to user data and browser information
  • Cookie Matching Challenges: May have lower match rates for user identification

Implementation Challenges

  • Server Maintenance: Requires maintaining server infrastructure or relying on a third-party provider
  • Version Requirements: Must use Prebid Server version 3.18.0 or above for FreeWheel's adapter
  • Implementation Complexity: More complex to set up and troubleshoot


Prebid.js Integration

Question

Answer

Where is the Prebid.js Integration Guide?

See here Prebid.js Integration Guide

What is a Prebid.js Integration?

Prebid.js is an open-source header bidding solution that enables publishers to implement header bidding on their websites and applications. It serves as a crucial technology in the programmatic advertising ecosystem, particularly for video advertising. Prebid.JS uses VAST specifications.  See Prebid.js Integration Guide for more information.  Key Prebid.JS features:

  • Header Bidding Integration: Allows publishers to conduct pre-auction bidding before making ad server calls
  • Adapter System: Uses specialized adapters (like FreeWheel's fwssp adapter) to connect with different demand sources
  • Format Support: Supports various ad formats including in-banner video and instream video ads
  • Customization: Offers extensive configuration options for publishers to control bidding behaviour
Prebid.js Integration-Specific Considerations for FreeWheel
  • Requires adapter version 10.10.0 or above
  • Prebid.js Uses VAST requests format
  • Supports user/cookie syncing with automatic inclusion of cookies in HTTP headers
  • Expanded schain detection to match Prebid 10+ specifications in v10 adapters.  Note: SCHAIN support Is planned for v10+ only, There is no Prebid.js SCHAIN support for V9 

Are there any specific tools that clients can use to help diagnose/troubleshoot Prebid.js Integrations?

We recommend that clients install the Prebid Professor Chrome browser extension (https://chromewebstore.google.com/detail/professor-prebid/kdnllijdimhbledmfdbljampcdphcbdc), which can be used to validate your prebid.js setup, identify the version of Prebid.js installed on website, list AdUnits and bids, visualise latencies and timings of your webpages header-bidding partners and filter bidders for troubleshooting.


What are the pros and cons of Prebid.js vs prebid server?


Prebid.js Benefits (Client-Side Integration)

Prebid.js Drawbacks (Client-Side Integration)

Technical Advantages

  • Simpler Implementation: Prebid.js can be more straightforward to implement as it only requires adding JavaScript code to web pages
  • Direct Browser Access: Has direct access to user data and browser information, enabling more precise targeting
  • Real-Time Debugging: Easier troubleshooting with browser-based tools like Prebid Professor for real-time debugging
  • Cookie Access: Direct access to first-party cookies for better user identification and targeting

Performance Benefits

  • Lower Latency for Small Auctions: For scenarios with fewer bidders, client-side can actually be faster as it eliminates an additional server hop
  • No Additional Server Infrastructure: Doesn't require maintaining a separate server infrastructure

Integration Flexibility

  • Format Support: Supports various ad formats including in-banner video and instream video ads
  • Customization Options: Offers extensive configuration options for publishers to control bidding behavior

Technical Limitations

  • Browser Performance Impact: Can slow down page load times and affect user experience, especially with many bidders
  • Cookie Syncing Challenges: Each demand partner needs to sync cookies individually, creating additional network requests
  • Browser Limitations: Subject to browser restrictions like cookie policies and ad blockers
  • Client-Side Resource Consumption: Uses end-user's device resources (CPU, memory, bandwidth)

Implementation Challenges

  • Version Management: Requires keeping the Prebid.js library updated (minimum v10.10.0 for FreeWheel's adapter)
  • Maintenance Overhead: Changes to adapter configurations require updates to client-side code

 


Supported Specifications

Question

Answer

What IAB ORTB spec does ORTB-S and Prebid Server support?

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

What IAB Content Category Taxonomy do our integrations support?

See the specification support table at the top of any integration guide. Here OpenRTB Supply Integration Guide as one of the references

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 if 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.

Does FreeWheel support burl/nurl via ORTB-S?

No, FreeWheel does not support burl or nurl. Please see the Bid Response section of the specification

What are the required Parameters that need to be included the Prebid.js headers within ad requests?


For full details please see Parameters section within Prebid.js Integration Guide 

How do I implement ads.txt and sellers.JSON?

The Freewheel account team will provide publisher clients with relevant lines to implement for ads.txt that will take into consideration any reseller relationships they have. Sellers.JSON updates will be done by the Freewheel team as part of the onboarding set up steps.


General Questions


Endpoint Prefix

Question

Answer

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.

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.

Is the endpoint prefix case-sensitive?

No, the endpoint prefix is not case sensitive.


Network ID

Question

Answer

What is a network id?

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

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

Question

Answer

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. 

  • For all oRTB-S integration(including Prebid Server oRTB-S), we support both custom site section tags and numeric site section IDs.


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.


Profiles

Question

Answer

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.


Transactions

Question

Answer

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


Multi-Bid, Multi-Imp, and Dynamic Podding - Supported by ORTB-S and Prebid Server ONLY

Question

Answer

What integration types can use Multi-imp, Multi-bid, or 2.6 Dynamic Podding?

ORTB-S and Prebid Server. Please reach out to your Freewheel account team representative who can help with the enablement of these features. 

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

  • Dynamic Podding does not need to be enabled and does not interfere with Multi-Bid and/or Multi-Imp as our system detects when maxseq and poddur are included in an ad request instead of being an always on solution. Therefore by priority:

    1. We check if the ad request has dynamic podding parameters and return ads based on the parameters and maximum amount of ads allowed on maxseq according to the OpenRTB Supply Integration Guide. 

    2. If the dynamic podding paramters are not included in the ad request, we check if the ad request is Multi-Imp instead by checking how many impression objects there are in the ad request, assuming Multi-Imp is enabled for the network. The maximum amount of impression objects is listed in the OpenRTB Supply Integration Guide.

      1. If there is only 1 impression and/or Multi-Imp is off then the transaction is treated as a non-podded single impression.

    3. If Multi-Bid is on we send back up to the maximum ads per impression opportunity listed in the OpenRTB Supply Integration Guide

    4. If Multi-Bid is off we sent back only one ad per impression opportunity as available

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.

Will the ORTB-S response contain more ads than the request's maxseq?

The ORTB-S response will contain at most the same number of ads as the request's maxseq or a number of ads that are less than or equal to the request's podduration.


How does Inventory Type and the Supply Source Impact the Integration?

Question

Answer

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 pass 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.

I am a reseller how does that impact my inventory and setup?


Does ORTB-S support deals?

ORTB-S supports passing downstream FreeWheel deals IDs back in the ad response for reporting purposes only. ORTB-S does not support the pmp.deals object in the request and cannot return bids that only correspond to that deal ID.


Testing and Validation Questions for Ad Servers

Question

Answer

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 is 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.


APIs

Question

Answer

Is there overall API support for FWSSP clients?

FWSSP clients will have API access for all the things they can manage in UI only. However the main restriction is that there is no STATS API, with no current plans for it.  


Privacy and Compliance

Question

Answer

How do I set up Ads.txt or InventoryPartnerDomain? 

Your FW SSP Account Manager will provide you with any relevant lines to implement as part of the onboarding process. Please refer to the FW SSP section of the guide for more details https://hub.freewheel.tv/display/MUG/ads.txt+and+app-ads.txt+setup#ads.txtandappads.txtsetup-FreeWheelSSP

For Inventory Partner Domain, please refer to https://hub.freewheel.tv/display/MUG/ads.txt+and+app-ads.txt+setup#ads.txtandappads.txtsetup-Setupforinventorypartnerdomainsetup


How do I set up sellers.JSON?

Your Freewheel Account Manager will ensure that the relevant sellers.JSON updates are done as part of the onboarding process.

For specific notes relating to Prebid JS integrations, please see https://hub.freewheel.tv/display/Resources/Prebid.js+Integration+Guide#Prebid.jsIntegrationGuide-9.Schain/SellersJSON/Ads.txt/appads.txt



Cookie Syncing

Question

Answer

How can I set up cookie syncing?

This only applies to web environment where we need to learn the cookie ID of a user.  For in app traffic we’ll rely on the device IFA to identify users. As part of the onboarding steps, we will configure clients for user syncing to fire via the impression trackers in the ad response as a default.

Please see specific notes around cookie syncing for each integration type as each has its own nuances:

In cases where a new ad server integration is being set up, there will be further implementation steps to be completed which will be explained by your Freewheel Account Manger. This does not apply for publishers using an already integrated adserver.



Programmatic Guaranteed

Question

Answer

Does FW SSP support Programmatic Guaranteed (PG)?

Yes, and it will require some backend enablement steps by your Freewheel team so please reach out to them if you wish to use this feature. This would also apply if you have a downstream partner who may want to use your supply acquired via MPP on PG deals as we’ll need to enable it on your network as well.

 For any PG demand, Freewheel  assures that it sits at the top of the waterwall and we expect the upstream adsever to have the same priority level on the supply side to guarantee the supply in order for PG to work in the most optimal way.

In order for us to guarantee the demand, the Freewheel system will need to know that an opportunity is exclusively for programmatic guaranteed this can be done by the upstream adserver passing a PG flag - _fw_pg_only=1 or ext.fw_gd=1 for oRTB-S requests which is our preferred method. Where the upstream adserver doesn’t support the PG flag, the expectation is that the publisher will create duplicate site sections for PG and add pg_only=1 to the site section meta data. This is to ensure that we can separate out the PG and non-PG requests and we expect an ad request for both types to be sent in parallel


Pricing and Auctions

Question

Answer

How can I set up floor prices?

This can be done  at network level or more granularly either passed on the ad request, Standard Attributes, or set on the network items. When setting up deal IDs, you have the option to inherit the floor price set on the inventory or override this with a CPM.

How do floor price priorities work?  

The priority levels of floor prices is as follows: 

  1. Ad request
  2. Network item floor price (SG, S, SS) and Standard Attribute (in case of conflict we'll take the higher value)
  3. System admin floor

For MPE, we'll take the floor price set at the inventory level unless a CPM floor is set on the listing (users can toggle between the pricing options).

For MPP orders, the price set on the Sold Order will take precedence

Can FW SSP work with net price?

Yes, your Freewheel account manager can set this up and put in place any fee structures or rev shares. The bid price we pass back to you will be the net price after any fees have been taken e.g a 15% rev share would pass $8.50 upstream on a $10 gross CPM.

What auction types does FW SSP Support?

We support both 1st and 2nd price auction for O&O programmatic. Please contact your Freewheel account manager if you wish to use both auction types.


Restrictions

Question

Answer

How can I restrict certain advertisers from running on my inventory?

Restrictions can be configured globally at network level, on Standard Attributes, or on the site axis network items. Blocks can be applied at advertiser, brand, industry level. You can also opt to block any cases where these are unknown for more secure delivery.

How can I configure restrictions around ad durations etc..?

Ad unit restrictions around max durations, max ads and break durations etc.. can be applied, globally at network level, on Standard Attributes or on the site axis network items.



You are evaluating Refined.
Back to Top