/

/

Server-side

Server-side

/

/

Meta conversions dropped suddenly, what happened?

Meta conversions dropped suddenly, what happened?

Server-side

Server-side

Meta conversions dropped suddenly, what happened?

Meta conversions dropped suddenly, what happened?

Rhobin

Rhobin

July 31, 2026

July 31, 2026

7 min read

7 min read

A sudden drop in Meta conversions is usually a measurement break rather than a sales break, because Meta reports website conversions on the day the conversion happened, so the number does not simply fill in later. Check the client's own order or lead record first: if that held while Meta fell, look at a Conversions API rollout, a reprioritised event configuration, lost match parameters, or a new consent banner.

A sudden drop in Meta conversions is usually a measurement break rather than a sales break, because Meta reports website conversions on the day the conversion happened, so the number does not simply fill in later. Check the client's own order or lead record first: if that held while Meta fell, look at a Conversions API rollout, a reprioritised event configuration, lost match parameters, or a new consent banner.

The symptom

Ads Manager opens on a number that is clearly wrong. Conversions well down on last week, spend exactly where you left it, clicks and cost per click normal, nothing in the change history, no red errors in Events Manager.

The client noticed first, or will within the hour, and the question is always the same: did the ads stop working? "We are looking into it" does not survive two of those calls.

The tell sits outside Meta. Pull the order count from the shop, or the lead count from the CRM, for the same dates. If that held while Meta's number fell, the sales did not drop, the record of them did, and creative fatigue, seasonality and learning phase resets are all out.

Why did Meta conversions drop overnight?

A sudden drop nearly always has a change behind it, and on Meta that change sits in the measurement path more often than in the market. Which one applies depends on what changed in the account and on the website that week, so read this as the order to check, not a ranking.

The attribution answer is borrowed from another platform

"Give it a few days, attribution will catch up" is the first reply in every forum thread. On Google Ads it is often right, because a conversion is credited back to the date of the click, so recent days genuinely fill in. Meta does not report website conversions that way. Announcing the iOS 14 changes in January 2021, Meta put it directly: "Offsite conversion events will be reported based on the time the conversions occur and not the time of ad impressions." A dip on Tuesday is a dip in conversions that happened on Tuesday.

What does move the count is the attribution setting, which Meta's reporting reference defines as an interval after the interaction, "7 days after clicking the ad" or "1 day after viewing the ad". It sits at ad set level, and its default became 7-day click and 1-day view with that same change. Duplicate an ad set or inherit a template with a shorter window and you are comparing two different measurements, so the drop is arithmetic.

Somebody connected the Conversions API last week

This one catches good teams, because the work was right in intent. The browser copy and the server copy of one purchase have to be recognised as a single event, and that only happens under conditions. Meta requires matching event IDs and event names, and adds a timing constraint: "events are only deduplicated if they are received within 48 hours of when we receive the first event with a given event_id".

Two very different stories make the same shape on a chart. If the identifiers never lined up, both copies counted, the earlier weeks were inflated, and the drop is the number returning to what it always was. If deduplication is working, the same documentation records the protective half: a server event is not discarded merely because no browser event arrived. That asymmetry is the case for collecting server-side, and it is why enhanced conversions and the Conversions API underdeliver on finished-looking setups.

The event configuration was quietly reprioritised

Meta introduced Aggregated Event Measurement to keep measuring web events under Apple's tracking prompt, and it ships with a ranking. In the same announcement, Meta capped it at "8 conversion events per domain ... for campaign optimization" and noted that when someone completes several, "only the higher prioritized event will be reported". A tidy-up in Events Manager, or one new event on a full list, can push Purchase down the order and change what is reported with nothing changing on the website. That post also states that "delivery and action breakdowns will not be supported for offsite conversion events", so teams often cannot segment their way to the answer.

Match quality fell and nothing turned red

Events arriving is not events counting. Meta scores the customer information on a server event out of 10, and is blunt about the bottom of that scale: unmatched events cannot be used "for attribution or ad delivery optimization", though they keep value "for basic measurement". So a release that stops passing one identifying parameter takes conversions out of the attributed number while events keep flowing and Events Manager stays green. Nothing raises an alarm, which is how a dip like this gets explained with bidding theories for a month.

The browser and the banner

  • Cookie lifetime. WebKit caps what Safari remembers: "all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry". Cookies set by a server in an HTTP response are not affected, and that is the whole difference between the two approaches.

  • Link tracking protection, stated accurately. Apple removes tracking parameters from "the links users share in Messages and Mail" and from "links in Safari Private Browsing". That is the real scope, not a blanket removal on every Safari ad click, though the overstated version circulates widely.

  • Blocking at the source. Ad blockers strip 30 to 40% of events before they leave the browser, a property of the audience rather than the campaign.

Then the banner. A consent tool deployed or reconfigured that week can produce the drop on its own, because in the EU the rule is not optional: under Article 5(3) of the ePrivacy Directive, storing or accessing information on a user's device "is only allowed on condition that the subscriber or user concerned has given his or her consent". A pixel that used to fire before a choice was made and now waits for one reports fewer conversions by design, and a refusal stays uncollected.

What good looks like

Run the triage before anyone proposes a project. Three numbers for the same dates: what the client's own system recorded, what Meta reported, what Events Manager received. The pair that diverged names the problem. Orders down too, and this is a sales conversation, not a tracking project. Orders and events steady while Meta's figure fell, and you are in attribution settings or event priority. Orders steady but events down, and collection is losing data on the way out. Same triage as a rising CPA when nothing changed, from the conversion side.

Where collection is the answer, Archon Signal is the fix. Collection moves onto the client's own domain and runs server-side, so the event is recorded by a server instead of left to a browser that may block it, and it reaches Meta with the detail needed to match and attribute it. Against a baseline where 15 to 30% of conversions are never captured, a properly configured server-side setup recovers 15 to 40% more than a browser-only one, and the next sudden drop becomes diagnosable rather than debatable.

Two limits belong in the same breath. Roughly 95% of events is the honest ceiling on any setup, a ceiling and not a promise, because consent refusals stay uncollected by design and an identifier the browser stripped before the request arrived is gone for good. What the browser refuses to store and what a blocker intercepts are recoverable, and usually the larger share, so the whole loss is not an iOS tax.

Frequently asked

What do I tell the client today, before we know the cause?

Give them the comparison that already exists: their own order or lead count next to Meta's reported conversions for the same dates. If their record held, say plainly that the sales did not drop and the reporting did, that you are isolating which cause it is, and when you will report back. That beats a theory, and it stops a budget decision being made on a reporting artefact.

We already run the Conversions API, so why did this happen to us?

Because having the tool is not the same as having it right. The two versions we repair most often are events that were never deduplicated against the browser copy, which inflates the earlier weeks, and server events too thin on identifying detail to be attributed at all. Both look fine from the outside, which is why they run for months.

Will the conversions come back once this is fixed?

Reporting corrects quickly, because sales that were already happening start being recorded again. The commercial effect is slower, since delivery has to relearn from a signal that now includes buyers it had written off. And if the cause was an inflated earlier period, nothing comes back: the outcome is a lower, correct baseline, which is worth more than a flattering one.

If Meta conversions dropped in an account and nobody can say whether the sales or the signal moved, request a free tracking audit and we will measure it on one real account.

ArchonLabs

Marketing intelligence agencies run for their clients.

© 2026 Archon LabsPrivacyTermsBehind your agency, not in front of it.