TL;DR
Peak-season tracking failures are almost never caused by peak season. They are caused by a change nobody verified in September, discovered on November 28 when the numbers look wrong and the store is frozen. What follows is what must be true in September, what gets locked in October, what the freeze window protects, and what you can still do during the weekend itself. The order it runs in matters, because each step depends on the one before it having a known-good baseline. The fourth Thursday of November 2026 lands on the 26th, so Black Friday is November 27 and Cyber Monday is November 30.
Key Takeaways
- November 27 is fixed; everything in this sequence is dated by counting back from it. A store that freezes mid-November has a September analytics deadline, not a November one.
- The PRO extension adds an order grid column marking orders sent through the Measurement Protocol, and it is filterable, which makes "did every order reach GA4" a query rather than an opinion [1].
- Verify consent handling before traffic mix shifts. EEA share of traffic changes during peak, and the consent method decides whether the container loads at all [1].
- Custom checkout and success page paths must be configured before any theme or checkout change is frozen, because that setting is what keeps purchase tracking attached to a non-default path [1].
- Redis caching for Measurement Protocol data is a documented PRO option, aimed at large stores with a lot of traffic [1].
- Version 1.17.3, released August 3, 2026, removed an unused HTTP context plugin that could start a PHP session on anonymous Full Page Cache hits and attach a session cookie to responses that should stay cacheable [1].
- Adobe's isolated security patch files require being on the latest security-only patch release for your line, which is a constraint your freeze plan has to accommodate [3].
The calendar you are actually working against
| Window | What it is for |
|---|---|
| September | Verification and fixes. Deploys are cheap and mistakes are recoverable. |
| October | Configuration lock. Changes get riskier, so anything structural lands here or not at all. |
| Mid-November | Freeze window opens. Extension and theme updates stop. No vendor publishes a freeze date; the window is your own choice. |
| November 27 to 30 | Black Friday through Cyber Monday. Observation only. |
The thing that makes September the real deadline is not caution. It is that verifying analytics requires generating events, and generating meaningful events requires normal traffic patterns. In late November your traffic is not normal, so a discrepancy you spot then cannot be cleanly attributed to a cause. September gives you a boring baseline, which is exactly what you need to compare against later.
September: prove purchases are arriving, do not assume it
Start here because everything downstream assumes it.
The Measurement Protocol configuration at Admin → WeltPixel → GA4 PRO → Enable Measurement Protocol Tracking Configuration selects which events go server-side, and Purchase is the one that has to be correct [1]. The verification tool is the order grid. The PRO extension adds a column marking which orders were sent through the Measurement Protocol, and since v1.16.0 in January 2026 that column is available in the grid's filtering options [1]. Filter for orders not sent, over a full month, and look at what they have in common. Payment method, store view, order status, and customer group are the usual patterns.
That last one is worth a specific check. Orders can be excluded by status, and stores using a review or fraud-check status frequently exclude it deliberately, then forget that the exclusion also removes orders that later clear into a normal status. The changelog documents a cron that picks up unsent orders and sends them once they move into a non-excluded status [1], so confirm your cron is running before you decide the exclusion is safe.
Then close the loop from the other direction. Enable the file log at var/log/ga4.log and confirm payloads are being written. The Google-side half is DebugView, which the PRO tier supports for Measurement Protocol events as well as client-side ones [1]. Realtime monitoring of the server-side stream is covered in the walkthrough on monitoring realtime server-side data in GA4, and for stores standing the server-side layer up for the first time, the Magento 2 GA4 server-side tracking setup guide is the place to start rather than doing it in October.
September, second half: consent and checkout paths
Two settings that quietly decide whether tracking exists at all during peak.
Consent. GA4 PRO offers two consent management methods: Magento's cookie restriction mode, where the GTM container loads only after the visitor accepts cookies, and External CMP, where the container always loads and a third-party consent platform drives Consent Mode v2 [1]. The documentation names the external CMP path as the recommendation for EEA stores [1]. The reason this belongs in the peak checklist is traffic mix. Paid campaigns during peak reach different geographies than your September baseline, so a consent configuration that looks fine now can behave differently in November when a larger share of sessions arrive from the EEA. Settle it while you can still change it. The implementation detail sits in the Google Consent Mode v2 on Magento 2 guide.
Checkout paths. If your store uses a checkout whose path is not checkout/index/index, or a success page that is not checkout/onepage/success, the extension has dedicated Checkout Page Paths and Success Page Paths settings to list them so transaction data still reaches Google Analytics [1]. This is the single highest-consequence setting in this article, because a store can pass every other check and still record zero purchases if the success page moved. Confirm the configured paths match your live URLs before anything freezes, and re-confirm after any checkout change, including one your payment provider makes on their side.
October: lock configuration and get the load story right
By October the question shifts from correctness to behavior under load.
Three documented items belong to this stage. First, cache compatibility. The extension is documented as Varnish Cache Ready and Full Page Cache Ready on both tiers [1], which is a compatibility statement rather than a performance promise, and it is the right time to confirm your own cache hit rates with tracking enabled. Version 1.17.3, released August 3, 2026, removed an unused HTTP context plugin that could trigger a PHP session start on anonymous Full Page Cache hits and attach a session cookie to responses that should have remained fully cacheable [1]. Cache efficiency on anonymous responses matters more the more anonymous traffic you have, which is the direction peak moves it, so an upgrade to 1.17.3 or later is worth having in place before the freeze.
Second, Redis. The PRO tier has a setting to use Redis for caching the extension's data when Redis is enabled, documented as useful for large stores with a lot of traffic [1]. We are not going to attach a throughput number to that, because none is published and inventing one would be worse than saying so. What we can say is what the documentation says: it caches the extension's data in Redis rather than through the default cache handling, and it is aimed at large, high-traffic stores [1]. If Redis is already part of your stack, turning this on in October and watching a normal week is a low-risk test. Turning it on for the first time on November 26 is not.
Third, bot traffic. Version 1.17.0, released May 18, 2026, added frontend bot detection that prevents tracking requests from firing for automated traffic such as Googlebot and AdsBot crawlers. The documented rationale is that heavy bot activity was causing unnecessary CPU load on the server and lower-quality data reaching Google Analytics [1], both of which cost more when your infrastructure is already under pressure. For the broader performance picture, the Magento 2 performance guide covers the store side of the same problem.
What does the freeze actually protect?
A freeze is usually written as a rule about deployments. For analytics it is more specific: it protects the relationship between your Magento configuration and your published GTM container.
The extension generates the GTM container JSON from your Magento configuration, so a configuration change makes the live container stale until you re-generate, re-import, and publish it [1]. During normal operation that is a chore. During peak it is a two-system change under time pressure, which is how a container gets imported and not published, and the storefront quietly serves the previous version. Freezing extension configuration and freezing the container are the same rule stated twice.
Patch cadence is the exception that needs planning. Adobe releases isolated security patch files independently between full security patches, and applying one requires being on the latest security-only patch release for your line, since isolated fixes are tested exclusively against that version [3]. That makes your position on the version ladder a freeze-planning input: 2.4.9, released May 12, 2026 [2], has the shortest ladder to climb if a patch lands mid-freeze. Decide in October what your response is if a critical patch lands in mid-November: which environments get it, who signs off, and what analytics verification runs afterward. Deciding that during the incident is what turns a patch into an outage. The mechanics of applying updates and patches are covered in the guide to updating Magento 2 and installing security patches.
The weekend itself: observe and log
During the four days, the only tracking work is observation, and it has one useful form.
Filter the order grid on the Measurement Protocol column, once per day. If the proportion of unsent orders looks like September's proportion, tracking is behaving. If it jumps, you have a real signal with a timestamp, which is far more actionable than a GA4 revenue figure that could be off for a dozen reasons.
Resist the urge to correct anything mid-weekend. A configuration change requires a container re-import to take effect [1], which means a two-system change on the busiest trading days of the year, to fix a reporting gap you can reconstruct afterward from Magento's own sales data. Write the discrepancy down, keep the log files, and fix it in December when the cost of being wrong is a report rather than a weekend.
Then do the part almost nobody does. On December 1, run the four-day totals from sales_order against GA4's revenue and keep the delta with your notes. Next September that number tells you where to start, and it beats reconstructing the weekend from memory.
FAQ
When is Black Friday 2026?
November 27, 2026, with Cyber Monday on November 30. The fourth Thursday of November falls on the 26th, so the promotional weekend runs from Friday the 27th through Monday the 30th.
Why start analytics preparation in September?
Because verification needs normal traffic and safe deploys, and a store that has frozen by mid-November has neither. September gives you a clean baseline to compare peak numbers against, plus enough time to fix what the verification finds.
How do I confirm every order reached GA4?
Use the order grid column the PRO extension adds to mark orders sent through the Measurement Protocol. It has been available in the grid's filtering options since v1.16.0, so you can filter for unsent orders directly and look for what they share [1].
Should I change tracking settings during Black Friday weekend?
No. Configuration changes require re-generating and re-importing the GTM container to take effect, which is a two-system change during your highest traffic period. Record the problem, keep the logs, and fix it after the weekend [1].
Does the extension need Redis for peak traffic?
Redis caching of the extension's Measurement Protocol data is an optional PRO setting, documented as useful for large stores with a lot of traffic. No throughput figures are published, so treat it as a change to test during a normal week in October rather than as a peak-day fix [1].
If your Magento store is heading into peak with server-side tracking you have not verified since spring, the WeltPixel Google Analytics 4 PRO extension gives you the PRO order grid column that turns this from a worry into a filter. Run that filter over September before you freeze anything.
Sources
- WeltPixel Google Analytics 4 User Guide, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
- Adobe Commerce 2.4.9 release notes, May 12, 2026, https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9
- Adobe Commerce, "Release schedule", https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/schedule