Ads Manager Sales Don't Match Shopify? Why Ad Platform Purchases and ROAS Differ From Real Revenue — and How to Fix It

Key Takeaways

• Platform ROAS is the platform's claim about its own ads; store revenue is what customers paid. Reconcile them at order level, never by comparing totals.
• Define actual revenue first — net of refunds, cancellations and undelivered COD orders, with tax, shipping and currency handled the same way on every platform.
• The biggest causes of inflated platform revenue are duplicate purchase events, values that include tax and shipping, refunds never deducted, and two or three platforms claiming the same order.
• Under-reporting comes from consent and ad blockers, payment-gateway redirects and off-domain checkouts, cross-device journeys and missing server-side events.
• Shopify's move to checkout extensibility — legacy thank-you page scripts stopped running for non-Plus stores on 26 August 2026 — broke many purchase tags; check yours.
• Judge channels on blended metrics such as MER, new-customer revenue and contribution margin, and use holdout tests to measure what each platform really adds.

The Short Answer: Platforms Report Claims, Your Store Reports Orders

Every e-commerce and D2C team eventually opens three tabs — Meta Ads Manager, Google Ads and the Shopify dashboard — and finds three versions of last month. The platforms usually look better than the store, sometimes dramatically so, and occasionally worse. The first instinct is to assume something is broken. Sometimes it is. More often, the systems are working as designed and answering different questions.

An ad platform answers: “How many purchase events, and how much purchase value, did my own ads influence, according to the rules I apply, between these two dates?” The answer is shaped by an attribution window, by which interactions qualify, by the date the platform assigns to each conversion, by the value your tracking sends, and by modelling for users the platform cannot observe. Each platform answers only about its own ads. None of them knows what the others claimed.

Your store answers a simpler question: “Which orders did customers place, for how much, and what happened to them afterwards?” It records every order exactly once, on the order date, at the price actually charged, and later records refunds, cancellations, returns and failed deliveries. It does not care which ad, if any, the customer saw.

So you should never expect the totals to match. What you should expect is a gap you can explain, unit by unit, with most of it coming from known measurement rules and the rest from errors you can fix. This guide covers purchase- and revenue-optimised campaigns. For lead-generation campaigns, where the reconciliation is against a CRM rather than a store, see our companion guide on why ad platform leads don't match your CRM.

Step Zero: Define “Actual Revenue” Before You Reconcile

The most common reason a reconciliation goes nowhere is that the two sides are measuring revenue differently, and nobody notices because both are called ‘revenue’. Before comparing anything, decide what your actual revenue number includes and make every platform send value on the same basis.

In practice we use two numbers. **Gross attributed revenue** is the order value excluding tax and shipping, on the day of the order. **Net realised revenue** is the same figure after refunds, cancellations and undelivered cash-on-delivery orders. Platforms can only ever be compared to the first, because they never learn about refunds unless you tell them. Your business runs on the second. The gap between those two numbers is, by itself, often larger than the attribution gap people argue about.

This matters even more in India, the UAE and other markets where cash on delivery is common. A COD order that is returned to origin was counted as a purchase by Meta and Google the moment the order was placed. If a meaningful share of your COD orders fail delivery, every platform's ROAS overstates real return by that share before any attribution question arises. We come back to this in the India-specific section below.

How Meta, Google and LinkedIn Count Purchases and Value

Each platform makes different default choices, and those choices explain much of the gap before you look at any tracking error.

**Meta.** Ads Manager credits a purchase if it falls within the attribution setting after an eligible click or view and dates it to the impression or click, so last week's ROAS keeps rising for several days as late purchases arrive. Since January 2026 vendors have widely reported that 1-day view is the only remaining view-through window, and since March 2026 only link clicks qualify as click-through. Meta also uses statistical modelling for some conversions it cannot observe directly. The value is whatever your Purchase event carries; Meta does not know if that includes tax or shipping, or if the order was later refunded.

**Google.** Google Ads uses data-driven attribution by default for most conversion actions, which can split credit across several Google ad clicks, so a conversion can appear as a fraction in some reports. Purchase actions should count ‘Every’, because each sale has value, and deduplicate using a transaction ID. Google's standard columns date conversions to the click; the ‘(by conv. time)’ columns date them to the purchase, which matches your store. Where consent is declined, Google may add modelled conversions. Unlike Meta, Google lets you correct the record after the fact through conversion adjustments: a retraction removes a conversion, a restatement changes its value.

