media
Insights · Measurement
A purchase event arrived.
Now check the order.
An event appearing in a tracking tool proves that an event was received. It does not, by itself, prove that a unique order was paid, that its value was correct or that an advert caused the sale. To compare Meta reporting with your store, separate event delivery, order accuracy and advertising attribution.
Start with a small, controlled sample before comparing whole-month totals. Record the same date range, time zone, currency and value definition, then investigate differences one by one. Do not change a working integration simply to make two headline numbers match.
Three questions that need separate answers
| Question | Evidence to inspect | What it does not prove |
|---|---|---|
| Did the event arrive? | A corresponding browser or server event received by the measurement platform. | That the payment completed or every parameter is accurate. |
| Does it represent the right order? | Order status, value, currency, timestamp and the behaviour when the confirmation page is revisited. | That the order belongs to an advertising campaign. |
| Why is it attributed to an advert? | The selected reporting window, attribution settings and measurement limitations. | That every store order should appear in Ads Manager, or that every reported conversion is incremental. |
Define the store total before comparing it
A shop can count orders created, orders paid or orders completed. Revenue can include or exclude tax, delivery, discounts and refunds. Write down which definition you need and verify the export settings, rather than assuming a dashboard label matches your business’s meaning of sales.
WooCommerce’s Revenue report distinguishes gross sales, returns, coupons, net sales, taxes, shipping and total sales. Its Analytics documentation also explains reporting configuration. Check the active date basis, statuses and filters in the actual store before relying on an export.
A fictional three-order reconciliation
The following records are invented to explain the method. They are not Plusbac orders, campaign results or a forecast. For this example only, values exclude tax and shipping, and the aim is paid sales less the recorded refund.
| Record | Store evidence | Reconciliation decision |
|---|---|---|
| Example 001 · £100 | Payment received; no refund in the chosen review period. | Include £100 under the example’s definition. Check the corresponding event and currency. |
| Example 002 · £80 | Payment received, then £80 refunded within the same example period. | Paid order count and retained revenue answer different questions; this record contributes £0 after its full refund. |
| Example 003 · £60 | Order created but payment still pending. | Do not count it as a paid sale simply because an order number exists. Inspect whether a Purchase event fired too early. |
The sample has £180 of paid order value and £80 of refunds, leaving £100 under the stated definition. It has two orders that were paid, one fully refunded order and one unpaid order. None of those facts tells us how many purchases Meta should attribute to advertising.
Investigate a mismatch in a useful order
- Check scope. Align currency, time zone, date basis, statuses and value definition. Include a written note about refunds that fall outside the original order period.
- Check the firing point. Establish which action produces Purchase and whether it can occur before successful payment.
- Check repetition. Revisit the confirmation page in a coordinated test. Inspect whether one transaction can produce multiple events.
- Check overlapping integrations. Inventory plugins, manual tags and browser/server paths. Two paths do not automatically mean two purchases: have the implementer verify the current provider’s deduplication requirements and the identifiers actually sent.
- Check attribution. Compare the selected advertising reporting settings and review consent, browser and measurement limitations. An event-receipt tool and an attributed-advertising report are different views.
- Record the result. Keep the evidence, confidence and next action for each discrepancy. A missing record is not permission to invent an attributed sale.
Make a repair only after identifying the failure. Changing plugins, adding server events or replacing a Pixel can introduce a second problem while leaving the first one unexplained. Test the agreed change against the same sample and retain the before-and-after evidence.
What our Plusbac case demonstrates
In the Plusbac implementation record, a coordinated client test produced one browser Purchase received in Meta. The case explicitly does not independently reconcile that event’s individual parameter values or repeated-confirmation-page behaviour. It therefore supports a receipt milestone, not a claim that every purchase was deduplicated, accurately valued or attributable to ads.
That is why a good measurement handover records both what passed and what remains to check. Server-side Conversions API work, Advanced Matching and campaign launch are separate scope decisions, not conclusions you can draw from a browser event arriving.
Download the fictional reconciliation worksheet (CSV) and replace its examples with a securely handled, appropriately limited sample. Do not put customer names, payment details or access credentials into a shared marketing worksheet.
Calculate with your own advertising figures · Apply the same discipline to lead outcomes