At a glance
Distribution of customers and revenue by shipping-address country (ISO-2 country code). Adobe Commerce’s multi-store nature makes this a strategic surface: a UK-headquartered merchant who runs separate Store Views for US, UK, EU, and AU sees the country read distinct from per-Store-View aggregations. Country detection uses shipping_address.country_id, not IP geolocation. A customer ordering from a UK billing address but shipping to a France hotel for delivery counts as France here.
| What it counts | COUNT(DISTINCT customer_email) and SUM(grand_total) grouped by shipping_country_id, over the trailing 30 days. Returns a ranked table by customer count and by revenue contribution. |
| API field | extension_attributes.shipping_assignments[0].shipping.address.country_id (ISO-2) and customer_email from GET /rest/V1/orders. |
| VAT / tax treatment | Revenue series uses grand_total (tax-inclusive on B2C, often exempt on B2B). Cross-country tax-rate variance creates a slight bias when ranking by revenue: tax-inclusive UK revenue is overstated by ~16.7% vs tax-exempt B2B US revenue. |
| Shipping inclusion | Included via grand_total. International shipping fees are typically much higher than domestic, biasing international-country revenue upward. |
| Discounts | Deducted. |
| Credit Memo refund treatment | Not subtracted. |
state machine inclusion | All states except canceled. |
pending_payment quirk | Included. |
Multi-currency grand_total vs base_grand_total | Uses base_grand_total for cross-country comparison. |
Store View scope (store_id) | All Store Views; country dimension is independent of Store View. A customer shipping to US on the UK Store View counts as US. |
| Time window | 30D |
| Alert trigger | None by default. |
| Roles | owner, marketing |
Calculation
Worked example
A homewares brand on Adobe Commerce 2.4.6 with separate UK, US, EU, and AU Store Views plus a B2B portal. Snapshot Monday 4 May 26. Top countries by customer count:| Country | Customers (30D) | Revenue (base_grand_total) | % of revenue |
|---|---|---|---|
| GB (United Kingdom) | 1,840 | $246,000 | 28.0% |
| US | 1,420 | $312,800 | 35.6% |
| AU | 320 | $87,400 | 9.9% |
| DE (Germany) | 280 | $51,200 | 5.8% |
| FR (France) | 240 | $46,800 | 5.3% |
| IE (Ireland) | 180 | $32,800 | 3.7% |
| NL (Netherlands) | 130 | $26,400 | 3.0% |
| ES (Spain) | 110 | $19,200 | 2.2% |
| Other (24 countries) | 286 | $56,400 | 6.4% |
| Total | 4,806 | $879,000 | 100% |
- **GB has the most customers (1,840) but the US has the most revenue (220 per US customer vs $134 per UK customer. Cross-check this with B2B Revenue Share: the US Store View is more B2B-skewed than the UK Store View.
- Australia is a small but high-value market ($273 revenue per AU customer). Worth a strategic question: is AU traffic conversion already optimised, or is there room to grow?
- **EU long tail (DE + FR + NL + ES + IE) totals 187/customer average. Combined this is the second-largest market segment. Strategic question: is the EU Store View configured optimally? Is local-language support active? Are local payment methods (iDEAL for NL, Bancontact for BE, SEPA Direct Debit) configured?
- 24 long-tail countries contribute 6.4% of revenue combined. Most are likely incidental international shipments. The merchant might consider whether to maintain shipping configurations to all 24 (each has tax compliance overhead) or restrict to top markets.
- Tax-treatment bias caveat: GB revenue includes 20% VAT; US B2B revenue is typically tax-exempt. The “true” comparison removes this: GB customer-revenue ex-VAT is ~313k. Even adjusted, US per-customer LTV is materially higher.
- Multi-currency note: the figures above are FX-converted via
base_grand_total. Merchants comparing to per-Store-View native-currency totals see different absolute numbers; this card’s view is the right one for cross-country strategic comparison. - Action: prioritise EU localisation (the long-tail segment with proven traffic but small per-country revenue suggests checkout friction at the local level); consider a US-targeted B2B sales hire; evaluate AU paid-traffic investment.
Sibling cards merchants should reference together
| Card | Why pair it with Customer Countries |
|---|---|
| Customer Count | The aggregate. Country breakdown is its decomposition. |
| Total Revenue | The revenue denominator. |
| AOV | Per-country AOV varies materially. |
| Total Shipping | International shipping fees inflate per-country revenue. |
| Tax Analysis | Country-by-country tax-rate variance. |
| B2B Revenue Share | Country mix correlates with segment mix; US tends B2B-heavier than UK on most stores. |
google_analytics.ga_users_by_country | Top-of-funnel comparison. Sessions per country vs orders per country reveals conversion gaps. |
shopify.customer_countries | Cross-platform peer. |
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin:Reports > Sales > Orders filtered by date and ordered by country (Adobe Commerce 2.4.4+ supports country filter on the Sales Orders report).
Customers > All Customers with Address country sort, but this is registered customers only (excludes guests).
Sales > Orders with the Shipping Address: Country filter applied; CSV export and pivot for the country distribution.For multi-Store-View merchants:
Switch the Store View scope and run Reports > Sales > Orders per scope. Cross-country flow (a UK Store View order shipping to France) is visible only in the order-level filter, not in the Store View aggregate.Why our number may legitimately differ from Admin:
| Reason | Direction of divergence |
|---|---|
| Time-zone. Admin in Store View timezone; card UTC. ±1 day inclusion. | Negligible at 30D |
Currency. Card uses base_grand_total; Admin uses Store View base currency. Multi-currency sums differ. | Material on multi-currency mixes |
| Country definition. Card uses shipping country. Admin can filter by billing or shipping; defaults vary by report. | Material if shipping and billing diverge frequently (gift orders, B2B) |
canceled exclusion. Card excludes; Admin reports include unless filtered. | Card revenue slightly higher per-country |
| Pair | Expected relationship | What divergence tells you |
|---|---|---|
google_analytics.ga_users_by_country | GA4 sessions/users by country should correlate with order-customer count by country | Material divergence indicates conversion-rate variance by country (a country with high traffic but low orders has a localisation gap). |
google_ads.google_ads_geo | Ad spend by country should correlate with new-customer revenue by country | If you’re spending in Germany but seeing zero German customers, your ads are geo-mismatched or the German checkout is broken. |
| Carrier shipping reports | Country distribution should match within carrier-included territories | Major divergence usually means a carrier-managed forwarding service changing destination after shipment. |
Known limitations / merchant FAQs
Why does the card use shipping country rather than billing? Shipping country reflects where goods physically go, which is the most relevant strategic dimension (logistics planning, international shipping fees, carrier choice). Billing country can lag where the customer actually lives (corporate-card billing addresses, gift cards, intermediary billing services). For merchants who care about billing-country distribution specifically (tax reporting, fraud analysis), configure a sibling card variant. Adobe Commerce vs Magento Open Source: any difference? None at the calculation. Both editions storecountry_id on shipping addresses identically. Adobe Commerce paid edition’s enhanced multi-region tax logic and Adobe Experience Cloud integration give richer reporting on top of the same underlying data; Open Source merchants compute the country roll-up identically.
A customer ordering from US to a UK gift recipient, who counts where?
The shipping address is UK; the card counts this as a UK order. Useful for logistics planning. For purchase-intent analysis (where the customer “lives”), use billing-country sibling.
My multi-store Adobe Commerce, the country distribution looks weird, why?
Likely cause: Store View routing is geographic (US Store View, UK Store View) but customers can technically check out on a non-matching Store View (a UK customer accidentally lands on the US Store View, completes the order with UK shipping). The card surfaces this; the merchant can use it to identify Store-View routing leakage.
Why does the EU long tail show inflated revenue per customer compared to GB customers?
International shipping inflation: international parcels typically cost 3 to 8x domestic shipping. Cross-check with Total Shipping. The “real” per-customer purchase intent is closer if you subtract shipping; gross AOV-by-country misleads.
Why is my country count higher than my Store View count?
Store Views are merchant-created (US, UK, EU, AU); customers can ship anywhere they have an address. A 5-Store-View merchant might serve customers in 40+ countries. The two metrics are independent.
A few orders show country = "" (empty), why?
Adobe Commerce can store empty country on incomplete addresses (typically virtual/digital products that don’t require shipping). Filter these out via the manifest if your merchant ships physical-only goods.
My multi-currency Adobe Commerce, are the per-country totals comparable?
Yes; the card uses base_grand_total. Per-currency caveats: a US customer ordering on the UK Store View pays in GBP, and base_grand_total is the GBP value FX-converted to the merchant’s primary currency at order time. A pure-USD comparison would require segmenting by order_currency_code = USD (only available via custom configuration).