> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Dayparting Waste (low-CR hours), Amazon Ads > Spend that lands in hour-of-day buckets that historically convert below threshold. Pause or apply negative bid modifier. How to read it, why it matters, an... **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Ad Platform](/nerve-centre/connectors#connectors-by-type) > Spend that lands in hour-of-day buckets that historically convert below threshold. Pause or apply negative bid modifier. ## At a glance > Spend in **hour-of-day buckets where conversion rate is \< 1%**, typically the dead overnight hours when shoppers click but rarely buy. The dayparting-pruning workflow, identify low-CR hours and apply a negative bid modifier or pause the campaigns during those windows. Industry typical: 4-12% of total ad spend lands in low-CR hours. Recoverable with hour-of-day bid scheduling. | | | | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **The formula** | `SUM(cost)` for hours where the 30-day rolling conversion rate is \< 1%. The 1% threshold is a generous floor; many categories have 2-3% account-blended CR, so the dead-hour cohort is genuinely low-quality. | | **Reports API endpoint** | `POST /reporting/reports` with `reportTypeId=spCampaigns` aggregated by `hourOfDay`. Hour-of-day reports require Amazon Advertising's hourly granularity (available on Sponsored Products; partial on Sponsored Brands). | | **What "low-CR" means** | A specific hour bucket where (clicks > 0) AND (orders / clicks \< 1%). The hour-bucket is in **PT (Pacific)** regardless of merchant location, Amazon's reporting backend timezone. | | **ACOS vs ROAS framing** | A low-CR hour is mechanically going to be high-ACOS / low-ROAS for that window. The fix is bid-modifier or pause, not budget-cut. | | **Attribution model** | Last-click within Amazon ecosystem, 14-day click window. The hour bucket is the *click* hour; the conversion may land days later but is attributed to the click hour. | | **Brand vs non-brand keyword scope** | Branded clicks tend to convert at any hour (people searching the brand name buy quickly). The waste pattern is concentrated in non-branded, late-night browsers click but don't buy. | | **Sponsored Products vs Brands vs Display vs DSP** | SP exposes hour-of-day reliably. SB and SD have partial hour reporting. DSP uses different scheduling controls (day-parts in DSP service agreements). The card focuses on SP. | | **Currency** | Account currency only. | | **Amazon-only attribution gap** | Not specifically relevant, dayparting is about timing, not attribution path. | | **Time window** | `30D` rolling. Hour-of-day patterns are usually stable, so 30D smoothing avoids over-fitting on a single-week anomaly. | | **Alert trigger** | `>$0 spend in hours with <1% conv rate`. Drives `sentiment_key: zero_conversion_spend`. The threshold is configurable (some accounts use 0.5% or 2% depending on baseline CR). | | **Roles** | owner, marketing, finance | ## Calculation Calculated automatically from your Amazon Ads 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 home-goods seller, 30-day window covering 14 Mar 26 to 12 Apr 26. Account-blended CR is 4.8%. The card flags spend in 5 hour-buckets below the 1% CR threshold. | Hour (PT) | Clicks (30D) | Orders (30D) | CR | Spend | Status | | -------------------------- | ------------ | ------------ | --------- | --------- | ---------------------------------------------- | | **02:00-03:00** | 1,240 | 6 | 0.48% | \$185 | Below threshold, prune | | **03:00-04:00** | 980 | 4 | 0.41% | \$146 | Below threshold, prune | | **04:00-05:00** | 720 | 3 | 0.42% | \$108 | Below threshold, prune | | **05:00-06:00** | 650 | 4 | 0.62% | \$94 | Below threshold, prune | | **22:00-23:00** | 2,400 | 18 | 0.75% | \$358 | Below threshold (but high volume, investigate) | | **Total dayparting waste** | **5,990** | **35** | **0.58%** | **\$891** | 3.3% of total spend | | Comparison: peak hours (in-window) | | | | | | | ---------------------------------- | ----- | --- | ----- | ----- | --------------- | | **20:00-21:00** | 4,200 | 220 | 5.24% | \$640 | Healthy peak | | **12:00-13:00** | 3,800 | 195 | 5.13% | \$580 | Healthy peak | | **08:00-09:00** | 3,400 | 158 | 4.65% | \$510 | Healthy morning | What a paid-acquisition lead does with this: 1. **The $891 in low-CR hours = 3.3% of total spend, recoverable.** Apply a -50% bid modifier on the 02:00-06:00 window across affected campaigns; for the 22:00-23:00 hour, drop to -25% (the volume is high so a full pause loses too much absolute conversion). **Estimated 30-day recovery: ~$520-650** (you lose some legitimate orders by reducing bids, so recovery is partial). 2. **The 22:00-23:00 hour is a special case.** CR is 0.75% (below threshold) but click volume is 2,400, high enough that even at 0.75% CR, this hour contributes 18 orders. Pausing entirely loses real conversions. The bid-modifier (-25%) preserves some volume while reducing waste. 3. **The peak-hour comparison shows what "good" looks like.** 20:00-21:00 PT (US prime evening shopping) converts at 5.24%. 10× the dead-hour rate. **The fix isn't to spend less, it's to redistribute spend toward the high-CR hours.** 4. **Dayparting waste rises during Prime Day.** Bargain hunters click everywhere at all hours; expect 02:00-06:00 spend to inflate 50-100% during sale weeks. Don't react in-window; review the next month after the promo cools. 5. **B2B-adjacent products show different patterns.** Office furniture, professional supplies, and similar B2B-leaning categories peak at 09:00-17:00 PT and have low-CR overnight; consumer goods peak at 20:00-22:00 PT. **Configure thresholds per category**; the default 1% CR floor may be too high for niche or seasonal products. Quick sanity tests: * Total dayparting waste 5-15% of spend = healthy. Recoverable with bid modifiers. * Total \< 3%: probably already optimised, or low-volume account where every hour matters. * Total > 15%: structural over-bidding in dead hours; auto-campaigns are spending where they shouldn't. * Pattern shifting suddenly (waste rising sharply): seasonality (e.g. tax-prep traffic at unusual hours) or competitor entered the auction during low-volume periods. * Same hours flagged month after month: candidate for permanent dayparting schedule. ## Sibling cards merchants should reference together | Card | Why pair it with Dayparting Waste | | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | [Spend by Hour](/nerve-centre/kpi-cards/amazon-ads/spend-by-hour) | The full hour-by-hour spend breakdown. | | [Conversion Rate by Hour](/nerve-centre/kpi-cards/amazon-ads/conversion-rate-by-hour) | The CR side of the same data. | | [ROAS by Hour](/nerve-centre/kpi-cards/amazon-ads/roas-by-hour) | The efficiency lens. Low-CR hours are also low-ROAS hours. | | [Day-of-Week Spend Mix](/nerve-centre/kpi-cards/amazon-ads/day-of-week-spend-mix) | The day-of-week analogue of this card. | | [Bid-Modifier Coverage](/nerve-centre/kpi-cards/amazon-ads/bid-modifier-coverage) | Tracks whether the dayparting fixes have been applied. | | [Wasted Spend](/nerve-centre/kpi-cards/amazon-ads/wasted-spend) | Keyword-level waste; this card is hour-level waste. | | [Zero-Conversion Spend](/nerve-centre/kpi-cards/amazon-ads/zero-conversion-spend) | Campaign-level waste. The three (keyword, campaign, hour) are independent slicings. | | [CPC by Hour](/nerve-centre/kpi-cards/amazon-ads/cpc-by-hour) | If low-CR hours also have high CPC, the waste is double. | ## Reconciling against the vendor's own dashboard **Where to look in Amazon Ads Console:** [Amazon Ads Console > Reports > Sponsored Products > Performance Over Time](https://advertising.amazon.com/reports), choose hour-of-day granularity. The total in low-CR hour buckets should match this card to within \~1%. [Amazon Ads Console > Campaign Manager > \[Campaign\] > Bidding](https://advertising.amazon.com/cm) shows day-part bid adjustments where set. **Amazon's native dayparting controls are limited compared to Google Ads**, they're per-campaign and have only 24 hour-buckets per day-of-week. [Amazon Ads Console > Recommendations](https://advertising.amazon.com/recommendations), sometimes flags "hours with low conversion" but inconsistently. **Why our number may legitimately differ from Amazon Ads Console:** | Reason | Direction of divergence | Why it happens | | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Timezone**. All Amazon Advertising reports use **PT (Pacific)**. Vortex IQ aligns to PT for Amazon Ads. | None when both PT-aligned. | Amazon's reporting backend is in Seattle. **Critical for dayparting**: a US-East merchant must remember 02:00-05:00 PT = 05:00-08:00 ET (early morning ET, dead-hour PT). | | **Hour-bucket granularity**. Amazon's hourly reports have \~99% completeness on Sponsored Products; rare hours may be missing in low-volume sub-accounts. | This card may show slightly less spend in those hours. | Hourly granularity is best-effort on Amazon. | | **Report-generation latency** (1-3 hours). | Today's hour-buckets are provisional for \~24h. | Amazon batches report builds. | | **Threshold definition**. This card uses CR \< 1% as the cutoff; the Console doesn't have an equivalent canned filter. | Manual recreation in Console requires custom filters. | Intentional design. | | **API rate limits**. Hour-of-day reports are heavier than daily reports; large accounts may have slower refresh. | Stale by up to 1 refresh cycle (\~4h). | Reports are paginated and rate-limited. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes legitimate divergence | | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | | [`amazon_sp.amzn_sp_total_sales`](/nerve-centre/amazon_sp/amzn_sp_total_sales) | Marketplace orders correlate with PT-hour conversion patterns. The peak hours in this card should match the peak hours in SP Total Sales by Hour. | None expected. | | [`google_ads.gads_dayparting_waste`](/nerve-centre/google_ads/gads_dayparting_waste) | Cross-platform analogue. Patterns may differ. Google Ads sees full-web traffic; Amazon Ads sees marketplace shoppers (often more concentrated in evening hours). | Different audiences, different patterns. | | [`shopify.total_revenue`](/nerve-centre/kpi-cards/shopify/total-revenue) | DTC site has its own dayparting pattern. The merchant's Shopify peak hours may be 1-2 hours earlier than Amazon's (DTC shoppers often browse before bed; Amazon shoppers commit during peak evening). | Independent traffic sources. |
Edge cases and rare reconciliation issues * **Daylight Saving Time**: PT shifts between PST and PDT in March/November. Amazon's reporting backend handles the shift; this card aligns automatically. * **Multi-marketplace**: each Amazon Advertising account is in its own marketplace timezone, but all REPORTING is in PT. A UK seller's "midnight rush" hour in BST is 16:00-17:00 PT, confusing but consistent. * **Hourly reporting on SB / SD**: partial. SP has full hourly reporting; SB and SD report daily by default and require explicit hour-bucket requests. The card focuses on SP. * **DSP**: not in this card. DSP's dayparting controls live in DSP service agreements, separate from this view. * **Threshold tuning**: 1% CR is the default; configure per-account to match category baseline. High-AOV categories (jewellery, mattresses) often have \<1% CR account-wide and need a lower threshold (0.3-0.5%). * **Volume floor**: an hour-bucket with \<50 clicks in 30 days is excluded from this card to avoid noise (small-sample CR estimates are unreliable).
## Known limitations / merchant FAQs **Why is dayparting waste so high in 02:00-05:00 PT?** Multiple causes: (a) **Insomnia browsing**, people click out of curiosity but don't commit. (b) **Bot / scraper activity**. Amazon's invalid-click filter catches some but not all. (c) **International browsing**, non-US shoppers in different timezones who see the US listing but can't buy from it. (d) **Wishlist-add behaviour**, overnight clicks build wishlists; conversions happen in next-day prime hours but attribute back to the click hour. **Should I pause overnight or just lower bids?** Bid modifier is the better tool. **Pausing entirely** loses the small but real overnight conversion volume; **lowering bids by 50-75%** preserves some impressions while reducing waste. Industry norm: -50% bid modifier on hours with \<1% CR. **Why is this card per-hour-of-day rather than per-hour-by-day-of-week?** Hour-of-day is the dominant pattern; day-of-week × hour-of-day creates 168 buckets per campaign which is noisy at typical Amazon spend levels. The card aggregates across days. For day-of-week patterns, use [Day-of-Week Spend Mix](/nerve-centre/kpi-cards/amazon-ads/day-of-week-spend-mix). **My category has high overnight CR (e.g. mattresses), should I lower the threshold?** Yes. The default 1% CR is calibrated to mid-volume consumer goods. **High-AOV / high-consideration categories** (mattresses, furniture, jewellery) often have account-blended CR of 0.5-1%, so the 1% floor catches everything. Lower to 0.3-0.5% per-category. **Low-AOV / impulse categories** (snacks, accessories) might use 2-3% as the threshold. **Why doesn't Amazon do this dayparting automatically?** Amazon's bidding system optimises for predicted-conversion-rate per click, which incorporates hour-of-day implicitly. **In theory** dayparting should be redundant. **In practice** Amazon's bid model has a generous floor and tends to over-bid in dead hours. Manual dayparting is still standard practice. **Multi-marketplace, do I have to do this per marketplace?** Yes. Each marketplace has its own peak hours (UK, DE, US, JP all differ). Each Amazon Advertising account is one marketplace, one timezone, one card. **Does daylight saving time affect this card?** Yes, but only in transition weeks. PST and PDT differ by 1 hour; the 30-day rolling window straddles the transition once a year. The card auto-aligns; expect a one-week dip in stability around the time changes. **My hour patterns shifted suddenly (e.g. last month's dead hours are now alive), what changed?** Three plausible causes: (a) **A new product launch** drove different shopper demographics. (b) **Seasonality**, back-to-school / Black Friday windows shift shopping behaviour. (c) **A creative refresh** attracted a different audience with different shopping hours. Re-baseline the dayparting model and reapply. **Can I trust today's hour-of-day data?** Less than the 30D rolling. The 14-day attribution window means today's hourly conversions continue to settle for two weeks. Use 30D rolling for actionable decisions; today is informational only. *** ### Tracked live in Vortex IQ Nerve Centre *Dayparting Waste (low-CR hours)* is one of hundreds of KPI pulses Vortex IQ tracks across Amazon Ads 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.