Eight capabilities,
all built on official endpoints

1. Budget burn alerts

The money most sellers lose is not in one badly performing campaign. It is in campaigns that burn the whole daily budget by mid-morning, lose the rest of the day, and leave the outcome to chance.

The service tracks the budget usage percentage of every campaign and portfolio, and flags when the day's spend is already close to the cap. It then proposes raising the daily budget or adjusting the bidding strategy so delivery is weighted toward the hours that actually convert.

Endpoints: Budget Usage API (near real-time budget usage for campaigns and portfolios), Reports (spend and sales data).

On the native rules. Amazon offers schedule-based budget rules that raise budgets for date ranges and for events such as Black Friday. We do not apply them blindly. We judge them against the account's actual performance instead: during peak events the native rule executes, and outside them the service still acts on rules you have approved.

2. Out-of-stock ad protection

Continuing to advertise a product you have run out of is one of the most common and most painful wastes in cross-border selling. The orders that ads generate cannot be fulfilled, and the conversion data is corrupted at the same time.

The service joins FBA inventory summaries to campaigns by SKU. When sellable stock falls below a threshold, it lists every campaign currently advertising that SKU and proposes pausing it or cutting its budget.

Endpoints: Selling Partner API FBA Inventory (inventory summaries and sellable units), Ads API Target and Ad (mapping spend to a SKU).

3. Zero-conversion term cleanup

Every account that has been running for a while accumulates search terms and targets that keep spending and never convert. Each one is small on its own. Together they are the least noticed block of spend in the account.

The service runs conversion attribution across search terms and targets, selects the ones that passed your spend threshold with zero conversions, and proposes turning them into negative keywords or pausing them. You decide whether to approve; anything applied is written to the audit log.

Endpoints: Reports (search term report, targeting report, with spend and attributed conversions), Campaign Management Target entity (negative keywords are writable).

4. Official recommendation consolidation

Amazon issues its own optimization recommendations across bid adjustments, keyword suggestions, budget changes and campaign extensions. They sit in separate entry points, which makes them hard to read next to your own account data.

The service pulls those through the unified recommendations endpoint, cross-checks them against actual performance, inventory position and your guardrails, and returns a deduplicated, ranked list of actions. Each one states which official recommendation type it came from.

Endpoints: Recommendations API (one endpoint for recommendations across all ad products, filterable by ad product and recommendation type).

5. Competitor ad intelligence

Want to know what competitors are running, for how long, and which ASINs they are pushing? In the EU, Amazon's ad library interface opens that up, free and without needing access to a competitor's account.

These results are for private analysis inside your own account. We do not use them to calculate or publish any industry index, ranking or insight about the health of Amazon's business, and we do not combine ad library data with other sources and offer it externally.

The service can search advertising records across nine EU countries by keyword, brand or product, returning the advertiser, the advertised product, the start and end dates and the creative type. That supports judging how competitive a keyword is, spotting new product launch timing, or confirming whether a competitor is bidding against you.

Endpoints: Ad Library API (Germany, Spain, France, Italy, Netherlands, Poland, Sweden, Belgium and Ireland; up to 1,000 results per request with a pagination token).

Scope note. This endpoint covers EU marketplaces only. That is a deliberate boundary, not a gap.

6. Cross-marketplace portfolio management

When the same products run in several marketplaces, adjusting them one by one reliably produces drift. A budget goes up in one store and is forgotten in another. A campaign is paused in one and keeps spending in the next.

The service manages structure at the portfolio level. A single adjustment can be applied across the campaigns and ad groups inside a portfolio, which keeps marketplaces consistent, while each market keeps its own data view.

Endpoints: Campaign Management (read and write across the five entities: Campaign, AdGroup, Ad, Target, Ad Association), Portfolios (portfolio structure and shared budgets), Exports (asynchronous bulk export of the structure, which avoids pulling large accounts entity by entity).

7. Inventory-linked advertising

In most tools inventory and advertising are two separate datasets. One says you are out of stock. The other says this SKU is spending money. The real loss happens in the days when the two do not agree.

The service feeds stock state into the advertising decision itself. When a shipment is received it flags the campaigns that can resume. When stock drops below a safety line it proposes a pause. When stock is high and the campaign is budget-capped it proposes an increase. Every flag names the specific SKU and the specific campaign.

Endpoints: FBA Inventory (inventory summaries), the Reports API sales and traffic report (aggregate sales and order metrics; we do not request a Restricted Data Token, so the interface returns no buyer identity fields and no order details, requires the Brand Analytics role), Ads API Campaign and Target (mapping to SKUs).

8. Rule oversight and rollback

Amazon provides two native rule types. A bidding rule can adjust base bids up and down against a ROAS guardrail. A budget rule can raise the daily budget on a schedule or when performance thresholds are met over the previous seven days. Both run inside Amazon's own console, outside our control, but their effects can be read.

What the service adds is a layer around them: the actual bid and budget changes produced by rules go into the same audit record, and you are warned in advance when a rule guardrail and your own guardrail point in different directions. Any change can be traced to the rule and the values behind it, and rolled back to the pre-change value.

One point to be clear about: the rules themselves are executed by Amazon. We do not promise that a rule will hit the ROAS guardrail you set, and Amazon states the same limitation itself.

Endpoints: Rule reporting interfaces (actual bids and budgets after a rule takes effect), Reports (comparing performance before and after a rule is enabled).

Endpoints and permissions

The table lists every official endpoint this service depends on, and what we do with it.

What is not built yet

The following are feasible on the available endpoints but are not in the current version: creative asset creation and moderation, conversion tracking (Conversions API), AMC datasets and audience analysis, and media planning with reach forecasting. Each needs additional interface access and its own product module, and we schedule them against actual customer demand.

How the data is measured, and what the models do

Every figure the service produces at runtime comes from Amazon's own APIs. We do not estimate values and we do not use data from outside Amazon. The interface screenshots and the numbers in the tables on this site are sample data, used to show what the product looks like; they are not any customer's account data. What follows sets out how the real figures are measured, how current they are, and what the models are and are not used for.

One more note. We do our interface work against test accounts. Test accounts do not serve ads and do not incur charges, so they also produce no performance data: no clicks, impressions, sales, ACOS or spend. On a live account those figures come from the seller's own advertising account.

How the metrics are defined, and how fresh they are

Report data is not real time. Each recommendation states the date of the data behind it, so a report that has not been generated yet is not mistaken for a performance problem. The report and recommendation views also show the last sync time, so you can judge how recent the numbers are.

What the models do, and where they stop

A recommendation comes from two parts: rules and statistical models. The rule part covers cases that can be decided unambiguously, such as sellable inventory below a threshold you set, or a search term with zero conversions in a given window. The statistical part is used for ranking and for spotting anomalies, such as locating the campaign level where spend has run off.

The models read past performance to find anomalies. They do not forecast sales, they do not promise results, and they do not attempt to project the future. Advertising outcomes also depend on market conditions, competition and the product itself, none of which the models control.

They can be wrong. When there is too little data, the account structure is unusual, or the pattern of a category is disrupted, a recommendation can be inaccurate. Every recommendation needs your confirmation for that reason.

How changes are checked

Each change is checked against the limits you set before it is sent to the API, and anything beyond them is not sent. In recommendation-only mode nothing is written. In managed execution mode every change records the previous value, the new value, the rule that triggered it, a timestamp and the API response. Because the previous value is kept intact, any execution can be identified and reverted.

You can switch back to read-only at any time. A single control stops all automated execution without revoking your authorisation.