Chunks Used in Chat #74

# Introduction A new feature has been introduced to support CPM floor configurations. This feature allows setting CPM floor values based on CPM percentiles. For example, the 80th percentile represents the CPM value below which 80% of impressions fall. Floors can be configured per country or per platform, cohort, and other parameters for the configuration. * * * ## **New CPM Percentile Configuration Section** - A new sub-section, **CPM Percentiles** has been added under the Ads menu in the left sidebar. Navigate to **Ads \> CPM Percentiles \> Interstitials** , and select the  **[green + sign]** to create a new entity. ### **List View and Available Filters** All the regular filters are available for CPM Percentile configurations.  ### **Standard Fields for New/Edit View**  #### **Fields Descriptions** | **Name** | **Validations** | **Description** | | --- | --- | --- | | Name | - Default: Blank - Type: String - **Mandatory** : Yes | Specify the Name for the configuration | | Priority | - Default: Blank - Type: Integer - **Mandatory** : Yes | Specify the priority of the configuration | | Label | - Default: Blank - Type: Single-select dropdown - **Mandatory** : No | Select the relevant label from the available options. | | Platform | - Default: None - Type: Single-select dropdown - Options: None, iOS, Android - **Mandatory** : Yes | **Usage** : Determines the platform used to retrieve CPM values from storage | | CPM source country | - Default: None - Single-select dropdown - Options: - **Mandatory** : Yes | **Usage:** Defines base country to fetch CPM floor from storage | | Additional countries to apply CPM | - Default: None - Two fields: - **Mandatory** : Yes | 1. Operator: Use this to define how the selected countries in the second field should be treated in the rule logic. Options: None, IN, NOT IN) 2. List of all countries excluding those already available for selection in the “CPM Source Country” field Choose one or more countries to which the CPM percentile setting should also apply (if using IN) or exclude (if using NOT IN). For the countries selected in this field, CPMs will be taken from country selected in “CPM source country” field | | Cohort Day | - Default: Blank - Single select dropdown these options: - **Mandatory** : Yes | Selected Cohort range is used to define which cohort day should be used to find required CPM value from the storage. | | Percentile | - Default: Blank - Single select dropdown with these options: - **Mandatory** : Yes | Selected Percentile value is used to define which Percentile value should be used to find required CPM value from the storage. | * * * ## Static CPM Configuration for MAX Interstitial Ad Unit The Static CPM Configuration section allows you to control the behaviour of CPM floor values based on either static settings or percentile-based logic. This section is visible when configuring MAX Interstitial Ad Units, and applies to all Bidding CPM Floor Types. ### Overview of Changes - Static floor CPM is renamed to Fallback CPM value. - A new configuration section, Static CPM Configuration, is introduced when the CPM floor type is set to either Static or Formula. ## How CPM Floor Values Are Determined ### When “Use Percentile” Is Enabled If you enable the “Use Percentile” option, CPM floor values are dynamically selected based on percentile configurations. Here’s how it works: 1. Percentiles are available for Ad Slots for Interstitials / Rewarded Videos and MAX interstitials / Rewarded videos Ad Units. 2. The system identifies matching CPM percentile configurations using: 3. If multiple configurations match, the system selects the one with the highest priority. 4. The CPM value is retrieved from a backend storage system. 5. The retrieved value is sent to the client. * * * ## Fallback Behaviour Fallback settings ensure that a CPM floor is still sent even if a percentile-based value cannot be determined. **Scenario 1: No Matching Configuration Found** If no percentile config matches the user that is the user does not match to any of selected percentile config by the following parameters: **Platform, CPM Source Country, Additional Countries to apply CPM, or Cohort Day:** - The system refers to the setting: If no matching configuration. **Scenario 2: No Percentile Data Available** If percentile data is unavailable (e.g., backend storage is inaccessible or lacks data): - The system refers to the setting: If no percentile available. * * * ### When “Use Percentile” Is Disabled If “Use Percentile” is disabled, the system does not apply any percentile logic. Instead, the existing CPM logic is used based on either: - A static CPM value, or - A formula defined in the configuration. ### New Fields in Static CPM Configuration  | **Name** | **Validations** | **Description** | | Fallback CPM Value | - Default: Empty - Type: float - Mandatory | Specify a fallback floor value to be sent to Max for interstitial bidding. | | Use Percentile | - Default: False - Type: Boolean - Mandatory if enabled | Enable to use percentile for CPM floor value. | | CPM Percentile Configs | - Default: Blank - Multi-select Dropdown - Options: List of available configs - Mandatory if Use Percentiles is enabled | Select the relevant config from the dropdown. | | If No Matching Configuration | - Default: Return Fallback value - Type: Dropdown - Options: Return fallback value, Return nothing - Mandatory if Use Percentiles is enabled | Select the relevant option if no matching config is available. | | If No Percentile Available | - Default: Return Fallback value - Type: Dropdown - Options: Return fallback value, Return nothing - Mandatory if Use Percentiles is enabled | Select the relevant option if no percentile is available. |  * * * ### Usage of Percentile Config in both Static and Formula Floor Types The Percentile configuration is designed to work with both Static and Formula CPM floor types. **Static Floor Type + (Use Percentile = true)** When the floor type is set to **Static** and the **Use Percentile** option is enabled: - The system ignores the fallback static CPM and instead follows the percentile-based logic: **Formula Floor Type + (Use Percentile = true)** When the floor type is **Formula** , the behaviour depends on the fallback policy defined in the formula configuration: - **If “If insufficient ad requests” = “Return Fallback Value”** : - **If “If insufficient ad requests” = “Return nothing”** : * * * ## Ad Slots Config Changes ### Configuring Static CPM Floors in Ad Slots When configuring ad slots, a Static CPM Configuration section is displayed based on your selected CPM floor type. **When Static CPM Configuration Appears** This section is shown if: - CPM Floor Type is set to Static or Formula, or - CPM Floor Type is Waterfall and Level Type is Fixed **Key Changes and Fields** - Static floor CPM has been renamed to Fallback CPM value. - The configuration section includes the following fields: The behaviour of these fields is described [here](https://tripledotstudios.atlassian.net/wiki/spaces/KB/pages/4244537368/CPM+Percentile+Configuration#New-Fields-in-Static-CPM-Configuration).  * * * ### **Behaviour in Waterfall CPM Floor Type with Level Type as Multiplier** - Static CPM configuration is not shown - Existing multiplier logic remains unchanged - User can still enter a CPM floor, but percentile logic is not applicable * * * ## **Summary of Logic** - Static CPM configuration appears for: - Percentile logic and fallback behaviour applies consistently across all applicable types - If Waterfall → Type = Multiplier, only multiplier logic is used (no percentile support) * * *

