Meta Pixel CAPI deduplication depends on browser and server events describing the same action with matching identity. For headless WooCommerce, the event path matters as much as the tag configuration.
Identify who owns each event
List each event, its trigger and its sender. Include the headless storefront, tag manager, WooCommerce plugins and backend jobs. For each business action, nominate one logical owner. Two integrations should not independently decide that a purchase has happened without a shared identity and a documented reason.
Use a table in the implementation notes with columns for event name, browser trigger, server trigger, unique key and consent rule. This makes overlapping responsibilities easier to spot than comparing dashboard totals alone.
Match the event name and event ID
Meta documents deduplication using matching event names and event IDs for corresponding browser and server events. Treat that ID as the identity of the business event, rather than a new random value created by each transport.
For a purchase, derive or persist a stable reference associated with the order and use it consistently. Keep it free of personal information. A reload, repeated webhook or retry must not silently turn the same purchase into a new event identity.
Use authoritative order data
The backend order record should determine whether the purchase condition is met and what value and currency are sent. Do not trust a query string or a client-provided total as the final commercial record. Define how failed, pending, cancelled and paid orders should behave before wiring the sender.
Separate analytics delivery from the checkout’s critical path. A provider timeout should not prevent an otherwise valid order from completing. Queueing and retries need a visible failure state and an idempotent way to resume delivery.
Review single-page application behaviour
A headless storefront can change routes without a full page load. Check whether tracking listeners are attached once, whether they clean up correctly and whether route changes create duplicate page events. A thank-you page revisit is a navigation event, not automatically a new purchase.
Test checkout in a clean session and in a returning session. Include browser Back and Forward, a hard refresh on the confirmation page and a retry of the backend notification. Record the expected event identity for each scenario before running it.
Consent and credentials need their own checks
Server-side delivery does not remove the site’s consent and data-handling obligations. Apply the agreed rules consistently across both paths and send only the approved fields. Keep access tokens on the server and redact them from logs, screenshots and support exports.
Verify the event path, not only the total
Use Meta’s testing tools to inspect corresponding browser and server events. Check names, IDs, timestamps, value, currency and the source of each delivery. Compare the path against a known test order, then investigate discrepancies before enabling wider traffic.
Keep a short QA matrix for a successful order, a failed payment, a refreshed confirmation page, a repeated server delivery and withheld consent. The goal is a traceable relationship between a real action and its recorded events; a dashboard total alone cannot establish that.
References and next steps
See Meta’s browser and server event deduplication guidance and Test Events guidance. For an existing store, a WooCommerce technical review can map the current senders before changes are made. Custom delivery work belongs in a maintainable plugin or API integration.
