Most advertisers spending real money on Meta and Google right now are not fighting the algorithm. They are quietly sabotaging it.
The platforms are willing to find them buyers. But the data going back is broken in specific, nameable ways, and a broken pipe is the same as no pipe.
Every day the setup keeps running, the algorithm trains on garbage, ads get more expensive, and scaling stalls.
So the question becomes: what exactly are advertisers doing wrong, and why does the algorithm punish them so quietly that nobody notices until the account is bleeding money?
The big one: the copy-paste pixel
Start with the mistake burning the biggest chunk of ad spend right now, because it lives inside a piece of code you probably copy-pasted from Meta 2 years ago and never looked at again.
You grabbed it from Events Manager, dropped it into your theme or clicked "Connect Pixel" in Shopify, checked the Pixel Helper, saw the green check, ticked tracking off the list. It looks like this:
<!-- Meta Pixel Code -->
<script>
!function(f,b,e,v,n,t,s)
{if(f.fbq)return;n=f.fbq=function(){n.callMethod?
n.callMethod.apply(n,arguments):n.queue.push(arguments)};
if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';
n.queue=[];t=b.createElement(e);t.async=!0;
t.src=v;s=b.getElementsByTagName(e)[0];
s.parentNode.insertBefore(t,s)}(window, document,'script',
'https://connect.facebook.net/en_US/fbevents.js');
fbq('init', 'YOUR_PIXEL_ID');
fbq('track', 'PageView');
</script>
<!-- End Meta Pixel Code -->And on the thank-you page, the default Purchase event most tutorials hand you:
<script>
fbq('track', 'Purchase', {value: 100.00, currency: 'USD'});
</script>Here is what is actually happening inside it.
The whole thing runs in the browser. Ad blockers, iOS Safari, Brave, and uBlock all recognize fbevents.js (the script which loads the Facebook Pixel) by name and block it before it even loads.
When we audit accounts, the typical loss is 40 to 60% of events every day, and with no CAPI catching what the browser drops, those events are gone for good.
Then look at the Purchase event itself. Value and currency. No email, no click ID, no event ID.
Facebook gets a notification that someone, somewhere, bought a thing worth $100. It cannot match the purchase to a person, cannot tie it back to the ad that drove it, and cannot dedupe it.
The value is hardcoded too, so the same $100 gets reported whether the order was $20 or $200.
The quiet account-killer though is the silent miss. The event only fires once the thank-you page loads.
Tab closed during the redirect, browser crash after payment, mobile network blip. The money is in your bank, the customer got their confirmation email, and Facebook never sees a thing.
So the green check proves almost nothing. The default snippet loses up to 60% of events to blockers, fires the rest without the data the platforms need to recognize a buyer, and silently misses every customer who closes the tab early.
The dedup trap
The next mistake is what happens once an advertiser tries the obvious fix, because the obvious fix doubles every purchase number in the account overnight.
Someone tells them they need CAPI. They wire up the server-side connection, check Events Manager the next morning, and purchases have jumped.
ROAS looks better than it has in months. They tell themselves the scaling problem is solved.
It is not.
Every sale is now counted twice, once by the browser pixel and once by the server, and the platforms do not handle that the same way.
Facebook will dedupe browser and server events, but only if you send a matching event ID with both. Skip it and Facebook treats every purchase as two separate sales.
Most accounts that "added CAPI" are running without that ID and silently doubling their data.
Google does not dedupe at all. Send both and you get duplicate conversions with no way to merge them. So pick server-side, because Google browser events get blocked the same way Facebook's do.
The pattern is always the same. Numbers look great for a week, then performance falls off, because the algorithm is optimizing on phantom buyers and hunting for more people who match a profile that does not exist.
So adding server-side without a matching event ID doubles your Facebook data, and adding it on Google duplicates outright, which means the "fix" trains the algorithm on sales that never happened.
Where does your tracking code live?
The next mistake is where the code lives, and it is the reason a lot of advertisers end up with duplicate events firing for months with no idea where they come from.
Picture 10 funnels with 5 pages each. Landing, checkout, upsell one, upsell two, thank-you. Tracking code pasted onto every page when the funnels were built.
50 snippets across the site. 6 months later the old setup stops working, a new layer of tracking goes in on top, and both fire on every page with no way to trace the duplicates.
The fix is one source of truth: funnel-wide header settings, or sitewide via Code Snippets or Fluent Snippets on WordPress.
The second flavor lives somewhere most advertisers forget to look: custom conversions created inside the Facebook dashboard, based on URL triggers.
They fire on every page load that matches the URL, which means every refresh and every share-link open. Someone sets them up, forgets, and later layers proper tracking on top.
The only way to kill the ghost is going back into the Facebook UI and digging it out by hand. This is almost always the source of the "extra" purchases nobody can explain.
So tracking belongs in one place at the funnel or site level, because the duplicates you cannot explain are almost always coming from a setup you forgot you had.
When do your events fire?
Where the code lives matters. When it fires matters more, because most setups are firing the most important event at the wrong moment and teaching the algorithm to find the wrong kind of person.
The standard tutorial wires the Purchase event to the "Buy Now" button click. One line of code, one event listener, one trigger. Clean.
And here is what that actually tracks. Every time someone clicks Buy Now. Not every time someone buys.
The click happens before everything that turns a click into a sale. Email blank. Card declined. Validation failed. Network dropped on submit. Customer closed the modal.
In every one of those cases the Purchase event already fired, the customer never paid, and Facebook has a sale logged against the ad that brought them there.
Multiply across thousands of clicks. The algorithm builds a profile of your buyers, except the buyers in the profile are not buyers. They are people who click and bail.
Facebook goes hunting for more of them, ROAS slips, CPMs climb, and most advertisers blame the creative.
So Purchase events should fire on successful payment, not on the button click, because every declined card and abandoned checkout teaches the algorithm to bring you more people who click but never buy.
What do your events carry?
The last mistake is what the event carries when it arrives, because even with everything else correct, the events themselves usually show up empty. And an empty event teaches the algorithm nothing.
Look at the default Purchase event from the top of this post again. Value, currency, nothing else.
That is what most setups send back every time a real customer buys, and it is why advertisers spend months convinced the platform is over-reporting or attribution is "fundamentally broken."
The platform is not broken. The event is empty.
Without an email, the platforms cannot match the purchase to a person. A purchase with no email is a purchase with no name.
Without a click ID, they cannot tie the sale back to the ad that drove it, so a customer who clicked your top ad an hour ago shows up as organic.
Without recency, the signal is stale by the time it arrives, and the auctions it would have informed are already over.
Now zoom out. Every mistake in this post is a different way of starving the same round trip.
The pixel without CAPI. The missing event ID. The scattered placement. The ghost conversions. The button-click triggers. The naked Purchase event. All variations of one failure.
Tracking is two-way. The pixel watching the site is half of it. The data going back is the half that drives optimization, and most setups are sending that half empty.
The ads are not the problem. The data feeding them is.
Once the events go back with an email and a click ID attached, the algorithm starts recognizing your buyers as real people, comparing them against everyone else in its index, and going out to find more of them.
That is the mechanism behind every "sudden scale" story you have ever heard.
Every mistake above is something TrueMetriks handles by default. The algorithm is willing to find you buyers. You just have to feed it data it can use.
