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.
| What it counts | Per-channel_id rolling 7-day SUM(total_inc_tax) compared against the prior 7-day window. Fires when any channel’s current week is ≤ 75% of the prior week. |
| VAT / tax treatment | Tax-inclusive. Both sides use total_inc_tax. |
| Shipping | Included. |
| Discounts | Already deducted. |
| Refunds | Not deducted (gross comparison). |
Incomplete / Declined orders | Included. The alert measures whether orders are being created at all per channel; a drop in Incomplete-creation also signals a broken channel. |
| Cancelled orders | Included. |
| Currency | Per-channel arithmetic comparison without FX, since most channels are currency-locked (Amazon UK = GBP) the comparison is internally consistent within a channel. |
| Channels covered | All channel_id values present in the index for the comparison weeks. New channels (less than 14 days of data) are excluded automatically to avoid false positives during ramp-up. |
| Why per-channel matters | A 5% drop on web (channel_id = 1) might be noise; a 60% drop on Amazon Channel Manager because the listing got suspended is a five-figure-per-week emergency that the store-wide alert won’t catch. Concentration drops hide inside store-wide aggregates. |
| Time window | 7D (rolling 7 days vs prior 7 days, evaluated daily) |
| Alert trigger | any channel drop >25% vs prior week |
| Sentiment key | revenue_trend |
| Roles | owner, finance, marketing |
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.channel_id | Channel | Prior week | This week | Delta | Verdict |
|---|---|---|---|---|---|
1 | Stencil web storefront | $82,400 | $79,180 | -3.9% | Within normal noise |
1019847 | Amazon Channel Manager | $13,520 | $14,180 | +4.9% | Healthy |
1019850 | Facebook Shop | $1,300 | $140 | -89.2% | ALERT FIRES |
1020114 | POS Terminal A | $2,280 | $2,200 | -3.5% | Within normal noise |
1020115 | POS Terminal B | $1,640 | $0 | -100% | ALERT FIRES |
- 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.
- The store-wide alert wouldn’t fire on either. Total store revenue: 95,700 this week, a 5.4% drop, well below the 25% threshold. Per-channel is essential for catching concentrated drops.
- 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.
- 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.
- 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.
- Identify the affected channel from the alert payload.
- Run channel-specific diagnostics (different per channel, see above).
- Verify the integration is configured correctly (Channel Manager → Connected channels, or POS → Devices).
- Check the marketplace’s status page (Amazon, Meta, eBay all publish status feeds).
- Notify the team with the channel name and observed drop percentage in the message.
Sibling cards merchants should reference together
| Card | Why pair it with Channel Revenue Drop Alert |
|---|---|
| BC Alert Revenue Drop | The store-wide version. Both alerts together cover both concentrated-channel and store-wide drops. |
| BC Channel Revenue Mix | The “what is normal” baseline this alert is the guardian of. |
| BC Channel Revenue Trend | The over-time view. After an alert fires, this shows whether the drop is acute or part of a longer trend. |
| BC Failures by Channel ID | If revenue dropped on a channel and failure count spiked, the channel is broken at the checkout layer (not the listing layer). |
| BC Channel OOS per Channel | If revenue dropped because top SKUs went out of stock on that channel. |
| BC Channel AOV | A channel with stable order count but falling AOV may not trigger this alert; pair to catch this case. |
| BC Alert Fulfilment Delay | Often co-fires when a marketplace integration has a sync issue. |
| Total Revenue | Context for prioritisation, a 50% drop on a 1%-of-revenue channel is less urgent than a 25% drop on a 30%-of-revenue channel. |
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:| Reason | Direction |
|---|---|
| Promotional cycles. A channel that ran a promotion last week and not this week shows a “drop” that’s pure mix shift, not a problem. | False positive |
| Holiday weeks. Bank Holidays, US public holidays in the comparison week distort week-over-week math. | False positive |
| Listing rotation. Merchants who rotate marketplace listings (cycle SKUs in / out for tax-treaty reasons) see channel revenue swings. | False positive |
| Platform outage. Marketplace genuinely down (Amazon, Meta have multi-hour outages). | True positive (but outside merchant control) |
| Listing suspension / policy flag. Merchant action required. | True positive |
| Integration credential expired. Merchant action required. | True positive |
| POS terminal offline. Hardware action required. | True positive |
| Card | Expected relationship | Notes |
|---|---|---|
amazon_sp.amazon_revenue_drop_alert | Should co-fire with the Amazon channel slice of this card | Amazon SP-API has its own outage signals; cross-checking pinpoints whether the issue is BC-Amazon-sync or Amazon-side. |
facebook.fb_shop_revenue_drop | Should co-fire with the Facebook Shop slice | Meta status page is authoritative for Facebook Shop outages. |
stripe.stripe_total_revenue | Web channel drops should reflect on Stripe if Stripe is the web processor | A drop visible here but not on Stripe means orders are being created (in BC) but failing payment (Stripe-side); investigate the gateway. |
sourceName) and Adobe Commerce (per-store_id); per-channel granularity is broadly equivalent.
Known limitations / merchant FAQs
The alert fired on a tiny channel (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. Eachchannel_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.