**LinkedIn.** LinkedIn is rarely a purchase channel for e-commerce, but B2B companies increasingly report ‘revenue’ from LinkedIn by sending closed-won deals from their CRM. The same principles apply: define value consistently, deduplicate, and remember the default 7-day view-through window will credit deals to LinkedIn that your CRM attributes elsewhere. For B2B revenue reconciliation, our lead-to-CRM guide and our LinkedIn offline conversions setup guide are the better starting points.

Why Ads Manager Shows More Revenue Than Shopify

When platform revenue is higher than store revenue — the most common complaint — work through these causes. They stack, so a single account often has three or four at once.

1. **Several platforms claiming the same order.** A shopper clicks a Meta ad, later clicks a Google Shopping ad, then buys. Both platforms count the full order value. Add a TikTok or Pinterest click and the same order is claimed three times. This alone explains why the sum of platform revenue exceeds store revenue in almost every multi-channel account. 2. **View-through credit.** Someone sees an Instagram ad, does not click, and buys the next day after a Google search. Meta claims it under 1-day view; Google claims it as a click. Your store sees one order. 3. **Duplicate purchase events.** The Purchase event fires on the thank-you page and again when the customer revisits their order status page; the tag exists both in a Shopify app and in custom code; or the browser pixel and the server event do not share an event ID, so Meta cannot deduplicate. Our guide to fixing CAPI duplicate events covers the event ID mechanics. 4. **Value includes tax and shipping.** A ₹1,000 product with 18% GST and ₹80 shipping is sent as ₹1,260 if the tag uses the order total. Platform revenue is then inflated by roughly a quarter compared with net product revenue. 5. **Refunds, cancellations and undelivered COD never deducted.** Platforms keep the original purchase forever unless you send adjustments. 6. **Subscriptions and repeat orders.** Recurring charges, or customers ordering again inside an attribution window, can be credited to an ad that had nothing to do with the renewal. 7. **Currency mismatches.** A store selling in several currencies that sends the local amount but labels it with the account currency inflates or deflates value by the exchange rate. 8. **Test orders and internal orders.** Staff orders, influencer seeding orders and developer tests trigger purchases. Your store may mark them; the platforms do not know.

Items 1 and 2 are attribution rules you should understand rather than ‘fix’. Items 3 to 8 are errors that make platform ROAS wrong by any definition, and they are where reconciliation pays for itself.

Why Ads Manager Shows Fewer Sales Than Shopify

The opposite gap — the store sees far more orders than the platforms report — usually means signal loss, and it hurts performance as well as reporting, because the algorithm optimises on fewer purchases than really happened.

- **Consent and ad blockers.** Shoppers who decline cookies or use blocking browsers may not fire the pixel or tag. Server-side events recover a share where consent permits. - **Off-domain checkout and payment redirects.** If checkout or payment happens on another domain — a payment gateway such as Razorpay, PayPal or Stripe-hosted pages, a COD verification step, a third-party checkout app — the return to your thank-you page can fail or lose the parameters that connect the purchase to the click. Customers who close the tab after paying never reach the page where the tag fires. - **Broken thank-you page tracking after Shopify's checkout changes.** Shopify has moved stores to checkout extensibility. Third-party reporting puts the cut-off for Plus stores' Additional Scripts at August 2025 and for non-Plus stores at 26 August 2026, after which legacy scripts on the thank-you and order status pages stop running. Tags that lived there need to move to the official channel apps or custom pixels. We cover the migration in our Shopify checkout extensibility CAPI guide. - **Cross-device and in-app browsers.** A shopper taps an Instagram ad, browses inside Instagram's in-app browser, then buys later on a laptop. Without logged-in identity or server-side matching, the platform may never connect the two. - **Purchases completed in apps, marketplaces or offline.** Orders placed on Amazon, a quick-commerce app, WhatsApp or in a store after seeing your ad are invisible to the platform unless you upload them. - **Attribution windows shorter than the decision.** For considered purchases — furniture, jewellery, courses, high-end electronics — many buyers take longer than seven days. Meta's 7-day click window will not credit them.

