When do I actually need to work through launch checklist and QA?

Use it before removing the password, sending public traffic, launching ads, or sharing the store with real buyers. The goal is to prove the buyer can order, pay, receive notices, and be tracked with evidence, not just to approve the page visually.

What should I check before launching a Shopify store?

Check production domain and HTTPS, mobile product-to-checkout path, test order, payment and refund records, primary-market shipping and duties, order emails, policy entry, GA4 purchase, Pixel/CAPI purchase, support entry, and first-hour monitoring. If there is no proof, do not mark it complete.

Is one test order enough for launch QA?

No. One test order proves one order path only. You still need mobile checkout proof, email proof, refund or cancellation traceability, GA4/Pixel/CAPI purchase validation, primary-market shipping evidence, policy entry, and support response path.

Can I launch ads if the test order works but GA4 purchase is missing?

Do not scale from that state. The order path may work, but missing purchase events can corrupt the first ad and analytics decisions. Hold and fix it, or allow only a limited soft launch with the event gap, retest time, and budget cap written down.

Is a blocked mobile payment button a No-go issue?

Yes, when it affects the primary buyer path. Desktop proof cannot replace mobile proof. Fix the blocked component, popup, sticky bar, or app conflict, then rerun the same mobile test-order path.

When can I soft launch, and when should I call No-go?

Call No-go when real buyers cannot order, pay, receive notices, find policies, contact support, or create usable purchase evidence. Soft launch fits only watchlist issues that do not block ordering and have a traffic cap, observation window, and trigger action.

Do I still need manual QA after Store Launch Readiness Scanner passes?

Yes. The scanner is an evidence entry point, not final launch permission. The final call still needs an order ID, mobile recording, DebugView, Pixel/CAPI screenshot, email sample, primary-market shipping proof, and manual retest.

How should I use the Scanner Release Gate Matrix?

Split scanner findings into payment, mobile, tracking, policy, SEO, speed, and support-entry gates. Each gate needs a scanner signal, manual proof, Go condition, Hold condition, and copyable-note write-back. Do not use one score as the launch decision.

Which four lanes should the launch release decision sheet review?

Review public surface, checkout/order, tracking/events, and operations/support. Launch QA Command Center is only the internal English shorthand; the deliverable is the release decision sheet. A passing page does not prove checkout works. A passing checkout does not prove purchase data is usable. Passing data does not prove support can handle exceptions.

Do Core Web Vitals need to be all green before launch?

Not always. Use LCP within 2.5 seconds, INP within 200 milliseconds, and CLS within 0.1 as reference targets, but make the launch call from the real mobile purchase path. A long blank hero, late purchase controls, or scripts blocking cart and checkout is Hold or No-go; a slow non-purchase page can be a post-launch watch item.

How should the final manual launch check decide fix today, delay and retest, or pause launch?

Fix today only when the issue can be repaired and retested on the same path. Delay and retest when setup, apps, Flow, or tracking need more work. Pause launch when the issue affects ordering, payment, notifications, policy promises, support entry, or purchase events.

How should I run the 2-hour launch room checklist?

Use T-120, T-90, T-60, T-30, and T-10 windows. Pause risky changes, run a mobile test order, reconcile purchase parameters to the order, recheck shipping/policies/support, and re-sort all open issues before traffic starts.

Shopify Pre-Launch Checklist: Test Orders, Checkout, GA4, Pixel/CAPI

Loading interactive version

Text version of this lessonExpand

Pre-launch QA is not a final click-through. It is a regression test before traffic: pages, payment, shipping, email, data, policies, and support must be tested through real paths.

From the previous lesson: test the fulfillment promise you already wrote down

The previous lesson leaves a shipping promise and exception matrix: a named market and SKU with its representative checkout rate, handling/transit wording, first-scan and tracking evidence, duties wording, exception boundary, and pause action.

It does not prove that a real buyer can complete payment and an order, or prove carrier performance, a duties outcome, payment settlement, or launch approval. The matrix only tells you what this lesson must test; the same promise still has to pass the current purchase, order, email, data, and support paths.

This lesson turns that input into a launch regression evidence board: choose a path, retain the proof, then take the next Go, Soft launch, Hold, or No-go action. A record or selected card is not launch approval.

Rank the issue first, then run regression through real user paths

Many stores discover after launch that mobile buttons break, failed-payment emails are missing, GA4 has no purchase, or policy links are hard to find.

