An accelerated checkout (Shop Pay, Mercado Pago Express, PayPal Express) takes the buyer straight to an external payment gateway without going through your site's checkout pages. Your browser pixel can't fire the purchase event because that event happens on a domain you don't control. The sale is recorded in your store, but Meta doesn't receive the buyer's email, phone or name. You don't lose the sale — you lose the data on who bought.
What is an accelerated checkout and why do platforms use it?
Accelerated checkouts are quick-buy buttons that skip your store's form steps. The buyer clicks "Pay with Mercado Pago" or "Pay with Shop Pay" and completes the transaction inside that platform's environment, which already has their shipping and payment details saved. The promise for the buyer is less friction. For the seller, more conversions at that step.
The problem is where the purchase confirmation event happens. In a normal checkout on your domain, your Meta pixel fires a Purchase event with the buyer's email, name and phone number on the thank-you page. In an accelerated checkout, that confirmation page lives on the gateway's domain — and your pixel code isn't there.
Which accelerated checkouts are most used in LATAM e-commerce?
| Accelerated checkout | Does the browser pixel reach the confirmation? | Platforms |
|---|---|---|
| Mercado Pago Express | No — redirects to mp.com.ar | Tiendanube, Shopify |
| Shop Pay (Shopify) | Partially — depends on configuration | Shopify |
| PayPal Express Checkout | No — redirects to paypal.com | Shopify, WooCommerce |
| Your store's native checkout | Yes — stays on your domain | Tiendanube, Shopify |
Mercado Pago Express is the most critical case for Argentine stores: it's the default payment method on Tiendanube for many users, and its flow redirects the buyer off your domain to complete the payment. If you don't have server-side tracking, everything that happens after that click is a blind spot for Meta.
What data exactly does Meta lose with an accelerated checkout?
When the browser pixel can't fire the Purchase event, Meta picks up the sale by inference — it sees it as a conversion without the matching parameters it needs to identify the buyer. The data that gets lost:
- Buyer's email — the most important parameter for matching to Facebook and Instagram accounts.
- Phone number — the second parameter in matching power.
- First and last name — improves precision when combined with other parameters.
- City, province and postal code — useful for geographic targeting and local lookalikes.
- Purchase value and items bought — without this, Meta can't optimize for purchase value.
The direct impact is on EMQ (Event Match Quality): the score Meta gives to the data quality of each event. Without matching parameters, EMQ drops to 2–3 out of 10. With all parameters sent from the server, it can rise to 8–9. The difference isn't cosmetic — it's your lookalike audiences and the cost of your campaigns. To understand what EMQ is and how it's calculated, read What Meta's EMQ is and why it determines the cost of your ads.
The impact on your campaigns: worse lookalikes, higher CPA
Meta builds your lookalike audiences from the people who bought in your store. If half of those conversions arrive without identification data, Meta builds lookalikes based on half your real buyers. The lookalikes are less precise, targeting deteriorates and CPA rises — without any metric in your Meta dashboard telling you why.
The number you see in Meta is the sale. The number Meta doesn't see is who bought. They're two different things, and the second matters more for optimization.
What's the fix for the accelerated checkout problem?
The fix is server-side tracking: instead of relying on the browser pixel (which can't fire off your domain), you send the purchase event straight from your server to Meta through the Conversions API (CAPI). The flow: the buyer confirms the purchase in Mercado Pago, your server receives the sale notification, and from there sends the event to Meta with all the buyer's data — email, phone, name, address.
This approach doesn't depend on the domain where checkout happens because it doesn't use the user's browser. The event goes straight from your server to Meta. To understand how CAPI works, read Meta's Conversions API explained simply: what it is and how to set it up.
Doesn't Tiendanube solve this with its native CAPI?
Tiendanube turned on Meta's Conversions API in 2024, but with an important limitation: it only sends three events (Add to cart, Add payment info and Purchase) and doesn't send the buyer's email or phone. EMQ with Tiendanube's native integration usually lands between 4 and 5 out of 10 — better than nothing, but not enough to build good audiences. To understand what the native integration does and doesn't do, read Tiendanube's Conversions API: what it sends and doesn't send to Meta.
How does the Escalafy Pixel solve data loss in accelerated checkouts?
The Escalafy Pixel runs on the server, not in the browser. When your store confirms a sale — whether the payment came from Mercado Pago Express, PayPal or the native checkout — Escalafy reads the buyer's data from the Tiendanube or Shopify backend and sends it to Meta through the Conversions API. The event arrives with email, phone, name and address. Your EMQ goes up. Your lookalikes get better.
Unlike other tracking solutions, Escalafy also knows the real cost of each order — the product, shipping, fees, installments. That means the event it sends to Meta carries not just the buyer's data but also the real profit behind that conversion, not just the GMV. See how it works in Escalafy server-side pixel.
Frequently asked questions about accelerated checkouts and the Meta pixel
If I turn off the accelerated checkout, is the problem solved?
Partly. If the buyer goes through your store's native checkout and the thank-you page is on your domain, the browser pixel can fire. But you lose the conversion rate those quick-pay buttons deliver — many buyers prefer them because their details are already saved. The right fix isn't removing the accelerated checkout but adding server-side tracking on top of the browser pixel.
Does server-side tracking create duplicate events?
If you have both the browser pixel and server-side tracking sending the same event, Meta can receive it twice. That's why server-side events carry an event_id field that Meta uses to deduplicate: if it receives two events with the same ID, it counts only one. Read more in Event deduplication in Meta Ads: how to avoid double counting.
How much data am I losing to accelerated checkouts right now?
You can estimate it by checking your EMQ in Meta's Events Manager. If it's below 6 and you use Mercado Pago Express as your main payment method, a significant part of that loss comes from there. An analysis of 42 stores in Argentina showed that average EMQ without server-side tracking was 4.2 out of 10.
Does this also apply to purchases from the Mercado Libre app?
Not directly — sales on Mercado Libre are a separate channel with its own tracking ecosystem. The accelerated checkout problem applies to your own store (Tiendanube, Shopify) when you use Mercado Pago as the payment gateway. Meta pixels have no access to the purchase flow inside the Mercado Libre app.
Does the data loss also affect funnel events (ViewContent, AddToCart)?
For events before checkout, the browser pixel keeps working because those events happen on your domain. The problem is specific to the Purchase event when checkout redirects off your site. But that's the most important event for Meta — it's the signal it uses to optimize bidding and build audiences.
Keep reading
What Escalafy does for your store
Connect your channels and see the truth behind your numbers. No Excel, in real time.