Release Notes: August 16, 2024
about 1 month ago by Nico Staple
Enhancements to the Forecast API; attribution for any ad format in the Management API; and a fix for campaign metrics in the Management UI.
Forecast
Forecast API
Added
- Forecast group-by array fields. Supports break-down by individual element of array fields, e.g. individual keyword, zone or ad type, instead of the set sent in an ad requests. Full details in Group by array fields The default behavior of grouping by the whole set remains the same. In order to expand the elements from an array, a literal
[]
is appended to the field name, or, if it is a known array field, the field name in singular form can be used - Auction selection algorithm support (Flat and CPM rate types), without support for auto-bid, ROAS targeting, or revenue overrides
- Support for reserved keywords:
$device
,$userAgent
,$ip
,$datacenter
,$referralUrl
,$url
,$domain
, and$acceptLanguage
- Speed up
Existing
forecasts by using the ad delivery cache
Ad Server
Management API
Added
- Attribution for any ad format — you can now attribute any ad format to retail transactions—not just product listing ads (PLAs)—by defining a set of attributable products, categories, and brands associated with an ad. For PLAs this is set automatically based on the product metadata when using the “create ads from products” workflow in the UI or API via pre-defined Ad Template mappings. For display ads, sponsored brands and other formats, the set of attributable sales is explicitly set to match advertiser goals from specific product collection promotions to more general brand awareness campaigns. Learn more on the updated Kevel Attribution knowledge base page.
Management UI
Fixed
- Rounding display inaccuracy for campaign metrics — we fixed a bug that caused the Management UI to incorrectly rounding some metrics returned from the Real Time Reporting API. These metric columns (clicks, impressions, etc) are shown when viewing Campaign, Flight, and Ad list tables in the UI. These values are displayed in a truncated format (eg "2.05m" to represent 2,050,000), and, in some cases, numbers were rounded down with inaccurate precision when rendered in the browser. There was no issue in the underlying reporting data—this was purely a UI rendering bug.