This lesson first separates issues into pause launch, fix before launch, can fix after launch, and watch after launch, then separates QA into user path, order path, data path, and exception path. Each path needs device, backend record, review lead, and retest result.

    Decision lens for this lesson
    
        Regression test: Rechecking the critical path after
        changes to confirm launch ability is still intact.
      
        User path: The full experience from entry page to
        product, cart, checkout, and support.
      
        Exception path: Non-ideal cases such as failed payment,
        out-of-stock, address error, refund, and support inquiry.
      
        Release call: When payment, order capture, mobile,
        policies, or support entry affects real buyers, fix before launch;
        small style or helper-copy issues can go into the post-launch fix pool.

Lesson output: launch blocker ranking sheet and pre-launch regression sheet. Use this output to decide whether the lesson is truly complete.

How this connects: launch QA must review system and payment evidence

Launch QA is not a final checkbox. It puts pages, checkout, orders, email, policies, fulfillment, tracking, and accountable roles into one release table.

System route: system integration to confirm SKU, orders, email, GA4, ad events, and permissions are not broken.
Payment route: payment gateway setup to decide whether live payment is safe using test orders, refunds, and payout evidence.

Pre-launch QA accepts test evidence, not looks fine

Launch QA is not browsing the homepage once. You need to test the user path, payment path, fulfillment path, and data path one by one, then keep order IDs, event parameters, email samples, or backend records. If the only proof is someone saying it was checked, the team will not know where to debug when launch traffic exposes a break.

Step 1: choose the path you are most worried about. Read what must pass, what proof to retain, and what should stop if it fails; a selected path is not a release conclusion, it only tells you which real record to run next.

Test path	Must work	Stop this if it fails
Purchase path	Mobile browsing, add to cart, checkout, payment, order email	Stop ads and public launch
Fulfillment path	Order enters admin, shipping, tracking, refund flow	Stop large-volume order intake
Data path	GA4, pixel, UTM, order value, and event records	Stop scaling decisions based on data

Completion standard

Finish at least one test order, one refund test, one full mobile-path retest record, and confirm the matching order, email, refund, or event data in the backend.

Lesson output: launch QA issue log

Turn launch QA from a memory list into a table that closes issues.

QA area	What to record	Close standard
Pages and navigation	Broken pages, dead links, mobile layout issues, wrong CTAs	Retest on desktop and mobile after fixing
Checkout and payment	Test order, failure message, refund path, email notification	At least one full test order can be reviewed
Data and support	Event firing, order status, support entry, review lead	Every issue has a review lead, status, and retest time

Accept launch with reviewable records, not image files

Image files can help communication, but they should not be the main acceptance standard for this lesson. Useful launch evidence lets another operator open the admin, report, or inbox tomorrow and verify the same order, event, or promise path.

Path	What to write in copyable lesson notes	How another person can verify it
Order and payment	Test order ID, payment status, refund record, inventory change, and customer email subject.	Check Shopify orders, payment admin, refund entry, and notification emails.
Shipping and promise	Primary-market test address, shipping amount, tax/duty display, free-shipping threshold, and policy URL.	Use the same address to rerun cart and checkout, then confirm the promise still matches.
Data and ads	transaction_id, value, currency, items, UTM test link, and ad test event name.	Open GA4 DebugView / Realtime, ad event testing, and Shopify order reconciliation.
Mobile and exception	Device model, browser, entry URL, stuck point, review lead, and retest time.	Rerun the path under the same device conditions and confirm buttons, popups, address, coupon, and support entry no longer block purchase.

This table works better for team execution than scattered image files. The launch record is whether traffic can start, what must not change, and what the next review should inspect.

Worked ecommerce scenario: pre-launch QA for a 20oz tumbler

Assume you are launching a 20oz tumbler. Ads promise 2-5 day delivery and free shipping over $49, and the first traffic will come from Meta and Google. Launch QA is not only checking whether the homepage looks polished. It connects the promise entry, order path, and data path: what buyers see, what Shopify records, and what GA4/Pixel/CAPI records as purchase must reconcile.

