--- title: "How Much Traffic on Black Friday? Size Your Peak | Evaluat" description: "How much traffic will Black Friday bring? Find last year's busiest hour in GA4, the peak minutes inside it and your growth, then set a load test target." url: "https://www.evaluat.com/blog/sizing-black-friday-load-test" last_modified: "2026-10-03" --- [Blog](https://www.evaluat.com/blog) [Ecommerce Performance](https://www.evaluat.com/blog/category/ecommerce-performance) # How to estimate peak traffic from your analytics Across the 138 retailers Queue-it tracked, Black Friday 2025 drew 78% more visits than an average October Friday. Your load test needs your own number, and last November's analytics already hold it. Find the busiest hour, find the minutes inside it, scale for growth, and turn the result into virtual users and journeys. Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 3 October 2026 [Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 9Ecommerce and peak season ![A worked example of sizing a Black Friday load test from last year's analytics. The busiest hour averaged 600 people on the site at once. Multiplying by 2.4 for the peak minutes after the email send gives 1,440, adding 8% growth gives 1,555, and adding 20% headroom gives a load test target of 1,900 virtual users.](https://www.evaluat.com/blog/sizing-black-friday-load-test-cover.svg) Summary The traffic number your Black Friday load test needs is already in last year's analytics, and finding it takes six steps. First, check you can still see last November. Google Analytics 4 keeps detailed data for only two months by default, so Explorations may not reach it. Second, find the busiest hour of last year's peak by listing sessions by date and hour, and note the average session length. Third, look inside that hour. An email send or a sale opening packs people into the first few minutes, so use server or CDN logs to see how much busier the peak minutes were than the hour's average. Fourth, scale for this year by comparing your recent weeks with the same weeks last year, then add headroom. Fifth, separate people from bots, because analytics leaves known bots out while logs count everything. Sixth, turn the result into virtual users with the concurrent users formula, and split them across browsing, basket and checkout journeys in the proportions your own funnel shows. In the worked example, a store whose busiest hour carried 600 people on average ends up testing at 1,900 virtual users, because the peak minutes, growth and headroom all stack. Check the estimate against your order data before you trust it, and let the test find the real ceiling above it. Listen to this article · 1:33 [Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/sizing-black-friday-load-test.mp3) Key takeaways - Size a Black Friday test from your own busiest hour last year, not from national averages. - GA4 Explorations keep two months of data by default; set retention to 14 months today so next year is safe. - The minutes after an email send or sale opening can carry several times the hour's average, so measure them in your logs. - Scale by your own recent growth, then add headroom; market forecasts disagree too much to borrow. - Analytics excludes known bots and logs include them, so use analytics for people and logs for shape. - Split virtual users across browsing, basket and checkout journeys in your funnel's proportions. ## How much traffic does Black Friday bring? Across the 138 retailers that Queue-it tracked in 2025, [Black Friday drew 77.5 million web visits, 78% more than an average October Friday](https://queue-it.com/blog/2025-online-holiday-shopping-statistics/). That is the market answer to how much traffic Black Friday brings. Your store’s answer can be very different, and it is the only one a load test can use. Market figures show the scale but hide the shape. Shopify’s network peaked at [489 million requests per minute on its edge during Black Friday Cyber Monday 2025, and its busiest minute of sales came at 12:01 pm Eastern time](https://www.shopify.com/investors/press-releases/shopify-merchants-achieve-record-breaking-14-6-billion-in-black-friday-cyber-monday-sales), one minute past the hour, which is the shape a timed launch or email send produces. Adobe forecasts [Black Friday 2026 online spending in the US at 12.9 billion dollars, up 9.2% on 2025](https://news.adobe.com/news/2026/09/adobe-us-holiday-shopping-season-to-hit-record). None of those numbers tells you how many people will be on your site at 08:03 on 27 November. Your own analytics can, because last year’s peak already happened on your site, with your customers, your email list and your discounts. This guide turns that history into a load test target in six steps, using one example store throughout. The method assumes you know what a concurrent user is and how the basic formula works. If not, [part 7 of this guide covers concurrent users](https://www.evaluat.com/blog/how-many-concurrent-users) in five minutes and is worth reading first. The countdown that this target feeds is in [part 1, the Black Friday readiness plan](https://www.evaluat.com/blog/black-friday-readiness-timeline). ## What you need before starting Gather these before you open any reports. Each one feeds a later step. - **Analytics access for last year’s peak week.** Google Analytics 4 or your platform’s own analytics, with editor access so you can check the retention setting. - **Server or CDN logs for last year’s peak day,** or someone who can query them. They give you the minute-by-minute shape that analytics does not. - **Order data by hour** from your ecommerce platform or order database. Order records are kept long after analytics detail is deleted, so they are your cross-check. - **This year’s promotion plan:** when emails go out, how big the discounts are, and whether the list or the advertising budget has grown. - **A spreadsheet.** Every step adds one line, and the last line is your target. The example store is a homeware retailer that sent its main Black Friday email at 08:00 on 28 November 2025. Its numbers are illustrative, chosen to make the arithmetic easy to follow. ## Step 1: Check that your analytics still reaches last November Before looking for the peak, make sure the data still exists. In Google Analytics 4, [properties retain two months of data by default](https://support.google.com/analytics/answer/9327811), and Google’s documentation says [the data retention setting only affects explorations and funnel reports](https://support.google.com/analytics/answer/7667196). Standard reports keep their totals, but the hour-level analysis in Step 2 is an exploration. So by October, a property left on the default cannot show last Black Friday in Explorations. Check the setting in Admin, in the property’s data settings, under Data retention. If it says two months, do two things today: 1. **Change it to 14 months,** the longest option for a standard property. Google notes that a longer setting applies to data you have already collected and not yet deleted, so this protects this year’s peak for next year’s planning. It does not bring back what has gone. 2. **Rebuild last year’s peak from other sources.** Your order data holds the busiest hour, because order records outlive analytics detail. Divide orders in each hour by that day’s conversion rate from the standard reports and you have an estimate of sessions per hour. Server or CDN logs, if you kept them, give the same answer more directly. You know this step worked when an exploration with a date range covering last Black Friday returns rows, or when you have an hourly sessions estimate from orders. ## Step 2: Find last year’s busiest hour Open Explore, start a free-form exploration, and set the date range to the week around last year’s peak, 24 to 30 November 2025 in the example. Add one dimension and two metrics: - **Rows:** Date + hour, which Google defines as [the date and hour when an event was collected, formatted as YYYYMMDDHH](https://support.google.com/analytics/answer/9143382) - **Values:** Sessions and Average session duration Sort by sessions, highest first. The top row is your busiest hour. A one-week range keeps the query small, which matters because explorations [may be based on sampled data if more than 10 million events are part of a query](https://support.google.com/analytics/answer/9327811). The example store’s top row reads 2025112808: 9,000 sessions between 08:00 and 09:00 on Black Friday, with an average session duration of 4 minutes. Its concurrent users for that hour come from the formula in part 7: 9,000 sessions multiplied by 4 minutes, divided by 60, gives 600 people on the site at the same moment, averaged across the hour. Write down one more number from the same hour: orders. The store took 171 orders between 08:00 and 09:00, a conversion rate of 1.9%. You will use it in Step 6. You know this step worked when you have three numbers for one specific hour: sessions, average session length and orders. ## Step 3: Find the busiest minutes inside that hour An hourly figure is an average, and peak trading is not evenly spread across an hour. GetResponse’s analysis of 4.4 billion emails found that [the first hour after sending captures 21.20% of opens and 44.14% of clicks](https://www.getresponse.com/resources/reports/email-marketing-benchmarks). When a big send lands, the first minutes after it are the busiest of the day. The gap between sending and buying can be hours rather than minutes. Klaviyo reports that on Black Friday 2024 [its customers’ most active sending hour was 9 to 10 am Eastern time, while peak order volume came shortly after, from noon to 1 pm](https://www.klaviyo.com/blog/when-to-send-black-friday-emails). Browsing peaks and checkout peaks do not always land in the same minute, which is why Step 6 treats them as separate journeys. Analytics will not show you the minutes. The standard time dimensions stop at the hour; the Analytics Data API has a [Date hour and minute dimension](https://developers.google.com/analytics/devguides/reporting/data/v1/api-schema) and the BigQuery export timestamps every event, but most teams get there faster with logs. Count requests for HTML pages, not images or scripts, in each minute of the busiest hour, after removing obvious bots (Step 5 covers how). Each person on the site requests pages at roughly the same pace, so page requests per minute rise and fall with the number of people present. That makes the ratio between the busiest minutes and the hour’s average a fair multiplier for concurrency. The example store’s CDN logs show an average of 2,000 page requests per minute across the hour, and 4,800 per minute between 08:00 and 08:10, straight after the email. The peak factor is 4,800 divided by 2,000, which is 2.4. Peak concurrency is 600 multiplied by 2.4: 1,440 people at once in the first ten minutes. If you cannot get minute-level data at all, treat the hourly figure as the floor, not the target, and let the capacity test find how far above it the site can go. ## Step 4: Scale last year’s peak to this year Last year’s peak is a baseline. This year’s will differ, and the national forecasts will not tell you by how much. Adobe expects US online spending to grow 9.2% on Black Friday, while IMRG forecast that [the total UK online market would see year-on-year growth of 0% in 2026](https://www.imrg.org/blog/expectations-for-online-trading-in-2026/). Your own trend is a better guide than either. Compare your last four complete weeks of sessions with the same four weeks a year earlier. Go back 364 days rather than a calendar year so that the weekdays line up. Then adjust for anything in the promotion plan that differs from last year: a larger email list, a deeper discount, a new advertising channel, or an earlier start. The example store’s last four weeks are 8% up on the same weeks of 2025, and its discount and email plan match last year’s. So the peak scales from 1,440 to 1,555. Then add headroom for what the trend cannot see. [Part 1’s plan](https://www.evaluat.com/blog/black-friday-readiness-timeline) uses 20 to 50 percent, with the higher end when discounts or advertising are heavier than last year. Because the store has already applied its measured growth and its promotion is unchanged, it takes the low end: 1,555 plus 20 percent is 1,866, which it rounds up to a target of 1,900. You know this step worked when you can explain every multiplier in one sentence to someone outside the team. ## Step 5: Separate people from bots Analytics and logs disagree about bots, and the disagreement matters. In Google Analytics, [traffic from known bots and spiders is automatically excluded, and you cannot see how much was excluded](https://support.google.com/analytics/answer/9888366). Your server and CDN logs keep every request, from people and machines alike. The machines are not a rounding error. Imperva’s 2026 report found that [automated traffic made up more than 53% of all web traffic in 2025](https://www.imperva.com/blog/bad-bot-report-2026-bots-agentic-age/), and Queue-it found that [28% of all Cyber Five requests came from a bot or a data centre in 2025, down from 36% in 2024](https://queue-it.com/blog/2025-online-holiday-shopping-statistics/). That gives each source a job: - **Use analytics to count people.** The 9,000 sessions in Step 2 are mostly human, which is what virtual users simulate. - **Use logs for the shape of the hour,** after filtering out known crawlers and the bot categories your CDN flags. Bots that run steadily all hour would flatten your peak factor if you left them in. - **Keep capacity for the machines.** Bots still consume server time on the day, so the headroom from Step 4 is partly there for them. There is a second gap in the opposite direction. In the UK and the EU, visitors who refuse analytics cookies may not appear in Google Analytics at all. If your analytics sessions look low next to your orders, trust the orders and scale up. ## Step 6: Turn the peak into virtual users and journeys A [virtual user](https://www.evaluat.com/blog/what-is-a-virtual-user) is one simulated visitor, so the example store’s target is 1,900 virtual users. The next question is what they do, because 1,900 people reading product pages load a site very differently from 1,900 people paying. Take the journey mix from your own funnel for the busiest hour. The example store’s 9,000 sessions break down like this: | Journey | Share of peak-hour sessions | Virtual users at 1,900 | | ------------------------------------------------ | --------------------------- | ---------------------- | | Browse: home, category, search and product pages | 91% | 1,729 | | Basket: add to cart, then leave | 5.5% | 105 | | Checkout: through to the payment step | 3.5% | 66 | For a sense of normal levels, Littledata’s benchmark of 421 Shopify stores over the summer of 2026 reports a median [add-to-cart rate of 6.5%](https://www.littledata.io/average/add-to-cart-rate/Shopify) and a median [conversion rate of 1.4%](https://www.littledata.io/average/conversion-rate/Shopify). Peak days do not follow summer averages, so use your own. Then convert orders into a checkout target. The store took 171 orders in its busiest hour, about 2.9 a minute. Scaled by the same factors as traffic, 2.4 for the peak minutes, 8% for growth and 20% for headroom, checkout has to complete about 9 orders a minute. That number is worth checking with your payment provider as well as your own servers. Run the mixed test at these weights first. Then consider a second run that over-weights checkout, because checkout pages are rarely cached and usually hit the database hardest. [Part 6 covers how to run the test itself](https://www.evaluat.com/blog/how-to-load-test-a-website), and the opening surge is the subject of [spike testing](https://www.evaluat.com/blog/what-is-spike-testing). ## How do you know the estimate is right? You know the estimate is sound when three independent numbers agree: analytics sessions, order data, and log traffic. Each step above produced a figure you can cross-check against another source, and a target that survives the cross-checks is one you can defend in a planning meeting. Run these checks before you book the test: - **Orders against sessions.** Sessions in the busiest hour multiplied by the conversion rate should land close to the orders your platform recorded for that hour. A large gap points to consent losses or tracking problems. - **The target against last year.** The new target should be well above last year’s hour-average concurrency. The example store’s 1,900 is about three times its 600, which matches the stacking of peak minutes, growth and headroom. - **The test against the logs.** When the test runs, its page requests per minute should approach the projected peak: 4,800 multiplied by 1.08 and 1.2, about 6,200 a minute for the example store. If the test produces far fewer, your virtual users are pausing longer between pages than real shoppers do. The whole estimate fits on one sheet: | Line | Example store | Where it came from | | ----------------------------- | ------------------- | ---------------------------------------------- | | Busiest hour sessions | 9,000 | GA4 exploration, Date + hour | | Average session length | 4 minutes | Same exploration | | Hour-average concurrent users | 600 | 9,000 × 4 ÷ 60 | | Peak factor | 2.4 | Logs, busiest ten minutes against the hour | | Peak concurrent users | 1,440 | 600 × 2.4 | | Growth | +8% | Last four weeks against the same weeks of 2025 | | Headroom | +20% | Low end of the 20 to 50 percent band | | Load test target | 1,900 virtual users | 1,440 × 1.08 × 1.2, rounded up | ## Common problems and fixes Most estimates fail in one of five ways. The symptom usually shows up as a target that feels too small, or as a test that passes while the real day struggles. | Symptom | Likely cause | Fix | | -------------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------- | | Explorations show nothing before August | Retention left on the two-month default | Set 14 months today; rebuild last year from orders and logs | | The target is smaller than last year’s busiest hour felt | Daily averages or the Realtime card were used | Use the busiest hour and the formula in part 7 | | The test passed but the opening minutes still struggled | The peak factor was skipped | Measure the busiest ten minutes in logs | | Logs show far more traffic than analytics | Bots in the logs, consent losses in analytics | Filter bots from logs; cross-check analytics with orders | | Checkout failed at a load the test passed | Every virtual user browsed cached pages | Weight journeys by your funnel and add a checkout-heavy run | ## How Evaluat uses your estimate The six steps work with any load testing tool, and the target is yours whichever tool runs it. In Evaluat, the number from Step 4 becomes the concurrent target of the test, and the table from Step 6 becomes weighted scenarios running side by side, each one a journey built once in the scenario editor. Datasets give each virtual user different products and search terms, so the test does not answer every request from one warm cache. Every virtual user is a real browser. Because each virtual user is a browser, the report shows what the peak did to the pages customers see as well as to the servers: Core Web Vitals per URL, response time percentiles from p50 to p99, error rates, and a video with network and console logs for any session. If checkout slows at 1,900 users, you open one of those 66 checkout sessions and watch where it stalled. The honest boundary is cost. A real browser needs far more compute than a scripted HTTP client, so a protocol-level tool is the better fit for very high request rates against an API, and many teams use both. We size the run to your forecast peak with you, using the arithmetic on this page. Last November’s peak already happened on your site. Read it out of your analytics this week, while there is still time to test against it, fix what breaks, and test again before 27 November. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) and bring your estimate; we will check it with you. [Previous · Part 8What happens when a web page loads: DNS, TLS, TTFB and render](https://www.evaluat.com/blog/how-a-web-page-loads) [Next · Part 10Latency, bandwidth and round trips, explained](https://www.evaluat.com/blog/latency-vs-bandwidth) ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad](https://www.evaluat.com/authors/ahmad-farzan) Common questions ## FAQ ### How much does website traffic increase on Black Friday? It varies by store, but across the 138 retailers Queue-it tracked in 2025, Black Friday drew 77.5 million web visits against 43.5 million on an average October Friday, an increase of 78%. Individual stores can rise far more or far less depending on their discounts and email lists, so use your own analytics for a load test. ### How do I see hourly traffic in Google Analytics 4? Create a free-form exploration, add the Date + hour dimension as rows and Sessions as the value, set the date range around your peak, and sort by sessions. Each row is one hour of one day, so the top row is your busiest hour. Add Average session duration as a second value to get the other input for the concurrent users formula. ### Why can I only see two months of data in GA4 Explorations? Because Google Analytics properties retain two months of detailed data by default, and that retention setting applies to explorations and funnel reports. Standard reports are not affected. You can raise retention to 14 months in the property settings, but data that has already been deleted does not come back. ### Does Google Analytics 4 show traffic by the minute? Not in the standard reports or explorations, where the finest time dimensions are hourly. The Analytics Data API has a Date hour and minute dimension, and the BigQuery export timestamps every event, but for most teams server or CDN logs are the quickest source of per-minute traffic. ### How much headroom should I add to last year's peak? Our Black Friday plan uses 20 to 50 percent on top of last year's peak, with the higher end when discounts or advertising are heavier than last year. If you have already scaled the peak by your measured growth, the lower end of that band is usually enough, because the test itself will show where the real ceiling sits. ### Should bot traffic be part of my load test? Simulate the people and keep capacity in reserve for the machines. Google Analytics excludes known bots automatically, so its sessions are mostly human, while your servers still have to answer every bot request. Queue-it reported that 28% of Cyber Five requests in 2025 came from a bot or a data centre. ### What if I have no traffic data from last year? Size from reach instead. Estimate how many people your launch email and advertising will bring in the first hour, treat that as your peak-hour sessions, and apply the same formula. The estimate will be rough, so run a capacity test to find where the site actually stops coping. Related reading ## More from the blog [![The concurrent users formula worked through: 12,000 sessions in the peak hour, multiplied by an average session of 5 minutes, divided by 60, gives 1,000 concurrent users. A bar comparison shows how small that is next to the 12,000 sessions in the same hour. Load tests are sized from the people on the site at the same moment.](https://www.evaluat.com/blog/how-many-concurrent-users-cover.svg)](https://www.evaluat.com/blog/how-many-concurrent-users) ### [How many concurrent users can my website handle? (with calculator)](https://www.evaluat.com/blog/how-many-concurrent-users) [Visitors per hour multiplied by session length. That is the whole formula for concurrent users, and most teams have never run it. It tells you how many people are on your site at the same moment, which is the number that loads your servers. How many your site can handle is a second question, and no server specification can answer it.](https://www.evaluat.com/blog/how-many-concurrent-users) [Ahmad Farzan · 23 September 2026](https://www.evaluat.com/blog/how-many-concurrent-users) [![A twelve-week countdown to Black Friday on 27 November: targets set at week 12, the first load test by week 8, fixes and a re-test by week 6, a spike rehearsal by week 4, a code freeze from week 2, while the expected traffic curve climbs to its peak on the day.](https://www.evaluat.com/blog/black-friday-readiness-timeline-cover.svg)](https://www.evaluat.com/blog/black-friday-readiness-timeline) ### [How to prepare your website for Black Friday: the 12-week plan](https://www.evaluat.com/blog/black-friday-readiness-timeline) [Black Friday 2026 lands on 27 November, and most sites that fail that morning failed weeks earlier, when nobody rehearsed the traffic. This plan counts down from the day: set targets from last year's analytics, find your real ceiling while fixes are still possible, rehearse the opening spike, then freeze and stand watch. Starting late? Jump in at your week.](https://www.evaluat.com/blog/black-friday-readiness-timeline) [Ahmad Farzan · 2 September 2026](https://www.evaluat.com/blog/black-friday-readiness-timeline) [![A code freeze calendar for Black Friday 2026 drawn as a timeline from 26 October to 4 December. A feature freeze starts on Friday 30 October, a full freeze starts on Friday 13 November followed by a final load test on the frozen build, Black Friday falls on Friday 27 November within the peak week, and a gradual thaw begins on Tuesday 1 December.](https://www.evaluat.com/blog/black-friday-code-freeze-cover.svg)](https://www.evaluat.com/blog/black-friday-code-freeze) ### [What is a code freeze, and should you have one before peak?](https://www.evaluat.com/blog/black-friday-code-freeze) [A code freeze does not protect you from the release you shipped in September. It protects the site you last load tested, by stopping changes nobody has proved since. Freeze about two weeks before Black Friday, include tags, configuration and content as well as code, and keep a tested route open for genuine fixes.](https://www.evaluat.com/blog/black-friday-code-freeze) [Ahmad Farzan · 7 October 2026](https://www.evaluat.com/blog/black-friday-code-freeze) See it on your site Test in real browsers.\ Debug in real sessions. ## Want to see this measured on your app? 30 minutes. We build a scenario on your real customer journey, run a small test, and walk you through the report. [Book a demo](https://www.evaluat.com/demo?intent=performance) [How it works](https://www.evaluat.com/how-it-works)