What This Step Does
In the previous step, the identifying information held in the browser was parked in the order data. Now that information gets used: once payment is confirmed, the server sends the purchase to GA4.
The trigger is the notification that arrives when payment completes. Shopify can automatically send word the moment an order is paid (a Webhook), and the orders/paid notification is what starts the process. The destination is the GA4 Measurement Protocol — the endpoint for sending data to GA4 directly from a server.
This article covers why the notification, rather than the browser, is the right trigger; how to avoid counting the same purchase twice; and how to keep watch on whether the numbers hold up.
Why the Payment-Complete Notification Is the Right Trigger
The Confirmation Page Doesn't Always Render
Judge a purchase by whether the confirmation page appeared and your numbers will wobble easily. The connection drops after payment, the user closes the window before the page loads, the browser back button re-renders it. All of these are ordinary behavior, and each one either loses a purchase or adds one. As long as something as fragile as a page render is your basis, that noise never goes away.
Work Only from the Fact That Payment Was Confirmed
The payment-complete notification is a server-to-server message sent when payment is confirmed. It doesn't depend on what happened on the user's screen, so the conditions under which it arrives are clear. Browser type, extensions, connection quality — none of the things outside your control affect it. Choosing a reproducible basis is the first step toward stable measurement.
Dropped connections and closed windows lose purchases; the back button can count them twice
Works only from the fact that payment cleared, so nothing on the user's screen affects it
In one sentence: stop counting visible events on screen and start counting facts the system has confirmed.
Three Pieces of Information Are Enough
Telling GA4 that a purchase happened doesn't take much. An identifier for whose purchase it was, an identifier for which order it was, and the amount with its currency. Getting those three to send reliably is the first goal. Load in extra fields from the start and troubleshooting spreads across too many suspects. Once delivery is stable, add the fields you actually need one at a time — it works out faster that way.
Four Points to Get Right in the Send
Always Verify Who Sent the Notification
The endpoint that receives notifications is also a door reachable from outside. Process a message without confirming the sender is genuine and you risk recording fabricated purchases from fake order data. Adopt one simple rule from the beginning: if verification fails, don't process. Temporary workarounds here have a habit of becoming permanent, so making no exceptions ends up being the safest path.
Never Count the Same Order Twice
Sends will fail on occasion and need to be retried. If nothing can tell whether an order has already been sent, one purchase becomes two. The order identifier is what makes that judgment possible: record which orders have been sent, and skip any identifier that shows up again. Tighten the exclusion rules too much, though, and legitimate purchases get dropped — so design retry capability and deduplication together, never one alone.
Decide How to Treat Orders with Missing Identifiers
In real operation, a certain number of orders arrive without identifying information — the earlier write failed, or the order came in through another channel such as a phone or in-store sale. What matters is deciding in advance what takes priority when that happens. Hold the send back, or record the amount anyway? Fixing the criterion keeps the handling consistent no matter who is on duty. This is less a technical problem than an operating policy.
Manage by "Succeeded," Not by "Sent"
Track sends by whether the other end accepted them, not by whether you ran the code. Record success counts, failure counts, and failure reasons, and you can mechanically pull the list of orders to retry. The state to avoid is the familiar "we sent it, probably" — with that in place, you can't explain a discrepancy when one appears. Making the process countable is what makes the quality defensible.
Answers to the Questions That Come Up
"GA4 and the Ad Platform Don't Agree"
When the ad dashboard and GA4 disagree, the first suspect should be differing definitions, not a bug. When a conversion is counted, how credit is assigned across touchpoints, and which events are in scope all vary — and any difference produces a gap even when both systems work correctly. Set an acceptable range in advance, and only when it's exceeded, separate whether the gap comes from losses or from duplicates. Working in that order shortens the path to the cause.
"It Works on Test Orders but Drifts in Production"
Tests tend to cover straightforward success cases. Production adds cancellations, re-payments, partial refunds, and retries. Miss that gap and you get the classic "clean in test, unstable in production." Laying out each order state and marking whether it should or shouldn't be sent removes a large share of post-launch trouble.
"Our Operators Can't Read Technical Logs"
The people running this day to day should be able to drive improvements without reading code or detailed logs. Three indicators are usually enough: send success rate, the top failure reasons, and the count of items not yet retried. Keep technical detail in the background and surface only where the problem is right now. That alone lets a team without a resident engineer keep improving.
Launch and Operations Checklist
In short: guard the door, don't count twice, make results visible, and keep secrets inside. Those four are the floor for this step.
Improve in Small Cycles
Check the send success rate weekly and work only on the top two failure reasons. After a fix, resend and confirm the difference, then fold whatever actually worked into the standard procedure. Once that cycle runs smoothly, widen the check to monthly and lower the operating load. Building something you can iterate on beats aiming for perfect analysis on day one.
Summary
Trigger on the payment-complete notification and send purchases to GA4 from the server. With that shape, what happened on the user's screen no longer matters — you count only confirmed payments. The essentials are verifying the sender, deduplicating by order, deciding how to handle missing identifiers, and managing by success rather than by attempts.
Across these three articles, the pattern has been the same: find where the thread breaks, park the information before it breaks, and resend from a confirmed fact. Even with an AI agent handling the specialized implementation work, measurement stays stable as long as people hold the decision about what counts as the correct number.