Skip to main content
Card class: Hero • Category: Ecommerce Platform
The same SKU showing different stock counts across embed vs Instant Site vs Facebook shop indicates a sync logic gap and risks overselling.

​
At a glance

Counts SKUs whose stock level disagrees across the store’s surfaces - the embed widget saying five in stock while the Facebook Shop still shows twelve, for example. Ecwid’s promise is one catalogue, one stock pool, across every surface. When a surface caches or lags behind the master stock count, customers on that surface can buy items that are already gone, and the merchant ends up cancelling orders and apologising. This card surfaces the drift before the oversell.
What it countsThe number of SKUs whose available-stock value diverges between two or more enabled surfaces at the moment of the snapshot.
API endpointMaster stock read from GET /v3/{store-id}/products (OAuth2 with read_catalog scope); per-surface stock derived from each surface’s catalogue feed / channel state and compared against the master.
What counts as driftAny SKU where the available quantity reported by one active surface differs from the master catalogue value (or from another surface) beyond a small reconciliation tolerance.
Tracked products onlySKUs with inventory tracking enabled. Products set to unlimited / untracked stock cannot drift and are out of scope here - see Products on Unlimited Stock (No Tracking).
Disabled surfacesIgnored. Only surfaces that are currently active and order-capable are compared.
CurrencyNot applicable. This is a SKU count, not a money value.
Time windowRT (real-time snapshot of current per-surface stock).
Alert triggerGreater than 0 SKUs with divergent stock across surfaces. Any drift is worth knowing about because each drifting SKU is a potential oversell.
SentimentInverse gauge - any non-zero value is bad. Drift is never desirable.
Rolesowner, operations, engineering.

​
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 small UK candle and home-fragrance maker running Ecwid across four surfaces, snapshot taken 21 Apr 26. A best-selling scent sold down fast over a weekend. The embed and Instant Site updated promptly, but the Facebook Shop catalogue feed lagged and kept advertising stock that was already gone.
SKUEmbedInstant SiteFacebookMasterDrift?
Sea Salt 220ml33113YES (Facebook +8)
Amber Noir 220ml7777no
Fig & Vetiver 220ml0020YES (Facebook +2)
Wild Mint refill15151515no
Inventory Sync Drift Across Storefronts = 2 SKUs
Both drifts are on the Facebook surface (feed lag)
Fig & Vetiver: master 0 but Facebook shows 2 -> active oversell risk
What it means for this maker. Two SKUs are drifting, and both are on Facebook, which points to a single cause rather than a random fault: the Facebook catalogue feed is lagging behind the master stock. The dangerous line is Fig & Vetiver. The master shows zero, but Facebook still lists two available. The next customer who buys it on Facebook will place an order the maker cannot fulfil, leading to a cancellation, a refund, and a disappointed first-time buyer - the most expensive kind of oversell. The reason the drift concentrates on one surface matters. Embed and Instant Site are Ecwid-native and update against the master almost immediately; social and marketplace surfaces depend on periodic feed pushes that can lag, especially after a fast weekend sell-down. So the practical reading is “trust the native surfaces, treat the feed-based surfaces as eventually consistent, and watch this card after any rapid sell-through”. The action: force a catalogue resync to the Facebook channel from the Control Panel, then confirm Fig & Vetiver drops to zero on Facebook. For a recurring lag, shorten the feed refresh or, for very fast-moving heroes, consider a small safety buffer so the feed lag cannot push the surface into negative real stock. Pair this card with Out-of-Stock Products so a master-zero SKU is never still live on any surface.

​
Sibling cards merchants should reference together

CardWhy it matters next to Inventory Sync DriftWhat the combination tells you
Out-of-Stock ProductsThe master truth.A master-zero SKU still showing stock on a surface is an active oversell, the worst drift case.
Low-Stock ProductsDrift risk leading indicator.Low-stock fast movers are where drift turns into oversell; watch these surfaces closely.
Stock-Out Burst (5+ SKUs in 1h)The trigger event.A burst of sell-outs is exactly when feed-based surfaces lag and drift appears.
Active Storefront SurfacesThe surfaces being compared.More active surfaces = more pairs that can drift; risk scales with surface count.
Channel-Specific Order DropAdjacent surface fault.A surface stuck on stale stock may also stop selling correctly; the two faults often co-occur.
Products on Unlimited Stock (No Tracking)Out-of-scope set.Untracked SKUs cannot drift; if a “missing” SKU is untracked, that explains its absence here.
Ecwid API Failure Rate SpikeShared-cause check.Drift plus an API spike points to a sync pipeline fault rather than a slow feed.
Revenue at RiskThe money exposure.Drift on high-value heroes converts directly into at-risk revenue from cancellations.

