Meta, connected to every purchase.
Set up shop measurement and verify what Meta receives, step by step.
Connect the correct pixel
- Open Pixels and events → Add pixel, select Meta, give it a name and choose the shop.
- Paste the Pixel ID for your Meta data source. The ID enables browser events and should match the one used by your storefront.
- For Atlas delivery, add the Conversions API token. This token enables server events and available matching data. The ID alone does not configure this second delivery path.
- Keep the pixel Active and save. When editing, the token field is blank to protect it: leaving it blank preserves the existing credential.
On entry: InitiateCheckout
With an active pixel and measurement permission handled before checkout, Atlas sends ViewContent and InitiateCheckout on entry. It does not wait for an email address or require a second acceptance checkbox in Atlas. An explicit withdrawal stops subsequent sends.
Choose a product, open checkout from your shop and look for InitiateCheckout in pixel history.
When payment is confirmed: Purchase
Purchase is sent when payment is confirmed. A failed attempt, a processing payment or an unconfirmed thank-you page is not a purchase. The event includes the final amount and original currency, identifiable products, quantities and available prices.
What information helps Meta
| Information | When available |
|---|---|
| Value and currency | The final order total in the charge currency. |
| Products | Available cart identifiers, names, quantities and prices. |
| Matching information | Email, phone, name and delivery location when present and valid. Protected using Meta’s required format. |
| Visit context | Available browser information and advertising references that help match the visit. |
Atlas does not invent missing information. If a shopper does not enter a phone number, no fictional number is sent. Advertising information is not added to the Stripe payment description.
Verify receipt, not just an attempt
- In Meta Events Manager, select the correct data source and open Test events. Use its browser-testing option to open your storefront.
- To check server delivery, copy Meta’s code into Edit pixel → Test event code and save. Send test event sends a diagnostic ViewContent; it does not simulate a purchase.
- Add a product to the cart and enter checkout from your storefront. Look for ViewContent and InitiateCheckout. Check Browser or Server origin and the amount and currency for that stage.
- To verify Purchase, complete only a purchase you have authorized, in the appropriate payment environment. A decline, incomplete form or canceled 3DS must not appear as a purchase.
- Open Atlas → Pixels and events → Activity → Inspect. Compare event name, reference, final amount, currency, products and time with Meta. When both paths arrive, verify that Meta treats them as the same purchase.
- Reload the receipt: it must not create another purchase. Then remove the test code and save the pixel.
Demo does not prove receipt in Meta. A Demo purchase or Stripe test alone does not verify the pixel connected to your Live shop. Check each source and distinguish receipt from ad attribution.
Understand delivery states
| What you see | What it means |
|---|---|
| Scheduled / pending | Atlas prepared the event; delivery is not confirmed yet. |
| Browser dispatched | The browser invoked the pixel. This alone does not prove Meta received it. |
| Accepted by Meta | The API accepted the submission. This does not guarantee campaign attribution. |
| Failed / retrying | Inspect the response. Atlas limits retries; an invalid credential requires fixing the connection. |
| Suppressed | Not sent, for example because measurement permission was withdrawn. |
| Preview | A sample delivery was prepared; this is not confirmation from Meta. |
Browser and Atlas delivery share a reference to avoid counting the same action twice. Each retry keeps the original amount and context; later cart changes do not rewrite what happened on entry.
The recovery window for Meta events is 24 hours. An expired event is not replayed with a new reference. If the pixel destination changes, pending events are not automatically redirected to a different data source. Correct the configuration and review the issue before retrying.
If an event is missing
- Confirm the pixel is active and assigned to the correct shop.
- Check the time range, ID and data source in Meta.
- Review Atlas history for the exact event and any error.
- Test in a browser without blockers while respecting the shopper’s measurement preferences.
- For Purchase, first confirm payment completed. If the issue remains, share the reference and time with the team, without credentials.
Shopify and Parkour Pixel
Parkour Pixel is not a requirement for Atlas. You can use an app to measure Shopify browsing and carts while Atlas measures its checkout. Installing an app does not automatically configure the pixel in Atlas.
Using the same ID on both sides keeps one data source, but does not prevent duplicate events by itself. Check which integration sends Purchase. Do not add a second purchase script to checkout HTML without coordinating its reference with the Atlas event.
When the storefront and checkout use different domains, browser data may differ. The Conversions API token lets Atlas use available advertising references and matching data from the journey. It cannot invent information the storefront did not pass along.
If you also use TikTok
Configure TikTok as a separate pixel with its own shop and ID. Review its events and history separately. Meta event names or statuses do not verify reception in TikTok.