How dependent is the brand on Amazon vs its own Adobe storefront? Concentration risk + early signal of marketplace policy hit.
At a glance
Amazon Seller Central revenue divided by Amazon + Adobe DTC combined revenue, expressed as a percentage. Tells you how much of your top-line depends on the marketplace versus your owned storefront. Above 50% is concentration risk, a single Amazon policy change, suspension, or Buy Box loss can wipe out half the business overnight.
| What it counts | Numerator: Amazon Seller Central revenue (sum of OrderTotal.Amount from the Amazon SP-API Orders resource) over the 30-day window. Denominator: Amazon revenue + Adobe Commerce SUM(grand_total) across all Store Views over the same window. Returned as a percentage of total combined revenue. |
| API field | Amazon side: OrderTotal.Amount from GET /orders/v0/orders (Amazon SP-API). Adobe side: grand_total from GET /rest/V1/orders. |
| VAT / tax treatment | Mixed. Amazon OrderTotal is the customer-paid total inclusive of any tax Amazon collected on the merchant’s behalf (Marketplace Facilitator regions, e.g. UK, EU, US-most states). Adobe grand_total is also inclusive of tax. Apples-to-apples in tax-inclusive markets. In tax-exclusive markets (some US states without Marketplace Facilitator, B2B Adobe stores), there’s a small bias. |
| Shipping inclusion | Included on both sides. Amazon OrderTotal includes ShippingPrice; Adobe grand_total includes shipping_amount. |
| Discounts | Already deducted, both sides. Amazon’s discounts (Lightning Deals, coupons, Subscribe & Save savings) are already netted in OrderTotal. |
| Credit Memo refund treatment | NOT subtracted on either side. Adobe Commerce grand_total is unchanged after a Credit Memo (refund lives separately). Amazon’s OrderTotal is unchanged after an A-to-Z claim or return refund. Both sides are gross of refunds. To see net-of-refund concentration, divide Net Amazon Revenue by Net Combined Revenue. |
state machine inclusion | All Adobe states included (matches Total Revenue): new, processing, complete, closed, canceled, holded, pending_payment, payment_review. Amazon side counts orders in any non-Canceled Amazon order status (Pending, Unshipped, PartiallyShipped, Shipped). The Adobe pending_payment quirk means a high-fail Adobe gateway can artificially inflate the Adobe denominator and depress the Amazon share, see FAQs. |
pending_payment quirk | Adobe Commerce includes pending_payment orders in the denominator even though they never collected cash. A store with high gateway-callback failures will have a denominator that’s 2-5% bigger than realised cash flow, which understates the Amazon share. For a “realised cash” version, filter Adobe to state IN (processing, complete, closed). |
Multi-currency grand_total vs base_grand_total | Both sides use display currency without FX. Amazon’s per-marketplace orders (Amazon US in USD, Amazon UK in GBP) sum without conversion; Adobe’s per-Store-View orders likewise. The combined ratio is approximately FX-neutral if Amazon and Adobe share similar currency mixes. International merchants with very different geo footprints between the two channels should use base_grand_total views. |
Store View scope (store_id) | All Adobe Store Views summed, including B2B portals. If your Amazon presence is consumer-only but Adobe includes a large B2B portal, the denominator is consumer + B2B and the Amazon share is artificially low. Filter the Adobe denominator to consumer-only Store Views for a fair retail-vs-marketplace comparison. |
| Time window | 30D vsP (rolling 30-day vs the prior 30-day) |
| Alert trigger | Amazon share >50% (channel-concentration risk). The threshold is a strategy signal rather than an outage signal; no has_threshold enforcement (alert is informational). |
| Roles | owner, finance, marketing |
Calculation
Worked example
A consumer-electronics brand on Adobe Commerce 2.4.6 with US, UK, and B2B Store Views, also selling on Amazon US, Amazon UK, and Amazon DE via Seller Central. The 30-day window covers 14 Mar 26 to 12 Apr 26.| Channel | Revenue (display currency) | Indicative USD |
|---|---|---|
| Amazon US | $312,400 | $312,400 |
| Amazon UK | £74,200 | ~$92,800 |
| Amazon DE | €58,600 | ~$63,200 |
| Amazon total (numerator) | ~$468,400 | |
Adobe grand_total US Store View | $272,320 | $272,320 |
Adobe grand_total UK Store View | £80,784 | ~$101,000 |
Adobe grand_total B2B portal | $58,220 | $58,220 |
Adobe pending_payment value (across views) | $12,168 | $12,168 |
| Adobe total (rest of denominator) | ~$443,708 | |
| Combined denominator (Amazon + Adobe) | ~$912,100 | |
| This card (Amazon share) | ~51.4% |
- Amazon now drives more revenue than your owned channel. Above 50% is the strategic warning zone, a single Amazon policy hit (suspension, Buy Box loss, takedown of a hero ASIN, ToS violation) can wipe out a quarter of the business in 24 hours. The card is a strategic-risk indicator, not an outage indicator.
- The B2B portal ($58,220) inflates the Adobe denominator and artificially lowers Amazon share. Most Amazon-vs-DTC analyses are about consumer business; B2B is a separate motion. With B2B excluded, Amazon share rises to 54.7%, the real concentration is worse than the headline.
- vs prior 30 days the share moved from 47.2% to 51.4%. Investigate which side moved: did Adobe DTC drop (a campaign ended, paid-ads softened) or did Amazon grow (a Lightning Deal landed, an ASIN went viral)? Pair with Total Revenue trend and
amazon_sp.amazon_sp_total_revenue. pending_paymentorders ($12,168) inflate the Adobe denominator slightly, understating Amazon share by ~0.7 percentage points. The “realised cash” Amazon share (excludingpending_payment) is ~52.1%.- The European mix is heavier on Amazon than the US mix. Amazon UK + DE = 101k (ratio 60.7%). Amazon US = 272k (ratio 53.4%). The brand is more dependent on Amazon in Europe than in the US, drives a different rebalancing strategy per region.
Sibling cards merchants should reference together
This is a strategy card, pair with these to drive decisions:| Card | Why pair it with Amazon Revenue Share |
|---|---|
| Total Revenue | The Adobe denominator. Movement on the share card without movement on this card means Amazon grew; movement on both means both are moving (often opposite directions). |
| Order State Distribution | A pending_payment spike inflates the Adobe denominator, suppressing Amazon share. Cross-check before declaring “Amazon is shrinking”. |
| Revenue by Store View | Filter to consumer-only Store Views to exclude B2B from the denominator for a fair retail-only comparison. |
| Credit Memo Total | Both sides are gross of refunds. A returns-heavy month doesn’t show in the share but does show here. |
| Email Revenue Share | Sister cross-channel card. Together they tell you “what % is Amazon, what % is owned email, what % is everything else”. |
amazon_sp.amazon_sp_total_revenue | The Amazon numerator on its own. Movement here without movement on the share card means Adobe DTC is keeping pace. |
amazon_sp.amazon_sp_buy_box_pct | The leading indicator of Amazon revenue health. Buy Box loss precedes revenue loss by days. |
google_analytics.ga_revenue_by_channel | GA4 doesn’t see Amazon (it’s its own walled garden). Use GA4 only for the Adobe DTC channel mix; this card spans both. |
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin: Adobe Commerce doesn’t natively know about Amazon, so reconciliation is per-side. For the Adobe denominator:Reports > Sales > Orders (or Reports > Sales in 2.4.6+). Set the same 30-day window, scope to All Store Views, Status filter “All Orders”. The Total Revenue column is the Adobe denominator. Cross-check with Total Revenue.For the Amazon numerator (in Amazon Seller Central, not Adobe Admin):
Reports > Business Reports > Sales and Orders by Date in Seller Central. Set the same 30-day window. The “Ordered Product Sales” column should match the Amazon numerator within ~1% (Amazon’s Business Reports include Pending orders; SP-API does too).Other Adobe Commerce Admin views that look relevant but aren’t:
- Marketing > Communications: email/transactional, not channel-revenue.
- Catalog > Products with marketplace flags: shows which SKUs sync to which channel, not channel revenue.
- Reports > Sales > Coupons: coupon-revenue, not channel-revenue.
- Stores > Configuration > Sales: configuration, not data.
- Customers > Now Online: irrelevant.
| Reason | Direction of divergence |
|---|---|
Time-zone. Amazon SP-API uses PurchaseDate in UTC. Adobe Commerce Admin uses Store View timezone. The 30-day window endpoints sit at different real-world cutoffs. | ±1 day’s data at the boundary |
| Currency. Both sides use display currency without FX. The combined ratio is approximately FX-neutral if both channels share similar geo mix; biased otherwise. Material for international merchants. | Material for FX-mix-asymmetric merchants |
| Store View scope. Adobe denominator sums all Store Views including B2B. If your Amazon presence is consumer-only, the denominator-includes-B2B inflates and Amazon share is artificially low. | Vortex IQ ratio lower than consumer-only manual calc |
pending_payment asymmetry. Adobe denominator includes pending_payment; Amazon SP-API’s Pending status is included in the numerator (matching). The asymmetry depends on relative pending_payment rates between channels. | Usually 0-2% bias |
| Marketplace-tagged Adobe orders. If Adobe hosts Amazon-routed orders via a Sales Channel module, they appear in both numerator and denominator. Configure the manifest to exclude. | Material if double-count not configured out |
| SP-API rate limits. Amazon SP-API has strict rate-limits; if the Vortex IQ sync throttled during the most recent run, the latest few hours of Amazon orders may be missing. | Self-resolves at next sync, typically within 1 hour |
| Refund timing. Both sides are gross of refunds. Amazon’s A-to-Z claim refunds are processed up to 90 days after the order; this doesn’t affect either side’s revenue figure (both are unchanged). | No divergence |
| Pair | Expected relationship | What divergence tells you |
|---|---|---|
| Amazon SP-API revenue + Total Revenue (this card’s combined view) vs the merchant’s bank deposits | Combined ≥ deposits | Combined includes refunded orders, pending_payment, and Amazon Pending. Bank deposits are net of all of those. The gap should be stable; growing gap means refunds are growing or pending_payment is growing. |
amazon_sp.amazon_sp_total_revenue | Should equal the numerator of this card | If they differ, one connector has a sync issue. Check the most recent sync timestamp on each. |
stripe.stripe_total_revenue | Stripe ≤ Adobe denominator | Stripe sees only the Adobe DTC side, and only the Stripe-paid subset of that. Doesn’t reconcile to combined revenue. |
google_analytics.ga_revenue_trend | GA4 ≈ Adobe revenue × (1 − tracking gap) | GA4 doesn’t see Amazon at all. Useful only for sanity-checking the Adobe side. |
Known limitations / merchant FAQs
Why does Amazon Seller Central show a different revenue figure than the numerator on this card? Three usual causes: (1) timezone, Seller Central renders in your account’s locale, the SP-API uses UTC; (2) you’re looking at a different metric in Seller Central, “Ordered Product Sales” matches but “Sales” sometimes excludes shipping/tax, and “Net Sales” subtracts refunds; (3) sync lag, SP-API rate-limits can leave the most recent few hours stale. My finance team says Amazon revenue is lower, why? Both sides on this card are gross of refunds. Amazon’s A-to-Z claims and return-refunds get processed up to 90 days post-order; finance typically uses Amazon’s settlement reports which net them out. This card uses SP-API order data which doesn’t net them. Pair withamazon_sp.amazon_sp_refund_value for the offset.
What’s the difference between state and status and how does it affect this card?
On the Adobe side: state is the lifecycle (8 values); status is the configurable label. The denominator sums all states regardless. On the Amazon side: Amazon’s OrderStatus is fixed (Pending, Unshipped, PartiallyShipped, Shipped, Canceled, Unfulfillable). The numerator includes everything except Canceled, matching the spirit of the Adobe-side inclusion of canceled (we want orders placed, not realised). This is intentional but worth knowing if you’re cross-checking.
Why does Adobe’s pending_payment matter to a card about Amazon share?
Because it inflates the Adobe denominator. A high-fail Adobe gateway can have 5%+ of grand_total sitting in pending_payment (orders the gateway didn’t confirm). That bloats the denominator and depresses the Amazon share artificially. For a “realised cash” view, filter Adobe to state IN (processing, complete, closed).
What’s grand_total vs base_grand_total and which does this card use?
grand_total is the order’s display currency; base_grand_total is the store’s base currency, FX-converted at order time. This card uses grand_total (display currency, mixed without FX) on the Adobe side and OrderTotal.Amount (display currency per marketplace) on the Amazon side. The combined ratio is approximately FX-neutral if both channels share similar geo mix; biased otherwise. Multi-currency international merchants should consider per-region card variants.
My multi-store Adobe Commerce, can I see per-region Amazon share?
Not on this card directly. Filter both sides per region: connect a per-marketplace Amazon (US, UK, DE) view alongside a per-Store-View Adobe filter. A per-region card variant is on the roadmap.
Why doesn’t Adobe Commerce dashboard show Amazon share?
Adobe Commerce doesn’t natively know Amazon exists. Some merchants use the Amazon Sales Channel module or M2EPro to bring Amazon orders into Adobe with a marketplace tag, that’s a configuration, not a default. If your setup does that, this card double-counts; configure the manifest to exclude marketplace-tagged Adobe orders from the denominator.
My Stripe revenue and Amazon revenue don’t match, expected?
Yes. Stripe is the Adobe DTC payment processor only; Amazon doesn’t use Stripe. There’s no direct relationship. Stripe sees the Adobe-side cash flow; SP-API sees the Amazon-side. They’re parallel, not overlapping.
Why doesn’t Google Analytics show Amazon revenue?
GA4 only tracks traffic on your Adobe Commerce storefront. Amazon shoppers never touch your site, so GA4 has no view of them. This card is the only place to get the channel-vs-channel revenue mix.
My Amazon share is below 50%, am I safe?
The 50% threshold is informational, not a guarantee. Some healthy DTC brands run at 60-70% Amazon and are fine because their margins on Amazon and DTC are roughly equal. Some struggling brands at 30% Amazon are in trouble because their Amazon margin is razor-thin while DTC subsidises. Use this card alongside amazon_sp.amazon_sp_buy_box_pct, per-channel margin analysis, and your category’s typical concentration to make a judgement.
Why does today’s number swing so much?
Daily resolution on a 30-day rolling window is smoothed enough to be stable; the share rarely moves more than 1-2 percentage points day-to-day. If you see >5pp swings between days, one of the connectors is having sync issues. Check the most recent sync timestamps on both Amazon SP and Adobe Commerce in your Vortex IQ workspace settings.