The Facebook Conversions API on Shopify

Updated

The Conversions API sends purchase and cart events from your Shopify store’s server straight to Meta, rather than depending on a script in the shopper’s browser. Because the request never touches the browser, ad blockers, Safari cookie limits and iOS App Tracking Transparency cannot intercept it. Most stores that turn it on see conversion counts rise, not because sales changed, but because they were already happening unreported.

What browser tracking loses

Three forces cut into browser-side data. Roughly a third of shoppers run an ad blocker that blackholes requests to Facebook domains. Safari’s Intelligent Tracking Prevention caps script-set cookies at seven days, so a shopper who browses today and buys next week arrives unrecognised. And iOS App Tracking Transparency, live since 2021, means most iPhone users never grant the identifier Meta matched on.

None of this shows up as an error. The pixel reports fewer conversions, ROAS looks worse than it is, and campaigns get paused for underperforming when they were actually working.

How the server-side path differs

When an order completes, your store sends a signed HTTPS request to Meta’s Graph API with the event name, value, currency and hashed customer details. It runs server to server. There is no script for a blocker to block and no cookie for Safari to expire.

It also carries better data. A browser event knows little about who converted. A server event built from a Shopify order can include hashed email, phone, name, city and country, which is exactly what Meta’s match quality score measures.

Deduplication is not optional

Send events both ways and Meta receives two copies of every purchase. Left alone, that doubles your reported conversions and halves your apparent cost per acquisition, and every budget decision made on those numbers is wrong.

Deduplication solves it. Both copies carry the same event_id and the same event name, and Meta keeps whichever arrives first. Pixelfy derives that ID from the Shopify order, so browser and server events always match without configuration.

Meta reports the result in the Events Manager Diagnostics tab. A healthy setup shows a high deduplication rate on Purchase. A rate near zero means the IDs are not lining up and you are double counting.

Setting it up on Shopify

Meta offers a partner integration, a manual implementation against the Graph API, and app-based setups. The manual route means writing and hosting server code, refreshing access tokens and hashing customer data to Meta’s specification. It is real engineering work for something an app does on a toggle.

With Pixelfy you paste the pixel ID and an access token from Events Manager. Server-side events start flowing for ViewContent, AddToCart, InitiateCheckout and Purchase, deduplicated against the browser pixel, on every pixel in your list including TikTok through its Events API.

What to check after a week

Open Events Manager and look at three numbers. Event match quality should be higher than it was on browser events alone, typically by two to four points once hashed email and phone are flowing. The deduplication rate on Purchase should be high. And total Purchase volume should be up on the same traffic.

That third number is the one to take to a client or a finance meeting. Compare a fortnight before and a fortnight after with steady ad spend. The extra conversions were always real, they were just invisible.

Questions

Do I still need the browser pixel if I use the Conversions API?
Yes. Meta recommends running both. The browser pixel catches signals the server does not see, and the redundancy improves attribution as long as the two are deduplicated with a shared event ID.
Is the Conversions API compliant with GDPR?
It can be, and it uses the same lawful basis as the browser pixel. Customer identifiers are hashed with SHA-256 before transmission, but you still need consent for tracking and should suppress events for shoppers who decline.

Related guides