While latency is helpful for Ad Optimization, many Ad Ops teams still need to get transparent reporting on latency and consider the latency for optimization.
There are two types of Latency reports available:
- Placement Latency
- Waterfall Latency
Breakdowns in latency could show opportunities for performance improvements.
What's in the Report?
The Placement Latency report highlights different latency breakdowns as simply as possible.
For complete instructions on the functionality available to you with DT's Dynamic Reporting, you can click here.
Default View
To make it easier, the Placement Latency report default view shows the following details when the report is opened:
- Placement average latency for the last seven days.
The breakdown is by App Name, Placement Type, Placement Name
Latency Report Dimensions
Below are the groups and their dimensions that are relevant to the Placement Latency report.
Group Name | Dimension | Description |
---|---|---|
Date/Time | - | Date and time of the report. |
Inventory | App ID | The DT unique identifier for the app. |
App Name | The name of the app as written in the app settings. | |
App Version | The version of the app. | |
Placement ID | The DT unique identifier for the placement. | |
Placement Name | The name of the placement is written in the placement settings. | |
Placement Type |
Placement type describes the format and location of ads in your app according to the placement setting when it was created. Placement types can be either:
|
|
Product Line | DT FairBid or DT Exchange. | |
Demand | Demand Source Name | Demand partners who bid in the auction. |
Device | Device OS | The operating system of the phone/device. |
Location | Country | The country from which the ad request was received. |
App Performance Metrics
Metrics appear in the left pane under the dimensions. Set out below are the metrics relevant to the App Performance report.
Metric | Description |
---|---|
SDK Request |
A Fairbid SDK event means a request from the SDK. This is different than Ad Request, and those are possible reasons: a) There is already a fill for the placement. In this case, the SDK will not start a new Ad Request but will return the fill. b) Placement's capping/pacing or targeting prevents the count of Ad Requests. However, The SDK will still send an event of SDK request. |
Successful Load Rate | The rate at which SDK Requests were met with Successful Loads. The calculation is Successful Loads divided by SDK Requests. |
Successful Loads |
A FairBid SDK event means that there is an ad that can be displayed. It's different from Fills in the App Performance or Bids Won in the Demand Performance. Fills or Bids Won is just a count of wins from the backend, but it may not be loaded in the SDK. |
Placement Avg. Latency | The average time it took to run through the placement's auction until getting a "Fill" or "No Fill" or the auction reaching its time limit. |