If your store sees many more orders than all platforms combined, start with a test purchase in a clean browser and watch the events fire. Most severe under-reporting turns out to be one broken tag or one redirect, not a deep attribution problem.

Why Google Ads and GA4 Show Different Conversions Again

Many teams also try to use GA4 as the referee between platforms and the store, then discover GA4 disagrees with everyone. That is expected, and understanding why prevents a lot of wasted debugging.

GA4 attributes conversions across all channels — paid, organic, email, direct — using its own attribution model, so it gives Google Ads credit only when Google Ads wins the attribution, not whenever a Google ad was clicked. Google Ads, by contrast, sees only Google ad interactions and credits them under its own windows. GA4 also counts sessions and events subject to its own consent handling, filters and thresholds, and its reporting identity can differ from the Google Ads tag. If you import GA4 purchases into Google Ads as your primary conversion action, the two will be closer; if you use the native Google Ads tag, they will differ by design.

The practical rule: pick one primary purchase source for Google Ads bidding — native tag with enhanced conversions, or GA4 import — and never set both as primary, or every sale is counted twice. Use GA4 for cross-channel journey analysis and on-site behaviour, Google Ads for optimising Google campaigns, and your store for revenue. If you want a single cross-channel view, the cleanest route is warehouse-based attribution, which we describe in our GA4 BigQuery multi-touch attribution setup.

How to Test Your Purchase Tracking in 20 Minutes

Before you reconcile a month of data, prove that one order is tracked correctly. A single controlled test purchase catches most of the serious errors — duplicates, wrong values, missing server events — in less time than it takes to export a report. We run this on every account before doing anything else.

1. **Prepare.** Open a private browser window with no extensions. Open Meta Events Manager's Test Events tool and Google Tag Assistant for your site. Note the time. 2. **Arrive through an ad-like URL.** Visit a product page with a test fbclid and gclid appended, or click a real ad preview, so the click identifiers flow through as they would for a customer. 3. **Buy something real and cheap**, using the payment method most of your customers use — UPI or a card for prepaid, or COD if that is half your volume. Discount codes should behave as customers' would. 4. **Watch the events.** In Test Events you should see exactly one Purchase from the browser and one from the server, with the same event ID, the order ID, the right currency and a value equal to your chosen definition. In Tag Assistant you should see one Google purchase conversion with a transaction ID. 5. **Revisit the order status page** and refresh it twice. No new Purchase events should fire. 6. **Repeat on mobile** inside the Instagram in-app browser, paying through a UPI app if you sell in India, to test the redirect path. 7. **Cancel and refund the order**, then check that your refund process — reporting deduction or Google retraction — picks it up.

Record what you see in a short test log with screenshots. If the test passes, most of your reconciliation gap will be attribution and refunds. If it fails, fix what failed and test again before analysing any historical data, because every report until then is built on a broken signal. Repeat the test after every theme change, app installation or checkout update; these are the moments tracking breaks.

Which Attribution Settings to Use for Reporting and for Bidding

A common source of confusion is that the attribution setting you use to read results and the one the algorithm optimises on do not have to be the same thing — and mixing them up makes reconciliation harder than it needs to be.

On Meta, the attribution setting on an ad set tells delivery which conversions to optimise towards. In reporting you can compare attribution settings side by side using the ‘Compare attribution settings’ option in Ads Manager columns, which shows, for the same ads, how many conversions fall under click-only versus click-plus-view rules. Looking at click-only results next to the default gives you an immediate sense of how much of your reported revenue depends on view-through credit — the part most likely to overlap with other channels. If a large share of a campaign's revenue only appears under view-through, treat that campaign's ROAS with extra caution until a holdout test confirms it.

On Google, the attribution model and window are set per conversion action. Data-driven attribution is the default for most actions and generally the right choice for bidding, because it uses your account's own path data. For reconciliation, what matters more is the click date versus conversion date distinction and making sure only one purchase action is primary.

