Meta Events Manager settings
Meta Events Manager carries a handful of switches that let Meta collect events on its own, in parallel to whatever tracking your website runs. They exist for shops that have no proper pixel implementation. Once the Pixel Manager is installed, every one of those events already arrives, deduplicated and with the correct value, so Meta's own collection adds nothing and in several cases actively corrupts your numbers.
This page is the complete list of what to set, and what to leave alone. It also covers the Diagnostics cards Events Manager shows next to those settings, which are the other thing merchants act on when they should not.
Turn Automatic events off, never use the Event setup tool, and disconnect Meta's Conversions API Gateway. Leave Automatic Advanced Matching on. Everything else can stay as it is.
The settings at a glance
Unless the row says otherwise, everything below lives under Events Manager → Data sources → your dataset → Settings.
| Setting in Events Manager | Set it to | Why |
|---|---|---|
| Automatic events, also shown as Track events automatically without code | Off | Meta fires its own Purchase from the page markup, and it cannot be deduplicated against yours. |
| Event setup, and the Set up the selected events for me button under Manage Events | Never use it. Delete rules that are already there | Click rules fire events with no event ID and usually no value. |
| Automatically include more detailed page and product info (microdata) | Either. Off is marginally tidier | Meta reads prices and titles off the page. It never changes the values the Pixel Manager sends. |
| Automatic Advanced Matching | On | Works alongside the Pixel Manager's own advanced matching. No conflict. |
| Conversions API Gateway (OpenBridge), under Settings → Integrations | Disconnect | A second server-side sender that only mirrors what the browser already sent. |
| Leftover integrations under Settings → Integrations: WordPress, partner connectors, plugins you removed | Remove the ones you no longer use | A connection Meta holds on its side outlives the plugin that created it. |
| Data source categories and event blocking | Leave alone unless events go missing | Only relevant if Meta has classified your shop into a restricted business category. |
| Domain verification, Aggregated Event Measurement, event priority | Leave as they are | These affect attribution and iOS measurement, not what is collected. |
Automatic events
Meta's Automatic events, shown in some views as Track events automatically without code and known internally as automatic event detection, inferred events or microdata events, lets fbevents.js scan the page's structured data shortly after PageView fires and send its own events based on what it finds.
On an order confirmation page that means a second Purchase. It is constructed inside Meta's own library, after the Pixel Manager has handed off, so no plugin can intercept it. You can recognise it by its event ID, which looks like pmw_xq9m1b4a3uqdcc61_26495490706760077: Meta takes the last event ID it saw on the page and appends its own counter. A genuine Pixel Manager purchase is always pmw_<order_id>, for example pmw_145741.
Turn it off. Full diagnosis, the DevTools check and a code-based alternative: Duplicate Purchase event caused by Meta's automatic event detection.
Event setup, and "Set up the selected events for me"
Under Manage Events, Meta offers to configure events for you and lists the standard events it thinks are missing. Behind that button sits the Event Setup Tool: point-and-click rules of the shape "fire a Purchase when a button containing this text is clicked".
Do not accept the offer, and close the dialog. The list of "missing" events is drawn from what Meta itself has been allowed to detect, not from what your pixel actually sends, so it is a poor picture of your setup in the first place.
Rules created that way fire directly from fbevents.js, carry no event ID and usually no value. Without an event ID, Meta cannot match them against the events the Pixel Manager sends, so every one of them is counted a second time. A Purchase rule bound to the place-order button is the worst case: it fires on every click, including the ones where the payment fails and no order is ever created.
If rules already exist, remove them under Data sources → your pixel → Settings → Event setup → Manage. The Pixel Manager (1.64.0 and higher) checks your pixel for active rules on its own and raises a card in the Opportunities tab when it finds any. Full entry: Extra events caused by Meta's Event Setup Tool rules.
Automatically include more detailed page and product info
This is Meta's microdata scraping. When it is on, fbevents.js reads Schema.org, JSON-LD and OpenGraph markup off the page and attaches what it finds to the events it sends, so a Purchase can arrive carrying a page title and whatever prices were visible on the page.
It is harmless in the sense that matters most: it never overwrites the value the Pixel Manager sends. What it does mean is that Meta records page-scraped figures next to your real ones, which is confusing to read in an export where an order worth 10.65 also carries a $57.99 scraped from a product tile.
Leave it on if your Meta catalog is fed from the pixel rather than from a product feed, because that is the mechanism keeping it up to date. Otherwise you may switch it off, since the Pixel Manager already sends complete product and value data with every event. Neither choice affects the accuracy of your conversions.
Automatic Advanced Matching
Meta's Automatic Advanced Matching lets the pixel pick up identifiers such as an email address or phone number out of form fields on the page, hash them, and send them with the event to improve the match rate.
Leave it on. The Pixel Manager's own advanced matching works from the order data rather than from the page, and the two do not conflict: Meta merges the identifiers per event.
The one reason to switch it off is a privacy policy that does not permit Meta to read what visitors type into forms, independently of what they eventually submit. That is a compliance decision, not a tracking one. Turning it off costs you nothing that the Pixel Manager sends anyway.
Conversions API Gateway
Meta's Conversions API Gateway, called OpenBridge inside the pixel configuration, is a Meta-hosted relay. It copies every event your browser pixel fires and delivers it to Meta a second time through the server channel.
It is not a substitute for, and not a complement to, the Pixel Manager's Conversions API. Because it can only mirror what the browser already sent, it contributes nothing for the orders where the browser pixel was blocked or never reached the order confirmation page, which are precisely the orders server-side tracking exists to recover. What it does contribute is a second server-side sender on one dataset and intake numbers that are hard to read.
Disconnect it under Events Manager → Settings → Integrations and keep the Pixel Manager's Conversions API. Full diagnosis, including how to recognise the 1:2 intake ratio it produces: Meta's Conversions API Gateway sends a second server event for every browser event.
Integrations left behind by other plugins
The same Events Manager → Settings → Integrations list is where connections outlive the plugins that created them. A WordPress entry from a Meta tracking plugin you have since removed is the most common one. Deactivating or deleting a plugin does not remove the connection Meta holds on its side.
Go through the list and remove anything you do not knowingly run: old tracking plugins, partner connectors, offline or CSV upload integrations, catalog connections you no longer feed. An integration for a different shop of yours, for example a Shopify store on the same Business Manager, is fine to leave as long as it points at a different dataset.
Business category event blocking
If PageView and ViewContent arrive but AddToCart, InitiateCheckout and Purchase never do, and nothing in your console or logs shows an error, check Manage data source categories and Manage event blocking under your dataset's Settings. Meta blocks conversion events for datasets it has classified into a sensitive business category, health and wellness being by far the most common. The Conversions API does not get around it, because the block sits on the data source.
This is not something to preemptively change. Full entry: Meta silently drops AddToCart, InitiateCheckout and Purchase.
Meta's Diagnostics cards
Events Manager keeps a Diagnostics list next to your dataset, and it mixes three different things behind one label: real errors, generic suggestions every advertiser sees, and findings that were true once and have not been rechecked since.
Two things to know before acting on any of them:
- They are dated, and they do not clear themselves. Every card carries a Detected date. A card whose date has not moved in weeks may be describing something you fixed long ago. After you change anything, give it a week and see whether that date moves forward before treating the card as still open. One shop spent three weeks acting on a card that Meta had detected while a Conversions API Gateway was still connected, months before the Gateway was removed.
- Some are feature suggestions, not faults. They appear on healthy datasets and stay there whatever you do.
The ones merchants running the Pixel Manager ask about most:
| Diagnostics card | What it means for you |
|---|---|
| Improve your match quality by sending more parameters | A suggestion, not a fault. The Pixel Manager already sends every matching parameter your shop actually holds for the customer. Meta lists the parameters it would like whether or not you could supply them. |
| Try the parameter builder tool | Nothing to do. It is a tool for building pixel code by hand, which is what the Pixel Manager already does for you. |
| Send missing user data parameters | The one worth a second look, but check the Detected date first. If it predates a change you made to your setup, wait a week and see whether it moves. |
| Fix price data for website Subscribe events | Not coming from the Pixel Manager. It sends no browser Subscribe event at all, and a server-side one only for the first payment of a WooCommerce subscription. It does not affect purchase reporting either way. |
What actually answers "is my tracking healthy" is not this list. It is Events Manager → your dataset → Purchase → Event deduplication, which reports your Event ID coverage for the browser and server sides (Meta's own recommended minimum is 75 %), and Event match quality, whose Additional conversions reported figure tells you whether anything is being counted twice. See How to read Meta's browser-received and server-received event counts.
How to see what is actually active on your pixel
Every one of these settings is delivered to the browser in one public file, so you can read the real state instead of trusting the toggles.
From the Pixel Manager. Open the Opportunities tab and the debug report. From version 1.64.0 the Pixel Manager checks each configured pixel for Event Setup Tool rules and for business category event restrictions, and names what it finds.
From Meta's own configuration file. Open https://connect.facebook.net/signals/config/<pixel_id> in a browser, replacing <pixel_id> with your pixel ID, and search for:
| Search for | What a hit means |
|---|---|
estRules | Event Setup Tool rules exist. Entries with "rule_status":"ACTIVE" are firing. |
iwlExtractors | Value extraction rules that scrape amounts out of the page HTML. |
openbridge | The Conversions API Gateway is connected. Confirmed by a following loadPlugin("openbridge3") and an optIn(…,"OpenBridge",true). |
restrictedEventNames | A non-empty list names the events Meta blocks for your business category. |
inferredEvents | Automatic events. A "buttonSelector":null means nothing is being fired. |
automaticMatching | Automatic Advanced Matching, with the list of match keys Meta collects. |
No hit for estRules and no hit for openbridge is the state you want.
Why these switches matter more than they look
They are stored on the dataset, not on your website. That has three consequences worth knowing:
- They apply to every site and integration that uses the pixel, not just this shop.
- They survive everything you do on the WordPress side. Deactivating a plugin, changing themes or migrating hosts leaves them exactly as they were.
- They are frequently switched on by someone else. An agency, a previous developer, or the setup wizard of a tracking plugin that was tried and removed years ago.
Changes take effect after a short propagation delay, usually minutes, once the pixel configuration cache expires.
What the Pixel Manager already sends
Nothing on Meta's side needs to fill a gap, because there is no gap:
- Every shop event, from page views to add to cart, checkout and the purchase, fires with a proper event ID and the correct value and currency.
- Browser and server-side events share one event ID per event, so Meta deduplicates them per pixel and each event is counted exactly once.
- Advanced matching identifiers are taken from the order data and hashed before they leave your server.
- The Conversions API sends once per paid order, from your server, which covers the orders where the browser pixel never got the chance.
The complete list of events: Supported events.
