OpenAI Ads WooCommerce Conversion Tracking

How WooCommerce orders map to OpenAI Ads order_created events, including order IDs, values, browser and server events, and consent.

Last updated: 3 September 2026. Written by PixelBridge team.

WooCommerce conversion tracking for OpenAI Ads should fire order_created after the order is confirmed, not when a shopper opens checkout or adds a product to the cart. The event should carry an order identifier, a conversion value and currency where that is allowed, and a shared event ID if the same conversion is also sent through the Conversions API. Measurement consent must be granted before any browser or server event leaves the site.

What this integration is for

WooCommerce already records orders, totals, customer details and order status. OpenAI Ads measurement needs a conversion event that represents that purchase, so advertising reports can connect a paid or confirmed order with campaign activity.

PixelBridge is an independent WordPress plugin for that measurement layer. It is not an official OpenAI or WooCommerce product, and it does not create campaigns. The WooCommerce connector is one of the first planned integrations. Until it ships, nothing on this page is a working plugin feature.

For store configuration itself, start from the official WooCommerce documentation. For the advertising measurement contract, use OpenAI's Measurement Pixel docs and the Conversions API docs. Event names and required fields can change. Confirm them in official OpenAI documentation before you treat a payload as final.

How purchase tracking should work

A useful purchase event is a completed commercial action. In WooCommerce that usually means an order exists and has reached a status that your store treats as real, such as processing or completed, depending on the payment method.

The intended sequence is:

  1. The shopper completes checkout.
  2. WooCommerce creates an order and assigns an identifier.
  3. If measurement consent is granted, a browser purchase event can fire on the order-received or thank-you state.
  4. If the Conversions API is enabled, WordPress can send a matching server event after the order is confirmed in PHP.
  5. Both payloads share one event ID so OpenAI Ads measurement can treat them as one conversion.

Do not fire purchase on:

  • Product page views
  • Add to cart
  • Checkout page load
  • Failed or cancelled payments
  • Admin-created draft orders that were never placed by a customer

A page view on a product or cart URL is still a page_viewed event if you measure page views. It is not a purchase. See conversion events for how those event types differ.

Order identifiers

Every purchase event needs a stable order identifier. WooCommerce already has one: the order ID, and often a separate order number if you use a custom numbering plugin.

The identifier is useful for three jobs:

  • Debugging: you can match a measurement event to a WooCommerce order.
  • Deduplication: browser and server events can point at the same order.
  • Later operations: if refund handling is added, the original order is the join key.

Use the identifier that will not change after checkout. If your store displays a formatted order number to customers, decide whether measurement uses the internal ID or the customer-facing number, then keep that choice consistent on browser and server events.

Do not generate a new random ID on the thank-you page if a server event will also send the order ID. The two sides would no longer look like the same conversion.

Conversion values

A purchase conversion is much more useful when it includes a value and a currency. Typical sources in WooCommerce are the order total and the store currency.

Plan the value carefully:

  • Decide whether the value includes tax, shipping and fees.
  • Use the same rule on browser and server events.
  • Send the store currency, not a hardcoded fallback, unless the order itself is in another currency.
  • Do not send a value for an unpaid or failed order.

Value is not the same as revenue in your shop reports. WooCommerce totals can include discounts, refunds later, or multi-currency adjustments. OpenAI Ads measurement will only see what you send. Keep the mapping simple and document it for your team.

If consent or your privacy policy does not allow value to be sent, omit it rather than guessing. A purchase event without a value is still a conversion. A made-up value is worse than no value.

Browser events

The browser event is the client-side purchase call after the pixel has loaded. On WooCommerce, the natural place is the order-received page, after WooCommerce has rendered a successful order.

A planned browser event should wait for:

  1. The OpenAI Ads Pixel to initialize with your Pixel ID.
  2. Measurement consent, if your site requires it.
  3. Proof that this page belongs to a real order, not a generic thank-you template with no order object.

Thank-you pages are easy to get wrong. Some themes load the same template for failed payments. Some checkout plugins replace the core order-received endpoint. Some caches serve a thank-you page without order context. The integration should read the WooCommerce order object, not assume that any visit to /checkout/order-received/ is a purchase.