Path	Evidence to inspect	Common wrong move	Next action
Promise entry	PDP, Shipping policy, and checkout show the same delivery timing and free-shipping threshold	Only checking homepage visuals and skipping the primary-market address until checkout shows high shipping	Use a primary US address to run cart, checkout, shipping, tax, and policy URLs, then record the test address and displayed result
Order path	Test order number, payment status, customer email, staff notice, refund record, and inventory change	Only checking that the payment button appears without confirming admin order or email delivery	Add the order number and refund record to copyable lesson notes as launch evidence
Data path	GA4 DebugView, Meta Pixel/CAPI testing, and Google Ads conversion diagnostics show purchase, value, currency, and transaction_id	Starting traffic because Shopify has an order while GA4 and ad events show no purchase	Fix Pixel/CAPI, UTM, purchase parameters, and thank you / order status tracking before judging scale. GA4, Pixel, and CAPI record visit, cart, and purchase signals; they are not decorative scripts.

Launch Blocker Triage practice: do not let real buyers become your testers

Launch QA is not just a list of pending issues. First decide whether the issue blocks payment, order capture, fulfillment promise, data judgment, or support access. Problems that stop real buyers from ordering cannot launch. Problems that create refunds, questions, or complaints must be fixed before launch. Small experience issues that do not affect purchase or promises can move into the first-week fix pool.

Signal	Wrong move	Correct call	First evidence
Mobile payment button is covered by a popup or chat widget	Use desktop page appearance and call QA done	No-go: fix the widget, then rerun a mobile test order	Mobile recording, device, test-order result, widget name
Shopify has a test order, but GA4 or ad testing shows no purchase	Start a small budget and wait for reports	Hold: data is not accepted, so do not use it for scaling calls	Order number, DebugView event, pixel/tag test result, and purchase parameters
Primary-market address shows high shipping, no delivery, or unclear duties	Launch first and explain when buyers ask	Must-fix: repair shipping rules, page promise, and policy wording	Primary-market address, shipping/duty display, PDP promise, and shipping policy URL
Thank you / order status tracking or app pixel compatibility is unclear	Payment works, so tracking can wait	Hold or soft launch: confirm checkout/accounts editor scope, app compatibility, and tracking state	Checkout configuration, thank you/order status state, and app pixel status

Why a Final Store Check Matters

Everything you set up earlier, entity, payments, storefront, logistics, compliance, and systems, must be validated in one real customer path. Looks correct in admin is not enough.

What QA Is Supposed to Achieve

Catch visible mistakes before users do.
Confirm the full funnel works end to end.
Make sure the team has one clear view of launch readiness.

Run a basic readiness scan first

Before manual QA, open the Store Launch Readiness Scanner, enter the store domain, and let it check public pages, policy links, contact signals, mobile performance, key links, and basic tracking signals. The report does not replace manual testing. It gives you the first issue list.

Use the scan as an investigation order, not a score. It cannot turn one score into proof that payment, order, mobile, event, or support paths pass. The report points to what to inspect; an order ID, mobile recording, event capture, email sample, and manual retest answer whether that path can release.

Scanner signal	Bring back to QA	Manual proof still needed	Write into copyable notes
Privacy, refund, shipping, contact, or footer links are missing, broken, or unreachable.	Failed URL, page type, HTTP status, screenshot time, and review lead.	Open the pages on mobile and confirm buyers can find the same promise from product page, footer, and checkout.	Whether the policy gap blocks launch, fixed links, retest time, and whether soft launch is allowed.
Mobile performance, button visibility, page loading, or the key purchase path is risky.	Test device, browser, page URL, failed step, recording or screenshot, and whether the test order was rerun.	Run product -> cart -> checkout -> thank you / order status on a real phone, not a narrowed desktop viewport.	Whether mobile is No-go, the fixed component, test order number, and paused theme / app changes.
Basic tracking, tags, key scripts, or event checks are incomplete.	GA4 DebugView, Meta Test Events, Google Ads diagnostics, transaction_id, value, currency, and order number.	Confirm purchase is not duplicated and not only a page-view event; ad events do not replace Shopify order facts.	Whether purchase can support first ad decisions, missing parameters, fix version, and 24-hour review window.
Support, fulfillment, FAQ, email notification, exception entry, or trust information is incomplete.	Issue type, buyer step affected, response lead, support template, shipping notification, and retest time.	Simulate failed payment, invalid address, out-of-stock, expired discount, and missing email so the buyer can see the next step.	Whether exception paths block public traffic, who covers day-one support, and which exceptions to review after 72 hours.

Basic setup steps

1Connect the production domain, enable HTTPS, and make sure the homepage is not a password or placeholder page.