Our rule of thumb: keep the platform's recommended settings for optimisation, add click-only and ‘by conversion time’ views for reporting, and make channel budget decisions on blended metrics. Changing attribution settings on live ad sets to make the numbers look closer to the store is the wrong fix; it changes what the algorithm optimises for without changing a single real order.

How to Reconcile Ad Platform Sales With Store Orders, Order by Order

Reconciliation means matching individual orders, not comparing totals. The key is that your purchase events carry the order ID — as event_id or order_id on Meta and as transaction_id on Google — so every platform conversion can be traced to a real order. If your tracking does not send the order ID today, fixing that is the first deliverable, because without it you can only estimate.

1. **Choose a closed window**, such as a fortnight that finished a week or more back, giving delayed purchases time to be reported. Record the time zone and currency each system uses. 2. **Export orders from the store** with order ID, created time, customer ID, gross product value, tax, shipping, discounts, payment method (prepaid or COD), fulfilment status, refunds and cancellations, plus any UTM or click ID data your store captured. 3. **Export platform conversions** at the finest level available: Google Ads conversions with transaction IDs via a report or the API; Meta purchase events from Events Manager or your server logs with event IDs; any server-side tracking logs you keep. 4. **Match on order ID.** Each platform conversion either matches a store order or does not. 5. **Classify unmatched platform conversions:** duplicates (same order ID twice), tests, modelled conversions without an ID, or orders that were later deleted. 6. **Classify unmatched store orders:** organic, email or direct orders the platform rightly does not claim; orders with ad click IDs but no platform conversion (signal loss); offline or marketplace orders. 7. **Compare values for matched orders.** Differences reveal tax, shipping, currency or discount inconsistencies. 8. **Apply refunds and failed deliveries** to matched orders to get net realised revenue per platform.

At the end you should be able to state, for each platform: how many of its claimed orders are real, how many are duplicates, how much value is tax and shipping, how much was later refunded or not delivered, and how many real ad-driven orders it missed. Those five numbers are the full explanation of your gap.

Purchase Mismatch Diagnosis Table

Use this table to match what you see to the most likely cause.

The Metrics That Settle the Argument: MER, New-Customer Revenue and Contribution Margin

Even with perfect tracking, platform ROAS will never sum to store revenue, because of overlapping attribution. That is why the teams that make the best budget decisions stop arguing about platform ROAS and adopt a small set of blended metrics alongside it.

- **MER (marketing efficiency ratio)** — total store revenue ÷ total ad spend, across all channels. It cannot double count, because both sides come from systems of record. Watch it weekly. - **New-customer revenue and new-customer CAC** — revenue from first-time customers ÷ spend. Platforms happily take credit for repeat customers who would have bought anyway; new-customer metrics strip that out. - **Contribution margin after ad spend** — revenue minus cost of goods, shipping, payment fees, returns and ad spend. A campaign with a beautiful ROAS on low-margin products can lose money; one with a mediocre ROAS on high-margin products can be your best investment. Our guide to reducing Meta catalogue spend on low-margin products shows how to act on this. - **Incrementality** — the revenue that would not have happened without a channel, measured through geo holdouts or platform lift studies. This is the only way to know a platform's true contribution; everything else is an allocation rule.

Use platform ROAS to compare campaigns and ads within each platform, because that is what the algorithm optimises on and it is internally consistent. Use MER, new-customer CAC and contribution margin to decide how much to spend in each channel. When the two disagree — a platform's own ROAS improving while MER falls — trust MER and investigate. Third-party attribution tools can help here; our Triple Whale vs Northbeam vs Hyros comparison explains what each does and does not solve.

How to Fix Purchase Tracking on Meta

On Meta, accurate purchase reporting depends on four things: one event per order, a consistent value, strong matching and server-side redundancy.

**One event per order.** Fire Purchase once, when the order is confirmed. If you run the browser pixel and the Conversions API together — which you should — send the same event_name and the order ID as event_id from both, so Meta deduplicates. On Shopify, choose one route: the official Facebook and Instagram channel app, or a dedicated server-side tool, not both plus leftover theme code. **Consistent value.** Decide whether value means product subtotal after discounts excluding tax and shipping (our recommendation) and apply it on every platform. Always send the currency code. If you sell in several currencies, send each order's real currency, not your account currency. **Strong matching.** Send hashed email and phone, external ID, IP address, user agent and the fbc and fbp values with server events, within your consent rules. Better matching recovers attribution for purchases the browser misses. Our CAPI troubleshooting guide explains how to read event match quality. **Server-side redundancy.** The Conversions API sends purchases from your server, so they survive ad blockers, closed tabs after payment and checkout redirects. For D2C brands on Shopify this is no longer optional; our Shopify CAPI and Andromeda guide covers the setup.

