Getting the Shopify Purchase event right

Updated

Purchase is the event Meta optimises against, and on Shopify it is the one most likely to be missing. A pixel pasted into your theme cannot run on Shopify’s hosted checkout, so it records browsing and stops before the sale. Installing through the Web Pixels API is what gets checkout_completed, and therefore Purchase, back into Events Manager with an order value attached.

The four events that matter, in order

ViewContent fires on a product page and tells Meta which items get attention. AddToCart marks real intent and is the event most retargeting audiences are built from. InitiateCheckout captures the drop-off point where abandonment campaigns earn their keep. Purchase closes the loop and carries the money.

Stores often track only PageView and then wonder why campaigns will not scale. Meta cannot optimise for conversions it never sees. The algorithm needs roughly 50 Purchase events per week per ad set before it leaves the learning phase, and page views do not count toward that.

Why Purchase goes missing

Shopify runs checkout on its own infrastructure and does not execute arbitrary theme scripts there. Any install that lives in theme.liquid loses the shopper at the checkout boundary. The pixel looks healthy in Pixel Helper on a product page, which is what makes this so confusing to debug.

Shopify Plus stores used to work around it with additional_scripts on the order status page. That surface is being retired in favour of the Web Pixels API and checkout extensibility, so a workaround built on it now has a shelf life.

Purchase events with no value

A Purchase that arrives without value and currency is worth very little. Meta can count it, but it cannot compute ROAS or run value-based optimisation, and your ad manager will show conversions against a blank revenue column.

Decide early whether value means the order subtotal or the total including shipping and tax. Either is defensible. Mixing them across pixels is not, because your reported ROAS then depends on which pixel you happen to be reading.

Multi-currency stores need one more check. Send the currency the order was actually placed in, not the store default, or Meta will convert amounts that were never in that currency.

Redundant and duplicate Purchase events

Meta flags "redundant purchase events" when it receives more than one Purchase for a single order. Refreshing the thank-you page can do it, and so can two install methods running side by side.

The proper fix is a shared event ID. When the browser event and the server event both carry the same event_id, Meta keeps one and discards the other. Pixelfy generates that ID from the Shopify order so browser and Conversions API copies always line up.

Without deduplication, a store sending both copies reports close to double its real conversions, and every optimisation decision made on that number is wrong.

Verify with a real order

Create a 100% off discount code and place a genuine order through the storefront. Test cards in Shopify’s bogus gateway do not always complete the same event flow.

Open Events Manager, go to Test Events, and look for one Purchase carrying the correct value, currency and content IDs. Then check the Diagnostics tab a day later. That is where Meta reports deduplication rates and missing parameters, and it will tell you about problems Pixel Helper cannot see.

Questions

Should Purchase value include shipping and tax?
Use the order subtotal if you want ROAS measured against product revenue, which is the more common choice. What matters more is consistency: pick one definition and use it across every pixel on the store.
What counts as a redundant purchase event?
Any second Purchase Meta receives for the same order within its deduplication window. It happens when two installs both report the sale, or when a browser and server event are sent without a shared event ID.

Related guides