2Place privacy, refund, terms, shipping, and contact pages in the footer.

3Finish one product page, cart, checkout, and order notification path before scanning.

4Use the report to prioritize manual QA for payments, email, shipping, and mobile flow.

Scanner Release Gate Matrix: release payment, mobile, tracking, policies, SEO, speed, and support entry separately

The Store Launch Readiness Scanner is not a single score that lets you skip judgment. Treat it like an early radar: when it finds a signal, move that signal into the right release gate and add manual proof. Payment passing does not prove mobile passing. Mobile passing does not prove purchase data is usable. Policy links passing does not prove support can handle exceptions.

Every release gate needs its own manual proof and Hold condition. If a gate has not completed its named retest, put it in the QA record and collect that proof; a different passing gate cannot speak for it.

Release gate	Scanner signal	Manual proof	Go condition	Hold condition	Write into copyable notes
Payment release gate	HTTPS, checkout path, payment entry, or key-link risk appears.	Primary-market mobile test order, order number, payment status, and refund or cancellation record.	Successful payment, order email, order status page, and refund/cancellation path all have proof.	Payment button is blocked, redirect fails, or the order succeeds without an admin record.	Payment gateway, test-order number, failure point, retest time, and day-one payment-failure response lead.
Mobile release gate	Mobile performance, button visibility, above-the-fold loading, or key purchase path is risky.	Real-phone recording of product -> cart -> checkout -> thank you / order status.	Variant selection, add to cart, address, payment, and order status all work without popups blocking controls.	Desktop passes but mobile buttons are blocked, address entry is hard, or payment redirect fails.	Device, OS, browser, failed page, fixed component, and paused theme / app changes.
Tracking release gate	Basic script, tag, or event check is incomplete.	GA4 DebugView, Meta Test Events, Google Ads diagnostics, transaction_id, value, currency, and order number.	Purchase fires once, and value, currency, order number, and ad-platform event match.	Only page-view events exist, purchase duplicates, value is missing, currency is wrong, or order-status tracking is unstable.	Which platform is usable, which parameters are missing, whether first ad learning is allowed, and the 24-hour review window.
Policy release gate	Privacy, refund, shipping, terms, contact, or footer links are missing, broken, or unreachable.	Check the same shipping, refund, and contact promise from PDP, footer, checkout, and order email.	Policy pages load, promises match, and buyers can find return, shipping, and contact paths before ordering.	Policy 404, promise conflict, broken contact path, or checkout promise differs from the PDP.	Fixed URL, promise version, review lead, retest time, and whether soft launch is allowed.
SEO release gate	Production-domain, index entry, title/description, key-link, or basic structured-data risk appears.	Check production domain, canonical, robots, primary PDP title/description, main collection entry, and core internal links.	Production URLs load, titles/descriptions are not placeholders, and primary PDP/collection pages are reachable internally.	Password page remains, noindex is left on, placeholder titles remain, canonical points wrong, or key internal links break.	Production URL, discovery path, fixes, retest method, and post-launch Search Console watch window.
Speed release gate	Mobile performance, above-the-fold resources, images, scripts, or third-party app load impact appears.	Check homepage, main collection, primary PDP, and pre-checkout path under primary-market mobile conditions.	Primary-path hero loads steadily, buy controls appear in time, and heavy scripts do not block pre-checkout actions; use Core Web Vitals reference targets of LCP within 2.5s, INP within 200ms, and CLS within 0.1, while still making the launch call from the real mobile purchase path.	Long blank hero, oversized images, popups/tracking scripts slowing purchase path, or obvious mobile jank.	Slow page, weak LCP/INP/CLS signal, suspected resource, temporarily disabled app/script, retest result, and post-launch watch item.
Support-entry release gate	Contact paths, FAQ, email notifications, exception explanations, or trust signals are incomplete.	Simulate failed payment, invalid address, out-of-stock, expired discount, and missing email.	Contact entry is visible, order email works, exception scenarios have guidance, and support knows what to watch on day one.	Contact path breaks, FAQ conflicts with policy, order email fails, or exception scenarios have no response lead.	Support entry, day-one response lead, template, exception tag, and 72-hour review metric.

Launch release decision sheet: four lanes decide together before launch

The final launch call is not another page review, and it is not the scanner score alone. Put four lanes into one release decision sheet: public surface, checkout and order, tracking and events, and operations and support. Each lane should state its Go condition, Hold condition, evidence, confirming lead, and first-hour action. Launch QA Command Center can remain the internal English shorthand, but the reader should carry away the decision sheet.

