Server-side WooCommerce purchase tracking

Server-side purchase tracking means your WordPress site itself sends a Purchase event to PureMetrix when the order confirmation page appears—instead of relying only on the visitor’s browser.

Why server-side

After payment, browsers may block scripts, shoppers may close the tab, and redirects from payment pages can interfere. An event sent by your server when the order confirmation appears is more reliable for revenue figures.

How the plugin works

With WooCommerce active, the plugin sends a Purchase event with order total, currency, number of items, and coupon code when the order confirmation page is shown. Each order is sent only once, even if the page is reloaded.

Setup and verify

Connect PureMetrix and check under Plugin integrations that WooCommerce is switched on.
Place a test order while logged out.
Check that the event and the amount appear in PureMetrix.
Repeat the test after theme or checkout plugin changes.

What stays in the browser

Pageviews and most Enhanced Measurements still use the tracking script in the browser (optionally routed through your own domain with the Ad-Blocker Defense (Same-Origin Proxy) setting). Purchases get the server-side safety net on top.

Privacy

The plugin sends only what the analytics needs: amount, currency, item count, and coupon code. To recognise the visitor, it also passes the buyer’s IP address and browser identifier (user agent) once; PureMetrix turns them into a hash (a non-reversible checksum) and does not store them. Payment providers remain separate.

Why purchases might be missing

The payment flow skips the order confirmation page.
A custom confirmation template bypasses the standard WooCommerce hook.
No Private Ingest Key is saved in the plugin (server events need it).
Test site and live site use the wrong site keys.

Refunds and repeat payments

Purchase events count completed checkouts, not net revenue after refunds. Reconcile your finances in WooCommerce. Automatic subscription renewals usually do not show the confirmation page, so they are not sent as purchases.

Payment redirects and the missing browser signal

With card payments and many wallets, shoppers pass through the payment provider’s site before returning to your confirmation page. Purchase tags that run only in the browser then miss orders or fire twice. The server-side Purchase event is sent once when WooCommerce shows the order confirmation.

The PureMetrix plugin is built for exactly this—test one order per active payment method and compare the revenue in the dashboard with WooCommerce reports for the same hour.

Avoid double counting

If you also send purchases from the browser (for example with your own script), switch that off—the server event is the reference. Agree with your finance team on whether revenue includes tax (PureMetrix uses the order total including tax and shipping). Refunds are not deducted—say so in your reporting documentation.

A test table for payment methods

Build a table: payment method, redirect yes/no, test order number, Purchase seen in PureMetrix yes/no, revenue matches yes/no. Repeat it after plugin updates and after changes to the confirmation template. Server-side tracking fails silently if a theme replaces the template.

Include wallets and buy-now-pay-later options—those flows involve many redirects.

Pending orders and delayed payments

The plugin records the purchase when the confirmation page appears, not when the money actually arrives. With bank transfer or other payment methods where money comes later, the purchase is counted in advance. Note this next to your PureMetrix settings so everyone reads the figures correctly.

Custom order statuses

Some shops use their own statuses such as awaiting-wire. The plugin does not look at the order status—what counts is that the confirmation page was shown. Check which of these orders actually turn into revenue; otherwise PureMetrix revenue will be higher than your finance figures.

Headless and custom checkouts

If your shop front end is a separate app (headless) and never shows the classic WooCommerce confirmation page, the plugin does not send purchases. In that case, send the Purchase event yourself at the moment the order is paid—not with fragile timing tricks in the browser. What matters to PureMetrix is that each order arrives once with the correct revenue.

Agree with the developers that preview and test versions use the site keys of a test site.

Avoid duplicates

The plugin marks each order after sending, so a reloaded confirmation page does not count twice. If you build your own integration, make sure each order is sent only once as well—double revenue destroys trust faster than slightly low figures.

Also test a failed payment: check whether a Purchase is recorded when the order stays failed or cancelled—some payment methods still show the confirmation page in that case.

Note order numbers next to the PureMetrix timestamps on your test sheet, so mismatches are sorted out in minutes rather than meetings.

Custom confirmation pages that bypass the woocommerce_thankyou hook need their own call to PureMetrix; otherwise orders paid via redirects will be under-reported permanently.

Headless or custom checkout apps that never show the classic confirmation page must send the purchase to the PureMetrix API from their order-complete webhook.