Channel-Specific Order Drop, Ecwid

Channel-Specific Order Drop: detects when one storefront surface stops producing orders while others keep going. Flags surface-specific outages and sync breaks. How to read it, why it matters, and how to act on it.

Metrics type: Key Metrics • Category: Ecommerce Platform

If one storefront surface stops producing orders while others continue, it points to a surface-specific outage or sync break.

At a glance

Detects when a single storefront surface goes quiet while the rest of the store keeps taking orders. A total-revenue dip is easy to spot; a single-surface outage hides because the other surfaces mask it in the headline number. This card watches each surface’s order volume against its own recent baseline, so a Facebook Shop that has silently stopped converting, or an embed broken by a host-site change, is caught before a week’s revenue from that surface is lost.

What it counts	Per-surface order volume in the last 24H compared with each surface’s own prior-period baseline. The card reports any surface whose order volume has dropped sharply while sibling surfaces continue normally.
API endpoint	GET /v3/{store-id}/orders (paged, OAuth2 with read_orders scope), grouped by originating surface; order.created webhook feeds the live count. Surface list cross-checked against the store profile.
Baseline	Each surface is compared against its own recent typical volume, not the store total, so a small surface is judged on its own scale.
What triggers it	A surface whose 24H order volume falls more than 50% versus its prior-period baseline while at least one other surface is producing orders normally.
Cancelled / pending	Excluded from the count; only orders that reach PAID (or the surface’s normal completion state) are counted toward volume.
Currency	Not applicable. This is an order-volume signal, not a money value.
Time window	24H vsP (last 24 hours vs prior comparable period).
Alert trigger	Any channel with order-volume drop greater than 50% vsP while sibling surfaces continue.
Sentiment	Inverse gauge - a fired alert is bad. A surface going quiet relative to its peers is a problem, not a neutral observation.
Roles	owner, 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, 24H ending 21 Apr 26.

The maker’s WordPress host pushed a plugin update overnight that broke the page the Ecwid embed sits on. The embed surface went quiet while every other surface kept selling.

Surface	Orders (last 24H)	Baseline (typical 24H)	Change	Status
Embed (WordPress)	1	12	-92%	ALERT
Instant Site	4	4	0%	normal
Instagram Shopping	3	2	+50%	normal
Facebook Shop	1	1	0%	normal

Channel-Specific Order Drop FIRED
Surface: Embed (WordPress)
24H volume 1 vs baseline 12  (-92%)
Sibling surfaces normal -> store-specific, not market-wide

What it means for this maker. This is exactly the failure the card exists to catch. Total store orders fell only modestly (9 vs ~19), because the Instant Site, Instagram and Facebook kept selling. On the headline Total Revenue card the dip looks like a quiet day, well within normal weekly noise for a small store. It would not have alarmed anyone until the weekly review, by which point five days of embed revenue could be gone.

The discriminator is that sibling surfaces are normal. If every surface had dropped together, the cause would be market-wide (a bank holiday, a payment-processor outage, a weather event). Because only the embed fell while its peers held, the cause is specific to that surface. For an embed, the usual culprit is the host site: a WordPress or Wix update broke the page, the embed code was removed in a redesign, or a caching plugin is serving a stale page without the widget.

The action is fast and surface-scoped: open the host page in an incognito window and confirm the widget renders and the cart works. Here the maker found the embed missing after the plugin update, rolled the plugin back, and the embed surface recovered within the hour. The card turned a five-day silent leak into a one-hour fix.

Sibling cards merchants should reference together

Card	Why it matters next to Channel-Specific Order Drop	What the combination tells you
Active Storefront Surfaces	The surfaces being watched.	A surface that drops to zero AND falls off the active count = fully disconnected, not just quiet.
Revenue by Storefront Surface	The cost of the drop.	The dropped surface’s revenue share tells you how expensive the outage is per hour.
Total Orders	The masked aggregate.	Total orders look fine while one surface is down; this card is why the aggregate lies.
Ecwid API Failure Rate Spike	Shared-cause check.	A drop plus an API spike points to a platform/connector fault rather than a host-page break.
Inventory Sync Drift Across Storefronts	Adjacent surface fault.	A surface showing as out of stock due to sync drift will also stop producing orders.
Conversion Rate	Funnel vs traffic.	Drop with traffic still arriving = checkout broke; drop with no traffic = the surface is unreachable.
Orders by Status	Where stuck orders pile.	Orders entering but stalling (e.g. awaiting payment) on one surface mimics a drop.
Total Revenue	The bottom line at risk.	The drop is the early warning; revenue is what it protects.

