Meta Events Manager Diagnostics Warnings Explained and Fixed

The Diagnostics tab in Events Manager is where Meta tells you that something about your pixel or Conversions API data could be better or is actively broken. The list can look alarming, especially on an older setup that has collected several layers of tracking code.

The wording of individual warnings changes over time, so this guide groups them by the kind of problem they describe. For each group you get what it usually means, how to find the root cause, and how to fix it.

How to read a Diagnostics warning

In Events Manager, select your pixel (dataset) and open the Diagnostics tab. Each issue typically shows a short title, which events it affects, and a recommended action. Before you act on one, collect four facts:

1. Which event? A warning on Purchase is more urgent than one on a rarely used custom event.
2. Which source? Browser (pixel) problems are fixed in your site code or tag manager. Server problems are fixed in your Conversions API integration.
3. How widespread? A warning affecting a small share of events can be an edge case. One affecting most events is a setup problem.
4. Is it current? Warnings can reflect recent days of data. If you fixed something today, give it time before expecting it to clear.

Prioritize warnings on the events your campaigns optimize for. Fixing a parameter on your Purchase event matters far more than tidying a ViewContent edge case.

1. Event match quality and customer information

Event Match Quality (EMQ) is a score out of 10 that estimates how well the customer information you send lets Meta match events to Meta accounts. Meta's setup verification guide shows it on the pixel's Overview, and recommends aiming for 6.0 or higher. Meta's Dataset Quality API documentation notes that EMQ applies to web events.

Warnings in this group usually say a customer information parameter is missing, has low coverage, or looks invalid. Common root causes:

• Server events without IP address and user agent. Browser events get these automatically, but server events don't. Meta's customer information parameters reference says client_user_agent is required for website events sent through the Conversions API, and recommends sending client_ip_address too. Neither may be hashed.
• Unhashed or badly normalized contact data. Email, phone and names must be normalized and hashed with SHA-256 before sending. Emails are trimmed and lowercased. Phone numbers keep digits only and must include the country code.
• Placeholder values. A dummy email such as noemail@example.com or a phone of all zeros, used when a field is empty, hurts matching. Meta's Dataset Quality API lists placeholder email and phone as diagnostic categories. Send nothing instead of a placeholder.
• Missing fbc or fbp. These are first-party cookie values set by the pixel. Read them on your server and pass them unhashed with server events. Meta recommends refreshing them regularly, since they can change.
• Server IP instead of visitor IP. If your server sends its own IP, or a proxy's, every event looks like it comes from one place. Read the visitor IP from the incoming request, respecting your proxy or CDN's forwarded header.

A normalized and hashed email in Node.js looks like this:

const crypto = require('crypto');

function hashEmail(email) {
  const normalized = email.trim().toLowerCase();
  return crypto.createHash('sha256').update(normalized).digest('hex');
}

Full rules for each field are in Meta's customer information parameters reference.

2. Domain warnings

Domain-related warnings say events are arriving from a domain you didn't expect, or from a URL that doesn't match your verified domain. Typical causes:

• Your pixel code is on someone else's site. A copied theme, a former agency's test site, or a scraper can carry your pixel ID and send events in your name.
• Staging or development sites. A staging copy with the production pixel sends test traffic into your real data.
• Server events with the wrong source URL. Meta's server event reference says event_source_url should match the verified domain, and it's required for website events sent through the Conversions API. A server that sends an internal hostname or its API URL causes mismatches.
• Checkout or booking on a third-party domain. Hosted checkouts, booking tools and form providers may fire your pixel from their own domain.

Fix: for unwanted domains, remove the pixel from staging and ask previous agencies to remove it. Events Manager's pixel settings also offer traffic permissions, where you can keep an allow list or a block list of domains. Be careful with allow lists: if you forget a domain you rely on, such as a hosted checkout, its events are rejected. For server events, set event_source_url to the actual page URL the visitor was on.

3. Deduplication warnings

If you send events through both the pixel and the Conversions API, Meta expects to match each pair and keep one. Warnings in this group mean too few pairs matched, or one side isn't sending deduplication keys.

Meta matches on the browser eventID and the server event_id, plus identical event names, within 48 hours of the first event with that ID. Common root causes:

• The browser pixel doesn't pass eventID at all.
• Browser and server generate their own IDs instead of sharing one.
• Event names differ, such as Purchase versus purchase.
• Server events are sent in delayed batches and arrive outside the window.

To dig in, open the event's details from the Overview and check its Event Deduplication tab, which shows the deduplication rate and how often each source sends each key. The full walkthrough is in Pixel and Conversions API deduplication.

4. Missing or invalid parameters

These warnings say an event is missing a parameter Meta needs, or has one in the wrong format. The most common is Purchase without a usable value or currency. Meta's pixel reference lists both as required for Purchase, and the Conversions API expects currency as an ISO 4217 code. If you use Advantage+ catalog ads, Meta also requires contents or content_ids on certain events so they can be matched to catalog products.

Fix: inspect the real event in DevTools (custom data appears as cd[value], cd[currency] and so on in the request to facebook.com/tr) or in your server logs. Then correct the template or tag that builds it. See missing value and currency parameters for examples.

5. Restricted or sensitive data

Meta may flag events whose URLs or parameters appear to contain information its business tools terms don't allow you to share, and may block those parameters. Typical sources are form values or customer details that end up in page URLs, custom parameter names that carry personal data, or event names that describe a sensitive condition.

Fix: find where the flagged data comes from. Common culprits are forms that submit with GET (putting fields in the URL), thank-you page URLs with names or emails in the query string, and custom parameters copied wholesale from a CRM. Remove the data at its source rather than trying to filter it in the tag.

6. Server and connection problems

When the Conversions API stops sending, Diagnostics may report that server events dropped or stopped. Meta's Conversions API troubleshooting notes that a valid payload returns a 2xx response and an invalid one returns a 4xx. Check your integration's logs for error responses, expired or revoked access tokens, and events older than seven days, which Meta rejects.

How to verify the fix

1. Reproduce one affected event after your change and inspect it, either in DevTools for browser events or in your server logs for Conversions API events.
2. Use the Test Events tab to confirm the corrected event arrives with the expected parameters. Our Test Events guide explains how.
3. Watch the Overview metrics, such as the deduplication rate and Event Match Quality, over the following days.
4. Return to Diagnostics after a few days. Warnings tied to older data take time to clear as new events replace it.

FAQ

Do I need to fix every Diagnostics warning?

No. Start with warnings on the events you optimize campaigns for, and with anything about blocked or restricted data. Minor warnings on rarely used events can wait.

I fixed the issue but the warning is still there. Why?

Diagnostics evaluate recent data, so warnings usually persist for a while after a fix. Confirm the fix with Test Events, then check back in a few days.

Why is my Event Match Quality low when the pixel works fine?

The pixel can fire perfectly and still send little customer information. EMQ improves mainly by sending more valid, properly hashed customer parameters, especially on server events.

Can someone else send events to my pixel?

Yes, the pixel ID is visible in your page source. Traffic permissions in your pixel settings let you restrict which domains Meta accepts events from.