logo

Get Updates

Changelog

Release: 1803 (2018-03-09)

v1.4

  • Introduced version 1.4: The old version 1.3 will be officially supported until 2019-03-09.

  • Warning levels: The forecast warnings no longer show the warning causes by default, to avoid large forecast responses. The level of detail of forecaster warnings can now be set with the warnings field in the forecast request.

  • Delete all forecasts: A new DELETE endpoint was added to cancel and delete all forecasts.

  • Removed support for synchronous forecasts

v1.2

  • Removed old API versions: Old and unused API versions have been removed, i.e. v1.2.

Release: 1710 (2017-11-01)

v1.2+

  • arrayContainsAny/arrayContainsAll Operations: The containsAny/containsAll can now be called as arrayContainsAny/arrayContainsAll.

Release: 1709 (2017-10-01)

v1.2+

  • Automatically retry processing logs: It was often observed that log files were not made available by the client at the expected time for the daily processing, requiring manual intervention to retry the process. From now on, when log files are not available, the system will automatically retry on the following day, picking new log files as they are made available, which automatizes and enhances the collection of daily log files.

  • Making requests resilient: During an update, it could happen that the previous system would get shut down, taking its asynchronous requests with it. This behavior has been improved, with the requests, or their answers, being kept on a separate storage, shared between the retired and the new system. This ensures all requests are properly handled and request information will never be lost.

Release: 1708 (2017-08-30)

v1.2+

  • Last update required for campaign impressions update: when updating the deliveredImpressions for a campaign, the lastUpdate parameter will need to be provided, otherwise the API will output an error. This will ensure that the number of deliveredImpressions is considered from the appropriate point in time.

  • Automatic Campaign Cleanup: After three months of a campaign’s finishing date, the campaign will be automatically removed from the system. This will prevent previous campaigns from cluttering the system, resulting in a performance improvement.

Release: 1707 (2017-07-30)

v1.2+

  • Default values for impression count hints: If an impression count hint targeted a log subset with few data points, it would only be able to generate artificial data if the targeting rule targeted all non-optional log row fields. It’s now possible to configure the system with default values for non-optional fields that can be used when generating artificial log rows.

  • Configurable delivery schedule: The campaign model now supports a deliverySchedule field that can be used to define a campaign pacing strategy. Each delivery schedule strategy is explained in detail in the delivery logic reference page.

  • isDefined operator: The isDefined operator is now available on targeting rules, which can be used to check if a field is defined. This new function is explained in more detail in the rules reference page.

  • Per-forecast hints: It is now possible to send a set of hints on each forecast request. This can be used to test hints without storing them on the system.

  • Historical data on rolling systems: Automatically deployed systems will now also include real historical data.

Release: 1706 (2017-06-30)

v1.2+

  • Campaign Retargeting: Introduces the possibility of targeting users based on their previous interactions with other campaigns. If campaign B is retargeting campaign A, then B will only deliver to users who have seen impressions from campaign A. More campaigns can be used in the retargeting list, with the new campaign only delivering to users who have seen impressions from all the campaigns listed.

Release: 1705 (2017-05-30)

v1.2+

  • Automatic Resource Cleanup: In order to avoid overloading the system, unused resources are automatically discarded, these include existing campaigns, frequency groups and hints. Existing campaigns and hints are considered eligible for removal if their startDate and endDate are outside the range of available log data. Frequency groups are considered eligible for removal if they only target unused/non-existing campaigns.

  • Background Cache Warming: Several internal caches are kept, to increase the performance of the Ad Forecaster, which need to be dropped when internal state is updated (e.g. existing campaigns, hints, etc). The Ad Forecaster now automatically populates these caches in the background when the system is idle.

  • Campaign Retargeting: The Ad Forecaster now supports defining campaigns with retargeting, i.e. they are only delivered whenever the user has seen all the campaigns that are being retargeted. The campaign model has been updated with a field retargeting which defines the ids of campaigns that this campaign is retargeting.

Release: 1704 (2017-04-30)

v1.2+

  • Frequency Groups and Caps in Availability Forecast: Availability forecasts now support frequency groups and caps.

  • Overlapping Hints warning: If more than one hint is applied in a request, a warning with code ‘OVRHNT’ is returned as part of the forecast response. A verbose message attribute is also returned, briefly describing the warning, namely providing the IDs of the overlapping hints.

Release: 1703 (2017-03-31)

v1.2+

  • Warning when campaign end date is greater than the data available: When performing a forecast for dates for which there are no logs available (or only partially available) a warning with code NOLOGS is returned with the forecast response.

  • Remove the default API: The API provided a default endpoint, which used the latest version of the API available. This was troublesome since when a new version was released this would be automatically updated and therefore it was not recommended to use in production. To avoid this the default endpoint has been removed and instead the API version should be set explicitly.

  • Implement forecast info endpoint: A new info endpoint has been added to provide information regarding the deployed system, e.g. start and end dates of available forecast data.

Release: 1702 (2017-02-28)

v1.2+

  • Forecasting with a master user id: If a master user id is provided in the log data it is now possible to forecast using that id for user tracking and frequency capping. The master user id is intended to aggregate different user ids and allows the implementation of scenarios like cross-device forecasting. This feature is supported on all forecast types. For deliverability forecasts this feature is enabled per campaign. For availability and eligibility forecasts the feature is instead enabled per forecast.

Release: 1701 (2017-01-27)