Command lane	Question before launch	Go condition	Hold condition	Evidence to keep	First-hour action
Public surface lane	When a real visitor arrives from ads, organic search, or the homepage, can they see one consistent product promise, policy entry, and contact path?	Homepage, main collection, primary PDP, footer policies, contact entry, and mobile hero all load, and promises do not conflict.	Policy 404, shipping/return promise conflict, primary PDP still uses placeholder media, or mobile CTA is blocked.	Production domain, primary-market mobile recording, policy URLs, primary PDP hero screenshot, and retest time after fix.	Inspect public entry, 404s, mobile hero, and support entry; do not redesign the theme.
Checkout and order lane	Can a real buyer go from cart to successful payment, receive order email, and leave a reconcilable Shopify order?	Primary-market mobile test order, payment state, order email, inventory change, refund/cancel path, and thank you / order status are reviewable.	Only desktop payment passed, order email missing, shipping/tax unstable, or refund/cancel path untested.	Test order ID, payment/refund record, order email subject, inventory-change screenshot, and mobile thank you / order status screenshot.	Watch failed payments, duplicate orders, missing email, and refund entry; do not change offer structure.
Tracking and event lane	Can Shopify order, GA4 purchase, ad events, UTM, and Pixel/CAPI explain the same order?	purchase has transaction_id, value, currency, and items, and ad test events reconcile with the Shopify order.	Order exists but purchase is missing, duplicated, value/currency mismatches, or thank you / order status tracking scope is unclear.	GA4 DebugView, Meta Test Events, Google Ads diagnostics, transaction_id, value/currency, order ID, and UTM test link.	Only judge whether purchase is trustworthy; do not scale from first ad data.
Operations and support lane	When payment fails, address is invalid, stock is missing, shipping is questioned, refund starts, or email is missing, can the buyer see the next step?	Support entry, order lookup, shipping notice, FAQ, exception copy, refund/return path, and day-one coverage are defined.	Exception path has no guidance, support does not know where to look, policy and email promises conflict, or nobody monitors tickets on day one.	Failed-payment screenshot, invalid-address copy, out-of-stock message, support template, day-one support lead, and 72-hour exception review fields.	Watch support entry, failed payments, order email, and shipping questions; do not start complex automation.

Put this launch release decision sheet into copyable lesson notes. If one lane is Hold, do not let another lane hide it. Public pages passing does not prove checkout is ready, and checkout passing does not prove purchase data is safe for scaling.

Final manual launch check: do not just tick the checklist, decide which faults break ordering

The last manual check before launch is not reading the checklist from top to bottom. The real question is whether an issue blocks payment, ordering, buyer promises, support, or the first traffic data. Every issue should land in one of three actions: fix today and retest, delay and retest, or pause launch.

