TL;DR
GA4's checkout funnel uses four events, and the Magento extension sends all four. What each step means depends on which side sends it. From the browser, add_payment_info is written on the order confirmation page, so the Add shipping to Add payment drop holds the entire Review & Payments step. From the server, it is sent when the order is created, which turns Add payment to Purchase into a list of orders that never got confirmed. Pick the sender first, then build and read.
Key Takeaways
- Decide per step whether the browser or the Measurement Protocol sends it, and only one of them; the guide's
Automatically disable data layer for enabled measurement protocol eventsoption enforces that [1]. - With the browser sender, add_payment_info reaches GA4 on the confirmation page just ahead of the purchase, so declined cards and Review & Payments exits all show up between Add shipping and Add payment.
- With PRO's server sender, add_payment_info goes out when Magento creates the order, and Add payment to Purchase becomes the orders that never reached the confirmation page.
- Use "indirectly followed by" between steps. "Directly followed by" means the next step "must occur immediately after the previous step" [2], and Magento sends other events in between.
- Virtual and downloadable carts skip the shipping step [5], so their buyers fall out at Add shipping in any funnel that requires it.
- Before Black Friday, save a baseline range and compare the funnel's Purchase users with total purchasers; admin orders never enter a closed funnel.
Pick the sender for each step first
Both editions send the four checkout events from the browser through the GTM container. PRO can also send Begin Checkout, Add Shipping Info, Add Payment Info and Purchase through the Measurement Protocol, from the Track Events list in the Measurement Protocol configuration [1]; the Standard vs PRO comparison covers the tiers.
The guide's rule is blunt: "make sure that you only track events on one side or another" [1]. Switch on Automatically disable data layer for enabled measurement protocol events and the extension stops pushing the browser copy of every event you selected for the server, so "even existing GTM tags will not fire" for them [1]. If you pause the duplicated client tags by hand instead, leave the one the guide labels WP - GA4 running, because it "is required for tracking sessions, page views and other important user metrics" [1].
The choice matters more for one step than for the other three. The payment step changes meaning with its sender, which the next two sections spell out. A server-sent step also has to land on the same user as the browser steps before it. The extension's server checkout events carry the browser's GA client ID and session ID, read from the GA cookies when they are present, and Google's Measurement Protocol guide says the client_id "should match the ID generated by the Google Analytics tag on your website" [4]. When that join breaks, the causes are the ones our article on purchases landing as Unassigned works through.
What each step records on Magento's default checkout
The events reference defines each event. This table is about the moment each one is recorded on the default two-step checkout, which is what a funnel actually measures:
| Step | Browser copy (both editions) | Server copy (PRO) |
|---|---|---|
begin_checkout |
When the checkout page loads | When the checkout page renders |
add_shipping_info |
When the shopper submits the shipping step, which saves address and shipping method together, guest or signed in | At the same moment |
add_payment_info |
On the order confirmation page, just ahead of the purchase, after Magento has placed the order | When Magento creates the order, before any redirect to a payment gateway |
purchase |
On the order confirmation page | On the confirmation page, where v1.12.1 (May 30, 2023) moved it [1] |
A page reload repeats begin_checkout. That doesn't inflate anything, because a funnel counts users and "a user can only enter the funnel once" [2].
How do you build the GA4 checkout funnel so real orders don't fall out?
Google's shortcut starts from the built-in report: open Checkout journey, click Add comparison, then Explore in the "Edit comparisons" dialog, and GA4 opens an exploration holding the report's four steps [3]. The long way is Explore > Funnel exploration template [2]. Either way, set it up like this:
- Keep it closed. In a closed funnel "users must enter the funnel in the first step" [2], which is the checkout question you're asking.
- Join every step with "indirectly followed by". Between the shipping submit and the confirmation the browser sends other events, the confirmation page's own page view among them. A directly followed step drops buyers who did nothing wrong.
Then decide about virtual goods. Adobe's checkout turns into a one-step procedure when the cart holds only virtual or downloadable products, "because shipping information is not required" [5]. No shipping step means no add_shipping_info, and Google says "If the user misses a step, they fall out of the funnel and aren't counted in any subsequent steps" [2]. If you sell gift cards, licenses or downloads, build a second exploration without the shipping step.
Where did they drop between Add shipping and Add payment?
Google's help text for the Checkout journey report gives an example: a large drop between Add shipping and Add payment might point to "high shipping costs or requiring users to login without an option to checkout as a guest" [3]. On Magento with the browser sender, that reading misses most of what the gap contains.
The browser copy of add_payment_info is built after Magento has placed the order and only reaches GA4 on the confirmation page. Everything that happens on Review & Payments therefore sits in this gap: shoppers who leave after seeing the final total, shoppers who try a coupon there and walk away (Adobe puts coupon entry in this step [6]), declined cards, and shoppers who leave at a redirect gateway and never come back. A declined card never places an order, so it never produces the event. On the browser sender, this gap is your whole payment step.
Add payment to Purchase then sits close to zero by construction. What separates the two is purchases the browser was told not to send: orders caught by Exclude Orders By Status (PRO) or Exclude Orders with 0 Value [1], or a purchase moved to the server that didn't join the shopper's browser identity.
Check your version before you trust old comparisons. v1.12.1 (May 30, 2023) and v1.12.5 (July 5, 2023) both fixed cases where the browser add_payment_info didn't fire because the redirect to the success page happened too fast [1]. A year-over-year read that starts on a build older than July 2023 compares against an undercounted payment step.
What does Add payment to Purchase mean on the server sender?
Move add_payment_info to the Measurement Protocol and the step moves earlier: it goes out when Magento creates the order, before any gateway redirect. The server purchase still waits for the confirmation page [1]. The gap between them is orders Magento created that the shopper never confirmed: redirect payments abandoned at the gateway, payments that fail after the order exists, and orders in an excluded status, which a cron job sends once they leave that status, as our article on GA4 and Magento sales report differences explains.
Here's the criterion for choosing:
| You want to know | Send add_payment_info from |
|---|---|
| Of the shoppers who submitted shipping, how many finished | The browser |
| How many orders Magento created that the shopper never confirmed | The server (PRO) |
One cleanup if you read item counts per step on the server sender: v1.17.4 fixed zero-priced configurable child items that were "duplicated in the server-side purchase and add_payment_info events, inflating item counts" [1]. After upgrading, compare item-level steps only from the date v1.17.4 went in.
Set the baseline before Black Friday
Save the funnel with a date range from a normal October week now, so peak traffic has something to be compared with. Switch the visualization to a trended funnel during the sale to watch each step's rate day by day [2]. The change-freeze timing belongs to the September checklist; build the funnel before your freeze starts.
Then compare the funnel's Purchase users with total purchasers for the same range. The Checkout journey report "is a closed funnel; it includes only users who began at the first step" [3], so buyers with no begin_checkout never appear in it. Orders created in the Magento admin are the clearest case: since v1.12.5 the extension sends them as server-side purchases, PRO only [1], with no begin_checkout before them. On PRO, with the purchase sent from the server, purchases whose browser events never ran are the other part of the difference. None of that difference is checkout abandonment. Since v1.17.4, with Require Visitor Consent for Server-Side Events switched on, server-sent checkout steps and purchases from shoppers who declined are not sent, so they are missing from the funnel the same way their browser events are, as the server-side consent guide explains.
Last, place one test order with GTM preview connected. On the browser sender, add_payment_info appears on the confirmation page immediately before purchase. On the server sender, turn on Enable File Log and the server copy shows up in var/log/ga4.log at order placement [1]; verifying GA4 events walks through both tools.
FAQ
Does sending a checkout step from both the browser and the server double the funnel?
No. A funnel counts users, and each user enters it once [2]. Sending a step from both sides doubles the event counts, and for purchase the guide warns that "1 transaction will be triggered twice and it will result in duplicate transactions" [1].
Why is there no billing step in the funnel?
Out of the box, Magento's checkout has two steps, Shipping Information and Review and Payment Information [5]. Billing sits inside the second, where the shopper "chooses the payment method, and applies any coupons" [6]. The extension sends a shipping event and a payment event, and no separate billing event.
Where is the built-in Checkout journey report, and can I change its steps?
It sits in the Monetization topic of the Life cycle collection, or the Drive online sales topic of the Business objectives collection. You can't customize it [3]; copy it into an exploration as described above.
What if my funnel is empty from begin_checkout onward?
That pattern usually points to a checkout or success page on a custom path. Fix it first with the custom and one-page checkout guide, then come back to reading drop-off.
Every checkout step in this funnel is sent by the Magento 2 Google Analytics 4 extension, from the browser or, on PRO, from the server. The current release is v1.17.5, September 16, 2026 [1].
Sources
- WeltPixel Google Analytics 4 User Guide and Change Log, v1.17.5, September 16, 2026, retrieved October 8, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
- [GA4] Funnel exploration, Analytics Help, retrieved October 8, 2026, https://support.google.com/analytics/answer/9327974?hl=en
- [GA4] Checkout journey report, Analytics Help, retrieved October 8, 2026, https://support.google.com/analytics/answer/14000977?hl=en
- Send Measurement Protocol events to Google Analytics, Google Analytics developer documentation, last updated October 7, 2026, retrieved October 8, 2026, https://developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events
- Customize checkout, Adobe Commerce PHP extensions documentation, retrieved October 8, 2026, https://developer.adobe.com/commerce/php/tutorials/frontend/custom-checkout/
- Checkout process and options, Adobe Commerce Admin User Guide, retrieved October 8, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/point-of-purchase/checkout/checkout-process