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.
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:
What this is telling leadership:
- **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
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:
Cross-connector reconciliation (when these connectors are connected for this merchant):
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).