Meta does not accept refund adjustments to past purchases in the way Google does, so for Meta you handle refunds in reporting rather than in the platform: report net realised ROAS from your own data, and if refunds or RTO are concentrated in particular products or regions, act on that in the campaign — excluding high-RTO pin codes from COD, for example — rather than expecting Ads Manager to show it.

How to Fix Purchase Tracking on Google Ads

Google offers more tools to correct the record than Meta, and using them makes Google's reported value much closer to real revenue.

1. **One primary purchase action.** Audit Goals → Conversions. Exactly one purchase action should be primary for each sale; the others secondary. A GA4 import and a native tag both set to primary is the most common cause of Google double counting. 2. **Count ‘Every’ for purchases and pass transaction_id.** Every sale should count, and the transaction ID lets Google discard duplicates when the tag fires twice for the same order. 3. **Send the right value.** The same definition you chose for Meta — product value after discounts, excluding tax and shipping — with the correct currency code. 4. **Enhanced conversions.** Hashed customer data sent with the purchase improves matching where cookies fail. 5. **Conversion adjustments for refunds and cancellations.** Google lets you retract a conversion (removing it and its value) or restate its value, by uploading the order ID and conversion action through a spreadsheet or the Google Ads API. Google's documentation notes a retraction cannot simply be undone, so build the process carefully: retract full refunds and undelivered COD orders, restate partial refunds. 6. **Consent mode.** Implement it correctly so Google can model conversions from users who decline cookies — and remember modelled conversions will not match individual orders. 7. **Use ‘by conv. time’ for reconciliation.** These columns date conversions to the purchase, so they line up with your store. Keep the standard columns for judging bidding.

Done properly, conversion adjustments make Google's reported revenue a close proxy for net realised revenue, and Smart Bidding then learns from orders that stuck rather than orders that were later refunded. Our Google Ads conversion tracking guide covers the base setup.

Shopify-Specific Causes of Purchase Mismatch

Shopify stores share a set of failure modes worth checking explicitly.

- **Legacy scripts after checkout extensibility.** If purchase tags lived in the Additional Scripts box or checkout.liquid, they may have stopped running when your store moved to the new thank-you and order status pages. Move them to the official channel apps, a custom pixel or a server-side tool, and test. - **Duplicate apps.** It is common to find the Facebook and Instagram channel app, a third-party pixel app and hard-coded theme snippets all sending Purchase. Keep one route per platform. - **Custom pixel sandbox limits.** Custom pixels run in a sandbox and cannot do everything legacy scripts could; some third-party scripts will not run there. Check your vendor supports it. - **Shopify's own attribution reports.** Shopify reports sales by UTM and referrer using its own rules — typically last touch on the session that converted — so they will differ from every ad platform. That is another valid lens, not a referee. - **Draft orders, POS and wholesale.** Orders created manually, in-store through Shopify POS, or through B2B channels can appear in total sales but were never eligible for ad attribution. Filter them out of the comparison. - **Post-purchase upsells and subscriptions.** Upsell apps may add value after the initial Purchase fires; subscription apps create recurring orders. Decide whether these belong in the value you send and stay consistent.

India and Cash on Delivery: Reconciling RTO and Payment Gateways

For Indian D2C brands, the two largest sources of mismatch are not attribution at all. They are cash on delivery and payment redirects.