Check item	Buyer risk	Fix today	Delay and retest	Pause launch	Evidence to keep
Checkout and payment	The buyer reaches the last step but cannot pay, card fails, PayPal does not return, or discount/tax changes.	Fix payment button, coupon, address guidance, or backup payment; then place one small mobile order.	Payment review, payout hold, tax/currency config, checkout app, or extension affecting checkout.	Primary payment cannot collect, real mobile checkout cannot finish, or refund/cancel path has no confirmation.	Mobile recording, test order ID, payment status, refund/cancel record, discount and tax screenshots.
Mobile product path	If buyers cannot see price, variant, add-to-cart, shipping promise, or trust proof, they will not continue.	Disable blocking popup, lift add-to-cart layer, add price/shipping/return promise, or fix primary media.	Theme structure rewrite, subscription/bundle app affecting variants, or heavy scripts slowing mobile.	Mobile cannot select the main SKU, cannot add to cart, or PDP promise conflicts with checkout promise.	Primary-market phone model, browser, entry URL, PDP recording, variant choice, and add-to-cart success screenshot.
Purchase tracking and events	The order may be real, but GA4, Meta, and Google Ads may not know what happened, so media decisions become wrong.	Fix UTM test link, purchase parameters, duplicate scripts, Pixel/CAPI connection, and order-status tracking scope.	Consent Mode, server events, cross-domain payment redirect, or ad-account conversion-goal reset.	Purchase is missing or duplicated beyond interpretation, or value/currency is clearly wrong while traffic is about to scale.	GA4 DebugView, Realtime, Meta Test Events, Google Ads diagnostics, order ID, transaction_id, value, and currency.
Shipping, refund, and policy promises	If buyers cannot understand delivery time, return rules, or who to contact, the result becomes tickets, refunds, disputes, and bad reviews.	Add policy entry, align PDP/policy/checkout promises, add return conditions, and repair footer/email links.	3PL timing unconfirmed, duties/tax promise unclear, or subscription/preorder/custom-product rules missing.	Refund, shipping, privacy, or contact entries are missing or conflicting, or ad promises have no page evidence.	PDP, Shipping policy, Refund policy, Contact, checkout shipping, order-email links, and primary-market test address.
Support and exception entry	If failed payment, address error, missing email, shipping question, or refund request has no entry, buyers complain through platforms or payment channels.	Test support inbox, add order lookup entry, write failed-payment/address-error guidance, and assign day-one response lead.	Support-system migration, untested automation flow, or return portal/ticket tags not connected.	Support inbox cannot receive, Contact breaks, refund/return has no response lead, or nobody covers day one.	Support test email, order-email screenshot, Contact URL, exception copy, day-one response lead, and 72-hour review fields.
Public pages and speed	If production domain fails, primary PDP is 404, hero loads too slowly, or title is placeholder, purchase trust and SEO both suffer.	Fix production domain, canonical, robots, main navigation, collection entry, placeholder title/description, and oversized hero image.	DNS propagation, theme performance rewrite, key app replacement, or Search Console observation window.	Production domain is unreachable, primary purchase page is 404, noindex remains, or mobile hero stays blank too long.	Production URL, main entry path, mobile-load recording, title/description, canonical, robots, and retest time after fix.

Write this back into copyable lesson notes. The team does not need “I checked it.” It needs which issue breaks ordering, whether it can be fixed today, whether it needs delayed retest or pause launch, and where the proof lives.

Page-Level Checks

Frontend Checklist

Homepage, product pages, collection pages, FAQ, policy pages, and contact pages all load correctly.
Navigation and footer links are valid.
Product title, pricing, variants, images, and stock state display correctly.
Mobile layout remains usable and readable.
Language, currency, and market presentation match your intended market.

Checkout Must Be Tested as a Real Path

Checkout QA Sequence

1Add products to cart and confirm pricing, discount, and shipping logic.

2Fill in realistic addresses and contact details.

3Check that main payment methods appear and behave correctly.

4Confirm the order lands in admin and inventory behaves correctly.

5Check confirmation emails and the next operational steps.

Shipping, Email, and Tracking Need to Be Checked Together

Shipping

Rates, delivery wording, tracking, and fulfillment messaging.

Order emails, abandoned-cart flows, subscription emails, and reply-to setup.

Analytics

View, add-to-cart, checkout, and purchase events.

Failure flows

Payment failure, bad address, or stock conflict should still produce understandable feedback.

Mobile Must Be Tested Separately

    Mobile Checks
    Primary CTA is visible and tappable on first screen.

        Product image, price, shipping promise, and trust signals remain
        readable.
      
Checkout fields and country selectors work smoothly.
Popups or sticky UI do not block core actions.

  

Final Launch Checklist

Before You Go Live

Core pages and policy pages complete
Payment and shipping logic tested
Email and order notifications working
Analytics events verified
Desktop and mobile reviewed
At least one realistic test order completed

Do Not Launch a Broken Funnel

If checkout, notifications, or support handling still break, do not launch just because the store looks finished.
Your first real visitors should not be your QA team.

Execution Advice

The most effective QA workflow is a simple checklist table, not memory. Walk through every core page and customer path deliberately, then fix issues before traffic scaling starts.

    QA table fields
    
        Path: page, checkout, email, shipping, tracking, or
        support flow.
      
        Issue: what failed and on which device, market, or
        browser.
      
        Review lead: who fixes it and when it must be
        retested.
      
        Acceptance: what proves the path is ready for launch.

Tracking and attribution need separate launch acceptance

Many teams test pages and payments but forget that analytics and ad systems are also part of the launch path. If `view_item`, `add_to_cart`, `begin_checkout`, `purchase`, Pixel/CAPI, or UTM naming breaks after launch, budget can drift before the team notices.

Define CAPI and attribution before checking data

