How to Keep Amazon and eBay Orders Imported Into Magento 2 Out of GA4 and Your Ad Platforms

|Dan Giura
How to Keep Amazon and eBay Orders Imported Into Magento 2 Out of GA4 and Your Ad Platforms

TL;DR

A marketplace connector creates ordinary Magento orders, and GA4 PRO's cron sends every order the extension hasn't sent yet, whoever created it. So an Amazon or eBay sale reaches GA4 as a purchase with no session behind it, and each enabled Conversions API addon sends it as a purchase, which Meta's addon labels as made on your website. Put imported orders in a store view of their own, switch the addons off there, and send that store view's GA4 purchases to a separate property. Excluding order statuses also works, under two conditions that are easy to miss.

Key Takeaways

  • Set the connector to create imported orders in one dedicated store view; the connector's Amazon and eBay import settings offer "Choose Store View Manually" [3] [4].
  • At that store view, set Enable Meta Pixel Server Side Tracking to No, and the matching switch in each other addon you run [2].
  • In 1.17.5, turning the GA4 Measurement Protocol off at that store view doesn't stop the purchase; give the view its own Measurement ID and API Secret instead [1].
  • Set Send eCommerce Event Data to multiple endpoints to No at the marketplace store view, so its orders aren't copied to your extra properties [1].
  • If you use Exclude Orders By Status instead, exclude every status the orders reach, Complete included, and switch it on only at the marketplace store view; an excluded status only delays the purchase [1] [3].
  • Credit memos on marketplace orders follow the store view's Measurement ID, so refunds land in the same property as their purchases [1].
  • Filter the order grid's Sent to Measurement Protocol column by the marketplace store view after the next import [1].

One imported Amazon order, followed through the extension

A connector such as M2E Pro "automatically creates a Magento Order and updates its status based on your settings" [5]. That order goes through Magento's normal order placement, so the GA4 extension can't tell it apart from a storefront sale. Nothing in the extension looks at which channel an order came from.

The extension's purchase normally fires from the success page. Orders the success page didn't send go out later through the cron the changelog calls Cron Push, which since v1.15.7 (September 2, 2025) reuses the payload stored from the frontend purchase event when one exists [1]. A marketplace order never had a success page, so the cron treats it as a missed one and sends it within minutes of import.

Destination Does it receive the marketplace order? What arrives
GA4, server-side purchase (PRO) Yes, by default A purchase with no browser session behind it
Each enabled Conversions API addon Yes, if the addon is on for that store view A purchase; Meta's addon labels it as made on your website
GTM browser tags, client-side pixels, the Google Ads tag on the success page No Nothing; no browser ever loaded a page for this order

The GA4 row lands in Unassigned. The purchase reaches GA4 from your server with no session source, one of the causes in why server-side purchases land in Unassigned, and for a marketplace sale there's no session to recover. GA4's revenue total moves closer to Magento's, which hides the problem, while your storefront conversion rate now counts sales that had no storefront visit. If you've filtered GA4 to Unassigned in a week Amazon ran a promotion and found it full of purchases, this is a likely source.

The addon row matters for a different reason. Meta's Conversions API describes action_source as the field that "allows you to specify where your conversions occurred", defines website as "Conversion was made on your website", and adds: "By using the Conversions API, you agree that the action_source parameter is accurate to the best of your knowledge" [6]. An Amazon sale sent through the addon carries website.

Does your Magento Amazon integration put orders in their own store view?

Check the connector first, because every fix below works per store view. Its Amazon order settings ask which store view the Magento order is created in: "Use Store View From the Listing" ("Magento order will be created for the same Store View as it is provided in Listing Settings") or "Choose Store View Manually" [3]. Items you listed with other software get a separate store view field. Fulfilled by Amazon orders have their own "Create in separate Store View" option, which decides "whether Magento Orders for corresponding Amazon FBA Orders have to be created in a separate Store View" [3]. The eBay import page offers the same pair, written "Use Store View from the Listing" with a lowercase "from" [4].

If your listings sit in your main store view and the connector follows the listing, every marketplace order lands in the same store view as your web orders, and no store-view setting below can separate them.

  1. Create a store view for imported orders: Stores > Settings > All Stores > Create Store View [7]. Adobe notes its name "appears in the language chooser in the store header" [7], so name it for shoppers who might see it.
  2. In the connector's Amazon and eBay order settings, choose that store view manually, for listed items, for items listed elsewhere, and for FBA orders.
  3. Import a test order and open it in the Magento admin to confirm it shows the new store view.

Other connectors may name the setting differently; look for where imported orders get their store view.

Switch the Conversions API addons off at the marketplace store view

Each server-side addon checks its own enable switch for the order's store view, at the time the order is saved and again before it sends. So No at the marketplace store view keeps that addon's purchase from being queued for those orders at all.

In Magento's configuration, switch the scope to the marketplace store view, clear the inherit box on the addon's enable field, and set it to No. For Meta the field is Enable Meta Pixel Server Side Tracking [2]; TikTok, Snapchat, Pinterest and the other addons each carry their own equivalent switch, and each one needs it.

Your storefront store views keep sending as before. The Meta Conversions API server-side setup for those views doesn't change.

Why doesn't GA4's switch at that store view stop the purchase?

In version 1.17.5 the GA4 purchase follows the store view's Measurement ID, not that store view's on/off switch. Setting Enable Measurement Protocol Tracking Configuration to No at the marketplace store view, or removing Purchase from Track Events there, leaves those orders flowing to whichever property the store view inherits, which is usually your main one. Don't use it as the fix for GA4.

