Fix guide · Webflow · advanced · about 60 min

Meta Pixel events have no event ID on Webflow

For the finding “Meta events have no event ID”. Also for: Any website, Shopify, WordPress, Framer.

What this means

Each Meta Pixel event can carry an event ID, a unique label for that one action. Your events arrive without one.

The Meta Pixel (still often called the Facebook Pixel) sends events from the visitor’s browser; the Meta Conversions API (CAPI) sends them from a server. Whether a missing event ID costs you money depends on whether your site also sends events from a server through the Conversions API:

  • Yes, or you are not sure: the event ID is how Meta recognizes that a browser event and a server event describe the same lead or purchase. Without it, Meta cannot merge them reliably, and the same conversion may be counted twice. We report this as high when we see signs of server-side tracking for Meta.
  • No, browser pixel only: there is nothing to deduplicate yet, so we report it as low. It matters the day you add the Conversions API.

Webflow has no built-in Conversions API. On a Webflow site, server events only exist if you or a tool added them: server-side Google Tag Manager, Meta’s Conversions API Gateway, an App or automation that forwards form submissions to Meta, or your own backend. If none of these is in place, this issue can wait.

We cannot see server-to-server traffic from a browser, so we cannot tell whether your Conversions API works; we only check the browser events.

How to confirm it yourself

  1. Open your published Webflow site in a private (incognito) window, open developer tools (F12), go to Network and filter by facebook.com/tr.
  2. Accept cookies, then trigger your key events (for example submit a test lead).
  3. In each request’s payload, the event ID is the field eid. No eid means no event ID.
  4. IDs that start with ob3_plugin-set_ are set by Meta’s own pixel code, not by your site. Meta does not document whether they can be matched with Conversions API events. Your server does not know these IDs, so server events you send with your own event_id will not match them.

How to fix

Meta merges a browser event and a server event when both have the same event name and the same event ID, received within 48 hours of each other. The ID must be created once and shared by both sides; two separately generated random IDs never match.

First, check how the pixel is installed. Webflow’s built-in integration (Site settings > Apps & Integrations > Meta Pixel) has no setting for event IDs, so its PageView and its automatic ecommerce events cannot carry yours. You can still send your own events with IDs from custom code on top of it (Route 2). If your server also sends PageView or shop events, move the pixel to GTM or custom code instead and clear the Pixel ID, so you do not end up with two pixels (see “Duplicate Meta Pixel events on Webflow”).

Route 1: Google Tag Manager with server-side GTM. If your Meta Pixel runs as a GTM tag:

  1. Create a variable that produces a unique ID per event, for example Stape’s Unique Event ID variable from the Community Template Gallery.
  2. Put that variable into the event ID field of your Meta tag. In the widely used Facebook Pixel tag template by Simo Ahava, this is the Event ID field under More Settings; in a Custom HTML tag, pass it as eventID in the fourth argument of fbq.
  3. Send the same value with the server event, for example by passing it to your server-side GTM container and mapping it to event_id in the Conversions API tag.

Route 2: form leads sent to the Conversions API from a webhook or automation. Webflow can send each form submission to a webhook or to an App, and the submitted field values are included. To share one ID between the pixel and that server event:

  1. Add a text input to the form, set its Name to event_id, and hide it (for example with display: none, as in Webflow’s guide to hidden honeypot fields).

  2. Add this to Site settings > Custom code > Footer code (or the page’s Before </body> tag field). It fills the field and sends the browser Lead with the same ID:

    <script>
      document.querySelectorAll('input[name="event_id"]').forEach(function (field) {
        var id = 'lead-' + Date.now() + '-' + Math.random().toString(36).slice(2, 10);
        field.value = id;
        field.form.addEventListener('submit', function () {
          if (window.fbq) fbq('track', 'Lead', {}, { eventID: id });
        });
      });
    </script>
  3. In your server code or automation, send the Lead event to the Conversions API with event_id set to the submitted event_id value.

  4. Remove any other Lead event for the same form (a GTM tag or a thank-you page snippet), or Meta receives two browser leads.

Route 3: Meta’s Conversions API Gateway. The gateway runs in your own cloud account (for example AWS) and receives events from the pixel. Meta says the event ID is generated and passed along automatically for deduplication. After setup, use the checks below to confirm.

Route 4: an App or Conversions API tool. Many tools set matching IDs, but only for the browser events they send. If you keep a separate pixel in Webflow’s integration or custom code, its events still have no ID. Check the tool’s documentation for deduplication and remove the other pixel.

Common causes

  • The pixel runs through Webflow’s built-in integration or Meta’s standard base code, neither of which adds event IDs to your events.
  • A Conversions API setup was added later, but the browser side was never updated.
  • In GTM, the Meta tag’s event ID field is empty or uses a value the server never sees.
  • The browser and the server each generate their own ID, so the two never match.

How to verify the fix

  1. In the Network tab, every facebook.com/tr request for your key events carries an eid, and it changes between actions.
  2. In Meta Events Manager, open Data sources > your pixel or dataset > Test events and trigger the action: the tool shows which events were received and which were deduplicated. Regular reports can take 30 minutes or more to update.
  3. Re-run the check on IsPixelWorking. The issue should be gone.

Sources