Open Events Manager on almost any ad account and you'll find a stack of yellow triangles. Meta's alert copy explains almost nothing: no severity, no priority, no cost. The same eight or nine warnings show up on nearly every account I audit. Here's what each one means.
| Fix first — corrupts data | Fix next — costs money | A nag, not a fire |
|---|---|---|
| Events received without event_id | Low event match quality | 'Set up Conversions API' banner |
| Double-counted purchases | Missing value or currency | 'Enable advanced matching' |
| Inflated ROAS you then scale | Browser/server parameter mismatch | URL not owned, domain unverified |
| Delayed events, bad event_time | Nothing broken — Meta wants data | |
| Missing _fbp and _fbc |
Which Events Manager warnings should you fix first?
Fix deduplication warnings first, event match quality second, everything else third. Dedup problems actively corrupt your numbers, so every decision built on them is wrong. Match quality problems waste budget quietly. The rest is cleanup.
| Warning | Severity | What it costs you |
|---|---|---|
| Events received without event_id | Critical | Double-counted purchases, inflated ROAS |
| Low event match quality | High | Fewer attributed conversions, higher CPAs |
| Missing value/currency on Purchase | High | Value optimization stops working |
| Browser/server parameter mismatch | Medium | Deduped survivor may carry wrong data |
| Delayed events / event_time issues | Medium | Late or rejected conversions |
| Missing _fbp/_fbc on server events | Medium | Weaker matching for anonymous visitors |
| URL not owned / domain not verified | Low–Medium | Config restrictions; rarely a real ownership issue |
| "Set up Conversions API" banners | Informational | Nothing broken; Meta wants more data |
- One real order — A single checkout completes
- Pixel sends Purchase — No event_id attached
- CAPI sends Purchase — Different payload, still no event_id
- Meta counts two — Nothing to match on, so both survive
- Same ID on both — Order ID as event_id, matching event_name
What does "events received without event_id" mean?
Meta is receiving the same event from two channels, usually the browser pixel and the Conversions API, and can't tell they're the same event because there's no shared event_id. So it counts both. One real purchase becomes two Purchase events, ROAS inflates, and Meta optimizes toward duplicated signals. This is the most damaging warning on the list. The fix is mechanical:
- Generate one unique
event_idper conversion (an order ID works well for Purchase). - Send that exact ID on the pixel event and the server event, same
event_name. - Verify in the event's details in Events Manager: deduplicated browser and server counts, not two separate totals.
| Layer | What sits there |
|---|---|
| Inputs | Hashed email from the order, Hashed phone, _fbp and _fbc cookies, Client IP and user agent, external_id |
| Your server event | Carries nothing automatically — you attach every parameter yourself |
| Destinations | EMQ rated good or great, More attributed conversions, Lower CPAs, Anonymous traffic matched |
Why is my event match quality low, and how do I raise it?
EMQ is low because you're not sending enough customer information parameters for Meta to match events to real accounts. Meta scores each event on its 0–10 scale, driven almost entirely by which identifiers ride along: hashed email, hashed phone, the _fbp and _fbc cookies, client IP, user agent, external_id.
Browser and server events earn EMQ differently:
- Browser (pixel) events automatically carry
_fbp,_fbc, IP, and user agent, but only include email or phone with advanced matching. For anonymous traffic, the browser's ceiling is low. - Server events carry nothing automatically. You attach every parameter yourself. That's the advantage: at purchase time your server knows the customer's email and phone from the order, data the pixel never had.
If your server EMQ trails your browser EMQ, your setup is dropping parameters, usually IP, user agent, or _fbp. Email is the heaviest lever; hashed email plus phone plus _fbp typically moves a Purchase event into the range Meta labels as good.
Why is Meta warning about missing value and currency on Purchase events?
Because without value and currency, Meta can't run value optimization or report ROAS: a $9 order and a $900 order look identical to the bidding system. Send value as a plain number and currency as the three-letter ISO code, on both the pixel and CAPI copies, and make sure they match.
What about mismatched parameters between browser and server events?
Dedup is working, but the two copies disagree: different value, currency, or content_ids under the same event_id. Meta keeps one and discards the other, so whichever side is wrong has a coin-flip chance of becoming your data of record. The usual culprit is a server event built from a webhook that computes the total differently (tax and shipping on one side but not the other). Compute the total, currency, and product IDs once and share them with both channels.
Why does Events Manager say my events are delayed?
The gap between event_time and when Meta received the event is too large. The Conversions API rejects events older than 7 days outright, and shorter delays still blur attribution and slow delivery optimization. Common causes: batch jobs uploading conversions once a day, webhook queues retrying for hours, and servers stamping event_time with the upload time instead of the purchase time. Send events in near real time, stamped with the moment the conversion actually happened.
What does "reduced performance due to missing fbp or fbc" mean?
Your server events aren't carrying Meta's own cookies. _fbp is the browser identifier Meta's pixel sets for every visitor; _fbc stores the click ID after someone lands with an fbclid in the URL. For visitors who never log in or buy, these are often the only identifiers available, so events without them match poorly for exactly the anonymous traffic you paid for. Read both cookies and pass them into your server events; if _fbc is missing but the URL had an fbclid, construct the fbc value from it, which Meta's CAPI docs support.
What does "events received from a URL you don't own" mean?
Events are arriving from a domain that isn't verified in your Business Manager. Verify it under Business settings, Brand safety, Domains, and the warning clears. Verification mattered most during the Aggregated Event Measurement era after Apple's ATT; Meta has since wound AEM down, but it still controls who can edit event configurations for your domain. If the URL genuinely isn't yours, look closer: usually a staging site or third-party checkout, occasionally someone who copied your site template, pixel included.
Why did my EU event volume drop after our consent banner went in?
Because your consent management platform is doing its job. In the EEA, Meta requires a consent basis for processing, so a CMP that blocks the pixel until the visitor accepts will visibly cut European volume. "Fixing" it by firing the pixel before consent trades a data problem for a legal one. What you can fix: track consented visitors reliably, through a server-side channel that ad blockers and tracking prevention can't eat. You won't recover the people who said no. You can recover the ones who said yes and got lost anyway.
Which Events Manager warnings are just Meta asking for more data?
A decent share of them. The "Set up the Conversions API" banner, the "enable automatic advanced matching" prompt, and the "share additional parameters" recommendations are not error states. Nothing is broken. Meta wants more data, because more data helps Meta, and often, though not always, helps you too.
My honest read: the CAPI prompt is worth acting on, because browser-only tracking genuinely undercounts in 2026. The rest are product suggestions, not alarms. The test is simple: do your Ads Manager conversion counts match your backend? If yes, the yellow triangle is a nag, not a fire.
Why does first-party server-side tracking clear most of these warnings at once?
Because nearly every warning above traces back to one root: relying on a pixel running in a browser you don't control. Server-side tracking changes the architecture. Instead of the browser being your only messenger, a server container (we build ours on Google Tag Manager, on your own subdomain, so the data stays first-party) receives each conversion and sends it to Meta's Conversions API directly.
That one change touches the whole list. You generate the event_id in one place and stamp it on both copies, so dedup warnings disappear instead of being patched. You enrich server events with hashed email, phone, _fbp, _fbc, IP, and user agent, which is exactly what raises EMQ. Events fire in real time with correct event_time values, so delayed-event notices stop. Ad blockers and Safari's tracking prevention can't reach a first-party server endpoint, so the conversions Meta receives finally match the orders in your backend. And because the server is one controlled pipe, you decide exactly what gets shared, and only for consented visitors.
Put simply: your current setup asks every visitor's browser to report your sales, and browsers increasingly refuse. Server-side means your own infrastructure reports them instead.
Frequently asked questions
How does Meta deduplicate browser and server events?
Meta matches events sharing the same event_name and event_id within a roughly 48-hour window, keeps the first copy received, and discards the later one. If either the ID or the name differs, both get counted.
What is a good event match quality score in Events Manager?
Meta scores EMQ from 0 to 10 and labels ranges from poor to great; you want key events rated good or great. Purchase events carrying hashed email, phone, and _fbp usually get there.
Do I need to fix every warning in Events Manager?
No. Fix deduplication immediately, match quality and missing value/currency next, the rest as maintenance. Banners suggesting CAPI or advanced matching are recommendations, not errors.
Why did my purchase count suddenly double in Ads Manager?
Almost always broken deduplication: a new CAPI integration went live without sharing the pixel's event_id, so Meta counts each purchase twice. Look for the "events received without event_id" warning on Purchase.
Is domain verification still required for Meta ads?
Yes. Even with Aggregated Event Measurement wound down, verifying your domain in Business Manager clears the "URL not owned" warning and controls who can configure events for your domain.
Can I ignore the "set up Conversions API" banner?
You can, but you shouldn't. It's a recommendation, not an error, yet browser-only tracking measurably undercounts because of ad blockers and browser privacy features, so CAPI through a first-party server-side setup is baseline practice now.
- events manager
- meta ads
- emq
- debugging
WhatsApp