Skip to main content
Metrics type: Key MetricsCategory: Ecommerce Platform
Real-time per-channel revenue regression, the canary that catches a broken POS / disconnected social storefront before the merchant notices.

At a glance

Per-channel revenue regression alert. Catches a broken POS terminal, a disconnected social storefront, a paused marketplace listing, or a rogue Channel Manager sync, before the merchant notices the channel has gone quiet. Where BC Alert Revenue Drop watches the store-wide pulse, this card watches each channel individually so concentrated drops aren’t masked by healthy traffic elsewhere.

Calculation

Calculated automatically from your BigCommerce 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 US homewares brand on BigCommerce Enterprise. Comparison week is 6 Apr 26 to 12 Apr 26 vs prior week 30 Mar 26 to 5 Apr 26. What’s interesting:
  1. Two alerts fire simultaneously, different root causes. The Facebook Shop -89% is almost always a Meta-side issue (policy flag, account suspension, Facebook Pay outage); the POS Terminal B -100% is almost always a hardware issue (network outage, terminal offline, app crash). Same alert, completely different diagnostics.
  2. The store-wide alert wouldn’t fire on either. Total store revenue: 101,140priorweekvs101,140 prior week vs 95,700 this week, a 5.4% drop, well below the 25% threshold. Per-channel is essential for catching concentrated drops.
  3. Facebook diagnosis sequence: (a) log into Facebook Business Manager, check for policy notifications. (b) try to view your Facebook Shop product page; does it load? (c) check Meta Status (status.fb.com). (d) try to place a test order. Most Facebook Shop drops resolve with a policy-acknowledgement click in Business Manager.
  4. POS Terminal B diagnosis sequence: (a) physical walk-around, is the terminal powered on, network connected, the BC POS app running? (b) call the store, has staff noticed the issue? (c) check BC POS Settings → Devices, does the terminal show as online? (d) reboot. Most POS-zero drops resolve with a power cycle.
  5. The 14-day exclusion saves false positives. A new Channel Manager integration in week 1 with $0 in week 0 would otherwise look like an alert; the 14-day minimum suppresses ramp-up noise.
The rapid-response playbook (when this alert fires):
  1. Identify the affected channel from the alert payload.
  2. Run channel-specific diagnostics (different per channel, see above).
  3. Verify the integration is configured correctly (Channel Manager → Connected channels, or POS → Devices).
  4. Check the marketplace’s status page (Amazon, Meta, eBay all publish status feeds).
  5. Notify the team with the channel name and observed drop percentage in the message.

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Where to look in BigCommerce Control Panel: Channel Manager → Health indicators show whether each integration is connected; Activity log shows recent sync events. Analytics → Sales on Plus / Enterprise has a Sales by channel per-day view that lets you spot week-over-week drops manually. For POS specifically: BC POS Settings → Devices shows online / offline status per terminal. Why our alert may fire on legitimately-quiet weeks: Cross-connector reconciliation (when marketplace integrations are connected): The per-channel real-time alert shape is BC-aligned with similar alerts on Shopify (per-sourceName) and Adobe Commerce (per-store_id); per-channel granularity is broadly equivalent.

Known limitations / merchant FAQs

The alert fired on a tiny channel (200200 → 50 = -75% drop), is that worth investigating? Yes, briefly. A channel with that little baseline can move 75% on a single missed order, but the alert’s job is to surface the signal; your job is to triage. Quickly check the channel’s health (is the integration connected, is the listing live), if everything looks fine and the drop is just sample noise, dismiss the alert. The triage takes 90 seconds; ignoring small-channel alerts means missing real failures on small channels. Why 25% threshold and not 50%? A 50% threshold misses many real channel failures (a marketplace listing throttled to 30% of normal traffic shouldn’t go undetected). 25% is the sweet spot, large enough to filter noise on stable channels, small enough to catch genuine throttling. Multi-channel stores with strong week-over-week seasonality may want to raise to 35% to reduce false positives. The alert fires every Monday on POS, why? Probably weekend rotations on POS. If your weekend was the comparison “prior week” and your Monday is the comparison “current week”, a high-weekend-low-Monday pattern looks like a drop. Configure POS-specific alert windows to use 14-day moving averages instead of week-over-week; the alert engine supports this. My Amazon channel just got suspended, how fast does this card fire? Within 24 hours of the rolling 7-day window dropping below the 75% threshold. For an Amazon suspension that takes effect overnight, the card typically fires around hour 36-48 after the suspension started. For faster catch use the Vortex Mind real-time channel-health monitor (separate from this card), which polls Channel Manager status directly every 5 minutes. Should I create a separate Slack channel for these alerts? For multi-channel stores, yes. The alert volume is low (most stores see 0-3 fires per month) but each fire is high-priority and channel-specific. Routing them to a dedicated #channel-alerts channel keeps the noise out of general operations channels and ensures the right humans see them. Why does the alert exclude new channels for 14 days? Because brand-new channels have inherently noisy week-over-week numbers as they ramp up; without the suppression every new channel would generate 2-3 false alerts in its first month. The 14-day suppression matches the typical marketplace approval / activation cycle. If you have a high-volume channel that’s about to go live, configure the alert manually for that channel after day 7. My multi-currency store has Amazon UK and Amazon US as separate channels, do they alert independently? Yes. Each channel_id is evaluated independently. If Amazon UK drops 30% but Amazon US is healthy, only the UK alert fires. Configure routing so UK alerts go to the UK team and US alerts go to the US team. Can I mute alerts during a planned channel pause? Yes. Configure a scheduled silence window in Settings → Alerts. For example, “silence Facebook Shop alerts from 14 Mar to 21 Mar 26” while you migrate listings. Don’t blanket-silence outside known maintenance, the false-positive cost is much smaller than missing a genuine outage. The store-wide BC Alert Revenue Drop didn’t fire but this one did, are they conflicting? Not at all, this is exactly the case the per-channel alert exists for. A 60% drop on a 5%-of-revenue channel only moves the store-wide aggregate by 3%, well below the 25% store-wide threshold. The per-channel alert catches the concentrated signal; the store-wide alert catches the systemic signal. Both running together is the right pattern. My alert payload says “Facebook Shop” but BC Channel Manager calls it “Meta Shop”, which is right? Both. Meta rebranded “Facebook Shop” to “Meta Shop” in some BC versions. We use whatever display name BC has indexed; if the name changed mid-period, recent alerts show the new name and historical comparisons use the old. Cosmetic only; the underlying channel_id is unchanged.

Tracked live in Vortex IQ Nerve Centre

Channel Revenue Drop Alert is one of hundreds of KPI pulses Vortex IQ tracks across BigCommerce 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.