I want the tracking questions answered before the promotion starts. During the peak, I want a short watch list and someone responsible for each warning.
The calendar dates are Friday 27 November and Monday 30 November 2026. The checkpoints below count back from Black Friday. If the store starts earlier, move them back. The schedule and freeze are my engineering recommendations, not Shopify, Google or Meta requirements.
This is the seasonal companion to my Shopify tracking audit checklist. Copy the tickets into your runbook. For each row, record owner · checked at · evidence · pass / failed / unknown · next action. The boxes here are a reading aid, not a saved task list. Keep order references and request captures in your team’s private records.
Four weeks before: what needs an owner?
By 30 October, I want a map of the purchase paths and a baseline to compare later. I record gaps now so a missing test does not become a green tick on launch day.
- List every purchase sender. Record the app pixel, custom pixel, web container and backend sender used for each destination. Note overlapping paths and who can change them. Use the audit’s scope and source checks.
- Agree the event contract. Define order identity, value, currency, product identity and consent expectations; list ordinary, express, alternative-payment and post-purchase paths actually offered. Use the tracking spec and developer QA situation.
- Save a comparison window. Record order inclusion rules, timezones, currency, refunds and the reports available. Start with order-by-order reconciliation; a missing export stays unknown.
- Assign the watch and recovery. Name the person who checks delivery, the person who approves an emergency change, and the tested configuration to restore. Use the tracking runbook situation.
Keep: sender map, baseline, test plan and named owners.
Two weeks before: which paths have actually passed?
By 13 November, I want retained test evidence for the paths in scope. Arrange authorised tests with the store owner; use a test environment where available. A helper reporting an event is one checkpoint, not proof that a destination received it.
- Trace purchase to destination. Match the order, amount and currency with the received event for each chosen path. Shopify Pixel Helper checks custom-pixel subscriptions and callbacks, one custom pixel at a time, and does not work on headless stores; check the destination separately. Follow the checkout purchase recovery situation.
- Check deduplication per platform. GA4 web-stream purchases use
transaction_id; require a nonempty value unique to the order. For Meta’s recommended ID method, browsereventIDand serverevent_idmust match, as must the event names; the second copy must reach the same pixel within 48 hours of the first. Keep the pair evidence using the Meta deduplication guide. - Test consent choices separately. Check fresh accept and reject sessions, then withdrawal; compare defaults, updates and actual requests, including backend senders. In Google’s basic mode, Google tags stay blocked until consent is granted; advanced mode can send cookieless measurements while consent is denied. Use the Shopify Consent Mode guide. This covers technical implementation, not legal advice.
- Inspect the server path, if used. Follow an incoming request through the client, tag and outgoing vendor response. Server GTM preview exposes these stages. Read production error and delivery logs too; the server container term covers its separate Preview mode.
- Check promotional product data. Compare the selected variant’s price and availability in the feed, landing page and checkout. Merchant Center requires them to agree. Review the product-ID mapping with the catalogue alignment situation; record unresolved product issues.
Keep: path-by-path results, paired events, consent captures and feed checks.
Shopify documents a specific limit: checkout_completed depends on the page where it fires loading. A successful test does not prove every checkout will emit a browser event. Keep that limit beside the results.
Seventy-two hours before: what do I freeze?
From 24 November at the planned launch time, I freeze nonessential tracking changes until the post-promotion review has given each follow-up an owner. If launch is not on 27 November, count back 72 hours from the actual start. A freeze needs a defect exception and a rollback owner.
- Record the tested versions. Freeze optional tag additions, new purchase senders, container migrations, event-name or ID changes and consent rewiring. Include theme, checkout and app changes that touch measurement in the review. Use the developer tracking spec.
- Recheck the launch configuration. Review the agreed purchase paths and consent evidence against the frozen setup. Confirm planned product-data updates still run; the freeze is not a reason to keep stale prices or availability. Use the audit checklist.
- Write the exception rule. For a confirmed defect: retain evidence, name the approver, make one bounded change, record the time, keep a rollback and repeat the affected checks. Use the tracking runbook situation for safe changes, rollback and escalation; if the defect is not yet confirmed, start with the read-only emergency diagnosis situation.
- Agree the watch cadence. Choose review times around launch and each promotion change; set alert limits from this store’s baseline. State who receives a warning and who acts if that person is unavailable. Use the tracking runbook situation.
Keep: frozen versions, launch recheck, duty plan and exception procedure.
During the peak: what do I watch live?
For 27–30 November, or the store’s actual promotion window, I watch delivery evidence first. A dashboard movement starts an investigation. It does not establish the cause or justify reconnecting a sender by itself.
- Purchase events: compare new orders with recent received purchases, amounts and currencies; segment by tested checkout path. If orders continue and a path goes silent, preserve evidence before a change. Use purchase troubleshooting.
- Deduplication: sample order identities and browser/server pairs; investigate blank, reused or mismatched IDs and unexpected repeat sends. Use the deduplication guide, with transaction_id and event_id as separate fields.
- Consent: inspect changed defaults, missing updates or payloads that differ from the tested choices. Review backend handling separately. Use the Consent Mode audit and the Consent Mode term.
- Server health: watch request volume, error responses and freshness of successful delivery; check retry backlog and oldest unsent event if the sender exposes them. For Cloud Run, Google’s monitoring guide covers request status, instances, CPU and logs. Use the server container term.
- Feed: after offer or stock changes, compare the current product data with the storefront and checkout. Record mismatches and the last successful update. Check Merchant Center’s price and availability requirements. If the mismatch is a product ID rather than a price or stock value, use the product-ID situation.
Keep: timestamped observations, incident evidence and every approved change.
GA4 says processing typically takes 24–48 hours and is sometimes slower; attribution credit for key events can change for up to 12 days. I label recent reports provisional. A quiet report alone is not proof of lost events, and a successful server response alone is not proof of final attribution.
The week after: what do I reconcile?
For 1–7 December, I review the promotion as a defined order window. I keep delivery failures, reporting differences and unanswered questions separate. This first review does not make attribution final.
- Match orders to available event records. Check missing or repeated IDs, amount and currency differences, exclusions, cancellations and refunds under the agreed rules. Separate gross purchase value from net sales. Use the order reconciliation situation and reconciliation term.
- Explain each gap with evidence. Mark confirmed delivery defects, expected consent differences, reporting timing and unknowns. Where only aggregate reports exist, state that limit rather than inventing an order-level match. Use the audit checklist’s evidence limits.
- Review the incident timeline. Record affected paths, gap times, fixes, repeat-test results and what is still unresolved. Give each follow-up an owner before lifting the freeze. Use the tracking runbook situation.
- Revisit provisional reports. For key events recorded on 30 November, set a follow-up from 13 December, after GA4’s documented 12-day attribution window; allow longer if processing is delayed. Move this date if the promotion ends later. Record the extraction date with each result. Do not declare the first-week comparison final. Use GA4’s data freshness reference for timing and the revenue reconciliation guide for the comparison.
Keep: reconciliation, gap register, incident timeline and follow-up date.
What does a completed checklist prove?
It proves the checks recorded, for the paths and period reviewed. It does not certify every order, settle attribution or promise campaign results. Untested paths and unavailable records stay visible as unknowns.
If a failed row has a clear cause, describe the fix to your developer. If the cause or scope remains uncertain, my Tracking Health Check is a separate diagnostic option. I can review the evidence and agree the next step; it is not required to use this checklist.
