"Meta Conversions API Setup Guide for Shopify Stores"

• Meta Conversions API (CAPI) is a server-to-server event feed that runs in parallel with the browser pixel — its job is to backstop the events browsers drop (ad blockers, ITP, in-app browsers) so Meta's optimizer has complete data.
• Shopify's native Facebook & Instagram sales channel ships CAPI out of the box; the correct setting for most DTC stores is "Maximum" data sharing with a working consent-mode integration.
• Every event you send twice (browser + server) must carry the same `event_id` and `event_name` so Meta deduplicates them into one conversion — mismatched IDs inflate reported conversions.
• Test everything end-to-end in Events Manager → Test Events (real-time) before turning it on for real traffic; a single test purchase should land as one deduplicated Purchase, not two.
• Event Match Quality (EMQ) is the number that decides whether CAPI moves ROAS — 6+/10 is the practical target; hashed email + phone + `external_id` (Shopify customer ID) are the biggest levers.

Key stat: Meta's own Conversions API documentation recommends running browser pixel + CAPI in parallel with `event_id` deduplication as the reference architecture — not one instead of the other. A CAPI-only setup is diagnostic, not final.

You don't need a developer, a server, or a weekend. You need 20 minutes and this guide.

Somebody told you that you need Conversions API. Maybe it was your ad agency, in a monthly report with a chart pointing down and to the right. Maybe it was a YouTube ad for another SaaS tool. Maybe it was a Meta rep on a call you don't remember booking. Whoever it was, they said it like it was obvious, and then they moved on, and you were left with a term that sounds like something out of a systems architecture textbook.

So you searched for it. And every guide you found started the same way: "First, deploy a server-side Google Tag Manager container." Or "Set up a Node.js middleware to proxy your events." Or a screenshot of a Postman request with a Bearer token in it. You closed the tab. You have a store to run. You do not have a backend team, and you're not going to hire one to fix a tracking pixel.

Here's the thing nobody leads with: if you're on Shopify, there's a version of this that takes about 20 minutes, requires zero code, and is the version Meta and Shopify actually recommend for stores like yours. It's not a workaround or a "good enough" hack — it's the native, first-party path, and it's sitting inside an app you may have already installed and half-configured three years ago.

This guide is that path. We'll also cover the two harder paths, so you know when you'd actually need them (probably not yet), and how to check your work once you're done — because a setup you can't verify isn't a setup, it's a guess with a nicer name.

Think about the Meta Pixel — the regular browser-based one — as a postcard. When a customer buys something on your store, your website scribbles "Purchase, $84, order #4471" on a postcard and drops it in a mailbox that runs through the customer's browser. That postcard has to survive a trip through ad blockers, browser privacy settings, and whatever the customer's phone decided to do with background tracking that day. A lot of postcards get shredded before they arrive. Not lost by Meta — shredded in transit, on the customer's device, before Meta ever sees them.

The Conversions API is a different mailroom entirely. Instead of relying on the customer's browser to deliver the news, your store's own back-office server picks up the phone and calls Meta directly: "Hey, order #4471 just happened, here's the amount, here's a hashed version of the customer's email so you can match it to an ad." No browser involved. No ad blocker in the path. No iOS setting to dodge. It's store-to-Meta, server-to-server.

That's the whole concept. It's not more complicated than that, even though most explanations make it sound like you're wiring up a satellite uplink.

