At a glance
Total revenue split by hour of the day (00-23) over the rolling period. The card the ad-scheduling, customer-service-staffing, and email-send-time teams live in, knowing your peak ordering hours lets you concentrate ad spend, staff support, and time email sends to match.
| What it counts | SUM(total_inc_tax) GROUP BY HOUR(date_created) over the period, summed across all 30 days then averaged or totalled per hour-of-day. Default view shows the average revenue per hour-of-day across the period. |
| VAT / tax treatment | Tax-inclusive (total_inc_tax). |
| Shipping | Included. |
| Discounts | Already deducted. |
| Refunds | Not deducted (gross). |
| Cancelled / voided orders | Included. |
| Currency | Multi-currency without FX. Filter by currency for clean per-currency hour patterns. |
| Channels / sources | All channels contribute by default. POS and marketplace-channel hours look very different from web hours; consider filtering to channel_id = 1 for a pure web-storefront pattern. |
| Time-zone treatment | Hour-of-day is computed in UTC by default. For local-time analysis use the time-zone toggle (Vortex Mind setting); the local-time view is more actionable for ad scheduling. UK store on UTC and BST handle automatically; US stores need explicit timezone configuration. |
| DST gotcha | Daylight Saving transitions shift the same wall-clock hour by 1 UTC hour twice yearly. The first 1-2 weeks after a DST flip show a smeared hour pattern; settle to clean once the rolling window flushes the pre-DST data. |
| B2B Edition note | B2B portal orders peak in business hours (9-17 local); retail orders peak evenings (18-22) and lunch (12-14). Mixing them produces a flatter pattern than is actionable; filter to one channel type at a time. |
| Time window | 30D (rolling 30 days, hour-of-day pattern smoothed across 30 days) |
| Alert trigger | None on this card directly. Pair with BC Alert Revenue Drop for hour-by-hour comparison. |
| Roles | owner, 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 UK fashion brand on BigCommerce Pro, web only, 30-day window 14 Apr 26 to 14 May 26, local time (BST).| Hour (local BST) | Avg revenue/hour | Order count avg | Pattern |
|---|---|---|---|
| 00-06 | £180/hr | 3 | Quiet overnight, mostly insomniacs and US-overlap |
| 07-08 | £620/hr | 11 | Commute browsing |
| 09-11 | £980/hr | 17 | Morning at desk, “remember to order” |
| 12-13 | £1,840/hr | 32 | Lunch peak #1, 1.6× day average |
| 14-16 | £1,420/hr | 25 | Sustained afternoon |
| 17-18 | £980/hr | 17 | Commute home |
| 19-21 | £2,640/hr | 47 | Evening peak #2, 2.3× day average |
| 22-23 | £1,420/hr | 25 | Late evening tail |
| Day average | £1,140/hr | 20 |
- Two clear peaks: lunch (12-13) and evening (19-21). This is the textbook pattern for B2C UK fashion. Evening is bigger (2.3× day average) than lunch (1.6×) because shoppers have time to browse and AOV is higher when not rushed. The single biggest hour is 20:00-21:00 BST, that’s where ad spend should index.
- The 19-21 evening peak is 4.4× the overnight 00-06 hours. If your ad scheduling is flat across 24 hours, you’re wasting overnight budget and underspending in the peak. Configure dayparting on Google Ads / Meta to weight 18:00-23:00 BST 2-3× the day average.
- Lunch peak (12-13) is mobile-skewed. Customers on phones during lunch break. Mobile UX matters more here than during evening (which skews tablet / desktop on the couch). Cross-reference BC Revenue by Device filtered to lunch hour.
- Customer service staffing implication. 2.3× volume in the evening means refund / question / chat queue spikes. Most BC merchants under-staff evening support; a single chat agent online 19-22 BST handles the bulk of issue resolution that would otherwise overflow to next-day email.
- Email send time. The standard “send at 9 AM” recommendation is suboptimal for BC fashion stores. Sending at 18:30 BST aligns with the rising evening peak; the email arrives just as shoppers settle in, AOV typically 15-20% higher than 9 AM sends.
- Configure ad-spend dayparting this week, weight 19-21 BST 2-3× the day average on Google Ads, Meta, TikTok.
- Move email sends to 18:30 BST for promotional campaigns, A/B test for 4 weeks against 9 AM.
- Staff customer-service chat 19-22 BST with at least one live agent.
- Mobile UX audit for lunch-peak hour specifically, optimise for one-handed phone shopping in 5-minute windows.
- Quarterly: review hour pattern for shifts, COVID-era patterns shifted toward evening; some brands now see 20:00-22:00 dominate even more strongly.
Sibling cards merchants should reference together
| Card | Why pair it with Revenue by Hour |
|---|---|
| BC Weekend vs Weekday | Day-of-week × hour cross-tabs reveal the weekend afternoon pattern (very different from Tuesday lunch). |
| Revenue by Day of Week | The orthogonal time cut. Together with hour-of-day they paint the full temporal pattern. |
| BC Revenue by Device | Hour × device cross-tabs reveal lunch-mobile vs evening-desktop patterns. |
| Revenue Over Time | The trend view; this card is the within-day pattern. |
google_analytics.ga_sessions_by_hour | Sessions-by-hour from GA4; correlates with revenue-by-hour but conversion rate may shift by hour. |
google_ads.ga_dayparting_performance | Ad-spend efficiency by hour; pair with this card to set dayparting bid modifiers. |
| BC Channel Revenue Trend | Per-channel hour patterns (POS only opens 9-21 typically, marketplaces 24×7). |
klaviyo.kl_send_time_optimization | Email send-time optimisation; align sends with evening peak. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: BC’s native Analytics → Sales does not surface hour-of-day patterns directly; the closest is the daily time-series. To verify hour patterns manually, Orders → All orders lets you sort by date_created descending, then visually scan the timestamps. There is no native hour-of-day view in BC; this card is one of the highest-value adds the connector provides. Why our number may legitimately differ from BC raw orders:| Reason | Direction |
|---|---|
| Time-zone configuration. BC stores order timestamps in store time-zone; we offer UTC default plus a configurable local-time view. Misconfigured local-time setting shifts the entire hour pattern by N hours. | Configurable mismatches |
| DST transitions. The UK BST/GMT flip and US DST flips smear the same wall-clock hour across 2 UTC hours during the transition week. | Transition-week noise |
| Marketplace order timestamps. Channel Manager orders use the marketplace’s order-creation timestamp, which may differ from BC’s index timestamp by 30+ minutes. | Marketplace orders may shift bucket by 1 hour |
| Cancelled / amended orders. An order created at 19:00 then amended at 21:00 retains its 19:00 timestamp; this is the correct attribution but may surprise merchants who think of it as a 21:00 transaction. | None, this is correct |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
google_analytics.ga_sessions_by_hour | Sessions-by-hour pattern correlates strongly with revenue-by-hour, but conversion rate varies by hour. | Conversion rate is typically higher in evening; sessions and revenue patterns differ in shape. |
google_ads.ga_dayparting_performance | Ad spend efficiency by hour; should align with revenue peaks if ad scheduling matches demand. | Ad-spend peaks may be intentionally before demand peaks (build awareness in afternoon for evening conversion). |
Known limitations / merchant FAQs
My peak hour is 02:00 UTC, that doesn’t match my customers, why? Almost certainly a time-zone configuration issue. UTC 02:00 corresponds to 21:00 EST or 18:00 PST. If your customers are US-based, switch the card’s time-zone toggle to local. UK / EU stores see UTC and BST/CEST line up cleanly during BST/CEST, then shift by 1 hour during winter (GMT/CET). Why are weekend hour patterns missing here? This card averages across all 30 days; weekend / weekday patterns blend. Use BC Weekend vs Weekday for the day-of-week split, or filter this card to “weekdays only” / “weekends only” via the day-filter toggle. Weekend afternoons typically show a single broad peak (12-18) rather than the weekday lunch-and-evening twin peaks. Should I shift my email send time to peak hour? Yes for promotional emails. Send 30-60 minutes before peak so the email is in the inbox when the customer enters peak browsing mode. For UK fashion stores, send at 18:30 BST for the 19-21 evening peak. Don’t send at peak, by the time the customer sees the email the peak window is half over. My ad spend is spread evenly across 24 hours, what should I do? Configure dayparting bid modifiers in Google Ads / Meta. A reasonable starting point: 1.5× bid modifier for peak hours (typically 19-21 local), 1.2× for secondary peaks (12-13 lunch), 0.7× for off-peak (00-06), 1.0× baseline elsewhere. Run for 4 weeks, measure ROAS by daypart, refine. My B2B portal hour pattern looks completely different, why? B2B buyers order during business hours (9-17 local) on weekdays. B2C customers order evenings and weekends. Mixing them produces a flat unhelpful pattern. Filter to B2B channel for B2B-specific scheduling decisions; filter to web for retail. Why does my POS hour pattern peak at 14:00-15:00? That’s the typical retail-floor “midday browse” pattern, post-lunch shoppers in town centres or malls. POS doesn’t have an evening peak because retail stores typically close 18:00-19:00. POS hour patterns are bounded by store opening hours and won’t show late-evening tails. My Amazon channel order hours look smeared compared to my web pattern, why? Amazon Channel Manager pushes orders to BC in batches; the timestamp is the BC index time, not the original Amazon order time. The hour pattern is somewhat dampened. For accurate Amazon hour patterns use Amazon Seller Central’s order-time-of-day report; for unified web pattern, filter this card tochannel_id = 1.
Why is my “today” pattern jumpy compared to the 30-day average?
Single days have small samples per hour. A 100-order/day store has only 4-5 orders/hour on average; a single £400 order moves a single hour bucket by 30%+. The 30-day rolling view smooths this. Don’t make decisions on a single day’s hour pattern. Use the 30-day or 7-day view.
My peak hour shifted from 20:00 to 22:00 over the past quarter, what does that mean?
Customer behaviour drift, often correlated with industry-wide shifts (post-COVID later-evening shopping, streaming-service competition for the 20-22 window). Verify by re-running the 30-day window vs 90-day-prior. If the shift is persistent, update ad scheduling and email sends accordingly. If transient (a one-month anomaly) ignore.
Can I see hour pattern by source country?
Not directly in this card; combine BC AOV by Country (filtered to a country) with the timezone-shifted hour view. Country-specific patterns differ materially: US peak is typically 20-22 local time across all timezones, UK peak is 19-21 BST, Asian markets often show midday peaks tied to commuting and work-break norms.
Multi-currency store, do I see hour patterns per currency?
Apply a currency filter. The hour pattern often shifts by currency (USD orders peak in US local time = 02-04 UTC, GBP in UK time = 19-21 UTC). Without filtering, the patterns blend; filtered they reveal the structurally different shopping habits per region.