> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Top-Velocity SKUs vs Ad Spend, Ecwid > Top-Velocity SKUs vs Ad Spend: fastest-selling Ecwid products that are under-invested in advertising. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Your proven winners that ads are barely backing. ## At a glance > A cross-channel card that cross-references your fastest-selling Ecwid SKUs against how much ad spend each one receives, to spot bestsellers that are under-invested in advertising. Products that already sell themselves are usually the safest place to put ad money, yet small sellers often spend evenly or on the wrong items out of habit. The card pairs sales velocity from Ecwid with spend from a connected ad platform, matching on product, and flags proven winners getting a thin slice of the budget. It combines Ecwid with an ad platform connector. | | | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it tracks** | For the top-velocity Ecwid SKUs over the trailing 30 days, the ad spend each receives from the connected ad platform, and the gap where high-velocity products take a low share of total spend. | | **API endpoint** | Ecwid side: order line items from `GET /v3/{store-id}/orders` and product data from `GET /v3/{store-id}/products` (OAuth2 with `read_orders`, `read_catalog`). Ad side: spend by product, campaign, or product group from the connected ad platform connector. Joined by Vortex IQ on product. | | **How velocity is set** | Units sold per day (or per window) from Ecwid order line items, ranked; the fastest movers are the top-velocity cohort. | | **How spend is matched** | Ad spend attributed to each product or its campaign / product group from the ad platform, mapped to the Ecwid SKU by product identity. | | **What it excludes** | SKUs with no sales velocity (nothing to back); products with no matchable ad entity; cancelled and unpaid orders in the velocity calculation. | | **Currency** | Single currency per Ecwid store; ad spend is shown in the store currency for comparison. The headline pairs revenue / velocity with spend. | | **Time window** | `30D` (rolling 30-day velocity and spend window). | | **Alert trigger** | `top sellers receiving <10% of ad spend`. | | **Sentiment** | Inverse gauge on the under-investment gap. Sensitive card; top sellers starved of spend is the headline. | | **Roles** | owner, marketing, finance. | ## Calculation Calculated automatically from your Ecwid data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example **A UK hobby seller of handmade leather goods running an Ecwid widget on a WordPress site, with a connected ad platform. Rolling 30D ending 09 May 26.** The seller runs a modest ad budget and has been splitting it across the whole range. The card ranks SKUs by sales velocity and lays ad spend alongside. | SKU | Product (masked) | Units sold (30D) | Velocity rank | Ad spend (30D) | Spend share | | ----------- | ------------------ | ---------------- | ------------- | -------------- | ----------- | | LTH-card-01 | "Slim card holder" | 142 | 1 | £18 | 6% | | LTH-key-04 | "Key fob" | 118 | 2 | £12 | 4% | | LTH-wal-02 | "Bifold wallet" | 64 | 3 | £150 | 50% | | LTH-blt-07 | "Belt, tan" | 9 | 11 | £90 | 30% | ```text theme={null} Total ad spend (30D) £300 Top-2 velocity SKUs spend share 10% (£30 of £300) Bottom-velocity belt spend share 30% (£90 of £300) Top sellers <10% of ad spend? At the threshold. Alert FIRES. ``` **What it means.** The two fastest movers, the card holder and key fob, together pull just 10% of the budget, while half the spend sits behind a mid-velocity wallet and nearly a third behind a belt that barely sells. The seller is funding the slow items and starving the proven winners. This is a textbook misallocation: the card holder is selling 142 units a month essentially on its own, and even a small spend increase behind it would likely return more than the £90 currently propping up a 9-unit belt. **The playbook.** 1. Shift budget toward velocity. Move spend off the low-velocity belt and onto the card holder and key fob; proven sellers convert ad clicks at a higher rate, so the same pounds work harder. 2. Watch stock before scaling spend. Pushing ads at a fast mover only works if it stays in stock; check [Low-Stock Products](/nerve-centre/kpi-cards/ecwid/low-stock-products) and [Stock-Out Burst (>5 SKUs in \<1h)](/nerve-centre/kpi-cards/ecwid/stock-out-burst-5-skus-in-1h) before increasing spend, or you will pay to advertise a sold-out SKU. 3. Decide the belt's fate. A slow seller with heavy spend is a candidate to cut, discount to clear, or test with new creative, but not to keep funding at 30% of the budget. 4. Re-check after a fortnight. Velocity and spend both move; the goal is for the spend-share ranking to start matching the velocity ranking. The card exists because sales live in Ecwid and spend lives in the ad platform, and the mismatch between them is invisible unless you put the two side by side. The join does exactly that and flags where the budget is fighting the data. ## Sibling cards merchants should reference together | Card | Why it matters next to this card | What the combination tells you | | ------------------------------------------------------------------------------------------------------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | [Top Products by Revenue](/nerve-centre/kpi-cards/ecwid/top-products-by-revenue) | The value ranking. | Velocity ranks by units; revenue ranks by value. A cheap fast mover and a pricey slow mover deserve different spend. | | [Low-Stock Products](/nerve-centre/kpi-cards/ecwid/low-stock-products) | Don't advertise into a sell-out. | Confirms a top-velocity SKU has stock before you scale spend behind it. | | [Stock-Out Burst (>5 SKUs in \<1h)](/nerve-centre/kpi-cards/ecwid/stock-out-burst-5-skus-in-1h) | Spend protection. | If a backed SKU joins a burst, pause its ads until restock to stop wasting budget. | | [Average Order Value](/nerve-centre/kpi-cards/ecwid/average-order-value) | Return context. | A high-velocity but low-AOV SKU returns less per ad click than a high-AOV mover. | | [Total Revenue (30d)](/nerve-centre/kpi-cards/ecwid/total-revenue-30d) | Budget proportion. | Frames whether total ad spend is sensible against the revenue it supports. | | [Orders to Email Campaign Attribution](/nerve-centre/kpi-cards/ecwid/orders-email-campaign-attribution) | Channel mix. | Shows whether a winning SKU sells via email or paid, so you fund the right channel. | | [Conversion Rate](/nerve-centre/kpi-cards/ecwid/conversion-rate) | Efficiency of traffic. | High velocity with strong conversion means ad pounds behind it will convert well too. | ## Reconciling against Ecwid **Where to look:** > **Ecwid Control Panel (`my.ecwid.com`) -> Reports -> Sales by product (or Catalog -> Products sorted by units sold)** > This is the velocity half: units sold per SKU over the window, which sets the ranking the card uses. This is a cross-channel card, so the comparison also draws on your **ad platform connector**. The spend-per-product half lives in the ad platform's own reporting (for example Google Ads, Meta Ads Manager, or a shopping-campaign breakdown), not in Ecwid. To fully reconcile, confirm the units-sold ranking in the Ecwid Control Panel and the spend per product or campaign in the ad platform. The card reconciles against BOTH dashboards. **Why our number may differ from the two source dashboards:** | Reason | Direction | Why | | ------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Product-to-ad mapping** | Either | Ads often run at campaign or product-group level, not per SKU; we map spend down to the SKU as best the ad data allows, which can differ from a raw ad-platform line. | | **Velocity basis** | Either | We rank by units sold; an Ecwid revenue-by-product report ranks by value, so the orders differ for cheap-but-fast vs pricey-but-slow items. | | **Attribution window** | Boundary days | Spend and velocity both use a 30D UTC window; the ad platform may report in its own time zone or attribution window. | | **Cancelled / unpaid** | Theirs higher | We exclude cancelled and unpaid orders from velocity; some Ecwid views include them. | | **Sync lag** | Marginal | Recent spend or sales may not have synced from one side yet. | **Internal identity:** `ecwid_top_velocity_vs_ad_spend` pairs each top-velocity SKU's `units_sold_30d` with its matched `ad_spend_30d`, joined on product between Ecwid and the ad platform connector; the alert fires when top sellers receive under 10% of total spend. ## Known limitations / merchant FAQs **Does this work without an ad platform connector?** No. The spend half of the join comes from a connected ad platform. Without one, Vortex IQ knows what sells fast on Ecwid but not what you spend on each product, so there is nothing to compare. **Should I always pour money into my fastest sellers?** Usually, but check stock and margin first. Advertising a proven mover is generally efficient because it converts well, but only if it stays in stock and the margin justifies the spend. A fast seller with a thin margin may not reward more budget the way a fast, high-margin one does. **Why rank by units sold instead of revenue?** Because velocity, units per day, measures momentum and conversion appetite, which is what ad spend amplifies. A separate look at [Top Products by Revenue](/nerve-centre/kpi-cards/ecwid/top-products-by-revenue) tells the value story; the two together stop you over-funding a cheap fast mover or under-funding a pricey one. **My ads run at campaign level, not per product. Will this still work?** Yes, with some approximation. We map campaign or product-group spend down to the SKUs it covers as the ad data allows. The mapping is less precise than per-SKU ads, so treat the spend-share figures as indicative rather than exact when campaigns are broad. **The same SKU is a top seller and a top spender. Is that a problem?** No, that is the goal. The card flags the opposite case: top sellers getting little spend. A winner that is also well-funded is exactly where you want to be; leave it alone and look at the under-invested rows. **A low-velocity SKU has most of my spend. What do I do?** Decide why. If it is a deliberate push for a new or strategic line, that may be fine. If it is habit or a stale campaign, shift the budget toward the proven movers. The card is a prompt to make that call consciously. **How fast does a budget change show up here?** Both velocity and spend use a rolling 30D window, so a reallocation takes a couple of weeks to fully reflect. Check the trend after a fortnight rather than the day after you move money. **Could a stock-out distort the velocity ranking?** Yes. A SKU that sold fast then went out of stock mid-window will show lower units than its true demand. Read this card alongside the stock cards so you do not de-fund a winner that simply ran out. *** ### Tracked live in Vortex IQ Nerve Centre *Top-Velocity SKUs vs Ad Spend* is one of hundreds of KPI pulses Vortex IQ tracks across Ecwid and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.