Server-side events · Setup reference
Meta Conversions API via the Meta for WooCommerce (Facebook for WooCommerce) plugin checker
Meta's official WooCommerce plugin (Facebook for WooCommerce) injects the Meta pixel and also sends Conversions API events from your WordPress server. Each event gets a generated UUID event_id, which is reused on the pixel and server sides for dedup, and the plugin normalises and SHA-256 hashes customer data itself. Problems usually come from a second pixel plugin or theme snippet, or from a consent plugin holding signals.
Read from the official documentation on 9 November 2026. Sources are listed at the end.
Check your own setup
Useful when you capture a server payload, for example by logging the plugin's request. The checker verifies fbc/fbp format, that event_time is within 7 days, action_source, that customer fields are hashed, that event_id is present, and value/currency on Purchase. It does not inspect your WordPress install, so it will not find a second pixel plugin or consent holds. Paste your thank-you page source into conversion-tag-checker to spot an extra Meta pixel Purchase call.
Open the Meta CAPI Event CheckerEndpoint and authentication
POST https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events
Plugin connects to Meta through its onboarding flow (Marketing/Facebook settings in WP admin); token handled by the plugin.
Standard event names
Spelled exactly as WooCommerce + Meta expects them. A near miss is treated as a different event.
| Event | Use it for |
|---|---|
| PageView | page loads |
| ViewContent | product page |
| ViewCategory | product category page (custom event name used by the plugin) |
| Search | product search |
| AddToCart | event_id stored in the WooCommerce session so pixel and server share it |
| InitiateCheckout | fired on the checkout form (classic and block checkout hooks) |
| Purchase | hooked to order creation and the woocommerce_thankyou hook; the plugin stores per-order browser/server 'purchase tracked' flags to avoid re-sending |
| Subscribe | orders that contain a WooCommerce Subscriptions subscription (needs the Subscriptions extension) |
| Lead | form submissions such as Contact Form 7 |
Required and recommended fields
| Field | What it needs |
|---|---|
| action_source | plugin default 'website' ('physical_store' for offline/in-store orders) |
| event_time | plugin default: current server time() |
| event_id | plugin-generated UUIDv4 per event |
| event_source_url | current URL; dropped for physical_store events |
| user_data | normalised then hashed by the plugin |
Match keys and hashing
| Key | Normalise and hash |
|---|---|
| em, fn, ln, ph, ct, st, zp, country, external_id | The plugin normalises these, then hashes them with SHA-256 before sending. Do not pre-hash them yourself. |
| Advanced Matching (enable_advanced_matching / use_pii setting) | Plugin setting that controls whether customer data is attached to pixel events. |
Click ids
| Click id | Where it comes from |
|---|---|
| fbc | The plugin reads the _fbc cookie, or builds fb.1.<creation_time>.<fbclid> from a ?fbclid= on the request when the cookie is missing or the fbclid changed. |
| fbp | The _fbp browser cookie. Meta's format is fb.${subdomain_index}.${creation_time}.${random_number}. |
Deduplication
- Meta treats a pixel event and a Conversions API event as the same when the pixel eventID equals the server event_id AND the pixel event name equals the server event_name.
- Pixel syntax: eventID is the 4th fbq argument, e.g. fbq('track', 'Purchase', {value: 12, currency: 'USD'}, {eventID: 'EVENT_ID'}).
- Duplicates sent to the same pixel ID are discarded only if they arrive within 48 hours of the first one; Meta generally keeps the event received first.
- Plugin behaviour: one UUID event_id is generated per event and passed to both the fbq call and the server event. AddToCart's id is kept in the WooCommerce session so a later page load reuses it.
Time limits and batch sizes
- event_time is a Unix timestamp in seconds (GMT) for when the event actually happened.
- event_time can be at most 7 days before the send time; if any event in a request is older, the whole request errors and no events are processed.
How to test before you trust it
- Meta Test Events (Events Manager): Events Manager > Data Sources > your pixel > Test Events generates a test ID; send it as test_event_code and remove it before production (events with it are still processed).
- Events Manager connection method: In the pixel's Overview, check each event is received from both Browser and Server and that deduplication shows for overlapping events.
Why events arrive but don't attribute
- A second Meta pixel from another plugin (pixel manager, GTM, theme header) sends its own Purchase without the plugin's event_id, so it double counts.
- Hold/Release Signals with a consent plugin (Meta publishes CookieYes and Complianz guides): until the visitor allows the Advertisement category, signal delivery stays 'held', so missing events can be consent working as designed.
- Pre-hashing customer data before it reaches the plugin double-hashes it: the plugin always applies SHA-256 to em, fn, ln, ph, ct, st, zp, country and external_id.
- Advanced Matching is its own setting (enable_advanced_matching / use_pii); check it is on if you expect customer data on pixel events.
- Renewal orders: the plugin clears the copied event_id and 'purchase tracked' flags on subscription renewals, so renewals are separate events. Do not expect them to deduplicate against the original order.
Sources
- WordPress.org: Meta for WooCommerce plugin (official, by Meta)
- GitHub facebook/facebook-for-woocommerce: Events/Event.php and events tracker (official source)
- GitHub facebook/facebook-for-woocommerce: Hold/Release Signals with CookieYes
- Meta for Developers: Handling duplicate pixel and Conversions API events
- Meta for Developers: Server event parameters
Platforms change these rules without notice. If a source says something different from this page, the source wins.