Recurrence Configuration You can configure event recurrences in two ways: - **Cooldown-based:** Set a cooldown period between consecutive occurrences. - **Weekly-based:** Choose specific days of the week for the event to recur. The following table explains the available fields and steps for each configuration method. | **Field** | **Description** | **Default/Options** | **Steps to Configure** | | --- | --- | --- | --- | | **Limit number of occurrences** | Allows you to limit how many times the event occurs. | Default: OFF (unlimited occurrences) | Toggle ON to enable. Enter the number of occurrences (e.g., 5, 10) in the "Number of occurrences" field that appears. | | **Number of Occurrences** | Allows you to specify the number of occurrences. | Only available when the Limit Number of occurrences toggle is on. | Specify the number of occurrence for the event. | | **Duration of event occurrence** | Displays the total duration of each event cycle (non-editable). | Based on activities and durations set earlier. | No input needed. This field is auto-calculated based on the event's duration (e.g., 10 days). | | **Occurrence Frequency** | Allows you to choose how often the event recurs: Cooldown-based or Weekly-based. | Options: Cooldown-based (default), Weekly-based | Select one of the two options: Cooldown-based or Weekly-based. | | **Occurrence Details** | Displays the status of the event occurrences. The **Next Occurrences** are also listed, providing a schedule for when future occurrences of the event will happen. The **Refresh** button allows you to manually update the list of occurrences. This is important because changes to the configuration are **not automatically calculated**. | Based on Occurrence configuration | No input needed. This field is auto-calculated | #### **Cooldown-based Recurrence** **Cooldown-based** recurrences allow you to define a specific cooldown period between consecutive event occurrences. This means the event will restart after a defined waiting period, such as 2 days or 12 hours, regardless of the day of the week. | **Field** | **Description** | **Default/Options** | **Steps to Configure** | | --- | --- | --- | --- | | **Cooldown between occurrences** | Defines the waiting period between consecutive event occurrences (Cooldown-based). | Days, Hours, Minutes | Input the cooldown period in days, hours, and minutes (e.g., 2 days, 0 hours, 0 minutes). | #### **Weekly-based Recurrence** **Weekly-based** recurrences enable you to set specific days of the week on which the event will repeat, such as every Monday and Thursday, or at an interval of every two weeks. | **Field** | **Description** | **Default/Options** | **Steps to Configure** | | --- | --- | --- | --- | | **Start of occurrence** | Defines the day(s) of the week the event will start (Weekly-based). | Days of the week: Monday, Tuesday, Wednesday, etc. | Select one or more days for the event to start (e.g., Monday and Thursday). | | **Repeat every [X] weeks** | Defines how frequently the event repeats in weeks (Weekly-based). | Default: 1 | Input the number of weeks between recurrences (e.g., to repeat every 2 weeks, enter 2). | For weekly-based recurring events, the start time of each occurrence will align with the event’s configured start time, **not midnight**. For example, if an event's start time is set to 10:00 AM, all weekly occurrences will also start at 10:00 AM. **Note:** Ensure that the event’s start time is configured correctly to match the desired occurrence start time, as it will automatically propagate to all occurrences. #### Validation: Avoid Overlapping Event Occurrences When configuring an event that recurs on **multiple days** in a week (e.g., Monday and Thursday), it’s crucial to ensure that the **duration** of the event does not cause the occurrences to overlap. Overlapping occurs when a new event starts while a previous one is still ongoing. **Scenario:** If your event's **duration** is long (e.g., 6 days), and you select **two or more start days** (e.g., Monday and Thursday), and the event repeats **every week** , the system may detect an overlap between occurrences and prevent saving the event configuration. **Example Configuration:** 1. **Event Duration** : 6 days 2. **Occurrence Days** : Monday and Thursday 3. **Repeat Every** : 1 week With this configuration, the system identifies a conflict because: - **First event** starts on **Monday** and lasts for 6 days (Monday to Saturday). - The second event is scheduled to start on **Thursday** of the same week, which falls **within the duration of the first event**. - This causes an **overlap** , as the Thursday occurrence would begin **before the Monday occurrence has ended**. **System Validation:** - As this overlap is detected, the system will display an error message like **"Occurrences are overlapping."** - The system will not allow you to save the event configuration until the overlap is resolved. **How to Resolve the Overlap:** There are two ways to resolve this issue: 1. **Reduce the Event Duration** : 2. **Increase the Time Between Recurrences** : **Key Points to Remember** : - **Ensure that event durations don’t overlap with the next occurrence**. Either reduce the event duration or increase the time between recurrences to avoid overlap. - If you select **multiple occurrence days** in the same week (e.g., Monday and Thursday), ensure that the total event duration allows enough time between these days. - If your occurrences are longer than a week, ensure that you don’t repeat the event every week. - If you receive the **“Occurrences are overlapping”** error, review your event duration and recurrence settings to make necessary adjustments. Once you’re done with your configuration, click **[Save]** on the bottom left side of the screen.  ### **Event Recurrence Logic** Let us understand the event recurrence logic with the help of an example. **Example: Configuring a Recurring Event Every Wednesday and Friday (Every 2 Weeks)** You want to create a recurring event that happens every **Wednesday** and **Friday** , repeating **every 2 weeks**. The event starts on **Thursday, 19th September**. #### Configuration Details - **Event Start Date:** Thursday, 19th September. - **Event Days:** Wednesday and Friday. - **Recurrence Interval:** Every 2 weeks. **Expected Event Occurrences:** (When number of occurrences are not limited) 1. **First Event:** **Friday, 20th September**. 2. **Second Event:** **Wednesday, 2nd October**. 3. **Third Event:** **Friday, 4th October**. 4. **Fourth Event:** **Wednesday, 16th October**. 5. **Fifth Event:** **Friday, 18th October**. 6. **Sixth Event:** **Wednesday, 30th October**. 7. **Seventh Event:** **Friday, 1st November**. **How It Works:** - The event starts on the first available day after the start date (Friday, 20th September). - A **1-week gap** is added after the first event to maintain the recurrence interval of 2 weeks for both event days (Wednesday and Friday). - The **week break** refers to skipping an entire **Monday-to-Sunday** week, regardless of how many days pass between the last event and the next. This ensures that events are spaced by full calendar weeks rather than simply counting a set number of days. - The event will occur **in the same week** (on Wednesday and Friday) every 2 weeks from that point onward.

