Features, grouped by the Amazon data role each one needs

Brand Analytics — Search Query Performance

Reports API v2021-06-30 · GET_BRAND_ANALYTICS_SEARCH_QUERY_PERFORMANCE_REPORT · weekly, monthly or quarterly period · optionally scoped to a list of the seller's own ASINs.

This is the role Amazon reviewers most often ask about, so here is exactly what GlassBox does with it. The Search Query Performance report gives, for each search query, the whole funnel at marketplace level — search query volume, impressions, clicks, cart adds, purchases — together with the selling partner's own share of each step, plus the median prices and shipping speeds at which the marketplace's clicks and purchases happened.

What the application computes from it

• Funnel bottleneck detection. For every query above a volume floor, each funnel step is compared with the one before it. When a step retains less than a configured fraction of the previous step, that step is named as the bottleneck — impression problem, click problem, cart problem or checkout problem — instead of collapsing the whole thing into a single conversion rate.
• Share gap. Where the seller's purchase share on a query is materially higher than their impression share, the query converts better for this seller than the marketplace average and the seller is under-showing on it. This becomes a concrete proposal to raise the bid or add the query as an exact-match keyword.
• Organic versus paid split. The seller's own advertising numbers for the same query — clicks, orders, spend, sales — are joined to the SQP row, so the seller can see how much of their own click share on a query they are paying for and how much arrives organically. Neither report can answer that alone.
• Price gap against the market median. The seller's own price for the ASIN is compared with the median purchase price on that query. A gap beyond a configured threshold is surfaced as a price signal, not as an advertising instruction.
• Period-over-period movement. Successive reports are stored, so a query whose volume or whose share is moving is flagged rather than being re-read from scratch.

What it does not do with it

Brand Analytics data is used only to produce recommendations for the selling partner who supplied it. It is never combined with another customer's data, never aggregated into market-wide statistics, never sold, never published, and never used to build a product for anyone other than that seller. Each customer's reports are stored in a database of their own.

The marketplace-level figures named above — query volume, the median prices, the funnel totals — are the ones Amazon itself publishes inside that seller's own report. We show them back to that seller, next to their own share, so they can act on their own listings. We do not republish them, do not derive any statement about Amazon's business or any other seller's business from them, and do not use them for our own purposes.

If the seller does not have Search Query Performance available, the module reports that the source is empty and the rest of the application works without it. The report can also be supplied by hand as a CSV export.

Selling Partner Insights — connection and marketplace discovery

Sellers API v1 · GET /sellers/v1/marketplaceParticipations

• Connection test. When the seller connects their account, the application makes one call and shows the result, so a missing role or an expired token is visible immediately rather than as a silent failure three days later.
• Marketplace list. The marketplaces the seller actually participates in populate the marketplace selector. Everything else in the product — reports, stock, recommendations — is then scoped to a marketplace the seller really has.

Product Listing — catalogue structure and fee estimates

Catalog Items API v2022-04-01 · GET /catalog/2022-04-01/items/{asin} with includedData=attributes,relationships,salesRanks,images,summaries · Product Fees API v0 · getMyFeesEstimateForASIN · Reports API v2021-06-30 · GET_MERCHANT_LISTINGS_ALL_DATA

• Variation map. Advertising reports identify an ASIN but say nothing about which parent it belongs to, or what colour and size it is. Catalog Items supplies the parent-child relationships and the variation attributes. Without them, a colour that converts and a colour that does not look like one product.
• Halo decomposition. With the variation map in place, the application separates the purchases an advertised ASIN keeps for itself from the purchases that flowed to its siblings. This is the difference between "this campaign is unprofitable" and "this campaign is profitable but the credit lands on a different child ASIN".
• List price and sales rank. Read from catalogue attributes and salesRanks to give the seller their own reference price and category position without leaving the application.
• Fee estimates. The per-unit fulfilment fee and referral fee for the seller's own ASINs at their own price, used as the authoritative input to contribution margin and therefore to break-even ACoS. A stale or guessed fee makes every downstream advertising decision wrong by the same amount.
• Merchant-fulfilled stock. The all-listings report supplies quantities for listings that FBA reports do not cover, so the stock picture is complete.

Pricing — competitive offers and Buy Box position

Product Pricing API · GET /products/pricing/v0/items/{asin}/offers

