Your test tool shows success, yet the sales report makes little sense. Where should you look? The event may have arrived with the wrong value, been sent twice, or arrived late. Successful delivery is one checkpoint, not the end of the investigation.
A Pixel sends website events through the browser. CAPI stands for Conversions API, a route for sending conversion data from the server. Check what happened in the business, what was sent, and how the report represents it. Meta’s resources cover event quality, matching, deduplication and freshness; TikTok explains overlapping Pixel and Events API events. Details differ by platform and integration. [1] [2]
1. Define the event before following its journey
When does an order become a purchase in this business: form submission, confirmed payment, or another stage? Agree with the business owner, then document the platform event representing it. Define value, currency, discounts and cancellations.
Choose a reference for test cases, such as the order system or CRM. Understand differences rather than forcing every ad report to equal the business record. Receiving events and attributing them to advertising are different questions.
2. Separate purchase time from arrival time
Record when the action occurred, when it was sent and received, and the time zone. If the system retries after an outage, check that it still describes the same transaction rather than creating a new record by mistake.
Server-side tracking describes a delivery route; it does not itself authorize collecting more data. Review consent, policies and processing arrangements before changing fields. Use test data and an appropriate environment.
Practical exercise: test five specific cases
These hypothetical events form a suggested checklist, not a universal deduplication window.
| Case | Test action | Check |
|---|---|---|
| Valid event | Test purchase with known value and currency | Name, value, currency and time |
| Two sources for one action | Send the intended browser and server copies | Link copies without inflating results under the platform’s mechanism |
| Retry | Redeliver after a simulated outage | No new business order created |
| Invalid value | Remove or change currency in a test copy | Error detection and handling record |
| Incomplete action | Leave before the agreed completion stage | No false completed purchase |
Write the expected outcome first, followed by observations and evidence. If the full path remains unclear, mark it unresolved. That is more useful than a generic success label hiding untested steps.
3. Explain differences before changing settings
First check period, currency and revenue definition. Then investigate missing, duplicate or delayed events, followed by attribution and modeling where relevant.
If browser and server each send the same purchase, check the integration’s matching mechanism. If an event is late, inspect its timestamp instead of reacting to an incomplete report with a budget change. Test possible causes before blaming either delivery route.
4. Hand over fixes that can be retested
For each issue, name the owner, planned change and repeatable test. Keep previous settings and, where possible, separate delivery changes from changes to what counts as a purchase.
Rerun affected cases after changes to the theme, store app or tagging tool. Today’s tests establish behavior in those cases, not every visitor’s experience. Before using a value in a budget decision, make clear what was checked and what remains open.
Official sources
Source documentation reviewed: 16 October 2026. Features and eligibility may change; check the linked documentation before implementation.
