A purchase can be reported incorrectly even when the order itself is real. Your store, browser integration, server integration and advertising report each describe a different part of the journey. Before using ROAS to increase a campaign budget, verify that purchases are recorded consistently and understand what the report attributes to advertising.
For eligible events, Meta recommends using the Pixel and Conversions API together with deduplication. The Pixel sends events from the browser; the Conversions API sends them from a server or connected platform. Two paths can improve the information available, but they must not turn one transaction into two reported purchases. Meta’s integration guidance.
In this guide
Begin with permission and data eligibility
Server-side delivery is not a way around consent or data restrictions. Before configuring events, review your privacy choices, integration settings and the information you are permitted to share. Health-related details can appear in URLs, product names, form fields and custom parameters; do not assume a field is suitable simply because a plugin sends it by default.
Meta’s Business Tools Terms govern use of these integrations. Check the requirements and any restrictions shown for your data source. Hashing an identifier is not the same as anonymizing the entire transaction or obtaining permission. Keep unnecessary information out of the event payload.
Make one event mean one thing
Define when a Purchase occurs: for example, when an eligible order reaches your chosen confirmed-payment state. Apply that definition consistently across the browser and server paths. A checkout visit, a failed payment and a completed order should not all emit the same purchase signal.
Write down which amounts the event value includes, including the handling of discounts, tax and shipping. Send the correct currency. Keep internal order IDs and event IDs understandable to the team, but avoid putting personal or sensitive information into those identifiers.
Use matching deduplication identifiers
Meta’s recommended approach matches the browser event name with the server event_name and the browser eventID with the server event_id for the same event. Both copies must reach the same dataset/Pixel context. Generate one stable identifier for the transaction event and pass it through both paths. Official deduplication requirements.
| Field | Browser example | Server example |
|---|---|---|
| Event name | Purchase | Purchase |
| Event identifier | eventID: order-test-001 | event_id: order-test-001 |
| Value and currency | Consistent with the defined order value | The same definition and currency |
| Destination | The intended Pixel/dataset | The same Pixel/dataset |
Also make your own retry handling consistent. A server job that retries should retain the identifier for the same event. A thank-you page refresh should not create a new transaction. Do not assume platform deduplication will correct every duplicate produced by your application.
Verify the setup with a small test matrix
- Place a permitted test order and compare the order record with the event name, ID, value and currency received.
- Check the browser and server connection methods in Events Manager, allowing for processing delay.
- Refresh the confirmation page and test a server retry; check for unintended additional purchase events.
- Test a failed or cancelled checkout so it is not treated as a paid order.
- Check that privacy choices and any data-source restrictions are respected.
- Review event freshness, diagnostics and deduplication rather than relying only on a successful API response.
Meta’s setup verification documentation explains received events, freshness, deduplication and matching. An event shown as received is not the same as a completed purchase attributed to an ad. Raw received-event counts can differ from counts after processing.
Separate attribution from the order ledger
Store revenue includes orders from several channels and returning customers. Advertising reports apply their own attribution settings and processing. Compare the same date range, timezone, currency and definition before investigating a discrepancy. Do not assume every order should appear in the ad report or that every attributed order was caused solely by the ad.
Keep renewals, refunds, cancellations and first purchases identifiable in your own reporting. A refunded test order does not automatically prove that an earlier advertising event has been reversed. Confirm how your integration handles those events and how your commercial reports account for them.
Make reporting definitions usable
ROAS expresses attributed conversion value relative to the cost basis used in that report. Label the attribution window and understand which costs are included before comparing platforms or service providers. For profitability decisions, use your business’s actual commercial costs and contribution alongside advertising metrics.
Repeat the checks after changing a checkout, plugin, event integration or consent setup. Record the last verified configuration and its owner. Then use the creative testing framework and budget pacing guide with numbers your team can interpret consistently.