Here's what CAPI does: it gives Meta a second, more reliable copy of the events that matter — purchases, checkouts started, product views — so that when the browser postcard gets shredded, Meta still has the server call to work with. Meta's own documentation describes this as improving the reliability and quality of event data used for ad targeting, delivery, and measurement (see developers.facebook.com's Conversions API docs). It's signal repair. It's plumbing.

Here's what CAPI does not do. It does not create purchases that didn't happen. It does not make your ROAS number go up because Meta is suddenly more excited about your ads. It does not personally fix a campaign that's losing money because the offer is wrong or the audience is wrong. If your ads are bad, better data delivery just means Meta finds out your ads are bad more accurately and faster. What CAPI fixes is undercounting and mis-attribution — the gap between "what actually happened in your store" and "what Meta's optimization algorithm can see." Feed the algorithm real, complete signal, and it optimizes toward real, complete signal. Feed it half the picture, and it optimizes toward whatever fragment survived the trip.

If someone promises you a ROAS bump from CAPI alone, they're selling you the postcard analogy without the honesty part.

Nobody unplugged your pixel. Four separate things happened over a few years that, combined, quietly cut a real chunk out of what the browser pixel can see. None of them were aimed at you specifically — they were aimed at tracking in general, and your store just got caught in the blast radius like every other store on the internet.

iOS App Tracking Transparency (ATT). Starting with iOS 14.5 in 2021, Apple began requiring apps to explicitly ask permission before tracking users across apps and websites. Most people, when asked "Allow this app to track you?", tap "Ask App Not to Track." Industry measurement firms have cited opt-in rates commonly landing somewhere in the 20-40% range depending on app category and audience, though the exact number moves around by source and over time — treat any specific percentage you read, including this one, as a rough approximation rather than gospel. The practical result for Meta advertisers: a meaningful share of iOS traffic — often a majority, depending on your audience — never gets tied back to an ad click the way it used to, on the browser side.

Ad blockers. Browser extensions like uBlock Origin, and blocking built into privacy browsers like Brave, intercept requests to known tracking domains, including Meta's pixel endpoint. Estimates for ad blocker usage vary widely by market and device type — desktop tends to run higher than mobile — but it's not a rounding error. If a customer runs an ad blocker, the browser pixel's postcard never leaves the building.

Browser tracking prevention. Safari's Intelligent Tracking Prevention (ITP) and Firefox's Enhanced Tracking Protection both restrict what cookies and scripts can do by default. Apple has documented that Safari limits the lifetime of cookies set via JavaScript to a matter of days rather than the year-plus lifetime advertisers used to count on. That matters for anything that relies on a returning-visitor cookie to connect a click today to a purchase next week.

Shortened cookie lifetimes generally. Even outside Safari specifically, the industry-wide trend has been toward shorter default cookie windows and more aggressive third-party cookie restrictions across browsers. The 30- and 90-day attribution windows advertisers used to plan around don't hold the way they used to on browser data alone.

Stack all four on top of each other and you get what most Meta advertisers have felt directly, even without a single statistic to back it up: campaigns feel like they're "underreporting" purchases you know happened, because your Shopify order list and your Ads Manager purchase count stopped agreeing with each other somewhere around 2021 and never really came back. That gap is what CAPI is built to close — not by tracking harder, but by tracking from a place none of those four things can reach: your own server.

There are three ways to get Conversions API running on a Shopify store, and they are not equally good for you. Here they are, ranked for the store owner who does not have an engineer on staff.

Path A — Shopify's native Facebook & Instagram app, Maximum data sharing. This is Shopify's own first-party integration with Meta, available as a free app in the Shopify App Store (sometimes still referred to by its older name, the Facebook Channel). It connects your store, your product catalog, your Pixel, and your Conversions API events, and it handles the server-side event delivery for you — no code, no separate hosting, no monthly fee for the integration itself. For the overwhelming majority of Shopify stores, this is the correct answer. It covers Purchase, Checkout, Add to Cart, and other standard e-commerce events out of the box, using Shopify's own order data. If you sell physical or digital products through standard Shopify checkout, start here and only leave if you hit a specific, named limitation.

Path B — a paid connector or server-side Google Tag Manager setup (Stape, and similar providers). This path exists for stores that need to send custom events the native app doesn't cover — things like tracking a quiz completion, a custom loyalty-program action, or events from a non-Shopify part of your funnel (a landing page built outside Shopify, for instance). These tools run a server-side container you manage through a dashboard, and most of the popular ones (Stape is the most commonly used in the Shopify ecosystem) are built to be configured without writing code, though they do involve more moving parts than Path A: a separate account, a subdomain, monthly hosting cost, and more settings to get wrong. Reach for this only when you have a specific custom-event need Path A genuinely can't meet.

Path C — a custom build against Meta's Conversions API directly. This means a developer writing code that calls the CAPI endpoint directly, usually from a custom backend or serverless function, following developers.facebook.com's API reference. This is the right call for large, complex stores with custom checkout flows, marketplaces, subscription logic Shopify doesn't natively expose, or multiple sales channels feeding one Meta pixel. It's also the path every generic "how to set up Conversions API" guide assumes you're on, which is exactly why those guides felt impossible. If you don't have a developer on retainer and nobody on your team can explain what an API endpoint is without Googling it first, you do not need Path C. You need Path A.

Ranked plainly: try A. If you hit a wall, evaluate B. Only reach for C if you have engineers and a genuinely custom setup that B can't handle either.

Here's what actually happens when you set up the native path, in plain terms, before we hit the numbered checklist later in this guide.

Install the app. From your Shopify admin, go to Settings → Apps and sales channels, or search the Shopify App Store for "Facebook & Instagram" (published by Meta/Shopify). Add it to your store. If you already have it installed from a previous attempt, open it — you're going to reconfigure it, not reinstall it.

Connect your Meta Business Manager. The app will walk you through logging into Facebook and selecting (or creating) a Business Manager account, a Facebook Page, and an Instagram account if you have one. This is also where you select which Meta Pixel to connect — either an existing one you've used before, or a new one the app creates for you. If you have multiple old pixels floating around from past agencies, pick the one that's actually connected to the ad account you're currently spending on. We'll come back to why this matters in the section on settings that bite people.

Choose your data-sharing level. This is the step that actually turns on Conversions API, and it's the one every generic guide skips because Shopify built the whole thing into a single toggle. Inside the app's settings, you'll find a data-sharing or "customer information sharing" control, typically presented as a few tiers:

• Standard sends event data only from the browser — the traditional pixel, nothing server-side. This is the weakest option and the one most likely to have been the default on an old install.
• Enhanced adds some hashed customer information (like email or phone, when available) to the browser-based events, improving matching without turning on full server-side delivery.
• Maximum turns on server-side event sharing — Conversions API — sending event data, including hashed customer information, directly from Shopify's servers to Meta, in addition to the browser pixel. This is the setting you want.

Set it to Maximum. This one click is functionally the entire "integration" that every complicated guide is trying to talk you through with code.

Review permissions and save. The app will show you what data categories it's about to start sharing (order details, customer contact info in hashed form, product data). Confirm, and give it a few minutes to start flowing — first events sometimes take up to 20-30 minutes to appear, occasionally longer during high-traffic periods.

[Screenshot: Shopify admin, Facebook & Instagram app settings page showing the data-sharing level selector set to "Maximum"]

That's it. There is no server to provision, no API key to generate by hand, no code to paste into `theme.liquid`. Shopify's app is doing the server-side call on your behalf, using order and checkout data it already has because it's your e-commerce platform.

Setup without verification is a guess wearing a lab coat. Here's how to actually check.

Go to Meta Events Manager (business.facebook.com/events_manager2, accessed through your Business Manager). Select the pixel connected to your store. You'll land on the Overview tab, which lists recent events — Purchase, InitiateCheckout, AddToCart, PageView, and so on.

The thing you're looking for is a small label or icon next to each event showing its source. Once Maximum sharing is live, you should start seeing events tagged as coming from both Browser and Server — sometimes shown as a combined badge, sometimes as two separate line entries for the same event name. That "Browser · Server" pairing is the whole point: it means the same real-world action (a purchase) is being reported to Meta from two independent paths, so if one gets blocked, the other still lands.

[Screenshot: Events Manager Overview tab, Purchase event row showing both Browser and Server source icons]

Give it a day or two of real traffic before judging. A single test order won't tell you much — you want to see a pattern across dozens of events. If you're impatient (fair), use the Test Events tab inside Events Manager. It lets you place a real or test order and watch the event arrive in near-real time, showing you exactly which parameters came through — order value, currency, hashed email, hashed phone, external ID, and so on.

[Screenshot: Test Events tab showing an incoming Purchase event with a green checkmark and parameter list]

What does a healthy overlap look like? You should see Server-side events roughly matching, or in some cases modestly exceeding, Browser-side event counts for Purchase specifically — because server events aren't subject to ad blockers or ATT opt-outs, they tend to be the more complete count. It's normal, and expected, for Browser-only events like PageView or ViewContent to still dominate on the browser side, since those aren't typically part of the order data Shopify's server-side integration pushes. Don't panic if PageView doesn't show a Server badge; that's not usually what CAPI is built to cover on the native path. Purchase, Checkout, and Add to Cart are the events to focus your verification on.

If, after 48 hours of real orders, you still see zero Server-tagged events on Purchase, stop and revisit the data-sharing level setting — it likely reverted, was never saved, or the wrong pixel got connected.

The first time you see the same purchase show up twice in Events Manager — once from Browser, once from Server — your instinct is going to be "wait, is this double-counting my sales?" It's a completely reasonable question, and the answer is: not if it's set up correctly, and Shopify's native integration handles this automatically.

Here's the plain-English version. When your store fires a Purchase event through the browser pixel, and separately fires the same Purchase event through the server, both events get tagged with a shared identifier called an `event_id`. Meta's systems look at that identifier — same event name, same event_id, arriving within a defined time window — and merge the two into a single counted event before it ever hits your reported numbers, per Meta's deduplication documentation. You see both entries in Events Manager because Meta shows you the sources it received, not because it's counting the sale twice in your actual campaign results.

So: seeing "Browser AND Server" on one purchase in Events Manager is correct and expected. That's the system working. What you actually need to watch for is different — true duplication, where a sale gets counted twice in your reported campaign numbers, which shows up as your total Purchase count in Ads Manager running noticeably higher than your actual Shopify order count over the same period, not just one event listing two sources.

True duplicates usually come from one specific mistake: two independent tracking setups pushing the same event without a shared event_id to tie them together. This happens most often when a store has the native Shopify app running Maximum sharing and a second, separate app or piece of custom code also firing Purchase events — for example, an old third-party pixel app installed by a previous agency that nobody removed, sitting alongside the native integration, both reporting the same order with no shared identifier. Meta has no way to know those two events are the same sale, because from its side, they look like two different, independent systems reporting two different purchases.

The fix isn't a setting — it's an audit. If you're on Path A only, with Shopify's native app as your single source of tracking, deduplication is handled for you and you don't need to think about event_id at all. If you have more than one tracking method installed (native app plus a legacy custom pixel, or native app plus a Stape-style Path B setup layered on top), that's when you need to check for genuine duplication, which we cover in the settings section below.

Inside Events Manager, click into any event (Purchase is the useful one to check) and you'll find a score labeled Event Match Quality, or EMQ, usually shown out of 10. Most store owners have seen this number, shrugged, and moved on, because nobody explains what it's actually measuring.

EMQ is Meta's estimate of how well it can match an event you sent to a real person in its system — meaning, how confidently it can tie "Purchase, $84" to an actual Facebook or Instagram account it can then use for ad optimization and reporting. It does this by looking at the customer parameters you included with the event: hashed email, hashed phone number, name, address, external ID (your internal customer or order ID), IP address, and browser identifiers like the click ID.

Here's the part that matters for this guide: server-side events sent via Conversions API typically score higher on EMQ than pure browser-pixel events, because Shopify's checkout data includes clean, verified customer information — a real email address and phone number entered at checkout — whereas browser-only events often have to rely on whatever weaker signals survived cookie restrictions. This is one of the concrete, measurable reasons CAPI is worth the 20 minutes: it's not just redundancy, it's often higher-quality data than the browser pixel was ever sending on its own.

What counts as a "good" score varies by store, order volume, and how much customer data is captured at checkout, so treat any specific number you've read elsewhere as a rough benchmark rather than a target to hit exactly. What you want to watch for, practically, is direction: after enabling Maximum data sharing, your Purchase event EMQ should move up, not stay flat or drop. If it's flat, something in the setup isn't actually pushing customer data through — worth a re-check against the verification steps above.

What moves the score, in order of typical impact: email address, phone number, and external ID (order/customer ID) tend to carry the most matching weight; name, city, state, and zip add smaller improvements on top. You don't control most of this directly with the native Shopify setup — it's pulled automatically from checkout fields — which is exactly why Path A tends to produce decent EMQ scores without you touching a single field mapping. If your checkout doesn't collect a phone number, for instance, that's a data-collection question for your store, not a tracking-setup bug.

Most CAPI "failures" aren't failures of the setup you just did. They're leftovers from setups nobody cleaned up. Four to check.

Multiple pixels from old apps or agencies. If you've worked with more than one agency or installed more than one marketing app over the years, there's a real chance you have two or three Meta Pixels loosely associated with your store — one connected through the current native app, one hardcoded by an old freelancer, one installed by an app you stopped using but never uninstalled. Each of these can independently fire events, none of them coordinated with each other, none of them sharing an event_id. Check Events Manager's list of pixels tied to your Business Manager and confirm which one is actually receiving your Maximum-sharing events. Anything else firing on your storefront is a candidate for removal.

Legacy custom pixel code sitting in `theme.liquid`. This is the single most common ghost in the machine. Somewhere around 2020-2021, it was standard advice to paste Meta Pixel base code directly into a Shopify theme file. A lot of stores did this, then later installed the native Facebook & Instagram app on top, without ever removing the original hardcoded snippet. Result: two browser-side pixels firing the same events, no event_id coordination between them, inflated browser-side counts, and a headache when you try to reconcile numbers. Check your theme's code editor (Online Store → Themes → Edit Code) for any `<script>` block referencing `fbq(` or `connect.facebook.net` outside of what the native app manages, and remove it if the native app is your source of truth now.

Customer privacy and consent settings in Shopify. Shopify's own customer privacy settings (Settings → Customer privacy) control cookie banners and consent behavior for stores serving regions with consent requirements, like the EU. If your consent banner is misconfigured — blocking marketing cookies by default and never properly capturing opt-in — it can suppress pixel firing for a meaningful share of EU visitors regardless of how well your CAPI setup is configured, since browser-side tracking is often gated behind consent in ways server-side order data isn't always tied to in the same way. This is worth a dedicated look if a meaningful share of your traffic is EU-based; it's outside the scope of a pure CAPI fix and deserves its own review against Shopify's customer privacy documentation.

UTM parameters vs. attribution. Not a bug, but a constant source of confusion: your UTM tags in Google Analytics or Shopify's own traffic reports are not the same system as Meta's attribution inside Ads Manager. A sale can show "direct" in your UTM-based reporting while Meta correctly attributes it to an ad, or vice versa, because they're using different windows, different matching logic, and different definitions of "last touch." Fixing CAPI does not make these two systems agree with each other — they were never going to agree, they measure different things. Don't chase that gap as if it's a tracking bug; it's two different rulers measuring the same tape.

This is the part everyone skips and the part you actually need to be able to explain if a customer, a lawyer, or a payment processor ever asks.

When Shopify's native app sends customer information to Meta as part of a server-side event, it doesn't send raw personal data. Fields like email address and phone number are hashed using SHA-256 before they leave your store's systems — meaning they're converted into a scrambled, one-way string of characters that Meta can compare against its own similarly-hashed user records to find a match, but that cannot be reversed back into the original email or phone number on Meta's end. Meta's Conversions API documentation is explicit that this hashing step is required for the personal-data fields sent through the API. This is the same broad approach used for the browser pixel's "Advanced Matching" feature, extended to the server side.

What does Meta do with matched data? It uses it for ad measurement, delivery optimization, and audience matching (like Custom Audiences built from customer lists) — governed by Meta's own data use terms for advertisers, which every Business Manager account has agreed to. You are not personally handling or storing this data differently than you already do as a Shopify merchant; you're authorizing Shopify's app to transmit a hashed version of data your store already collects at checkout.

What should go in your privacy policy? At minimum, plain-language disclosure that you use tracking and analytics tools including Meta's advertising and measurement tools, that some customer information is shared with Meta (in hashed form) to improve ad measurement, and a link to how customers can manage their ad preferences through Meta's own settings. Shopify's own policy generator and customer privacy documentation are reasonable starting points, but if you're serving EU customers or operating under state privacy laws (California's CCPA/CPRA and similar state frameworks), it's worth having actual counsel review your policy rather than relying on a template — this article is not legal advice, and specific compliance requirements vary by where your customers are and what data you collect beyond the tracking fields discussed here.

The practical posture for most small-to-mid Shopify stores: disclose clearly, keep your Shopify customer privacy consent settings configured for the regions you serve, don't collect more than you need, and don't treat "we turned on Maximum sharing" as a decision that needs to be hidden from customers. It's a standard, disclosed advertising practice used by a large share of e-commerce stores running Meta ads — not a secret backdoor.

Here's the uncomfortable truth about tracking setups: they don't stay fixed. Something breaks them eventually — a theme update overwrites a snippet, an app gets reinstalled and resets a setting, someone connects a new pixel for a rebrand and forgets to deprecate the old one, Shopify or Meta changes something on their end. And because tracking failures are invisible by nature — your store keeps selling, your dashboard keeps loading, nothing throws an error message anyone sees — breakage is almost always silent. You find out weeks later, when you're trying to figure out why campaign performance quietly got worse and can't tell if it's the ads or the data.

A short weekly check, five minutes, catches most of this before it costs you real ad spend:

• Open Events Manager and glance at Purchase event volume for the last 7 days. Does it roughly track your actual order volume for the same period? A sudden cliff — events dropping by half or more with no corresponding drop in real orders — is the single biggest red flag.
• Check that Purchase events still show the Browser · Server pairing, not just one source. Losing the Server side specifically usually means the Shopify app's data-sharing setting got reset or disconnected.
• Glance at EMQ on your main events. A sudden drop suggests customer data fields (email, phone) have stopped populating — sometimes caused by a checkout customization or a new app interfering with order data.
• Watch for a "No recent activity" or "Not receiving data" warning banner in Events Manager itself — Meta surfaces this automatically when a pixel goes quiet, and it's worth actually reading instead of dismissing.

None of this needs a dashboard or a subscription to catch, if you're willing to actually look every week. Most stores aren't, which is the entire reason tracking breaks silently for months at a time — nobody's checking, because checking isn't anybody's job.

A straight, numbered path. Follow it in order. Each checkpoint tells you what to do if something looks wrong before you move on.

1. Log into your Shopify admin and go to Settings → Apps and sales channels. Search for "Facebook & Instagram" if it's not already installed, and add it.

Checkpoint: if you find you already have it installed but haven't touched it in over a year, open it anyway — settings and requirements change, and an old connection may be using an outdated setup.

1. Connect (or reconnect) your Meta Business Manager, Page, and Instagram account through the app's setup flow.

Checkpoint: if you're prompted to create a brand-new Business Manager and you know you already have one from past ad campaigns, stop — log into business.facebook.com first, confirm which Business Manager owns your existing pixel and ad account, and connect that one. Creating a second one splits your history.

1. Select your Meta Pixel — the existing one tied to your ad account, not a new one, unless you genuinely have no pixel history to preserve.

Checkpoint: if you're not sure which pixel is "the real one," check Ads Manager → your active campaigns → which pixel is selected as the conversion source. Match that one.

1. Open the data-sharing / customer information settings inside the app and set the level to Maximum.

Checkpoint: if you only see Standard and Enhanced as options with no Maximum tier visible, your app version may need updating, or your store's region/settings may be restricting it — check for an app update before assuming it's unavailable.

1. Review and accept the data-sharing permissions shown, and save.

Checkpoint: read what's listed before clicking through — you want to see order data, customer contact fields, and product data mentioned. If it only mentions product catalog data with nothing about customer or order information, you may still be on a lower tier.

1. Remove or disable any old, redundant tracking. Check theme code for a hardcoded pixel snippet in `theme.liquid`, and check your installed apps list for any old "Facebook Pixel" or "FB tracking" app that predates the native integration.

Checkpoint: if removing an old snippet feels risky because you're not sure what else it's tied to, duplicate your theme first (Online Store → Themes → Actions → Duplicate) so you have a safe rollback copy before editing.

1. Place a real or test order, then open Events Manager's Test Events tab and watch it arrive.

Checkpoint: if nothing shows up within 15-20 minutes, double check step 4 actually saved — reopen the app and confirm Maximum is still selected. It sometimes doesn't save on the first attempt.

1. Check the Overview tab in Events Manager 24-48 hours later for the Browser · Server pairing on Purchase events, and glance at the EMQ score.

Checkpoint: if you see Browser only, with no Server tag, after 48 hours of real orders, the connection didn't fully take — repeat steps 2 through 5, paying close attention to which Business Manager and pixel you're connecting.

1. Add the weekly five-minute check (from the section above) to your calendar or your Monday routine, or hand it to whoever manages your ads.

Checkpoint: if nobody on your team actually owns this check, it's the same as not having it — assign it to a real person or a real reminder, not "someone should probably look at this."

That's the whole path. No server. No code. No developer required.

Related reading: PixelProof free instant pixel scan Meta Pixel diagnostics for Shopify DTC How to verify Meta Pixel installation 30-day compliance monitoring playbook

Do I still need the regular pixel if I have Conversions API? Yes — keep both running. They're not competing systems, they're redundant paths to the same destination, and Meta's own deduplication (matched by event_id) prevents double-counting when both fire for the same purchase. The browser pixel also still covers behavioral events like page views and content views that the native CAPI setup isn't primarily built to carry. Turning off the browser pixel to "avoid duplicates" actually makes your data worse, not better.

Will CAPI fix my ROAS? Not directly. CAPI fixes what Meta can see — it repairs signal loss, which helps Meta's optimization algorithm make better decisions with more complete data, and it often improves reported numbers because previously-missed purchases now get counted. But if your ad creative, offer, or targeting is the actual problem, better data delivery won't paper over that. Think of it as giving Meta accurate glasses, not a different set of ads to run.

Is Maximum data sharing legal? It's a standard, widely used advertising configuration, not a gray-area hack — the data sent is hashed before it leaves your store, per Meta's documented approach. That said, "legal" also depends on your own disclosure: you still need appropriate privacy policy language and consent handling for the regions your customers are in, particularly the EU and states with their own privacy laws. The setup itself isn't the legal risk; skipping disclosure is.

Why do my Shopify order count and my Ads Manager purchase count never match exactly? They're measuring different things through different windows. Ads Manager attributes purchases to ads using its own click/view attribution logic and time windows, which can include or exclude orders your Shopify report counts differently (subscription renewals, phone orders, POS sales, orders outside the attribution window). Even with perfect CAPI setup, expect these two numbers to be close, directionally consistent, and never identical.

How long does it take for events to start showing up after I turn on Maximum sharing? Usually within 20-30 minutes for the first events, though it can occasionally take longer, especially right after installing the app for the first time. Give it a full 24-48 hours of real order volume before judging whether the setup worked — a handful of test orders isn't enough data to see a reliable pattern.

I have Shopify Plus with a custom checkout — does the native app still work? In most cases, yes, since the native app pulls from Shopify's order data rather than requiring a standard checkout template. Heavily customized checkouts (particularly `checkout.liquid` extensibility on Plus, or fully custom checkout extensions) are exactly the scenario where it's worth confirming with your dev team or a Shopify Partner that events are still firing as expected — this is one of the more common reasons a store legitimately needs to look at Path B or C instead of stopping at Path A.

What's the difference between Standard, Enhanced, and Maximum again? Standard is browser-only, no server-side data. Enhanced adds hashed customer info to browser events without turning on full server delivery. Maximum turns on Conversions API — server-side event delivery straight from Shopify, including hashed customer data — on top of the browser pixel. For CAPI specifically, you want Maximum; the other two tiers don't include server-side delivery at all.

Do I need a Stape or server-side GTM setup if I'm just running standard Shopify checkout? Almost certainly not. Path B (Stape-style server-side GTM) earns its cost and complexity when you need custom events the native app doesn't cover, or you're tracking activity outside Shopify's own checkout (a separate landing page builder, a quiz funnel, a non-Shopify signup flow). If your funnel starts and ends inside Shopify's standard checkout, Path A covers you.

My EMQ score seems low — should I be worried? Worry less about hitting a specific number and more about direction and completeness. If it moved up after switching to Maximum sharing, that's the setup working as intended. A persistently low score is worth investigating if your checkout isn't collecting a phone number, or if a checkout customization is stripping customer fields before they reach Shopify's order data — those are the two most common causes.

How do I know if my old agency left tracking code behind that's messing things up? Check two places: your theme's code editor for any Meta Pixel `<script>` snippet outside what the native app manages, and your installed apps list for anything with "pixel," "Facebook," or "tracking" in the name that you don't recognize using. If you find either, verify what it's doing in Events Manager (does removing it change your pixel count?) before deleting it outright, and back up your theme first.

• Shopify Web Pixels API docs: shopify.dev/docs/api/web-pixels-api — the sandboxed customer-event surface CAPI ships against on modern Shopify.
• Shopify custom pixels reference: shopify.dev/docs/api/pixels/customer-events — the canonical event catalog you dedupe against.
• Meta Conversions API best practices: developers.facebook.com/docs/marketing-api/conversions-api/best-practices.

• Meta Conversions API best practices — Meta's canonical setup + testing guide.
• Shopify Web Pixels API — sandbox rules every CAPI-adjacent custom pixel obeys.

• Meta Pixel diagnostics for Shopify DTC brands (2026)
• Meta Pixel breaks after Shopify checkout upgrades — 6 signals
• 30-day compliance monitoring playbook for DTC brands
• PixelProof — real-time Meta Pixel & CAPI monitor
• PixelProof pricing