v1.3+

  • Introduced version 1.3: The old version 1.2 will be officially supported until 2018-01-27.

  • Persisted targeting rules: Targeting rules can now be persisted server-side and then referenced by their id when defining targeting criteria for a campaign, or directly in a eligibility or availability forecast. This is useful to re-use complex (and potentially large) targeting rules, e.g. for defining white/black lists. An example campaign definition with a targeting rule reference can be seen below:

    {
  "id": "campaign1",
  "startDate": "2012-09-02 00:00:00",
  "endDate": "2012-09-07 23:59:59",
  "priority": 0,
  "targeting": [
    { "id": "fcf0991d1" },
    { "rule": "geoCountry = \"GB\"" }
  ],
  "weight": 100
}

  • Percentiles with campaign ids: The percentile results are now aggregated by campaign id, making it easier to browse the forecasted values for multiple campaigns.

Release: 1610 (2016-10-25)

v1.2+

  • Frequency cap support in eligible inventory forecast: Forecasts for total inventory volumes now support setting multiple frequency capping rules.

  • Revamped log data storage: The underlying data storage that’s responsible for storing and accessing the log data has been revamped and should provide better performance characteristics.

v1.0, v1.1 and v1.1.1

  • Removed old API versions: Old and unused API versions have been removed, i.e. v1.0, v1.1 and v1.1.1. The only supported API version is now v1.2.

Release: 1605 (2016-05-24)

v1.0+

  • External monitoring endpoint: Expose the system’s usage metrics in the API, allowing the integration with, or development of, external monitoring systems.

Release: 1604 (2016-04-27)

v1.2+

  • Available inventory forecast: Forecast for total available inventory volumes, taking into account inventory taken by the existing campaigns.

v1.0+

  • Competing campaigns breakdown: Breakdown “stolen” impressions by competing campaigns in available inventory forecast.

Release: 1603 (2016-03-30)

v1.0+

  • System status dashboard: Monitoring dashboard allowing to see usage metrics, namely number of forecast requests and allocated resources for the past day, week and 2 weeks.

  • Revamped scaling strategy: Rely on Mesos, Marathon and other related tools to improve cluster management and ease scaling and automation of individual micro-services.

Release: 1602 (2016-02-29)

v1.0+

  • Reduced variance in results: The sample selection strategy was improved so that forecasts for a sampling level yield less variance in the results.

  • Notification hook: When performing asynchronous forecasts it is now possible to provide a callback URL (notifyUrl field in ForecastRequestParams) where an HTTP POST message (Notification) will be sent after the forecast has finished. This solution avoids polling for results.

Release: 1601 (2016-01-29)

v1.0+

  • Forecast completion ETA: Asynchronous forecasts now provide an expected time of accomplishment (eta field in ForecastStatus). It is only available if there are partial results available (i.e. the progress is between 0% and 100%, exclusively).

  • Campaign definition last update: When defining/updating campaigns it is now possible to set the lastUpdate field so that changes to the campaign state (i.e. deliveredImpressions) are correctly reflected when forecasting the campaign.

Release: 1511 (2015-11-30)

v1.2+

  • Eligible inventory forecast: Forecast for total inventory volumes, disregarding campaigns or ad selection logic. As it does not use the ad selection logic, it is much faster than the regular delivery forecast interface.

v1.0+

  • Advanced geo targeting rules support: Using distance to a lat-long point, with format latLong near (<lat>,<long>) by <distance> <unit>. Both km and mi units are supported. latLong is an example field that contains the user coordinates and exists in the log data sent to the Ad Forecaster.

Release: 1509 (2015-09-30)

v1.0+

  • Revamped targeting rule support:

    • Added new string operators: startsWith and endsWith
    • Support for array operators: containsAny and containsAll
    • Support for custom key-value fields, through indexing “container” fields (map and array), e.g. dynamicTargeting["gender"] = "male"

Release: 1507 (2015-07-29)

v1.0+

  • Show processing and queued forecasts: API endpoint forecast modified to show information about queued forecasts, currently executing forecasts and async forecasts that have been completed but whose response hasn’t been retrieved.

Release: 1506 (2015-06-30)

v1.2+

  • Hint collision checking: When new hints are added, the system will issue a warning if it believes that two hints will occur at the same time.

v1.1+

  • Use existing inventory pool on manual adjustments: Multiplier hints and Impression count hints have a new inventoryPoolRule field to train a hint with an existing inventory pool, in order to fill missing segment information.

v1.0+

Release: 1505 (2015-06-08)

v1.2+

  • Forecast results with campaign ids: The forecast results are aggregated by campaign id, making it easier to browse the forecasted values for multiple campaigns.
  • Key names in groupBy: The groupBy results now contain the key names of the groupBy fields making it easier to navigate through the results.

v1.0+

Release: 1504 (2015-05-12)

v1.2+

  • Introduced version 1.2
  • JSON error responses: Error responses are returned as JSON instead of plaintext.

v1.1+

  • Manual forecast adjustments: A new API end-point called hints supporting the ability to manually increase or decrease the forecasted inventory for a given time-span and optionally targeting rule. This enables adjusting individual segments such as ad units, placements, or entire sites based on known factors that will affect inventory for those specific areas, such as a new movie or TV series episode release date, shopping seasons or new sites or placements coming onboard.

v1.0+

  • Show forecasted delivery for existing campaigns: New API endpoint listing all stored campaigns and their forecasted delivery - forecast/existing_campaigns
  • Forecast with alternative settings for stored campaigns: Adds a way to run a forecast with specific changes to one or more stored campaign settings, either on its own or combined with a new campaign. This is useful for testing changes to stored campaigns before actually committing them. - ForecastRequest
  • List and stop running forecasts: A new API endpoint to list and/or stop the running forecast jobs
  • Define number of incremental results per forecast: A new field in forecast requests responsiveness to set the amount of incremental results received while the job is running. A more responsive forecast will show more interim results but also increase the total time for the entire forecast to complete.
  • Validation of campaign rules: Campaign targeting rules are now validated during API requests, if an invalid targeting rule is found (e.g. unknown field or operator) the request will fail with the appropriate error message.