If you searched for how the Meta Conversions API works on Shopify, the short version: you don't build it. Shopify's Facebook & Instagram sales channel sends server-side events to Meta once you set customer data sharing to the maximum level, and it handles the SHA-256 hashing and the browser/server deduplication for you. Installation takes about four minutes. The part that actually decides whether your ad account can attribute revenue is parameter coverage, and that's where most stores sit at an event match quality score of 4 or 5 and assume nothing more can be done.
So this post spends two paragraphs on setup and the rest on the match rate.
Turn it on, then leave it alone
In the Facebook & Instagram channel settings, connect the Business Manager account, pick the pixel (Meta now calls it a dataset), and set data sharing to the maximum tier. That tier is what enables server-side events. Shopify then fires both browser and server events for the standard set — PageView, ViewContent, AddToCart, InitiateCheckout, Purchase — with a shared event ID so Meta collapses the pair into one conversion.
The single most common mistake we clean up: a store has the native channel connected and a third-party Conversions API app installed, both sending Purchase. Meta's deduplication only works when the event name, event time and event ID line up. Two independent senders don't produce matching IDs, so you get roughly double the purchases in Events Manager, a ROAS figure that looks fantastic, and a budget being spent against a number that isn't real. Check Events Manager for the connection method breakdown before you add anything. If you see two server integrations, one of them goes.
Read the match quality score for what it is
Events Manager gives each event an event match quality score from 1 to 10, plus a per-parameter table showing which identifiers you're sending and how well each one matches. That table is the useful part. The headline number is a diagnostic, not a KPI.
Realistic targets from what we see on Shopify stores: Purchase should sit between 6.5 and 8.5. ViewContent and AddToCart will sit at 3 to 5 unless you're doing extra work, because at that stage you usually have no email address. Anyone promising you a 9.5 across the board is either sending identifiers they shouldn't have or hasn't looked at the pre-purchase events.
The parameters that move the number
Meta matches on whatever you send, but the weight is nowhere near even. Ranked by what we've seen actually shift the score on Shopify stores:
- Email — the workhorse. Present on every completed checkout.
- Phone in E.164 — on Indian and UAE stores this often scores higher than email, because so many Meta and WhatsApp accounts here were created against a phone number rather than an inbox nobody checks.
- fbp and fbc — the browser cookies. fbc in particular is what ties a conversion back to a specific ad click.
- external_id — a stable, hashed ID you control. Cheap to add, and it's the only identifier available on pre-purchase events for logged-out traffic.
- Name, city, state, postcode, country — small individual lift, meaningful in combination, and free because Shopify already has them from the shipping address.
- client_ip_address and client_user_agent — required for server events to be usable at all. The native integration sends these.
Date of birth and gender are in the spec. Almost no Shopify store has them, and collecting them at checkout to chase a match rate is a bad trade.
Phone formatting is where Indian stores quietly lose points
Shopify will happily store a phone number as 9876543210, or 98765 43210, or 0 9876543210, depending on how the customer typed it and whether your checkout enforces a country code. Meta expects digits with the country code and no separators. A ten-digit Indian mobile with no 91 in front will not match, and it won't tell you it didn't — it just shows up as a lower-scoring phone row in the parameter table.
Two fixes. Set the phone field on checkout to require a country code so new orders come in clean. Then, for existing customers, normalise the stored numbers. If you have a large customer table this is a one-off script rather than a manual job, and it's the sort of thing worth handing to a developer for an afternoon rather than doing in a spreadsheet.
Same principle for postcodes. UAE addresses often have none, which is fine. Indian PIN codes typed as "560 068" with a space will not match against "560068".
Getting identifiers into the events that happen before checkout
Purchase match quality is the easy win. ViewContent and AddToCart are where campaigns optimising for upper-funnel signals get starved, and the fix is to know who the visitor is earlier.
Three things that work, in order of effort:
- New customer accounts. Shopify's one-time-code login means a returning customer identifies themselves with six digits and no password to remember. Once they're logged in, the email is available to your pixel on every subsequent event, not just at checkout.
- external_id on everything. For logged-in visitors, use the hashed Shopify customer ID. For guests, pick one stable value and stick to it across browser and server events. The absolute value doesn't matter; consistency does.
- Email capture that fires the event. Your welcome popup already collects an email. Most implementations never pass it to Meta. Wire the submit to a pixel call so the rest of that session carries an identifier.
One constraint to plan for rather than discover during QA: custom pixels on Shopify run in a sandbox. They don't get free access to the parent page's DOM or the first-party cookies that Meta's browser pixel sets there. If your plan involves reading _fbp out of document.cookie from inside a custom pixel, rework the plan. And since Shopify retired checkout.liquid customisations, the additional-scripts trick on the thank-you page isn't available as a fallback any more.
fbc, fbclid, and the redirects that eat it
fbc is built from the fbclid query parameter on the landing URL. Anything that drops or rewrites the query string breaks it: a link-cloaking app, a legacy redirect rule sending /products/x to /collections/y, an app that bounces first-time visitors to a country selector, a UTM-cleaning script somebody installed for tidy analytics reports.
Test it in ninety seconds. Take a live ad's URL, add ?fbclid=test123 to your own homepage URL, load it, and check whether _fbc exists as a cookie. Then repeat on a product URL that you know sits behind a redirect. We find a broken one on maybe a quarter of the accounts we audit, usually on the mobile app-deeplink path.
The purchase event that lies: COD and cancellations
Shopify's Purchase event fires when the checkout completes. On a store where 55% of orders are cash on delivery and 20% of those never get paid for, you are teaching Meta's optimiser to find people who place orders, which is not the same population as people who pay for them.
The honest options are both imperfect. You can keep optimising on placed orders and accept that your true CPA is higher than reported, adjusting your target manually. Or you can send a second, custom server-side event when an order is actually delivered and paid, and optimise campaigns against that instead. The second is better and harder: the delivery event lands 4 to 9 days after the click, so learning is slower, and you need enough volume for Meta to work with a delayed signal. Below roughly 50 delivered conversions a week per ad set, don't bother.
A worked number, so this isn't theoretical
Take a store doing 1,000 orders a month at ₹2,400 AOV, spending ₹4,00,000 a month on Meta. Events Manager reports 380 purchases attributed to Meta. Match quality on Purchase is 5.1: email present but often unhashed junk, phone missing the country code on most records, no external_id.
Fix the phone normalisation, add external_id, and pass city, state and postcode. Suppose the share of Purchase events Meta can match to a person goes from 62% to 81%. Attribution scales with what's matchable, so 380 × (81 ÷ 62) = 496 reported purchases. Spend is unchanged at ₹4,00,000, so reported CPA moves from ₹1,053 to ₹806, and reported ROAS from 2.28 to 2.98.
Note what did and didn't happen. You didn't sell one extra unit. You made 116 sales visible that the algorithm previously couldn't learn from, which is the real gain, because those 116 conversions now feed optimisation and lookalike building. Treat the ROAS number as a measurement correction, not a performance win, or your next month's forecast will be wrong.
When custom server-side is worth building, and when it isn't
The native integration sends a fixed set of events with a fixed set of parameters. You can't add a custom event, you can't send Meta your own value field, and you can't push offline conversions. To do those you need your own path to the Conversions API: a Shopify Flow trigger into a small private app, or a server-side tag manager container, plus a system access token and a maintenance owner.
Below about ₹3–5 lakh a month in Meta spend, we usually advise against it. The native channel plus a clean custom pixel plus correct phone formatting gets you most of the available lift, and a homegrown middleware that silently stops sending events in March is worse than no middleware. Above that spend level, or if you're on Hydrogen where the native channel doesn't apply, custom becomes the right call and we treat it as a proper build with monitoring rather than a script somebody wrote once.
If you sell into the EU or UK, consent is a hard limit on all of this. No consent, no fbp, and no lawful server event either. India's rules are moving in the same direction. Build the consent plumbing through Shopify's Customer Privacy API now rather than retrofitting it under deadline.
The checks that tell you it's done
Place a real test order. In Events Manager, open the Purchase event and confirm: one deduplicated event, not two. Server and browser both listed as connection methods. Email, phone, external_id, fbp and address fields all showing in the parameter table with a match rating, not just "sent". Then leave it a week and look at the score again, because a single order tells you the plumbing works and a week of orders tells you whether it works for everyone.
If the score is still under 6 after all that, the problem is upstream in your data, not in the integration. Send us the Events Manager screenshot and the order status page URL through the free audit and we'll tell you which parameter is failing.