Skip to content

Proof of completeness

Coming to PixelCapi Pro

Why does Meta report fewer sales than your store?

Because a conversion has to survive a whole chain — the browser, the network, an ad blocker, a gateway redirect, the platform’s own API — and your store only has to write a row to the database. Order-to-Event Reconciliation is designed to compare those two lists directly: every WooCommerce order against every Purchase event that was actually sent, so a missing sale stops being a number and becomes an order you can open.

what already helps

Server-first Purchase, shipped today

Before reconciliation exists, the largest single cause of missing sales is already handled: the Purchase event no longer depends on the thank-you page loading.

Fired from payment hooks

The server sends Purchase when your store records the payment. A closed tab, a slow redirect back from an offsite gateway, or a customer who never returns to your site no longer costs you the conversion.

Queued, retried, never blocking

Sends go through an async queue with retries. A platform API having a bad minute does not slow your checkout, and it does not silently drop the event either.

the mechanism

What reconciliation is designed to show

Coming to PixelCapi Pro

Everything in this section describes intended behaviour, not shipped behaviour.

One row per order, not one number per week

The point of the view is that every gap has an order number attached to it, so you can open the order, see what happened and fix the cause rather than the symptom.

Order #1481 store ✓ event ✓ Matched
Order #1482 store ✓ event ✕ no Purchase sent

Designed output. This capability has not shipped, and these are not real rows.

TODO(owner: screenshot)

Order-to-Event Reconciliation — available once the capability ships.

how it will work

Three steps, once it ships

  1. step 1

    Your orders are the reference list

    Reconciliation will start from WooCommerce, not from the ad platform. The store is the one system that knows for certain that a sale happened.

  2. step 2

    Each order is matched to its Purchase event

    The send log already records which event ID was used for which order, so the join is designed to be exact rather than a guess based on timing and value.

  3. step 3

    The gaps are listed with their reasons

    An order with no event, an event the platform rejected, or an event still waiting in the retry queue are three different problems. They are designed to be shown as three different rows.

documentation

Read the details

The reference pages for this, including the parts that are still being verified.

Questions people ask about this

Short answers. Anything we cannot confirm, we say so.

Is Order-to-Event Reconciliation available today?

No. It is in development. This page describes what it is designed to do, and the roadmap badge marks it everywhere it appears on this site. Release notes go out on the changelog as each part ships.

Why not just trust the number in Events Manager?

That number tells you what the platform accepted, not what your store sold. Comparing the two is the only way to see which specific orders never made it, which is what this capability is designed to do.

What already helps with missing purchases today?

Purchase is server-first: it fires from your payment hooks rather than from the thank-you page, so a sale is still captured when a customer closes the tab or an offsite gateway never redirects back. That is in the released plugin now.

Will it change my orders?

It is designed as a read-and-compare view. Reconciliation reads orders and the send log; it does not rewrite order data.

Proof beats promises. Watch this land.

This capability is in development. Release notes go out on the changelog as each part ships.

Check your tracking — free Follow the changelog