Version 0.1.0-beta.4

TL;DR: Search performance analytics is rebuilt on Insights, with your own date ranges and comparison periods, sortable performance tables for queries, categories, products, brands, and pages, and the dashboard's own preset filters. Six legacy analytics actions are retired. Ranking rule customizations now validate before they submit and explain what the backend rejected. Catalog actions cover both catalog generations, and you can review a project's integrations.

Analyze Search performance with the dashboard's own numbers

Headline KPIs (revenue, RPV, AOV, and conversion rate) now come back pre-computed with current, previous, and trend values for every metric, so the figures match what you see in the performance dashboard.
Sort, search, and page through new performance tables for queries, categories, products, brands, and pages. Every row carries its own previous-period value, so you can see movement without a second call.
Apply the dashboard's preset filters instead of rebuilding them by hand: no revenue, no search results, and top searched-for queries; top categories and lowest converting for categories; and top products for products.
Plot any single metric as a daily time series with its comparison period alongside it.
Read metric cards for the Products tab.
Break page performance down by device, across desktop, mobile, and tablet.

Choose your own reporting windows

Every analytics action now accepts an explicit start and end date, plus a custom comparison window, in either YYYYMMDD or YYYY-MM-DD form. Leave them out and behavior is unchanged: a rolling window compared against the period of equal length immediately before it. Date ranges now anchor to the last date your account actually has data for, so results line up with the dashboard's "Data available through" range instead of drifting past it.

Retired analytics actions

Six analytics actions are no longer available. Their coverage moved to the new performance tables and the metric trend:

Top queries and queries driving sessions but no revenue are now the query performance table, using the top searched and no revenue preset filters.
Top categories and lowest-converting categories are now the category performance table.
Top-performing products are now the product performance table.
Sitewide daily performance is now the metric trend, which plots any metric valid for the tab you pick rather than a fixed pair of revenue figures.

Safer ranking rule customizations

Customization writes are validated before they are sent, so a malformed payload is caught up front instead of failing at the backend.
When the backend does reject a write, you now get its actual message rather than a bare failure with no detail.
Each rule type now declares which item types it accepts, so you can tell before writing whether a combination is valid.
Attribute boost and bury is now a named option instead of a free-form field.

Catalog actions now cover both catalog generations

A project still on the earlier catalog generation used to get an empty list alongside a success status, which read as "no catalogs" when catalogs existed. Catalog browsing now queries both generations and merges the results, and per-catalog actions detect which generation a catalog belongs to and route accordingly. Catalog configuration and job history remain concepts that only apply to the newer generation, and now say so explicitly instead of returning a confusing not-found error. See product catalogs.

Review a project's integrations

See which external systems are connected to a project, across ads, email, SMS, storage, SQL, and authentication. Responses carry only each integration's ID, name, and type; configuration and credentials are never returned. See project settings and access.

Bug fixes

A malformed date in an analytics request now returns a clear error naming the account and the problem, instead of failing without explanation.
A customer filter set at the top level of a scenario used to be accepted and then silently ignored, so the scenario ran against all customers. It is now rejected, with guidance to scope your audience on a Condition node instead. See automation scenarios.