CAPI means Conversions API. It lets the server send order, cart, and checkout signals to ad platforms instead of relying only on the browser Pixel. You usually see it in Meta Events Manager, Shopify apps, server-side tracking, or system-integration settings. If CAPI and Pixel duplicate or miss orders, the ad system learns from the wrong order quality.

Attribution means assigning order credit to an ad, keyword, content piece, or channel. You see different attribution views in GA4, Google Ads, Meta Ads, Shopify reports, and UTM reports. If purchase, UTM, or order value is incomplete, you may scale traffic that looks good but does not contribute profit.

Data and attribution QA order

1Use GA4 DebugView or Realtime to confirm product view, add-to-cart, checkout, and purchase events.

2Check that order value, currency, transaction ID, product ID, and source data are not missing.

3Confirm ad conversion events match the real order path before scaling traffic.

Mobile QA must check interaction, not only pages

The expensive mobile failures are often input, scrolling, popups, address fields, sticky buttons, and payment redirect issues, not whether the page opens. Desktop success does not prove the mobile order path is ready.

Mobile issues that are easy to miss

Country, province, postal code, and phone fields behave differently across markets.
Newsletter popups, chat widgets, or sticky bars cover checkout buttons.
Payment buttons move below the fold after the keyboard opens.

Test failure paths, not only successful checkout

A single ideal test order does not reveal what real customers will hit. Walk through failed payment, invalid address, out-of-stock, expired discount, missing email, and unreachable support paths before launch.

Failure-path checklist

Failed payment shows a clear next step instead of a dead end.
Invalid addresses and unavailable regions explain what the customer can change.
Out-of-stock and expired promotion states do not leave misleading promises on the page.
Support entry points work when the order cannot be completed.

Official QA boundary: accept launch through a real order path

Official sources last reviewed: 2026-06-29. Shopify test orders, checkout, thank you, order status, customer accounts, Customer events, GA4, and ad-event surfaces can change as admin surfaces change. Before launch, use what your store admin currently shows.

Shopify test order documentation states that test orders can verify checkout, order processing, inventory, shipping, email notifications, and tax settings. Pre-launch QA should simulate a customer path from site entry to notification instead of only checking that pages load. If you do not have an order number, payment or refund record, email sample, mobile retest record, and event parameters, the QA is not accepted yet.

Store Launch Readiness Scanner only tells you where to look first. The final launch call still needs an order ID, mobile recording, event screenshot, email sample, and manual retest.

Official boundary	How this lesson uses it	Evidence before release
Shopify test orders	Use a test order to verify checkout, order processing, inventory, shipping, email notifications, taxes, refunds, and admin order state.	Test order number, success page state, admin order, customer email, refund record, and inventory-change record.
Shopify checkout editor	Checkout, thank you, order status, and customer accounts share an editor boundary, and customization scope differs by plan. When checkout friction appears, classify it as a setting, app, plan, or development issue first.	Checkout configuration, thank you / order status state, app state, and editable-scope decision.
GA4 ecommerce reports	GA4 ecommerce reports depend on events such as view_item, add_to_cart, begin_checkout, purchase, and required parameters. After the test order, reconcile order ID, value, currency, and transaction_id.	DebugView / Realtime event, purchase parameters, UTM test link, and Shopify order ID.

Operating calibration: test the settings that can cost real money first

The launch risks that create immediate losses are usually shipping, payments, policies, tracking, and app costs rather than theme color. Treat each checklist item as a real transaction test: can the store take payment, ship, refund, send email, and record GA4 plus ad conversions correctly?

Test domestic, international, and remote shipping addresses instead of trusting the default rate table.
Place a test order and verify payment, refund, email notifications, order status, and support access.
Freeze non-essential apps before launch so fees and page speed do not grow before conversion is proven.

Copyable lesson notes: launch QA acceptance record

