Why WooCommerce needs the Conversions API more than most
On WooCommerce, the Meta pixel usually reports a purchase when the order-received page loads. That page is a weak spot. Many payment methods send the buyer to another site to pay: PayPal, iDEAL through a bank app, Klarna, or a hosted card page. If the buyer pays and closes the tab instead of waiting for the redirect back, the pixel never fires.
Page caching and optimization plugins add to it. Script delay or combine settings can hold back or break the pixel, and a cached order-received page can even fire for the wrong order. The Facebook Conversions API avoids all of that by sending the purchase from the server, based on the order itself.
Which WooCommerce order statuses should count
This is where WooCommerce setups often go wrong. A new order can be Pending payment, On hold, Processing or Completed. Only paid orders should reach Meta as a Purchase. Otherwise Meta optimizes towards people who start a bank transfer and never pay.
- Processing or Completed after a successful online payment: send it.
- On hold for bank transfer or cash on delivery: wait until it's actually paid.
- Pending payment or Failed: don't send it.
- Refunds and cancellations: they shouldn't create a new Purchase.
What Meta needs from a WooCommerce order
To match a server purchase to an ad, Meta needs more than the billing email. The useful set is the fbc click id (from the fbclid on the landing URL), the fbp browser id from the _fbp cookie, hashed email and phone, the IP address and user agent of the visit, and the order value and currency.
The click details belong to the visit, not to the order. If your plugin only reads the order at payment time, it has to have saved those details earlier, when the visitor first landed. Settl's plugin saves them on landing and keeps them for 90 days.
Avoid the duplicate-plugin trap
Many WooCommerce stores end up with two or three tracking sources at once: Meta's own Facebook for WooCommerce plugin, a pixel plugin like PixelYourSite, and a snippet a developer pasted into the theme years ago. Each one may send its own Purchase event with its own id.
Meta can only deduplicate events that share an event name and event id. Different plugins don't share ids, so you get two or three purchases for one order. Before adding anything, check what's already sending events and keep one source per pixel.
Facebook Conversions API on WooCommerce: what to look for in a plugin
There are plenty of WordPress plugins that claim Conversions API support. Before you pick one, check how it handles the things that matter on WooCommerce specifically.
- Does it send the purchase from a server hook when the order is paid, or only from JavaScript on the order-received page? Only the first survives a closed tab.
- Does it save the fbclid when the visitor lands, or only look for it at checkout? Visitors often land on a product page days before they buy.
- Does it share one event id between the browser pixel and the server event?
- Does it respect order status, so bank transfers and cash on delivery count only when paid?
- Does it retry when Meta's API returns an error, and can you see per order whether the send worked?
- Does it keep working with your caching and optimization plugins without special exclusions?
How to test it in Events Manager
In Meta Events Manager, open your dataset and the Test Events tab. Copy the test code into your tracking setup, place a real test order with a payment method that leaves the site, and close the tab right after paying. The Purchase should still arrive, marked as a server event.
Then remove the test code and check the Overview over the next days. Purchase should be received from Browser and Server, with deduplication working and an Event Match Quality score shown. The Diagnostics tab lists missing parameters or duplicate warnings.