Reconciling against Ecwid

Where to look in Ecwid’s own dashboard:

Ecwid Control Panel (my.ecwid.com) -> My Sales -> Orders, filter by date (last 24H) and segment by source/channel Compare today’s per-surface order count against a normal day. A surface sitting near zero while others are normal confirms the alert.

To check whether a surface is actually reachable, open it directly: load the host page carrying the embed, open the Instant Site URL, or open the Facebook/Instagram shop, and attempt to add to cart.

Why our number may differ from Ecwid’s Control Panel:

Reason	Direction	Why
Attribution of source	Either	A surface drop is only visible if Ecwid recorded the order source; unattributed orders sit in “other / direct” and can blur a single surface’s count.
Time zone	Boundary hours	We compare on a UTC 24H window; Ecwid uses the store’s configured time zone, which can shift which orders fall inside “today”.
Low-volume noise	False signal risk	A surface that normally does one or two orders a day can read as a large percentage drop on a quiet but normal day; the card weighs sibling activity to reduce this.
Pending payment	Either	An order placed but not yet PAID may not count toward completed volume yet, briefly mimicking a drop.
Sync lag	Marginal	Webhook-driven; the most recent few minutes may not be counted.

Internal identity:

drop_flag(surface) = (orders_24h(surface) / baseline_24h(surface)) < 0.5 AND any_sibling_normal = true

---

Known limitations / merchant FAQs

How is this different from just watching total revenue? Total revenue masks single-surface failures. If your embed dies but your Instant Site and social shops keep selling, total revenue dips only slightly and looks like a quiet day. This card watches each surface on its own, so a surface going silent is caught even when the headline number looks fine.

Why does it only fire when other surfaces are normal? Because that is the signal that the cause is surface-specific rather than store-wide. If every surface drops together, the cause is usually external (a bank holiday, a payment outage, bad weather) and a single-surface alert would be misleading. The “siblings normal” condition isolates the faults you can actually fix on one surface.

My smallest surface fired a drop alert on a normal slow day. Is that a false positive? Low-volume surfaces are inherently noisy: going from two orders to zero is a 100% drop that may just be a quiet day. The card weighs sibling activity to suppress this, but for very small surfaces you may still see the occasional benign alert. Treat a single quiet day with caution; a multi-hour zero with healthy siblings is real.

The embed dropped. What do I check first? Open the host page that carries the embed in a fresh incognito window. Confirm the widget renders and you can add to cart and reach checkout. The usual culprits are a host CMS update (WordPress/Wix/Webflow) that broke or removed the embed, a caching plugin serving a stale page, or the embed code being dropped in a redesign.

A social surface dropped. What is the usual cause? A lapsed connection. Facebook and Instagram tokens expire and the catalogue sync can silently stop. Check the channel status in the Control Panel under Sell Anywhere and reconnect if the token has expired.

Could a sync break cause this rather than an outage? Yes. If a surface stops syncing the catalogue or shows everything as out of stock, customers cannot buy and the surface goes quiet. Cross-check Inventory Sync Drift Across Storefronts and Ecwid API Failure Rate Spike; a drop alongside an API spike points to a connector or platform fault.

Does a deliberate pause (e.g. turning a surface off) fire this? If you intentionally disable a surface it should fall off Active Storefront Surfaces, which gives context. A surface that is still enabled but suddenly producing nothing is the case this card is designed to flag.

How fast does it react? It works on a rolling 24H comparison fed by order webhooks, so a surface going quiet surfaces within the polling cycle, far faster than a weekly revenue review would catch it.

Why are engineering and operations on the roles list, not just the owner? Because the fixes are operational or technical: reconnecting a channel, rolling back a host-site change, or chasing a sync fault. The owner needs to know revenue is at risk; operations and engineering are the ones who restore the surface.

---

Tracked live in Vortex IQ Nerve Centre

Channel-Specific Order Drop 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.