<commit_before>---
layout: page_v2
page_type: module
title: Module - Price Floors
description: Determine and enforce auction price floors
module_code : floors
display_name : Price Floors
enable_download : false
sidebarType : 1
---

# Price Floors Module
{:.no_toc}

* TOC
{:toc}

## Overview

The Floors module provides an open source framework in Prebid for Publishers to configure price floors on their own or to work with a vendor who can provide floors.

A ‘floor’ is defined as the lowest CPM price a bid will need to meet for each Prebid auction. It’s a way for publishers to signal to bidders the price to beat, thereby protecting the value of their inventory.

The module provides several ways for floors to be defined, that are used by bidder adapters to read floors and enforced on bid responses in any supported currency. The floors utilized by the Prebid.js floors module are defined by one or more set of rules containing any or all of the following dimensions:


- AdUnit
- GPT Slot Name
- MediaType
- Ad Size
- Domain

{: .alert.alert-warning :}
When using GPT Slot name, the gpt library is required to load first. Failing to do so may yield unexpected results and could impact revenue performance.

The entire set of floors selected by the Floors Module for a given auction is called a “Rule Location”. A Rule Location can be any one of:
1. Within the AdUnit (AdUnit)
2. Within setConfig  (Package)
3. Retrieved from a real-time data service (Dynamic)


{: .alert.alert-info :}
Even though floors are defined with five pre-configured dimensions, it’s possible to extend the list of dimensions to attributes of the page, user, auction or other data by supplying a dimension matching function. For example, a publisher can provide a matching function that returns the device type to allow the price floor module to use device type as an attribute within a prebid floor rules file.


## How it Works
There are several places where the Floor module changes the behavior of the Prebid.js auction process. Below is a diagram describing the general flow of the Floors Module:

![Floors Module Flow](/assets/images/floors/floors_flow.png)

1. When building the Prebid.js package, the Floors module (and any analytics adapters) needs to be included with 'gulp build --modules=floors,...'
2. As soon as the setConfig({floors}) call is initiated, the Floors Module will build an internal hash table for each auction derived from a Rule Location (one of Dynamic, setConfig or adUnit)
  - a. If an endpoint URL (a Dynamic Floor) is defined, the Floors Module will attempt to fetch floor data from the Floor Provider's endpoint. When requestBids is called, the Floors Module will delay the auction up to the supplied amount of time in floors.auctionDelay or as soon as the dynamic endpoint returns data
3. Bid Adapters are responsible for utilizing the getFloors() from the bidRequest object for each ad slot media type, size combination. The Floors Module will perform currency conversion if the bid adapter requests floors in a different currency from the defined floor data currency.
4. Bid Adapters will pass the floor values to their bidding endpoints, to request bids, responding with any bids that meet or exceed the provided floor
5. Bid adapters will submit bids to back to Prebid core, where the Floors Module will perform enforcement on each bid 
6. The Floors Module will mark all bids below as bids rejected. Prebid core will submit all eligible bids to the publisher ad server
    - a. The Floors module emits floor event / bid data to Analytics adapters to allow Floor Providers a feedback loop on floor performance for model training


## Defining Floors

How price floors are used in the page will depend on how you’re obtaining the floors and how Prebid.js is integrated into the pages. For optimal revenue performance, we strongly recommend an automated flooring method compared to manual, sporadic updates.

### Floors Defined in the AdUnit

In this approach, the Publisher configures the floors directly into the Prebid.js AdUnits. This method can be used on simple pages or as part of a content management system that dynamically creates AdUnits.

Below are some basic principles of ad unit floor definitions:

- Ad unit defined rules only apply to the ad unit they are created in
- Setting a rule with a value that does not match the context of that given ad unit will never be used
- If multiple ad units have configured floor objects, the first ad unit’s schema would apply to all subsequent ad unit floor definitions
    - Values can differ between ad units


