SignalBridge- Install
- One script in the site header, through a header scripts plugin or your theme
- Event ID
- Taken from the Meta Pixel call when it has one, so the browser and server copies match
- Order number
- The number in the /checkout/order-received/ URL
- Purchase value
- The Pixel call's value first, then a data layer purchase event, order structured data or the page
- Match data
- Email, phone and names typed at checkout (hashed), fbp and fbc, fbclid, IP address and user agent
- Consent
- Applies what your cookie banner passes to sb_consent
- Not covered
- Refunds, cancellations and orders created in the admin
- Avoid
- Two scripts or two Pixels on the same page
Who sends what to Meta on a WooCommerce store
The official Facebook for WooCommerce extension installs a Pixel and also sends events from your server. Its source code shows how it handles a purchase: it creates one event ID, stores it on the order, sends the server copy through the Conversions API with that ID, and injects the Pixel call on the order received page with the same ID. Meta's documentation says a browser event and a server event with the same name and ID, received within 48 hours, are deduplicated, so the extension on its own is designed to produce one purchase per order.
SignalBridge does not replace that Pixel. Its script wraps the page's fbq function, so every Pixel call passes through it. When the call carries an event ID, SignalBridge sends its server copy with that ID. When it does not, SignalBridge adds an ID to the browser call and uses the same one for the server copy. If the Pixel library is blocked in the shopper's browser, the call is still queued by the stub that Meta's snippet creates, and SignalBridge reads it from there, so a purchase can still reach Meta when the Pixel library is blocked.
That leaves two sensible setups, and the right one depends on what is already installed. They are compared below. If you keep the extension's server events and add SignalBridge for Meta, there are two server copies of one order. Meta's rule is written for a browser and server pair, so do not assume the second server copy is removed. Check it with the test order and the count comparison in this guide.
Which setup fits your store
Pick the row that describes your store today. You can change it later.
| Your store today | What to do | Why |
|---|---|---|
| Facebook for WooCommerce is connected and its Conversions API works | Keep it. Add SignalBridge for the other platforms, and connect Meta in SignalBridge only if you want its consent handling, Lead events and delivery log for Meta too | Meta already has a server copy of each purchase. A second sender adds records, not coverage |
| A Meta Pixel from Google Tag Manager or pasted code, with no server events | Connect Meta in SignalBridge and use the same dataset as the Pixel | SignalBridge becomes the only server sender and shares the Pixel call's event ID |
| No Meta Pixel on the site | Connect Meta in SignalBridge and consider adding a Pixel too | Without a Pixel, Meta receives server events only and has no browser copy to compare |
| Two Pixels or two header scripts, for example one in the theme and one in a plugin | Remove the extra copy first | Each copy sends its own event IDs and nothing links them |
What Meta receives for each WooCommerce event
SignalBridge prefers your Pixel as the source and detects the event from the page only when no Pixel reports it.
| Event | Where SignalBridge gets it | Notes |
|---|---|---|
| PageView | The Pixel's own PageView call, copied with its event ID | If the page has no Pixel, SignalBridge sends its own page view. |
| ViewContent | The Pixel call on a product page, otherwise product structured data on the page | Price and name come from the same markup search engines read. |
| AddToCart | The Pixel call, otherwise a click on a button that looks like add to cart | The click fallback is switched off whenever one of your pixels was found on the page. |
| InitiateCheckout | The Pixel call, otherwise any URL that contains /checkout | The order received page lives under /checkout/, so an InitiateCheckout can also follow each purchase. Ignore it in funnel reports. |
| Purchase | The Pixel call on the order received page, otherwise the page itself | Order number from the URL. See the next table for the value. |
| Lead | A form with an email field, such as a contact or quote form | The checkout form is not reported as a lead. |
How a purchase and its value are found
The order received page is the only place SignalBridge sees a WooCommerce purchase. When your Pixel reports it there, SignalBridge uses that call. When no pixel does, it recognises the page by a heading such as Order received, so a theme that renames the heading or puts another heading above it can hide the page. These are the value sources, from most to least reliable.
| Source | What it gives | Watch for |
|---|---|---|
| Your Pixel's Purchase call | The value, currency and the event ID the extension generated | This is the best case, because it is the number the store itself computed. |
| A data layer purchase event | Value, currency and transaction ID, if a tag manager or plugin pushes it | Used only when no Pixel call has a value. |
| Order structured data on the page | Total, currency and order number | Present only if the theme prints it. |
| The order summary on the page | The total shown in the order overview | Read from page text. A thousands separator, as in 1,234.50, can be misread. |
| Products the visitor looked at | An estimate from the prices of products viewed during the visit | Last resort. A value that is not the order total means the total was not found. |
Match data, consent and what the script cannot see
Email, phone and names come from what the shopper typed into the checkout form. SignalBridge reads those fields as the shopper types and keeps them for 30 minutes in session storage and a first-party cookie, so they are still available on the order received page. If nothing was captured, it scans the confirmation page, which shows the billing details. They are normalised and hashed before they reach Meta. The fbp and fbc values are read from the Pixel's cookies, and fbclid from the landing URL when the shopper arrived from an ad.
The script does not read your cookie banner on its own, apart from Silktide's. Your banner passes the choice by calling sb_consent(true) or sb_consent(false). Set window.SB_REQUIRE_MARKETING_CONSENT = true before the snippet if shoppers who have not chosen yet must not be tracked, because without it they are treated as allowed. After a decline, SignalBridge clears the stored identifiers and does not send that visitor's events to Meta.
There is no order feed from WooCommerce. SignalBridge does not see refunds, cancellations, manual orders or a purchase whose buyer never returns to the order received page. The page is also shown for orders that are still unpaid, such as bank transfer and cash on delivery, so a Purchase can precede payment. Compare against paid orders when you check the numbers.
Set it up
Allow about twenty minutes. Work on a staging copy first if your store uses full page caching.
Add the snippet to the header
Copy the WordPress snippet from your pixel in SignalBridge and paste it into the header section of a header scripts plugin such as WPCode, or into a theme field that prints in the head. It must load on every page, including the checkout and order received pages.
Exclude it from script delay and caching
If a speed plugin delays, combines or defers JavaScript, add the SignalBridge script to its exclusions. Keep the order received page out of full page caching, because a cached copy cannot carry the right order or the right event ID.
Find the dataset your Pixel reports to
In Meta Events Manager open the dataset whose Pixel ID matches the one on your site. SignalBridge must send to that same dataset for Meta to line the two copies up.
Connect Meta in SignalBridge
In the pixel's settings choose Facebook Ads and Connect with Facebook, approve the permissions and select the ad account and that dataset. To use a token instead, choose Manual setup and enter the Pixel ID and a Conversions API access token from Events Manager.
Connect your cookie banner
Make the banner call sb_consent(true) when a shopper accepts marketing cookies and sb_consent(false) when they decline. If you operate where consent is required, set window.SB_REQUIRE_MARKETING_CONSENT = true above the SignalBridge snippet.
Run the connection test
Copy the current Test Events code from Events Manager, paste it into the Test field of the Facebook card in SignalBridge and run the test. The event appears in the Test events tab for that code.
Test it with a real order
Place a test order
Use a low-value order with a test payment method. In the SignalBridge event stream you should see one Purchase with the WooCommerce order number, the right value and currency, and the Facebook destination marked as delivered.
Compare the event IDs
In Events Manager open Test events, repeat the order, and open the browser and the server Purchase. They should show the same event ID. If they differ, SignalBridge did not see the Pixel call, usually because of a script delay or a second Pixel.
Reload the order received page
Refresh it and confirm that no second Purchase appears. The order number in the URL is what lets a repeat be recognised.
Compare counts after a day
Compare yesterday's Meta Purchase count with your paid WooCommerce orders. A count well above your orders points to a second sender with different IDs. A count close to your orders means deduplication works.
Problems that are specific to WooCommerce
Meta shows more purchases than WooCommerce
Check for a second sender with different IDs: a second Pixel, a Pixel inside a tag manager as well as the extension, or the order received page served from cache. Compare the event IDs in Test events, then remove the extra copy.
No Purchase appears after a test order
The script may not have loaded on that page. View the page source of the order received page and look for the SignalBridge snippet. A caching or script-delay plugin is the usual cause.
The Purchase has the wrong value
Open the event and see which source supplied it. If it came from the page text or the products viewed, push a purchase event to the data layer, or let the Pixel call supply the value.
Large orders show a tiny value
A total with a thousands separator can be misread when it is taken from page text. Use a Pixel call or data layer value, and test an order above 1,000 if your orders reach that size.
The order number in SignalBridge differs from the one the customer sees
SignalBridge uses the number in the URL, which is WooCommerce's internal order ID. A sequential order number plugin changes the number shown to customers but not the URL.
Server events stop arriving after a period of working
Look for a reconnect alert in SignalBridge. An expired or revoked Meta access token is the usual cause, and delivery resumes once you connect Facebook again.
What to know before you rely on it
Where this setup stops, so the numbers you see are read correctly.
- A purchase is recorded only when the buyer reaches the order received page in a browser that runs the script.
- There are no refund, cancellation or manual order events for Meta.
- If the same page also runs a TikTok Pixel, events mirrored from the Meta Pixel go to Meta only, not to your other connected platforms.
- Event Match Quality follows what shoppers enter. A guest checkout without a phone number matches less than a returning customer.
- Meta decides attribution, so Ads Manager and SignalBridge will not agree exactly.
Questions about this setup
Do I need to remove Facebook for WooCommerce?
No. Keep it for the catalogue and its Pixel. SignalBridge reads its Pixel calls and reuses their event IDs. Only decide whether to keep both servers sending purchases to Meta, using the table above and the count check.
Which dataset should I connect?
The one whose Pixel ID is on your site. Meta documents that browser and server events must go to the same Pixel to be deduplicated.
Will it work with Google Tag Manager?
Yes. If a tag in the container fires the Meta Pixel, SignalBridge sees the call like any other. Keep one Pixel, not one in the container and one in the theme.
Does it work with block-based checkout?
The script loads on those pages too. What can differ is how the order received page prints the total, so run the test order and check the value.
What happens for shoppers who block the Pixel?
The Pixel's call is still queued by the stub in your page, so SignalBridge can send the server copy with its event ID. A shopper who blocks the SignalBridge script as well is not seen, which is why a custom domain helps.
Can SignalBridge send refunds to Meta?
No. There is no order feed from WooCommerce, and Meta has no refund event for the Pixel or the Conversions API.
Sources
The vendor documents this guide relies on. Statements about SignalBridge come from the product itself.
- Meta for Developers: Handling duplicate Pixel and Conversions API eventsThe event name plus event ID rule, the 48-hour window and the fallback.
- facebook-for-woocommerce on GitHub: events trackerHow the extension stores one event ID per order and sends it through the Pixel and the Conversions API.
- Meta Business Help Center: About event match qualityThe 0 to 10 score and the priority of each customer information parameter.