**Introduction** Waterfall is the process used to get the best price for an impression of an advertisement. The Waterfall configuration allows you to optimise the delivery of ads by controlling the order in which ad networks are called to fill an ad request. The waterfall setup enables that the most valuable and relevant ads are prioritised, maximising revenue opportunities. **Table of Contents** ## Waterfall Settings ### Request Refresh Period The **Request Refresh Period** settings allow you to manage the frequency and behaviour of ad requests. By configuring these options, you can: - Control how often ad requests are refreshed - Increase the refresh period after unsuccessful attempts, - Set limits on the maximum time between requests. | **Waterfall** | | **Field Name** | **Description** | **Comments** | | **Ad request refresh period**   | This field determines how long the game waits before attempting to request another ad after a failed attempt | - Type: Integer - Default: 30 seconds | | **Enable increment** | This checkbox enables or disables the incrementing of the refresh period in case ad requests fail. When checked, the refresh period will increase with each unsuccessful attempt. | - Type: Boolean - Default: Unchecked | | **Increment refresh period with every unsuccessful attempt X** | Multiply the refresh rate in every consecutive attempt. This resets on a successful attempt  | - Type: Integer - Default: 5 | | **Until a max value** | Maximum value that the refresh period could reach  | - Type: Integer - Default: 90 seconds  | 1. Navigate to **Ads \> Configuration \> Waterfall** , and enable the **Request Refresh Period** setting by clicking on the  **[green + sign]**. 2. Fill in the fields following the information listed in the table above.