· 4 min read · IsPixelWorking team

What is ob3_plugin-set_ in Meta Pixel event IDs?

You open your browser’s developer tools, look at a Meta Pixel request and find an event ID you never set:

eid=ob3_plugin-set_87cdb4e545b5bd773960c73e042ceebe8d9d55b48ffa4f41a28fd6adf88a2e3c

Your site did not create it, and we found no explanation of the prefix in Meta’s documentation. The short answer: the Meta Pixel creates this ID itself, because your pixel is connected to a Conversions API Gateway. It is not an error and nothing malicious. Whether it helps or hurts depends on how else your site sends events to Meta.

What ob3_plugin-set_ means

We read Meta’s pixel code (fbevents.js, version 2.9, October 2026) and the settings Meta serves for real pixels. Here is what it does:

  • The ID comes from a part of the pixel called openbridge3. OpenBridge is Meta’s internal name for the Conversions API Gateway, and ob3 is short for it.
  • The pixel loads that part only when Meta’s settings for your pixel include a Gateway address. Without a Gateway, you will not see these IDs.
  • When an event leaves the browser without an event ID from your site, this part gives it one: the prefix ob3_plugin-set_ plus 64 characters. The characters are a hash of the page’s address, the time and a random number, so every event gets a new value.
  • A pixel connected to the Gateway sends each event twice, once to Meta and once to your Gateway, which forwards it to the Conversions API. Both copies carry the same ID.

That last point is the purpose. Meta’s Conversions API Gateway documentation says the event_id deduplication key is generated automatically and passed to both channels. ob3_plugin-set_ is what that looks like in practice. Because Meta does not document the prefix itself, the details may change with future pixel versions.

Two related prefixes appear in the same code. ob3_fallback-set_ is the ID the Gateway copy gets when an event reaches it with no ID at all. sgwpixel_plugin-set_ is handled the same way as ob3_plugin-set_ and appears to belong to Meta’s newer Signals Gateway. We have not seen either one on a real site yet.

How common it is

In our October 2026 scan of 387 websites, 159 sent Meta Pixel events. On 33 of them, about one in five, those events carried ob3_plugin-set_ IDs. We then checked the settings Meta serves for each pixel. All 35 pixels that sent these IDs had a Conversions API Gateway connected, hosted on AWS, Google Cloud or through a hosting partner. A control group of 40 pixels without these IDs had none.

Does it break deduplication?

Meta merges a browser event and a server event when both have the same event name and the same event ID. How that works out for you depends on your setup.

You only use the Gateway. Nothing to fix. The generated ID is how Meta matches the browser copy with the Gateway copy.

You also send events from your own server. This is the case to watch. You might use a plugin, server-side Google Tag Manager or custom code for the Conversions API, while a Gateway is still connected from an earlier setup. Your server knows nothing about the ob3_plugin-set_ IDs, so its event_id never matches them. Meta cannot merge your server’s copy with the browser copy, and the same purchase may be counted twice.

You can fix this in two ways:

  • Keep one server-side sender per pixel. If your own Conversions API setup covers the events, disconnect the Gateway, or the other way round.
  • Give your events your own ID. When your site passes an eventID in the pixel call, Meta’s code uses it instead of the generated one, and the Gateway copy carries your ID too. Send the same value as event_id from your server, and all copies share one ID. Our post on event IDs and deduplication shows how to set them up.

You see both kinds of ID on one page. That is normal. If your site sets IDs on its own events, those keep your IDs. Events the pixel sends by itself, such as SubscribedButtonClick for button clicks, get ob3_plugin-set_ IDs. We saw this mix on a few shops in the scan.

Not every event gets one

The Gateway can be set to skip some events, and events it skips get no generated ID. On some sites in our scan, one event left without an ID while other events from the same pixel had one, in both directions: a page view without and a button click with, or the reverse. We do not know the reason in each case. So look at several events before you decide what your setup does.

If you did not know you had a Gateway

Someone connected it: a developer, an agency or a hosting partner. The Gateway runs on a cloud account, and Meta says its only cost is the cloud resources or partner fees. That is worth knowing for two reasons. You may be paying for it, and it may be sending the same events as a newer setup. Ask whoever manages your Events Manager which Conversions API connections your pixel has before you add another one.

Check your own setup

  1. Open your site in a private window, open developer tools on the Network tab and filter by facebook.com/tr.
  2. Trigger the events you care about and look at the eid field of each request.
  3. If it starts with ob3_plugin-set_, your pixel uses a Conversions API Gateway. If it is your own value, your site sets the IDs. If there is no eid, the event has no ID. Our event ID guide explains when that matters.

The free IsPixelWorking check runs these steps for you. It shows the event IDs your pixel sends and whether the same event goes out twice.

More from the blog

Check your own pixel. Paste a landing page and see what it sends to Meta before and after consent. Free, about a minute.

Check a page