--- title: "Troubleshooting — Egenverk Conversion Relay" description: "Common Conversion Relay problems and what to do, such as nothing measured, unconfirmed tests, stuck purchases, double events and caching." canonical: https://egenverk.se/en/plugins/conversion-relay/docs/troubleshooting lang: en updated: 2026-10-14 alternate: https://egenverk.se/plugins/conversion-relay/docs/felsokning.md --- # Troubleshooting Egenverk Conversion Relay · v1.7.0 · WordPress 6.5+, WooCommerce 8.2+, PHP 7.4+ · Updated 2026-10-14 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](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](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](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. ## Resources - [Product page](https://egenverk.se/en/plugins/conversion-relay) - [Changelog](https://egenverk.se/en/plugins/conversion-relay/changelog) - [Docs](https://egenverk.se/en/plugins/conversion-relay/docs) - Previous: [Data and privacy](https://egenverk.se/en/plugins/conversion-relay/docs/data-and-privacy) - Next: [Reference](https://egenverk.se/en/plugins/conversion-relay/docs/reference)