​
Reconciling against Ecwid

Where to look in Ecwid’s own dashboard:
Ecwid Control Panel (my.ecwid.com) -> Catalog -> Products -> open the drifting SKU and read its master stock figure Then open the same SKU on each live surface: the embed on your host page, the Instant Site URL, and the Facebook/Instagram shop. Compare the availability each surface shows against the master figure.
For the social surfaces specifically, check the channel sync status under Sell Anywhere (Channels); a feed that last synced hours ago is the usual source of drift. Why our number may differ from Ecwid’s Control Panel:
ReasonDirectionWhy
Feed-based surfaces are eventually consistentExpectedSocial and marketplace surfaces update on a feed schedule, so a transient gap right after a sale is normal and may clear before you can confirm it manually.
Reconciliation toleranceOurs sometimes lowerA drift inside the small reconciliation tolerance is not counted; Ecwid will still show the raw per-surface numbers.
Untracked productsOurs lowerSKUs with no inventory tracking are excluded here but appear with stock in Ecwid’s catalogue view.
Snapshot timingEitherThis is a real-time snapshot; a force-resync between our snapshot and your manual check can make the drift appear or vanish.
Disabled surfacesOurs lowerWe only compare currently active surfaces; Ecwid may still display stock on a configured-but-off surface.
Internal identity: ecwid_inventory_sync_drift = COUNT(DISTINCT sku WHERE stock_on_any_active_surface != master_stock beyond tolerance)

​
Known limitations / merchant FAQs

Why would the same SKU show different stock on different surfaces at all? Ecwid’s native surfaces (embed, Instant Site) update against the master stock pool almost immediately. Feed-based surfaces (Facebook, Instagram, marketplaces) update on a sync schedule, so for a short window after a sale they can advertise stock that is already gone. This card flags that window so you can close it before it causes an oversell. Which direction of drift is dangerous? A surface showing more stock than the master is the dangerous one - it can take orders you cannot fulfil. A surface showing less than the master is conservative: you lose a possible sale but never oversell. The card counts both, but the master-higher-than-surface case is benign while the surface-higher-than-master case is the oversell risk. A drift appeared and then cleared on its own. Was it real? Probably a normal feed-lag window that resolved on the next sync. Transient drift right after a sale is expected on feed-based surfaces. Persistent drift, or drift that keeps the surface above the master after a force-resync, is the kind that causes oversells. How do I fix a drift right now? Force a catalogue resync to the affected surface from the Control Panel under Sell Anywhere, then re-check the SKU on that surface. If it keeps recurring on the same surface, shorten the feed refresh interval, and for very fast movers consider a small safety buffer so feed lag cannot push the surface into negative real stock. Do untracked products show up here? No. A product set to unlimited / untracked stock has no quantity to compare, so it cannot drift and is excluded. If a SKU you expected is missing from this card, check whether it is untracked via Products on Unlimited Stock (No Tracking). Why is the alert at greater than zero rather than a percentage? Because each drifting SKU is an independent oversell risk, and a single oversell on a first-time buyer is costly out of proportion to its size. There is no “acceptable” amount of drift, so the threshold is simply any. Does this catch the case where a SKU is sold out on the master but still live on a surface? Yes, and that is the most important case it catches. A master value of zero with any active surface still showing stock is an active oversell waiting to happen. Pair this card with Out-of-Stock Products for the full picture. My drift count spiked right after a busy weekend. Is that normal? It is common. Fast sell-through is exactly when feed-based surfaces fall behind. Expect a brief rise during and just after a busy period, and confirm it clears on the next sync. A burst of sell-outs is the trigger - see Stock-Out Burst (5+ SKUs in 1h). Why are engineering and operations on the roles, not just the owner? Because resolving drift is operational (force a resync, adjust a feed schedule) or technical (fix a sync pipeline fault). The owner needs to know an oversell is possible; operations and engineering close the gap.

​
Tracked live in Vortex IQ Nerve Centre

Inventory Sync Drift Across Storefronts 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 or book a demo to see this metric running on your own data.