Egenverk Conversion Relay · Documentation

Troubleshooting

Start with Configuration status on the Settings tab and with the log. Open it with Open the log on the Validation & log tab, or under WooCommerce → Status → Logs with the source egenverk-conversion-relay.

Where is the log?

Under WooCommerce → Status → Logs, source egenverk-conversion-relay. Errors are always logged. For more detail, choose Info + warnings + errors or Debug + all other levels as the Log level on the Settings tab.

WooCommerce has its own threshold under WooCommerce → Settings → Advanced → Logs that can hide info and debug entries even when Conversion Relay writes them. Lower it while you troubleshoot.

Nothing is measured

Check in this order:

1. Enable measurement (master switch) is on, and Enable Conversions API or Enable browser pixel is on.
2. A Pixel ID is saved.
3. A Consent adapter is selected. Otherwise the notice Conversion Relay is not measuring. Choose a consent integration under WooCommerce → Settings → Conversion Relay. appears.
4. With the WP Consent API: the WP Consent API plugin is active, otherwise Conversion Relay is not measuring. The WP Consent API plugin is not active, so marketing consent cannot be read. appears. The banner must also declare its consent type (opt-in or opt-out). Without a consent type, consent counts as unknown.
5. The browser pixel is used only when Mode is Production, and only for the events switched on under Browser events.
6. The visitor has accepted marketing. Unknown or denied consent measures nothing.
7. The page cache has been purged since the settings were last changed.

If the admin shows Conversion Relay requires WooCommerce. or a notice that Convert Relay is active, the plugin does not run at all until that is fixed.

The validation test is not confirmed

• If Validate synthetic API event cannot be pressed, it says Configure Pixel ID and API key first. Fill in both and save.
• A Pixel ID with characters other than letters, digits, hyphens and underscores is not saved, and a message says so. The same goes for an API key with spaces or control characters.
• API responded · validation unconfirmed means the API answered without an acknowledgement that could be verified. Validation could not be completed means the request failed. Check that the Pixel ID and key belong to the same data source in Ads Manager, and read the error code in the Validation log and in the log.

The notice says the API key cannot be decrypted

The saved API key can no longer be decrypted, usually because the site security keys changed. Enter the key again. This happens when the WordPress security keys (salts) are changed. Enter the key again, or define it in wp-config.php. Purchases queued before the change cannot be read either, so place fresh test orders.

Database locks shows Unavailable

The queue uses the database's named locks (GET_LOCK) so that a purchase is sent by one process only. Without them no purchases are queued, and this is logged as an error. You need MySQL or MariaDB with GET_LOCK. A database proxy that shares connections between requests must keep the same connection for the whole request.

Warning that the purchase snapshot failed

The latest purchase snapshot failed on the Validation & log tab means a purchase could not be queued. Check currency, quantity, encryption and database support: currencies outside ISO 4217 and fractional quantities are not supported. The warning clears when the next purchase is queued.

Purchases are stuck in the queue

• While the master switch or Enable Conversions API is off, purchases wait in the queue. They are sent once you switch it back on, as long as they are less than seven days old, otherwise they become Expired.
• Check that WordPress scheduled jobs run: under WooCommerce → Status → Scheduled Actions, group egenverk-conversion-relay, pending actions should not pile up.
• A purchase that could not be sent is retried with increasing delays, at most eight times and within seven days. After that it becomes Failed.
• A purchase with the status Unconfirmed is not retried automatically. Use Retry on the Delivery status tab.

Purchases are paused

Mode or Pixel ID changed after the purchases were queued. They are never sent with the new settings. Restore the setting and press Retry, or let them expire after seven days.

The test order from validation does not show in Production

That is by design. Orders from Validation mode are never resent. Place a new test order after switching to Production.

An order was not counted

• The master switch or Enable Conversions API was off when the order was paid. Such orders are not captured afterwards.
• The order is not paid yet, is on hold or its payment is not confirmed. Cash on delivery and bank transfer count once the order reaches Processing or Completed.
• The order was placed without marketing consent, or consent was refused at payment. Consent given after payment does not count.
• The order is a subscription renewal, or was excluded with the egenverk_conversion_relay_capture_order filter.
• The order was cancelled or refunded before the purchase was sent. It then gets the status Suppressed.
• The payment is more than seven days old.

A refund after the purchase was sent is not reported. Keep that in mind when you compare ad revenue with the store's.

Events are counted twice

Usually another OpenAI pixel is still in place, for example in Google Tag Manager. Conversion Relay never takes over a pixel it did not load. Remove the old pixel and its event tags, then check that the browser loads one pixel and sends one event per action.

Copies of orders made by plugins that duplicate or split orders carry the original order's link. Exclude them with the egenverk_conversion_relay_capture_order filter, see Reference.

The pixel does not load

• An ad blocker can stop the pixel. Purchases from the server are still sent.
• If the site uses a Content Security Policy, OpenAI's addresses must be allowed, see Reference.

A refusal of consent does not reach the server

The page cache and any CDN must not serve cached HTML to requests carrying the cookies wp_woocommerce_session_*, woocommerce_items_in_cart or wordpress_logged_in_*, and must pass the cookies through to PHP. WooCommerce's usual page cache exclusions do this, but check it on each site.

If the store is reached on more addresses than its home address and WordPress address, for example through several domains, add them with the egenverk_conversion_relay_allowed_origins filter, see Reference. A rejected origin is logged as a warning.

Settings changed but the store behaves as before

Pages carry the settings they were rendered with. Purge the page cache. Purge it after updating the plugin as well.