Do I need a developer for a Shopify Conversions API setup?

Not for the standard path. The Facebook and Instagram sales channel handles server side sending once you raise the customer data sharing level, so there is no code to write. You need a developer only if you have a headless or heavily customised checkout, or if you need events the channel does not cover, such as refunds, subscription renewals or point of sale orders.

Will enabling server side events double count my purchases?

Not through the native integration, because the browser event and the server event carry a shared event ID and Meta deduplicates them. Double counting usually comes from a second purchase pixel added by a theme snippet or another app, since that one sends without the shared ID. Audit for leftover pixels before you enable server side sending.

How do I know it is actually working?

Open the dataset in Events Manager and check the connection method on the purchase event. It should read as browser and server rather than browser only. Then count paid orders in Shopify for a closed seven day window and compare that with purchase events received for the same window and time zone. If 180 orders produced 162 events, coverage is 162 divided by 180, or 90%, and the 18 missing orders are what you investigate.

Why do the events received still not match what Meta reports for my campaigns?

They measure different things and are not supposed to match. Events received counts what arrived in the dataset. Campaign conversions count what Meta attributes to an ad within a chosen attribution window, which excludes orders from other channels and shifts with the window you select. Use coverage to judge whether tracking is intact, and attribution to judge campaigns.

Do the data sharing levels affect privacy compliance?

Yes. A higher level means more customer information is transmitted with each event, so it belongs in your privacy notice and your processing records, and it interacts with consent settings and regional rules that can suppress sending. Check the current description of each level in Shopify and in Meta's official documentation before enabling it, since the definitions have been revised more than once.

Shopify Conversions API Setup Guide

A Shopify Conversions API setup sends checkout and purchase events to Meta from Shopify's servers instead of relying only on the shopper's browser. On a standard Shopify store you do not write any code to get it. You connect the Facebook and Instagram sales channel, point it at the correct dataset, and raise the customer data sharing level to the tier that includes server side sending. The switch itself takes a minute. Everything around it is where stores lose weeks, and that is what this guide is about.

Shopify Conversions API setup: what has to be true before you start

The prerequisites are dull and they are exactly where most implementations fail quietly. Confirm all four before you touch any setting.

Admin rights on both sides. You need Shopify admin access and a role in the Meta business portfolio that owns the dataset. A staff account that can install the channel but has no dataset permission will produce a connection that looks finished and sends nothing.
One dataset, not three. Older stores accumulate a pixel from a theme snippet, another from a marketing app and a third from the sales channel. Decide which dataset is the source of truth first. Turning on server side sending across a messy pixel estate makes diagnosis harder, not easier.
A checkout you have not rebuilt by hand. The native integration expects Shopify's own checkout flow. Headless storefronts and heavily customised checkouts change what the channel can observe, and they usually mean a custom pipeline instead.
Domain verification in Meta business settings. An unverified domain limits what you can configure downstream and creates a second problem you will misread as a tracking problem.

The data sharing level is the switch, not the app install

Installing the sales channel does not enable server side events. The setting that does is customer data sharing inside the channel. Shopify exposes it as a small set of levels, historically labelled standard, enhanced and maximum, where the highest level is the one that adds server side sending alongside the browser pixel. Both the names and the behaviour of each level have been revised more than once, so read the description in the app and in Meta's own documentation rather than trusting a screenshot in a blog post, including this one.

Two things follow from that. Raising the level changes what customer information leaves your store, so it belongs in your privacy notice and your processing records, not only in a marketing checklist. And the level applies going forward only. It does not backfill events for orders that were already placed, so do not judge the change by looking at last week.

Which events leave your server, and which still come from the browser

With the native path you do not pick events one by one. Shopify sends the core commerce funnel: page and product views, add to cart, checkout initiation and purchase. Purchase is the event that drives optimisation and reporting, so verify that one first and treat the rest as supporting evidence. Check the current event list in Shopify's help documentation, because it is tied to the sales channel version your store is running.

Both a browser event and a server event exist for the same action. They are reconciled through a shared event ID, and the channel handles that for the events it owns. You do not build it, and you should not bolt on a second manual purchase pixel to "make sure it lands", because deduplication only holds while one system is responsible for those events.

What the native path will not send

Server side sending through the sales channel is scoped to the storefront. Refunds and cancellations, subscription renewals billed weeks later, phone orders and point of sale transactions do not arrive by that route. If those are a meaningful share of revenue, you are looking at a separate build: Meta's API directly, a server side tag manager container, or offline event uploads. Each is real engineering with ongoing maintenance, and it is worth deciding honestly whether your current spend justifies it.

Verifying in Events Manager instead of assuming

Open the dataset in Events Manager and look at the event list. Each event shows a connection method. Before the change, purchase reads as browser only. Afterwards it should read as browser and server. If it still says browser after a day of orders, the switch did not take effect, and no amount of waiting will change that.

Then watch one real order end to end. Place a test purchase, or wait for a live one, and follow it in the activity view. You are checking three things: that the event arrives, that it carries a value and a currency, and that it is not duplicated into two separate purchases.

A coverage check you can run in ten minutes

Pick a seven day window that has already closed, and hold that same window and the same time zone on both sides. Count paid orders in your Shopify admin for that window. Count purchase events received in Events Manager for the identical window. Say Shopify reports 180 paid orders and Events Manager reports 162 purchase events. Divide one by the other: 162 divided by 180 is 0.9, so 90% of orders produced an event and 18 orders did not. That gap is your work list.

Be precise about what this check measures. It compares orders placed against events received. It is not a comparison against the conversions Meta attributes to your campaigns, which is governed by attribution logic and will match neither figure. Coverage tells you whether the pipe is intact. Attribution tells you who gets credit for what came through it.

While you are in the panel, glance at the event match quality indicator for purchase. It reflects how much identifying information arrives with each event, and raising the data sharing level normally moves it. Read it as a direction of travel rather than a target to chase.

Where Shopify setups break quietly

A duplicate pixel from an app or theme. A leftover snippet firing the same purchase outside the channel will not share the event ID, so it cannot be deduplicated. Search your theme files and your installed apps before blaming the API.
Customer privacy controls. Shopify's privacy settings and regional consent rules can suppress data sharing for some visitors. If you install a consent banner after enabling server side events, rerun the coverage check, because the number will move.
Reconnection after a permissions change. Changing the connected business, rotating an admin or reinstalling the channel can leave the connection in a half configured state. Reopen the data sharing setting and confirm it, rather than assuming it survived.
Missing value or currency. A purchase event with no value is still a conversion, but return on ad spend becomes meaningless, and any bidding target you set from it is built on nothing. If you are working out what a usable target looks like, our ROAS calculator is a faster place to start than a spreadsheet.
Multiple stores on one dataset. Two storefronts reporting into a single dataset produce a purchase count nobody can reconcile with either admin.

A sane order of operations

Audit the pixels already firing on the store and remove the ones you are not keeping.
Verify the domain and confirm dataset permissions for the account doing the work.
Connect the sales channel and select the dataset deliberately, not the one preselected for you.
Raise customer data sharing to the level that includes server side sending, and update your privacy notice on the same day.
Wait for real orders, then check the connection method on purchase.
Run the seven day coverage check, write the percentage down, and rerun it after any theme, app or consent change.

None of this is glamorous, and it is the reason browser only measurement has been unreliable since the mobile tracking changes that reshaped Facebook ads reporting after iOS 14. It also sets the floor for everything automated that sits above it, whether that is Meta's own delivery systems or an AI targeting layer, because none of them can optimise toward a purchase they never received. Get coverage measured and documented first, then argue about strategy.