Browser events can be blocked by extensions, strict browsers, Content Security Policy rules or a consent banner that never grants measurement. That is why a server event is part of the design. It is a complement, not a way to ignore consent. See the OpenAI Ads Pixel for WordPress guide for how the pixel itself should load.

Server-side events

The Conversions API sends the same conversion from WordPress after the order is confirmed in PHP. That is useful when the thank-you page never loads, the shopper closes the tab, or the browser pixel is blocked.

A planned WooCommerce server event should fire from an order lifecycle hook, not from a generic wp_footer callback. The hook should represent a confirmed order. Payment methods differ: some mark the order as processing immediately, others wait for a webhook. The integration should follow the status that means "this purchase is real" for that gateway.

Server events still need:

  • The Pixel ID
  • The event name (purchase)
  • The order identifier
  • Value and currency where allowed
  • The shared event ID
  • Attribution data such as oppref when it is available
  • The same consent rule as the browser event

The plugin can send Conversions API events for the same order. Read Conversions API and the official Conversions API documentation for the current field contract.

Deduplication

If you send both a browser event and a server event for one WooCommerce order, OpenAI Ads measurement needs a way to see that they are the same action. That is a shared event ID.

The planned model is:

  1. WordPress generates or stores one event ID for the order.
  2. The browser event includes that ID.
  3. The server event includes the same ID.
  4. Both events use the same Pixel ID and event name.

Without that shared ID, a successful thank-you page plus a successful server hook can look like two purchases. With it, a blocked browser event can still leave one valid server conversion.

Do not reuse one event ID across different orders. Do not create a new ID on every page refresh of the thank-you page. The order is the unit of conversion.

Purchase tracking is still advertising measurement. If your legal setup treats that as optional, the WooCommerce integration should not load the pixel, fire a browser purchase, or send a Conversions API event until the required permission exists.

Consent is not a WooCommerce setting. It usually comes from a cookie banner or consent plugin. PixelBridge is designed to read that state rather than add a second banner. See consent.

A few WooCommerce-specific traps:

  • Checkout can complete while the banner is still unanswered.
  • Some stores grant statistics consent but not marketing or measurement consent.
  • Server events must follow the same permission as browser events. A PHP hook is not a loophole.

This page is implementation guidance, not legal advice.

Refunds

WooCommerce can refund an order in full or in part. OpenAI Ads refund or adjustment events are not supported by PixelBridge yet.

Until refund support exists:

  • Do not send a second purchase with a negative value as a workaround.
  • Do not delete the original purchase event from your own logs and assume advertising reports will follow.
  • Treat the original purchase as the conversion that was sent, then wait for a documented refund mapping.

If refund events are added later, they should reference the original order identifier and follow official OpenAI Ads measurement rules. That work is not released.

Planned setup

When the WooCommerce integration ships, the intended WordPress path is:

  1. Install PixelBridge when the plugin is available. The public listing is not live yet. See installation.
  2. Enter your OpenAI Ads Pixel ID.
  3. Enable WooCommerce purchase tracking in the plugin settings.
  4. Choose the order status that should count as a purchase for your payment methods.
  5. Decide whether browser events, server events, or both should fire.
  6. Confirm consent rules before any event is allowed.
  7. Place a test order on a staging site and check diagnostics.

Do not also paste a second purchase script into the thank-you template.

Troubleshooting

If a WooCommerce purchase does not appear in OpenAI Ads measurement, work through the problem in this order:

  1. Confirm the Pixel ID matches the advertising account.
  2. Confirm the shopper reached a confirmed order, not a checkout or failed payment screen.
  3. Grant measurement consent and retry.
  4. Check whether the thank-you page is cached without order context.
  5. Check whether a custom checkout plugin replaced the core order-received flow.
  6. If both browser and server events are planned, confirm they share an event ID.
  7. Inspect diagnostics and the troubleshooting guide.

A missing oppref value does not always mean tracking failed. It can mean the visit did not come from an OpenAI ad. See oppref attribution.

Related guides