If the desktop homepage looks good but the mobile product-page button is covered, ad traffic will expose a QA problem, not an ad problem. Do not finish this lesson by writing "I checked everything." Leave a record that another person can review and continue.

    Your copyable notes should include these 6 fields
    
        Current pressure: Mobile payment, test order, shipping
        promise, GA4/Pixel/CAPI, policy entry, or support entry that blocks
        launch.
      
        First evidence: Order number, mobile recording,
        DebugView, Pixel/CAPI test result, primary-market shipping record, email
        sample, and review lead.
      
        This-week action: Fix blockers, rerun test order,
        repair policy/shipping, fix purchase parameters, and pause launch-day
        changes.
      
        Stop action: Before test order, mobile proof, or
        purchase event exists, do not run public traffic, scale, or change
        several core settings.
      
        Review window: Within 24 hours review orders, failed
        payments, email, support, and purchase; within 72 hours review
        exceptions.
      
        Next route: Support response path, fulfillment setup, or
        system integration depending on the biggest blocker.
      
        Route back to lesson: Payment failures go back to the payment lesson, shipping promise gaps go back to fulfillment, policy conflicts go back to policies, support entry gaps go to the next support lesson, and event or automation gaps go to system integration.

When you share this note with the next operator, the point is not proving that you checked. The point is making it clear whether traffic can start, what must not change, and what the first review should inspect. Keep the full record in the same QA document for review.

If browser controls limit copying, select the record or enter it into your QA document manually; a successful copy does not mean the path has passed.

Launch-day 2-hour room: who clicks, who confirms

In the final 2 hours before launch, do not rely on a chat message that says I checked it. Break each action into who clicks, who confirms, what backend record is saved, and which changes stay paused. This is not paperwork. It protects the payment, shipping, policy, and tracking paths you just accepted from being broken again before first traffic.

Time window	Who clicks what	Who confirms	Proof to keep	Launch-day pause rule
T-120 minutes	The launch lead closes temporary change lanes for theme, apps, payment, shipping, and pixels, leaving only blocker fixes open.	A second person confirms production domain, password page state, primary product, policy entry, and support entry.	Home, product page, policy entry, support entry, current theme version, and app list record.	Unless fixing a Blocker, do not change theme structure, add apps, or rewire payment and tracking.
T-90 minutes	The QA runner uses a primary-market mobile path from ad entry or home through cart, checkout, payment, and order status.	The operations lead confirms the order appears in Shopify and both customer and staff emails arrive.	Mobile retest record, order number, payment status, email sample, and order status state.	Do not send public traffic before mobile passes; desktop page checks cannot replace mobile proof.
T-60 minutes	The finance or data lead opens payment admin, refund entry, GA4 DebugView, ad event testing, and Pixel/CAPI tests.	The launch lead confirms transaction_id, value, currency, and items reconcile with the Shopify order.	Successful payment record, refund entry, purchase parameters, ad test event, and Shopify order reconciliation.	If purchase is missing, allow only Hold or Soft launch. Do not use ROAS, revenue, or ad-platform results to judge scaling.
T-30 minutes	The fulfillment lead rechecks shipping, duties/taxes, delivery timing, discount, return entry, and FAQ with a primary-market address.	The support lead confirms first-day replies for refunds/cancellations, missing email, and failed payment.	Primary-market shipping record, policy URLs, support reply snippets, and exception handling entry.	Do not launch ads promising free shipping, fast delivery, or unconditional returns until shipping and return promises align.
T-10 minutes	The launch lead re-sorts all open issues into Blocker, Must-fix, Can-ship, and Watchlist.	A second lead confirms first-hour monitor, budget cap, support entry, review time, and rollback move.	Launch room checklist, final decision, first-hour watch metrics, and 24-72 hour review time.	If any Blocker remains, No-go. If Must-fix remains, Hold. Only Watchlist allows limited traffic.

The value of this table is turning launch from a feeling into an evidence-based launch record. The final copyable lesson notes should include the current window, first proof, launch-day pause rule, and next review time.

Launch-day pause table: stabilize the paths that can cost money

The launch risks that create immediate losses are usually shipping, payments, policies, tracking, and app costs rather than theme color. On launch day, protect the paths you already accepted, then read the first real orders and exceptions.

Pause first	Why it matters	First-day review
Theme rewrites, popups, chat widgets, checkout apps	These changes can cover mobile buttons, alter checkout, or invalidate the QA proof you just collected.	Mobile recordings, add-to-cart / checkout taps, failed payments, and where users get stuck.
Shipping, duties, discounts, return promises	These promises affect orders, refunds, support, and ads, so they should not be rewritten while traffic is starting.	Primary-market orders, shipping surprises, coupon failures, refund/cancel requests, and support questions.
Pixel/CAPI, GA4, UTM, thank you / order status tracking	Tracking changes affect first traffic decisions. Without purchase evidence, do not use reports to scale.	purchase, value, currency, transaction_id, ad test events, and Shopify order reconciliation.