A Magento shop that sells on Amazon or eBay through M2E (or a similar connector) sees this every week:
- Admin → Sales is busy.
- Yesterday’s net profit includes those orders — it should.
- Attribution says match is soft, or Purchases lag Magento order count.
- Someone pastes the pixel again, or asks for a Magento module, or wants Conversions API to “fix match rate.”
Stop. Marketplace orders never load /checkout/onepage/success. There is no increment id in the DOM, no gclid, no guest thank-you sentence. A browser pixel cannot invent a storefront that did not happen.
That gap is expected. Treating it as a broken install is how teams waste a week and still misread POAS.
Two Magento orders, two jobs
| Channel | In Magento REST / P&L? | Storefront thank-you? | Pixel Purchase? |
|---|---|---|---|
| Your site (Luma / Hyvä / custom checkout) | Yes | Yes, if the page is alive | Yes, after marketing consent + order id |
Amazon / eBay / M2E (m2epro… payment) | Yes | No | Never |
P&L answers: *what did we keep after COGS, shipping, fees and ads?* Marketplace units belong there. They used inventory and often used ads on the marketplace — just not your Google/Meta click on your product page.
Campaign attribution answers: *which storefront click became a Magento order?* That is a Purchase on success plus a click id. M2E never walks that path.
SKU contribution in a honest Magento P&L stays revenue − COGS on the line. Do not allocate marketplace shipping or Amazon fees onto the SKU to “make pixel match.”
Why match rate looks worse than the shop
Most Magento profit tools (and first instincts) do:
`` pixel Purchases ÷ all Magento orders ``
If half of yesterday was Amazon, the ratio is capped at ~50% even when every storefront thank-you fired perfectly. You then “fix” a healthy pixel.
Score attribution only on storefront orders after the pixel went live:
- Exclude marketplace payment methods (M2E codes look like
m2epro…) - Ignore the first Magento ~60-day backfill from before the snippet existed — those orders will never get a Purchase either
- Compare Purchases to storefront orders in the same store timezone, not to Admin “all sales”
Illustrative day (not a customer case):
| Line | Count |
|---|---|
| Magento orders (all channels) | 80 |
| Of which M2E / marketplace | 32 |
| Storefront orders | 48 |
| Pixel Purchases | 46 |
| Naive match (46 / 80) | 58% |
| Honest storefront match (46 / 48) | 96% |
The 58% number is a category error. The two missing storefront Purchases are the only pixel problem — usually a success page without an order id, consent denied on thank-you, or a dead success template. Not Amazon.
What a pixel is allowed to see
A consent-first Magento snippet (one Head paste, no module, no theme JS) can fire:
- PageView on pages the shopper actually opened
- Purchase when success exposes a Magento increment id
- Checkout stages (cart, checkout, payment) on your checkout
It cannot fire Purchase for:
- M2E / marketplace imports
- Admin-created orders
- Phone / EDI orders with no storefront
- The 60-day historical sync
Marketplace demand also does not belong in a consented funnel. Those customers were not in your session. Do not treat funnel success counts as DailyProfit orders — see statistics are not GA sessions and where Magento lost the sale.
Campaign POAS from the pixel stays Beta. It is a cut list for paid storefront traffic. Amazon’s own ads live in Amazon’s UI. Putting them into the same POAS bar as Google Search is another category error.
What not to do
- Do not install a Magento module or Conversions API to “catch” M2E orders. There is no browser, no click id from your landing page, nothing honest to upload as a Google Purchase.
- Do not hide marketplace revenue from the P&L so match looks prettier. You still paid COGS and often fulfilment.
- Do not raise Google budget because Magento order count is up, if the lift is Amazon.
- Do not call the pixel dead because Purchases < all Magento orders.
Do this instead:
- Yesterday’s net on all Magento orders (including marketplace) — how to read Overview
- Pixel health on storefront orders after pixel-live
- Campaign cuts only where Purchase + click id exist
- Marketplace ads and fees as their own cost lines, not as “unattributed Google”
How to check in Magento this week
In Admin, open a “missing Purchase” order and look at payment method. If it is M2E / Amazon / eBay, the pixel did its job by staying silent. If it is Stripe, PayPal, or your checkout method and the shopper saw thank-you, then debug the success page — not the marketplace.
If storefront orders keep landing and Purchases stay at zero for hours, that is a pixel outage (success template, consent, CSP). Marketplace volume is not that signal.
Where Verid fits
Verid pulls every Magento order into DailyProfit. The pixel attributes storefront Purchases only. Marketplace / M2E methods are excluded from match-rate scoring so a healthy snippet is not marked broken. Attribution remains Beta.
You still decide whether Amazon is good business. The job of the number is to stop you “fixing” a pixel that never should have seen those orders.
Try the demo, or start a trial. If Magento sales look fine and cash does not, start with green Magento, red bank.