WooCommerce Advanced Purchase Tracking (APT)

Where to find it: PixelYourSite Pro → WooCommerce → Advanced Purchase Tracking card (top of the page). Related settings live further down in the Track Purchases card.

The problem this fixes

The standard WooCommerce Purchase event fires from the browser on the thank-you page. That works for most orders, but not all of them. Common reasons the browser event never fires:

• The visitor never reaches the thank-you page. Off-site payment gateways (Stripe Checkout, PayPal Standard, bank transfer flows) return the visitor to a different URL, or the visitor closes the tab before redirect.
• Full-page caching. A cache plugin serves a cached version of the thank-you page where the inline JS is stale or where the order context is missing.
• JavaScript errors. Another plugin or a theme breaks the page’s JS, and the Purchase tag never executes.
• Slow gateways. The payment returns after the visitor has already left.
• Mobile network drops. The redirect completes server-side but the page request fails on the device.

Every one of these costs you a real conversion in Meta, Google Ads, GA4, TikTok, or Pinterest reports, plus the optimisation those platforms could have done with that data.

Advanced Purchase Tracking fixes the gap by firing the Purchase event from your server through each platform’s Conversion / Events API as soon as the order status changes to one you select. The event arrives even if the visitor never saw the thank-you page.

How it works

When you enable Advanced Purchase Tracking and select an order status (typically Processing or Completed), PYS attaches itself to WooCommerce’s order status hook. The moment WooCommerce transitions an order into that status, PYS fires the Purchase event server-side via:

• Meta Conversions API (when enabled).
• GA4 Measurement Protocol (when enabled).
• TikTok Events API (when enabled).
• Pinterest API (when enabled).

Each event carries the same parameters the browser-side Purchase would have carried (value, currency, contents, customer matching data) and the same event_id so Meta and GA4 can deduplicate against the browser event if both fire.

The “normal” browser/API Purchase event still works for the orders where it does fire. Advanced Purchase Tracking is the safety net underneath, not a replacement.

Requirements:

• Meta: the Conversion API access token in PixelYourSite Pro → Meta (Facebook).
• GA4: the Measurement Protocol API secret in PixelYourSite Pro → Google Analytics.
• TikTok: the Events API access token in PixelYourSite Pro → TikTok.
• Pinterest: the API token in PixelYourSite Pro → Pinterest.

If the token for a platform isn’t configured, the toggle still saves but no events go out.

Fire the Purchase Event for the following order status

A list of every WooCommerce order status on your site. Tick one or more. When the order moves into a ticked status, the server-side Purchase event fires. We recommend using Completed.

You can tick multiple statuses. The fire-once protection prevents duplicate Purchase events if an order transitions through several ticked statuses.

Duplicate tracking is avoided

PixelYourSite never fires APT Purchase events for orders that already fired the default Purchase when the order was placed. The system is simple: When the default Purchase event is fired, the order gets a flag. The plugin will check if the flag exists before triggering APT Purchase events.

Track refunds on Google Analytics

woo_track_refunds_GA (separate toggle below the status picker).

When an order moves to Refunded, PYS fires a refund event to GA4 via Measurement Protocol. GA4 then reduces revenue and conversion counts in reports. Requires the GA4 Measurement Protocol API secret.

This currently sends only to GA4.

Edge cases and things to know

Order ID. The Purchase event carries the WooCommerce order ID. If you have Order ID Prefix configured, the prefixed ID is what reaches the platforms.

Subscription renewals. When WooCommerce Subscriptions is active, PYS also hooks woocommerce_subscription_payment_complete and woocommerce_subscription_status_updated. Renewals fire Purchase events independently of the manual order status flow. See WooCommerce Subscriptions Tracking.

Status transitions that don’t match. If your store uses a custom order status that isn’t in the default list, you can still tick it from the same list (WC custom statuses are surfaced automatically).

Manually-created orders. Orders added in the WooCommerce admin (not through checkout) move to the chosen status the same way, so Advanced Purchase Tracking fires for them too. If you create test orders by hand, expect Purchase events.

Failed payments. Orders that never reach a ticked status (e.g., they stay in Pending payment and get cancelled) do not fire Purchase events. This is the desired behaviour.

AJAX-blocked. PYS explicitly blocks the server-side fire when the order status transition is triggered inside an AJAX checkout request (wp_doing_ajax() or wc-ajax parameter), and from AngellEYE PayPal API requests. The hooks fire from the order lifecycle, not from the visitor’s AJAX call. This is a safety net against double-firing.

POAS / ProfitConversion. When the POAS feature is enabled, the ProfitConversion event fires alongside the server-side Purchase on the same status transition. It has its own fire-once tracking and won’t be blocked by the Purchase deduplication.