In the "fixed price" invoicing model, a flat rate is charged. This means that the costs (gross) always correspond to the agreed price (gross). Regardless of the actual quantity delivered, when choosing a fixed price, 100% of the agreed price is always used for cost calculations.

However, there is the possibility to distinguish between a forecasted fixed price and a realized fixed price.

For Mercury, a fixed price means that the costs are already fixed and known. Each fixed price refers to a specific volume, e.g.:

  • Fixed Price (Impressions)
  • Fixed Price (Clicks)
  • Fixed Price (Views)
  • Fixed Price (X) → X serves as a placeholder for a conversion type yet to be selected

All entered data is prorated down to individual days in the database. In forecasting, Mercury uses the fixed price and divides it by the number of days in the total runtime.

Even when choosing a fixed price, a cost import can be used. However, Mercury always imports only the realized total amount (from the start to yesterday or until the end of the runtime) and not the actual daily realized costs. This total amount is also prorated over the days, with the number of days and the realized volume assigned to the fixed price being used to calculate a daily share. Regardless of the cost import, the realized costs thus proportionally reflect the trend of the realized volume.

This also means that there may be discrepancies between the actual realized costs and the realized costs calculated by Mercury. These discrepancies are insignificant in the Mercury plan, as only the cumulative value for the entire duration is shown there. But they become relevant if this data is used in a report where different periods can be viewed.

According to this logic, a fixed price is always applied to the entire runtime of a plan item, even to plan items that are not yet active, meaning they have not yet been completed. The reporting of costs from the start to yesterday is done with the realized fixed price, which is interpreted in Mercury as the amount for the entire duration and prorated over the realized days. If this is not desired, the date in the "Adserver Data Until" column must always be set to the day +1 up to which the costs were recorded.

Therefore, we recommend not working with fixed prices but rather choosing a variable pricing model (CPM, CPC, CPV, CPX) when an active cost import is being used, and the costs should be viewed on a daily aggregation level with their actual realized values.

If a cost sync is still used when working with a fixed price, it should be noted that the imported costs can be found in the "Realized: Costs (AdServer)" column and can also be overwritten there. Mercury will not consider entries in "Realized: Gross Price" accordingly.