Magento Success Page Fired PageView — Why There Is Still No Purchase

A familiar Magento pattern:

1. Magento shows a new order in Admin.
2. Your profit tool (or Verid) syncs that order within minutes.
3. Attribution still says Purchases: none yet.
4. Pixel health shows plenty of PageViews — including one on /checkout/onepage/success/.

That is not a sync bug. The storefront loaded the script and sent a browse event. It never sent a Purchase with an order id Magento can match.

What the success page must do

For Magento paid acquisition, a useful Purchase event needs at least:

• An order identifier the backend can match (increment_id like 000000066, or another stable id you sync)
• Ideally the same click ids the shopper arrived with (gclid / gbraid / wbraid / fbclid)

PageView alone proves the snippet is installed. It does not attribute revenue to campaigns.

Why Magento thank-you pages fail quietly

1. Guest checkout has a thinner DOM

Logged-in customers often get a success template with an .order-number link to the order view.

Guests frequently get a short sentence and a bare <span> with the increment id — no .order-number class. Scripts that only query that class never see an id, so they skip Purchase and only leave a PageView.

2. The copy is translated

English success text is easy to scrape: “Your order number is: 000000066.”

Spanish Luma (and most EU stores) says something closer to “Su número de pedido es…”. German uses Bestellnummer, French commande, and so on. A pixel that only looks for the English word “order” will miss the number even when it is sitting in plain sight.

3. Short increment ids get rejected as “not an order”

Early Magento shops still run numbers like 66 or 000000066. Over-aggressive validators that demand six-plus visible digits (and ignore zero-padding / locale copy) drop the match. The shopper sees the order; the pixel does not.

4. Consent gates Purchase but not PageView

Many setups allow a basic PageView while marketing storage is denied, then block conversion events until consent. Result: a healthy PageView count and a permanent zero on Purchases. Check your CMP before rewriting the theme.

5. You looked at the wrong day

Initial Magento sync often pulls ~60 days of history from before the pixel existed. Those orders will never get a matching Purchase. Attribution should only score orders on/after the first real pixel event — anything earlier is expected empty history, not a broken install.

How to verify in five minutes

1. Place a test order (or wait for a real one).
2. Confirm Magento Admin has the increment id.
3. On the success URL, open DevTools → Network and look for a request to your pixel endpoint with event: Purchase and a non-empty orderId.
4. If you only see PageView on /checkout/onepage/success/, the page did not expose an id the script understands.
5. In Magento, check whether the shopper was a guest, and what language the success sentence uses.

Optional hardening in the theme (one line is enough):

``html <div data-verid-order="{{ order.increment_id }}"></div> ``

Or set window.veridOrderId in a success block. Explicit beats scraping.

What “fixed” looks like in Verid

In Attribution you want:

• Pixel installed (PageViews arriving)
• Purchases received with order ids
• Magento orders in range starting to match those Purchases
• Then campaign POAS stops being “spend-only bars”

Docs: Purchase pixel and Attribution. Related: POAS vs ROAS and Magento + Google + Meta in one P&L.

Practical checklist this week

• Reproduce one success page as guest + as logged-in customer
• Confirm the increment id is visible in HTML or via data-verid-order
• Confirm Purchase fires once (not only PageView)
• Ignore pre-pixel backfill orders when judging match rate
• If you run ES/DE/FR/IT storefronts, do not assume an English-only scraper works

Magento already knows the order. Until the thank-you page tells the pixel the same id, every ad dashboard will keep guessing — and your “unattributed” warning will keep telling the truth.