Meta Ads CPA Spiked After April 29? Fix Event ID Before You Touch Bids
If your Purchase coverage and dedupe started falling while CPA climbed, do not start by rebuilding campaigns.
Start with event identity. A broken event_id contract can make good traffic look expensive, undercount server coverage, and teach Meta on noisy conversion data.

If this sounds familiar
- CPA jumped even though budgets, audiences, and offers did not change.
- Events Manager shows lower coverage or dedupe for Purchase, Lead, or InitiateCheckout.
- Event Match Quality looks flat, but coverage is sliding.
- iOS in-app browser traffic shows odd
pcm_-style identifiers or empty event IDs. - Pixel and Conversions API events both fire, but Meta does not deduplicate them consistently.
This is usually a signal-quality problem before it is a media-buying problem.
What likely changed, and what to check first
April 29 is a breakpoint, not a diagnosis
A lot of advertisers saw the same shape around April 29: coverage fell, dedupe weakened, and CPA rose. I would not treat one rumored cause as proven across every account. But the first debugging path is clear: verify the event contract before changing campaigns.
Meta's own Conversions API documentation is explicit about the dedupe model: the browser event and server event need the same event name and the same event identifier. Pixel sends this as eventID; Conversions API sends this as event_id.
1. Do not let pcm_ replace your canonical event ID
If your checkout, form, or plugin layer has a real first-party identifier, use that.
Good examples:
order_9182lead_493022- a generated UUID stored before browser and server dispatch
Risky examples:
- empty
event_id - a browser-only generated value that the server never sees
- a
pcm_value becoming the canonical ID when your own ID should exist
For iOS in-app browser traffic, be extra strict. If a Meta-generated or privacy-related value appears where your first-party event ID should be, preserve your own ID and pass it through both channels.
2. Match browser and server exactly
For dedupe, close is not enough.
- Browser:
fbq('track', 'Purchase', data, { eventID: 'order_9182' }) - Server:
event_name: 'Purchase',event_id: 'order_9182'
The ID should be generated once, stored once, and reused. Do not generate a fresh UUID on the server after the Pixel already fired a different one.
3. Send as much lawful match data as you can collect
Event Match Quality improves when Meta can match an event to a person with confidence. Send clean user_data where you have permission and a valid basis:
client_ip_addressclient_user_agentfbcandfbp- hashed
emandph - hashed
fn,ln,ct,st,zp,country external_idwhen you have a stable customer or lead ID
Do not invent values. Do not send data you should not process. But do not starve Meta when the data is already available at purchase or lead submission.
4. Keep events simple
Most broken accounts are not missing ten more events. They have too many competing event sources.
One Purchase trigger. One matching server event. One event ID. One source of truth for user data.
Sources checked:
- Meta Conversions API deduplication documentation
- Meta Conversions API server event parameters
- Meta customer information parameters
- Meta Engineering: Andromeda ads retrieval engine
- AdExchanger: What Meta's Andromeda update changes

What this costs when left unresolved
- Server events lose credit because the browser/server pair cannot be reconciled.
- Duplicate events inflate or confuse conversion feedback.
- Weak user data reduces match confidence, especially on iOS and in-app browsers.
- High CPA decisions get made from a corrupted event stream.
- Creative and bid tests become hard to trust because the conversion signal is unstable.
Bad dedupe does not just make reporting ugly. It changes what Meta learns from.
What good looks like in practice
- Each conversion has one canonical first-party
event_id. - Pixel and CAPI send the same event name and event ID.
- Server coverage is high enough to survive browser loss.
- User data includes click IDs, browser context, and hashed customer fields when available.
- Purchase, Lead, and InitiateCheckout are clean, limited, and easy to audit.
Once identity is stable, then campaign and creative work becomes meaningful again.
Why campaign tweaks will not fix this
This is exactly why we built UTM Grabber
UTM Grabber helps preserve campaign, click, and source context so your server-side conversion layer starts with cleaner first-party attribution data.
- Capture UTM and click IDs before browser privacy rules erase context.
- Pass source data into forms, orders, and CRM records.
- Keep attribution fields stable enough for CAPI, reporting, and revenue analysis.
Who should run this audit now
- Ecommerce teams seeing Purchase dedupe or coverage decline.
- Lead-gen teams using Meta Pixel plus Conversions API.
- Agencies managing accounts with iOS in-app browser traffic.
- WooCommerce and WordPress teams using multiple tracking plugins.
- Growth teams trying to separate signal loss from creative fatigue.
If CPA moved suddenly, do the boring signal checks before the expensive campaign rebuild.
What real users are saying
Start by stabilizing event identity, click IDs, and source data.