Attribute matrix and data sourcing

Every attribute the model needs, what it means, and whether the amazon_sp or amazon_ads MCP server can supply it. Read this when deciding what to ask the user for, or when explaining why a number could not be sourced.

Source tiers used throughout:

---

1. The headline finding

The calculator's hardest problem — mapping a product to Amazon's referral-fee category and then to the right FBA size-tier table — does not have to be solved at all when an ASIN exists.

fees_getMyFeesEstimateForASIN accepts an arbitrary PriceToEstimateFees.ListingPrice and returns Amazon's own itemised fee estimate at that price. That means:

• No referral-fee category mapping needed (Amazon applies its own band logic).
• No FBA size-tier calculation needed (Amazon applies its own tier + billable weight).
• No fee-table maintenance, no staleness, no per-marketplace rate cards.
• Break-even and target-margin prices can be solved by probing the API at candidate prices, which is exactly what the tiered referral bands require.

The rate limit is the constraint: getMyFeesEstimateForASIN is ~0.5 rps. fees_getMyFeesEstimates takes a batch, which is the one to use for a price sweep or a whole catalogue.

What SP-API's fee estimate does not cover, and therefore still needs modelling or a user input: storage, inbound placement, low-inventory fee, storage-utilisation and aged-inventory surcharges, returns processing fee, and the non-CEP surcharge.

---

2. Attribute inventory

2.1 Context

2.2 Product

2.3 Package

2.4 Programme flags

2.5 Costs and returns

2.6 Storage and inventory health

2.7 Overrides and solver targets

---

3. Advertising per unit — the one that needs a decision

The calculator takes a single number ("total ad spend ÷ units sold"). Producing it correctly requires both servers and a stated convention:

Numerator — ad spend attributable to the ASIN (amazon_ads)

• allv1_AdsApiv1CreateReport (v1 cross-product reporting) or rp_createAsyncReport (v3).
• Advertised-product-level reports for SP, SB and SD give cost by advertised ASIN.
• SB and SD are not always resolvable to a single ASIN; SB in particular spends at the brand level. Any per-ASIN SB allocation is an assumption that should be declared.
• DSP spend, if any, sits outside these reports entirely.

Denominator — units (amazon_sp)

• Sales & Traffic report gives total units ordered by ASIN.
• Ads reports give ad-attributed units.

Dividing by ad-attributed units gives you cost-per-attributed-unit, which flatters nothing and is close to ACoS-per-unit. Dividing by total units gives the TACOS-style per-unit ad load — and that is the one that belongs in a P&L, because the ad spend was incurred to sell the whole quantity, not just the attributed slice.

The calculator's own label ("total ad spend ÷ units sold") implies the TACOS convention. A skill should compute that by default, show both, and say which it used. Attribution window also has to be pinned and stated, or the numerator moves under you.

---

4. Derived outputs

All computed, none sourced:

The refund administration fee is 20% of the referral fee, capped at 5 units of the local currency (52.5 SEK / 20 PLN).

The two solves are why the fees estimate matters so much: referral bands, FBA price bands and VAT all move with price, so a fixed fee assumption produces a wrong break-even. Either probe the API across a price sweep (batch endpoint) or model the bands locally and calibrate against one live estimate.

---

5. Summary — what each side owns

SP-API can supply: referral fee, FBA fulfilment fee, size tier, current price, package dimensions (with caveats), storage charges, inventory age, days of supply, return rate, return dispositions, inbound placement fees, and — via settlement — the fees Amazon actually charged.

Ads API can supply: ad spend by advertised ASIN across SP/SB/SD, plus attributed units and sales.

Neither can supply: COGS, inbound freight, VAT rate, other per-unit costs, target margin. These are the irreducible seller inputs — five fields, and the model cannot run without them.

Genuine gaps: referral-fee category name (avoidable via the fees estimate), high-return-rate threshold status, CEP enrolment, and cross-market FX.

---

6. Implications for a skill

Three distinct modes, which want different code paths:

1. Pre-launch / no ASIN. Everything manual. Requires the full fee tables to be embedded, which means they go stale and need a verification date. This is the expensive mode to build and the one most likely to be wrong six months out.

2. Live estimate (ASIN exists). SP-API computes Amazon's side at any candidate price; Ads supplies the ad load; the seller supplies five numbers. No fee tables to maintain. This is the mode with the best accuracy-to-effort ratio.

3. Reconciled actuals. Settlement data gives the fees Amazon actually charged rather than estimated, which closes the gap between the model and the P&L. Slowest to build, most defensible output.

Recommendation: build mode 2 first. Mode 1 is a fee-table maintenance burden dressed as a feature; mode 3 is a data-pipeline problem more than a calculator problem.

Two things to carry into the skill regardless of mode: report type identifiers should be validated against Amazon's current Report Type Values documentation rather than hardcoded from memory, and account/marketplace/profile selection should be presented as options rather than silently defaulted.