What does work is giving the store view a different destination:

  1. In GA4, create a property for marketplace orders and an API secret for its web stream [1].
  2. In Admin > WeltPixel > GA4 PRO, switch the scope to the marketplace store view and override Measurement ID and API Secret with the new property's values [1]. The override works as in mapping Magento 2 store views to GA4 properties.
  3. At the same scope, set Send eCommerce Event Data to multiple endpoints to No if your default scope uses it, so marketplace purchases aren't also copied to the extra properties listed there [1].

The orders still go out, get marked as sent, and land in a property you can read when you want marketplace revenue in GA4. Your main property stops receiving marketplace orders. Refunds follow too: since v1.15.7 a refund is sent from the store view the credit memo belongs to, where earlier builds sent every refund from the Default store [1].

The Measurement Protocol is a PRO feature, so a GA4 Standard store has no server-side purchase for the cron to send.

Status exclusion, the route the changelog names

The extension's own changelog pitched status exclusion for this case. The v1.12.7 entry (July 26, 2023) says it "is especially useful when importing orders with custom statuses into Magento 2 and you don't want to send them to Google Analytics" [1]. It works, with conditions.

An excluded status holds the purchase back without dropping it. Since v1.14.13 (February 17, 2025) "a cron that picks up unsent orders and sends them if they move into a status that is not excluded" covers GA4 and the server-side addons [1], and our GA4 vs Magento sales report reconciliation explains the timing gap that creates. By default the connector moves orders along: "once the order is "Shipped" on Amazon, its status in Magento will change to "Complete"" [3], and the eBay page says the same [4]. Exclude the statuses a fresh import gets but not Complete, and every marketplace order reaches GA4 on the day it ships, dated the day it arrives.

So the status route needs every status those orders can reach, Complete included, excluded, with Exclude Orders By Status set to Yes at the marketplace store view only. The status list itself is set at website or default scope, so it only stays out of your storefront orders where that switch stays No.

The refund is where this route really costs you. Marketplace orders get credit memos, and the connector can "automatically create Magento Credit Memos" when paid orders are canceled on Amazon [8]. The extension sends a refund event from each credit memo while Refund is in Track Events, and it doesn't check whether GA4 ever got the purchase. With status exclusion, those refunds subtract marketplace revenue from a property that never received the sale. If you refund marketplace orders through Magento, use the separate property.

Since v1.17.4, with Require Visitor Consent for Server-Side Events switched on (it's disabled by default), the extension gates the GA4 Measurement Protocol and every Conversions API addon on the Consent Mode v2 choice stored with the order [1], as our guide to server-side events and consent on Magento 2 explains. It's a consent control, so don't rely on it to sort imported orders.

How do you confirm the next import stayed out?

The order grid already records what was sent. Since v1.15.5 (July 29, 2025) the grid has a column marking orders sent through the Measurement Protocol, and since v1.16.0 (January 7, 2026) you can filter by it [1]. It's the same column the order grid and log checks start from.

  1. After the next import, open Sales > Orders and filter by the marketplace store view.
  2. Add the Sent to Measurement Protocol column. With a separate property, the new orders read Yes and show up in that property, never in your main one. With status exclusion, they read No until they ship.
  3. In Meta Events Manager, compare the day's Purchase count with your storefront order count for the same day; marketplace orders should no longer add to it.

FAQ

Will marketplace orders already sent to GA4 disappear after the change?

No. The new store view and property apply to orders imported after you save them, and purchases the extension already sent stay in the reports where they landed.

Can I just turn off GA4 server-side tracking at the marketplace store view?

Not in 1.17.5: the purchase still goes to the property that store view inherits. Override the store view's Measurement ID and API Secret with a separate property instead [1].

Do FBA orders need the same store view?

They need a non-storefront one. The connector's Amazon settings offer "Create in separate Store View" for FBA orders [3]; point it at the marketplace store view or a second one set up the same way.

Route imported orders to their own store view and property with the Magento 2 Google Analytics 4 extension, so your main GA4 property and your ad platforms learn only from storefront sales.

Sources

  1. WeltPixel Google Analytics 4 User Guide and Change Log (Measurement Protocol Tracking Configuration; General configuration; change log v1.12.7 to v1.17.5), retrieved October 20, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
  2. Meta Pixel Conversions API Addon for Google Analytics 4 PRO User Guide (Meta Pixel Server Side Tracking configuration), retrieved October 20, 2026, https://docs.weltpixel.com/MetaPixelAddon/User-Guide-WeltPixel-Meta-Pixel-Addon.html
  3. Amazon Orders, M2E Pro documentation, last updated 2025-10-22, retrieved October 20, 2026, https://docs-m2.m2epro.com/docs/orders/
  4. eBay Order Import, M2E Pro documentation, last updated 2026-04-13, retrieved October 20, 2026, https://docs-m2.m2epro.com/docs/help-m2-ebay-integration-configuration-account-set-up-order-import/
  5. Overview of Amazon Sales and Orders, M2E Pro documentation, last updated 2025-10-23, retrieved October 20, 2026, https://docs-m2.m2epro.com/docs/sales-orders/
  6. Server Event Parameters, Conversions API, Meta for Developers, retrieved October 20, 2026, https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/server-event
  7. Store views, Adobe Commerce Admin documentation, last updated October 8, 2026, retrieved October 20, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/site-store/store-views
  8. Orders Cancellation & Refund, M2E Pro documentation, last updated 2025-10-23, retrieved October 20, 2026, https://docs-m2.m2epro.com/docs/help-m2-amazon-integration-sales-orders-orders-cancellation-refund/

Ready to upgrade your tracking?

Server-side tracking for Magento and Shopify — accurate data, better attribution, full privacy compliance.