Why Is My Meta Pixel Not Tracking Purchases?
Find why Meta Pixel is not tracking purchases by checking the saved order, Purchase trigger, Pixel ID, consent, payload and browser or server delivery.
Your Meta Pixel may not track purchases because the Purchase trigger never runs, it sends to the wrong Pixel ID, consent or browser settings block it, or the checkout does not reach the page your integration expects. Start with one verified order and find the first point where the expected event disappears.
Do not reinstall the plugin or create a new Pixel before locating that point. A working PageView proves only that the base tracking route can run. It does not prove that your checkout supplies Purchase.
If Niwa helps shoppers reach checkout, keep the same distinction: useful product assistance is a customer workflow, while your commerce integration must measure the saved order correctly.
1. Check what happened in the store
Find the order in WooCommerce. Compare the time, status, gateway result, amount and currency with your intended purchase definition.
A customer reaching the payment page is not necessarily a paid order. Cash-on-delivery and bank-transfer flows can also differ from card checkout. Check what your integration defines as the moment of purchase rather than assuming every gateway uses the same state.
Choose a test order with an unambiguous result. If there is no successful order under your definition, investigate checkout first. Tracking should not manufacture a purchase that the store did not accept.
2. Confirm the correct destination
Inspect the Pixel ID in the browser diagnostic tool and compare it with Events Manager and the integration's saved configuration.
Also check the live domain. A staging site, cached header or older tag-manager version can send events to a different source. Being signed in to an advertising account does not mean you are viewing the intended website source.
If you have server delivery, confirm that its destination matches the intended browser destination. Changing the browser setting alone does not necessarily change an existing server connection.
3. Watch the actual success trigger
Complete your controlled checkout with browser diagnostics and network inspection open. Look for Purchase after the order is accepted.
If PageView appears but Purchase never runs, inspect the trigger owner. A manually pasted base code has no automatic WooCommerce order logic. A commerce plugin needs to support your checkout and gateway path.
An off-site payment flow may complete while the customer does not return to the website. If browser tracking depends on that return, it can miss that outcome. A correctly implemented server-side integration may report eligible orders independently, but you must verify its order trigger and privacy setup.
If your tag fires only on a URL pattern, check the actual confirmation URL. Do not broaden a rule so far that it counts checkout visits or recalculation requests as purchases.
4. Inspect permitted loading and delivery
A visitor who declines advertising tracking may not produce a browser event. An ad blocker or browser restriction can also prevent it. That is different from a broken success trigger.
For a controlled permitted test, use a browser without blocking extensions and provide the appropriate consent. Then repeat with advertising consent declined to verify the site honors that choice.
Inspect console errors and blocked requests. If optimization settings delay or alter tracking scripts, test the specific suspected setting in a safe environment. The older WooCommerce documentation notes that caching and optimization can interfere, but that is a troubleshooting possibility, not a diagnosis of every missing Purchase.
Avoid disabling security or consent globally merely to make a dashboard number appear.
5. Verify the purchase payload
If Purchase is present, inspect its value and currency. Meta's event reference lists those parameters for Purchase.
Compare the value with the actual test order and your treatment of tax, shipping and discounts. Check product identifiers when catalog measurement is relevant. Look for malformed values, the wrong currency or missing order context.
If your setup sends both browser and server representations, inspect the shared event identity. Follow the official deduplication guidance instead of generating unrelated IDs in each path.
6. Separate a missing event from a reporting difference
Look for the permitted test event in the matching Events Manager source. An event received there and a purchase attributed in an advertising report answer different questions.
If the event arrives but Ads Manager does not credit it to an ad, investigate attribution and campaign reporting separately. Do not keep reinstalling the website loader after delivery has been demonstrated.
Likewise, all WooCommerce orders do not necessarily appear as Pixel-observed purchases. Consent choices, browser delivery and the selected purchase definition can limit the observed count. A controlled event test is useful evidence; it is not a promise of identical totals.
Keep a precise repair record
Record the verified order, installation owner, event trigger, Pixel ID, consent state and the point of failure. Redact personal details, access tokens and order-access links before sharing logs.
Niwa's WooCommerce tools support product and business operations around the store. They do not replace the need to verify your tracking integration's purchase trigger.
Existing WordPress store owners can use the standalone Niwa plugin. Niwa Business is USD 150 for a custom WordPress website or migration, hosting, maintenance and business-specific AI adaptation. Contact Niwa with your current store workflow if you want customer assistance built around how the store actually sells.
