How does the Ad Forecaster scale?
The Ad Forecaster uses Marathon, a framework for container orchestration, for managing the infrastructure, enabling it to scale to hundreds of nodes. As such, new machines can be easily added to the cluster, quickly becoming usable in processing incoming requests.
What happens if a machine fails?
When the cluster starts, data is automatically distributed evenly across all machines. In case of hardware failure, the remaining machines identify that the cluster has changed and redistribute the data from the failing machine. In such cases, performance might degrade and requests may take longer to respond, as the cluster will be one machine short.
Is the Ad Forecaster secure?
The Ad Forecaster values data privacy. As such, the deployment can be done in the client’s own infrastructure, allowing data to stay within their premises. Furthermore, all interactions with the API and UI can use HTTPS, ensuring encryption of all exchanged information with the server.
A new API version is available. Will the one I’m using be removed?
Whenever a new API version is released, the previous version is still available for at least one year. That gives our clients time to go through the changes and update on their own schedule.
What is the terminology used?
- Campaign impression goal: the maximum number of impressions to be delivered for a campaign.
- Eligible impressions: the number of impressions matching the targeting rules, ignoring any existing campaigns or frequency caps.
- Available impressions: the number of impressions matching the targeting rules, excluding campaigns with a higher priority level.
- Forecasted delivery impressions: the number of impressions predicted to actually be delivered for the campaign, considering its rules and overlapping campaigns.
- Lost impressions: the number of eligible impressions that were delivered to other campaigns.
The Ad Forecaster provides three forecasting endpoints, for discovering the Eligible, Available and Forecasted delivery impressions. Please refer to the API documentation for more details.
What is cross-device forecasting and how to use it?
Cross-device targeting is a technique adopted to improve campaign performance. If a masterUserId
is provided in the log files, it is possible to use this id for user tracking and frequency capping,
instead of using the userId. To do so, the useMasterUserId parameter should be set to true in
the forecast request. While counting users, if the masterUserId is not provided for an impression,
its userId is considered instead.
It is possible to target only users that have a masterUserId by including the following targeting
rule in the forecast request: "targeting": [{"rule":"hasMasterUserId"}]
What data do I need to send to the system?
The Ad Forecaster requires historical log files of at least 28 days to bootstrap and provide accurate forecasts. Less data might be temporarily used for development environments or while bootstrapping systems, with a negative impact in forecasting quality and accuracy.
In a production environment, only the previous 28 days are taken into consideration. Logs should be provided on a daily basis. Logs older than 28 days can be discarded.
Optionally, existing campaigns can be added to the system using the campaigns API. This allows the engine to evaluate which inventory will be reserved or compete with new campaigns. Campaign details should be periodically updated to keep Ad Forecaster synchronized with the actual delivery. To leverage accuracy and caching, we recommend updating the campaigns every six hours.
Which fields can be used for aggregation?
Fields with a large count of possible values are not used for aggregation, as
doing so would negatively impact performance. Refer to the /forecast/fields
endpoint to get the list of groupable fields.
What is the amount of data required for accurate forecasting?
Forecasting will have its accuracy improved with the increase of the historical data made available to the engine. Refer to the log sampling page for a sample size calculator.