**Cash on delivery and RTO.** Platforms record a purchase when the COD order is placed. A share of COD orders are cancelled, refused at the door or returned to origin, and none of that reaches Meta or Google unless you send it. If a meaningful fraction of your COD orders fail delivery, platform ROAS overstates real return by that fraction on COD orders. Report prepaid and COD separately, calculate delivered revenue for each campaign, and retract undelivered COD orders in Google Ads through conversion adjustments. On Meta, consider sending Purchase only for prepaid orders and a separate event for COD orders that you confirm or deliver, then optimise towards the event that represents money in the bank — but test this carefully on a new campaign, because changing the optimisation event resets learning. **Payment gateway redirects.** Prepaid orders often route through Razorpay, PayU, Cashfree, Paytm or UPI apps. On mobile, customers frequently complete payment in a UPI app and never return to the browser thank-you page, so the browser pixel never fires. Server-side Purchase events triggered by your store's order webhook solve this, because they fire when the order is created regardless of where the customer ends up. **GST.** Indian prices are usually shown including GST. Make sure the value you send excludes it if your reporting definition does, or you will overstate revenue by the GST rate.

Brands selling into the UAE and Saudi Arabia see similar COD dynamics, and the same approach applies.

Build a Reconciled Revenue Scorecard

The goal is a weekly scorecard where every number has a declared source and nobody has to argue about which tab is right.

Watch the match rate for each platform month to month. A stable rate means measurement is consistent; a sudden drop usually means a tag broke, an app was installed twice or a checkout change landed — and it usually shows up here before anyone notices in campaign metrics.

Set a rhythm around it. Review the scorecard weekly with marketing and finance in the same meeting, so spend decisions and revenue reality are discussed together rather than in separate rooms with separate numbers. Run the full order-level reconciliation monthly. And re-run the twenty-minute test purchase whenever the scorecard's match rate moves sharply, because a tracking break caught in days costs far less than one discovered at quarter end.

Worked Example: A D2C Brand on Shopify (Illustrative)

Treat these numbers as a teaching example — they are invented to demonstrate the method, though every cause in them is one we meet regularly in audits. A D2C apparel brand in India spends on Meta and Google. For a closed 14-day window, Meta reports 1,180 purchases worth ₹21.2 lakh and Google reports 640 purchases worth ₹12.9 lakh — ₹34.1 lakh in total. Shopify shows 1,450 orders and ₹24.8 lakh in total sales including GST and shipping. Finance says delivered revenue, net of returns and RTO, is ₹18.6 lakh.

Order-level matching finds that about 9% of Meta's purchases are duplicates, because the channel app and a leftover theme snippet both send Purchase. Values on both platforms include GST and shipping, inflating each order by roughly a fifth relative to product value. Some 310 orders are claimed by both Meta and Google. 38% of orders are COD, and around a quarter of those are not delivered, none of which reached either platform. And 140 prepaid orders paid through UPI apps never fired the browser pixel but were caught by neither platform's server events, because none were configured.

After removing the duplicate route, changing value to product subtotal, adding server-side purchases from the order webhook, uploading Google retractions for undelivered COD orders and reporting overlap through MER rather than summed ROAS, the picture changes. Meta's reported ROAS falls but becomes trustworthy; Google's reported value moves close to delivered revenue; MER becomes the weekly headline; and the brand discovers that two campaigns with excellent platform ROAS were driving mostly COD orders with poor delivery rates — the most valuable finding of the exercise.

Common Mistakes When Ad Platform Revenue Doesn't Match Your Store

- **Adding up platform revenue.** It always exceeds real revenue in multi-channel accounts. Use MER for totals. - **Comparing gross platform value to net store revenue.** Define value once and use it everywhere. - **Sending order total including tax and shipping.** It inflates ROAS by the tax rate plus shipping. - **Ignoring refunds, cancellations and RTO.** Report net realised revenue and use Google conversion adjustments. - **Two primary purchase actions in Google Ads.** Every sale counts twice. - **Pixel and CAPI without shared event IDs.** Meta double counts. - **Leaving legacy Shopify scripts in place.** They may have stopped running, or may run alongside new apps. - **Reconciling on ‘last 7 days’.** Recent days are incomplete. Use closed windows. - **Using GA4 as the referee.** It uses its own cross-channel model; it is another lens, not the truth. - **Cutting a campaign on platform ROAS alone.** Check contribution margin and incrementality first.

If you want this done for you, our analytics and tracking and Conversions API engagements start with an order-level reconciliation like the one above, and the free tracking audit will tell you quickly how large your gap is and where it comes from.