One of our clients came to us because his purchases weren't tracking properly. He's using TrueMetriks with a custom setup, so we'd already handed his developer the step-by-step guide for wiring custom tracking the right way.
The developer built it. Then the client came back and told us the numbers were wrong. Sales were happening in the backend but he couldn't see them inside TrueMetriks or Facebook ads dashboard.
We knew right away it wasn't our tool. The tool reports what it's handed, nothing more.
So a gap like this can only live in one place: how the events were wired on his site. We asked for access, went in, and started debugging.
It took us about ten minutes to find the issue. His developer hadn't fired the purchase event after each purchase.
He'd accumulated all of them and waited, firing a single event only once the buyer reached the final thank-you page. One event, at the very end, for the whole journey.
This client was running a funnel with this structure: a front-end offer, then three one-click upsells, with downsells in between. That's a long road.
Every extra step is another door the buyer can walk out of. So the more upsells stacked up, the more buyers bought one or two things and then closed the tab before they ever reached that final page.
Those buyers were ghosts. They paid. Real money moved. But because the event only fired on a page they never reached, nothing ever recorded the sale.
Meta never heard about it. The dashboard never showed it. The sale was real and invisible at the same time.
So here's the proper way to track, and it's the opposite of what his developer did:
Fire the purchase event each time a purchase actually happens, not once at the end. Easy to say. But it points straight at a mistake almost everyone running upsells makes...
Almost everyone makes one of two versions of this mistake
Here's what most advertisers do with the tracking Pixel code:
They wire the purchase code to a PAGE instead of to the PURCHASE event itself, and it comes in two ways.
The first way is the one the client had. The purchase code lives on the thank-you page only. Batch and wait.
And it under-reports in two separate ways. First, every buyer who bails before the thank-you page is never reported, and the more upsells you stack the worse the leak gets.
Second, the value is unknowable. Say your front-end is $20 and your upsell is $100. One event firing on the thank-you page can't tell you whether that person spent $20 or $120.
So the number sent to Meta is a guess. Even the sales you do report carry a corrupted value.
The second way goes the other direction. The purchase code fires on page load.
Walk the funnel: front-end, checkout, upsell 1 page, upsell 2 page, thank you. The event fires the moment the upsell-1 page loads, then again when upsell-2 page loads and finally one more time when the thank-you page loads.
Which means it fires for everyone who lands on these pages.
And everyone lands there, because buyers get redirected to upsell 2 page whether they bought upsell 1 or declined it. The code has no way to tell "bought" from "skipped."
Same trap if the event sits on the thank-you page, which everyone reaches no matter what they purchased along the way. So you report purchases that never happened.
That second mistake is a real, self-inflicted source of the "Meta is over-reporting my sales by 30%" complaint.
The 30% isn't Meta inventing sales to look good. It's your own event firing on a page everyone loads.
One mistake hides sales that really happened. The other invents sales that never did.
And the over-reporting most advertisers blame on Meta is usually their own purchase event firing on a page everyone loads.
Both mistakes are the same root error
Under-reporting and over-reporting feel like opposite problems, which is exactly why advertisers chase them in opposite directions.
They're the same mistake pointed two different ways, and once you see the root you stop chasing symptoms.
Treating them as two separate fires is the trap. "Meta sees too few of my sales" sends you hunting for missing data.
"Meta sees too many of my sales" sends you hunting for phantom data. Two investigations, opposite directions, and they never meet.
But look at what both flavors actually do. Both wire the event to where the visitor is standing instead of what the visitor bought.
Page location stands in for a purchase. And page location is a lie about purchase.
A page can load without a sale. A sale can happen without that page loading.
The moment you let the page speak for the buy, you've handed Meta a number that has nothing to do with money.
This means that under-reporting that's been costing you sleep and the over-reporting that's been costing you sleep both trace back to the same single code wiring choice.
The rule: when it's one event and when it's several
So if a page isn't the trigger, what is?
Most people assume it's one customer, one sale, one event. So the idea that a single funnel could ever need more than one event feels wrong.
Let me give you an example so you can see exactly where the line sits.
Five products bought together in one checkout is one event. It's a single buy decision, a single transaction, one moment money changes hands.
Doesn't matter how full the cart is.
An order bump on the checkout page is part of that same front-end purchase. Still one event.
The buyer ticked a box during the same checkout. Same transaction.
But each one-click upsell is its own separate event. It fires on the actual buy, and it carries that purchase's actual value.
The upsell is a new decision, a new charge, a new moment money moves. So it earns its own event.
So a funnel with a front-end plus two upsells can legitimately fire three purchase events for one person.
Each one fired the moment it happens. None of them batched at the end.
One checkout is one event no matter how many products are in the cart, but every one-click upsell is its own event fired the moment that purchase happens, so one person moving through a front-end and two upsells should fire three purchase events, not one.
The self-diagnostic you can do today
And here's the part you can use today, without reading a line of your funnel's code.
You need one question, and you ask it at every point in your funnel where money actually changes hands.
The question is this:
How does a purchase event trigger in this funnel? Does it trigger when the page loads, or does it trigger when the purchase actually happens and money leaves the customer's credit card carrying the data such as email, Facebook click ID, product ID and product value as parameters which Facebook requires that you send along with the purchase event?
Walk your funnel step by step and ask it at each one.
Two signatures tell you it's broken. A real buy with no event firing on it means you're leaking sales.
An event firing on a page everyone reaches means you're inventing them.
That's the whole check.
And going back to our client, our tool (TrueMetriks) wasn't broken. Neither was Facebook.
Instead the event was wired to the wrong thing, and once we wired it to the actual purchase event instead of the thank you page, the sales that had been disappearing came back into view.
Nothing about TrueMetriks changed, the only thing that changed is what it was told to do.
Your ads dashboard has been honest the whole time. It reported exactly what it was handed.
The trouble is it was handed a dishonest signal, and a dishonest signal reported faithfully still comes out wrong.
The number was never the problem. The wiring underneath it was. And now you know exactly where to look.