{% highlight js %}
 var adUnits = [<commit_msg>Update floors.md<commit_after>---
layout: page_v2
page_type: module
title: Module - Price Floors
description: Determine and enforce auction price floors
module_code : floors
display_name : Price Floors
enable_download : false
sidebarType : 1
---

# Price Floors Module
{:.no_toc}

* TOC
{:toc}

## Overview

The Floors module provides an open source framework in Prebid for Publishers to configure price floors on their own or to work with a vendor who can provide floors.

A ‘floor’ is defined as the lowest CPM price a bid will need to meet for each Prebid auction. It’s a way for publishers to signal to bidders the price to beat, thereby protecting the value of their inventory.

The module provides several ways for floors to be defined, that are used by bidder adapters to read floors and enforced on bid responses in any supported currency. The floors utilized by the Prebid.js floors module are defined by one or more set of rules containing any or all of the following dimensions:


- AdUnit
- GPT Slot Name
- MediaType
- Ad Size
- Domain

{: .alert.alert-warning :}
When using GPT Slot name, the gpt library is required to load first. Failing to do so may yield unexpected results and could impact revenue performance.

The entire set of floors selected by the Floors Module for a given auction is called a “Rule Location”. A Rule Location can be any one of:
1. Within the AdUnit (AdUnit)
2. Within setConfig  (Package)
3. Retrieved from a real-time data service (Dynamic)


{: .alert.alert-info :}
Even though floors are defined with five pre-configured dimensions, it’s possible to extend the list of dimensions to attributes of the page, user, auction or other data by supplying a dimension matching function. For example, a publisher can provide a matching function that returns the device type to allow the price floor module to use device type as an attribute within a prebid floor rules file.


## How it Works
There are several places where the Floor module changes the behavior of the Prebid.js auction process. Below is a diagram describing the general flow of the Floors Module:

![Floors Module Flow](/assets/images/floors/floors_flow.png)

1. When building the Prebid.js package, the Floors module (and any analytics adapters) needs to be included with 'gulp build --modules=floors,...'
2. As soon as the setConfig({floors}) call is initiated, the Floors Module will build an internal hash table for each auction derived from a Rule Location (one of Dynamic, setConfig or adUnit)
  - a. If an endpoint URL (a Dynamic Floor) is defined, the Floors Module will attempt to fetch floor data from the Floor Provider's endpoint. When requestBids is called, the Floors Module will delay the auction up to the supplied amount of time in floors.auctionDelay or as soon as the dynamic endpoint returns data, whichever is first.
3. Bid Adapters are responsible for utilizing the getFloors() from the bidRequest object for each ad slot media type, size combination. The Floors Module will perform currency conversion if the bid adapter requests floors in a different currency from the defined floor data currency.
4. Bid Adapters will pass the floor values to their bidding endpoints, to request bids, responding with any bids that meet or exceed the provided floor
5. Bid adapters will submit bids to back to Prebid core, where the Floors Module will perform enforcement on each bid 
6. The Floors Module will mark all bids below the floor as bids rejected. Prebid core will submit all eligible bids to the publisher ad server
    - a. The Floors module emits floor event / bid data to Analytics adapters to allow Floor Providers a feedback loop on floor performance for model training


## Defining Floors

How price floors are used in the page will depend on how you’re obtaining the floors and how Prebid.js is integrated into the pages. For optimal revenue performance, we strongly recommend an automated flooring method compared to manual, sporadic updates.

### Floors Defined in the AdUnit

In this approach, the Publisher configures the floors directly into the Prebid.js AdUnits. This method can be used on simple pages or as part of a content management system that dynamically creates AdUnits.

Below are some basic principles of ad unit floor definitions:

- Ad unit defined rules only apply to the ad unit they are created in
- Setting a rule with a value that does not match the context of that given ad unit will never be used
- If multiple ad units have configured floor objects, the first ad unit’s schema would apply to all subsequent ad unit floor definitions
    - Values can differ between ad units


{% highlight js %}
 var adUnits = [
{'fraction_non_alphanumeric': 0.03794067067927773, 'fraction_numerical': 0.0023645743766122097, 'mean_word_length': 4.2719546742209635, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5078624', 'n_tokens_mistral': 2291, 'n_tokens_neox': 2197, 'n_words': 1478}