Stop Over-Reporting: Why Your Meta/Facebook Ads Conversions Don’t Match Google Analytics or Your CRM

How accurate is purchase tracking?

We’ve got over 100 sales tracked via meta, but can only 100% attribute about 50-60 of them to ads directly via UTM’s and discount codes.

If someone went to purchase, and the purchase failed for what ever reason. Would meta count it as a purchase still?

Trying to find out why theres a discrepency.

The short answer is:

What is the main cause of discrepancy between internal sales data and Meta purchase tracking?

Meta’s purchase tracking is notoriously inaccurate and almost always over-reports conversions because of its multi-touch attribution model and the unreliability of browser-based tracking.

A failed purchase should not be counted if your tracking is correctly configured to fire the Purchase standard event only on the final order confirmation page, but technical errors like duplicate tracking or an improperly placed Pixel can cause it to count.

The solution to fix the discrepancy and get a much more accurate number in Meta Ads Manager is to implement server-side tracking using the Facebook Conversions API with Server-Side Google Tag Manager and a server solution like Stape or Google Cloud Platform.

The long answer is:

The discrepancy you’re observing is a very common and frustrating experience for advertisers.

The 50-60 sales you can 100% verify are being credited by your internal systems, which likely use a last-click attribution model or direct verification via discount codes.

The 100 sales Meta reports are due to its generous default attribution window, which credits conversions that happen within a certain time frame after someone either clicks the ad (up to 7 days by default) or simply views the ad (up to 1 day by default).

If a user sees your ad, closes the app, and then searches for your brand and buys two days later, Meta will still claim that sale, but your UTM-based tracking will credit the search channel.

This fundamental difference in how Meta attributes credit compared to your internal sales data is the primary reason for the mismatch.

Regarding a failed purchase, Meta should absolutely not count this as a conversion.

The standard practice is to fire the Purchase standard event only when the final order confirmation page loads, which should only happen after the transaction is successfully recorded in your backend system.

If a user’s credit card fails and they are redirected to an error page, the Purchase event should not fire.

The fact that Meta may be counting failed purchases strongly suggests a technical misconfiguration, such as the Pixel firing multiple times on the thank you page due to a page reload, or perhaps an older Pixel being placed on a less-secure step of the checkout process.

Another major technical issue causing over-reporting is deduplication failure, which occurs when you are running both the browser-based Pixel and the server-side Conversions API, but you haven’t correctly implemented the unique event_id parameter to tell Meta to merge the two identical events.

To get the cleanest and most accurate data flowing to Meta for optimization, an excellent solution is to transition to server-side tracking using the Meta Conversions API, implemented via Server-Side Google Tag Manager, hosted on a platform like Stape or Google Cloud Platform.

This setup is a cheap and powerful way to address all the major technical causes of inaccurate tracking.

The Conversions API sends event data directly from your server to Meta, completely bypassing issues caused by ad blockers, cookie restrictions from browsers like Safari, and the opt-out policies from privacy updates like Apple’s App Tracking Transparency.

Server-Side Google Tag Manager acts as a control center, allowing you to centralize your tracking logic.

Your website sends one stream of clean data to your server, and then the Google Tag Manager server container transforms it and sends it to Meta via the Conversions API.

Stape is a particularly cost-effective choice for hosting the server container because it is specifically designed for this purpose, offering a managed, auto-scaling cloud environment that is significantly cheaper and less complex to maintain than setting up and managing your own server on Google Cloud Platform.

By sending data directly from the server, you can ensure the Purchase event only fires after your backend confirms a successful sale, you can reliably send more high-quality customer data parameters (like email and phone number) to improve Meta’s Event Match Quality, and you can ensure proper deduplication with your existing Pixel, leading to a much more accurate reported conversion number and better campaign optimization.

About The Author