• Correct fee basis. A fee estimate is only as good as the price it is computed at. The current landed offer price is read so the fee estimate, and therefore the margin and the break-even ACoS, reflect what the product is actually selling for today.
• Buy Box awareness. When the seller does not hold the Buy Box, spending on advertising for that ASIN converts very differently. The application surfaces this as a reason attached to the affected recommendations instead of silently producing a bad one.
• Delivery promise. The shipping time range on the offer is turned into a plain delivery estimate shown alongside the listing, so a seller can see whether a conversion problem is a delivery problem.

Finance and Accounting — real contribution margin

Finances API v0 · GET /finances/v0/financialEvents · paginated, within Amazon's 180-day window

• Fees as they were actually charged. Financial events are aggregated per SKU into referral fees, fulfilment fees, storage, refunds, reimbursements and promotional rebates. Estimates are replaced by what Amazon actually took.
• Break-even ACoS per product. Combined with the seller's own cost of goods, this produces the single number every advertising decision in the product is measured against. Bid ceilings, negation thresholds and scale decisions all derive from it.
• Cash flow and affordability. Settled and withheld amounts feed a liquidity view, so a proposed purchase order can be checked against money that actually exists rather than against revenue.
• Effect verification in money. When a previously approved action matures, its predicted saving is compared with the settled numbers, and the card says whether the prediction held.

No buyer identity is read, stored or displayed. Financial events are used at SKU and fee-type level only.

Inventory and Order Tracking — inventory position across Europe

Reports API v2021-06-30 · GET_AFN_INVENTORY_DATA_BY_COUNTRY

• Stock by country. For Pan-European sellers, the same SKU can be comfortable in one country and about to run dry in another. Stock is tracked per country and joined to the campaigns that drive demand for it.
• Stock-aware advertising guardrail. A recommendation to raise a bid or a budget is blocked when the projected out-of-stock date for that ASIN falls inside its replenishment lead time. This runs as a deterministic check before execution, not as advice the operator may ignore by accident.
• Restock planning. Demand is projected with an explicit uncertainty band; lead time is estimated from the seller's own purchase-order history rather than from a guessed constant; reorder points are computed at a service level the seller chooses. The optimiser reports the worst five per cent of simulated outcomes, not only the average, so the downside is visible.
• Purchase-order planning. Proposed quantities are packed into cartons and containers, priced with landed cost, and checked against available cash.

Amazon Advertising API — the advertising engine

Authorised separately from the Selling Partner API. Reporting v3 for search term, advertised-product and purchased-product reports; Sponsored Products v3 endpoints for negative keywords, campaign negative keywords and keyword updates.

Negative keyword engine

Layers 0 through 6, each with a distinct job:

• Layer 0 — relevance. Search terms are classified as relevant, irrelevant, or a competitor brand. Brand protection is deterministic: a term matching the seller's own brand can never be negated, regardless of what any model suggests.
• Layer 1 — statistical threshold. Instead of a folk rule such as "negate after twenty clicks", a Beta posterior over the term's conversion rate is compared with the break-even conversion rate implied by the seller's margin. A term is only proposed for negation when the probability that its true conversion rate is below break-even exceeds a threshold the seller sets, by default ninety per cent. Multiple comparisons are controlled with a Benjamini-Hochberg false discovery rate procedure, so a large account does not generate false positives simply by being large.
• Layer 2 — n-gram aggregation. Losing patterns spread across many low-volume terms are found at the phrase level, with a guard against negating a phrase that also occurs inside profitable terms.
• Layer 3 — minimum radius. A negation is applied at the narrowest scope that solves the problem — exact match at ad-group level by default — rather than at campaign level where it would also block terms that are working.
• Layer 4 — hygiene. Cannibalisation between campaigns competing for the same term; harvesting a proven term into its own exact-match target as a single atomic operation; rescuing a term that was negated on evidence that no longer holds.
• Layer 5 — guardrails. A deterministic validator that every action passes immediately before export or execution, whatever produced it. It enforces the seller's whitelist and brand terms, refuses to negate a term with a recent conversion, caps how many negations may be applied in one batch as a share of active terms, caps bid movement at a configured percentage (25% by default) and at an absolute ceiling, and blocks scaling when stock or unit margin will not support it.
• Layer 6 — audit log. Every proposal, approval, rejection, whitelist entry and execution is recorded with its timestamp, its actor and its evidence.

Bid engine

A maximum cost per click is derived from the seller's break-even ACoS and the revenue-per-click measured over 7-, 14- and 30-day windows, with recent windows weighted more heavily. Bids above the ceiling become bid-down proposals. Targets that have historical orders but have stopped receiving impressions are identified as bids that have fallen below the auction and become bid-up proposals.

Campaign advice

Pause, reduce, optimise, scale and create proposals with explicit budgets and an estimated monthly impact, arbitrated against the stock position so that "scale" and "about to run out" cannot both win.

Execution

Two paths, the seller's choice. Either a Sponsored Products bulk operations workbook that the seller uploads in Seller Central themselves, or direct execution through the Advertising API after a dry-run diff, with idempotent retries and token expiry surfaced in the interface rather than swallowed.

What GlassBox does not request, and does not hold

• No personally identifiable information about Amazon customers. The application does not call the Orders API, does not request restricted data tokens, and holds no buyer names, addresses, phone numbers or email addresses.
• No role whose purpose is buyer personal data. Every role listed above returns catalogue, advertising, inventory or fee data about the seller's own business. GlassBox needs none of the roles that exist to give access to personally identifiable information about Amazon customers, and it never requests a restricted data token.
• No buyer-seller messaging, no solicitations, no shipping documents.
• No pooled datasets. Amazon information from one selling partner is never combined with another's, and never used to produce a benchmark, an index, a report or a product sold to anyone.

How the numbers are produced

Every number the application shows carries a machine-readable record of how it was produced. The interface exposes it as a "why?" control on the figure itself. There are five kinds, and they are never blended silently:

When several steps combine, the result inherits the weakest of them. A recommendation that rests at any point on a heuristic is labelled heuristic, not counted. Assumptions are listed separately from inputs, so the seller can see both the number and the rule that was applied to it.

Where a language model is used, and where it is not

GlassBox uses a large language model in four optional places. None of them runs unless a model provider key has been configured, and with no key the application runs entirely on deterministic code. In none of them does the model decide anything, and in none of them can it write to Amazon. The four are not equally cautious, and we say which is which rather than describing the strictest one and letting you assume the rest.

1. Search term relevance (Layer 0). The model is shown search terms together with the ad group and campaign names they appeared in — as written in the seller's own account, which in practice often means the seller's own ASINs are in those names — and returns a relevance label. No performance figure is sent with them. A deterministic heuristic runs regardless and co-signs the result; brand protection is deterministic and the model cannot override it. Any label for a term that was not sent is discarded.
2. Daily briefing narrative. The briefing is computed deterministically first and is then sent with its real figures in it — window length, spend, sales, ACoS, wasted spend, and the proposed actions — with an instruction to keep every number exactly as given and rewrite the prose only. A truncated or failed response is discarded and the deterministic text is shown; the returned text is not re-verified number by number. This is the least sealed of the four, and it has its own off switch.
3. Executive summary. Here the numbers are sealed: every figure, date and ASIN is replaced by a marker before the call, restored by our code afterwards, and the whole answer is thrown away if a single marker was lost, altered or invented.
4. Pattern hypotheses. Deterministic pattern detection runs first; the model is then asked for additional hypotheses on top of those findings, which can name the seller's own ASINs and their share of spend against their share of sales. Every hypothesis it returns is displayed with a visible "hypothesis, not a measurement" badge and is never used in a calculation. If deterministic detection found nothing, the model is not called at all.

The exact fields sent, the processor that receives them, which switch governs which path, and the option to use your own model provider key are set out on the Data & AI page.

Accuracy and data freshness

• Freshness is shown, not assumed. Every source carries the date of the data behind it. Daily series older than three days are marked stale in the interface and the engines that depend on them say so on the recommendation itself. A source with no known date is reported as unknown rather than dated as today.
• Amazon's own reporting lag is respected. Advertising attribution is not final on the day it is reported, and Search Query Performance is published on a delay. Windows are computed against complete periods, and an action is not judged effective or ineffective until enough days have passed for its effect to have matured.
• Forecasts are scored against reality. Predictions are stored when made and scored when the horizon matures. The resulting error is shown in the application as a running accuracy figure, together with how many predictions it is based on.
• Nothing is claimed for thin data. Below the volume floors, the application abstains and says why, instead of producing a recommendation with no evidence behind it.
• Independently checked. The engines are covered by an automated test suite of over six thousand tests, including end-to-end runs from ingest through audit, approval, export and de-duplication on re-run.

See plans and pricing Ask a question